Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bazel Release 1.0

github.com

Post reply on HN
Print view View original

111–120 of 180 posts

Re: Bazel Release 1.0

#111

Post by jingwen »

oweiler wrote: post #109
mrighele wrote: post #77

Earlier quoted context omitted.

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

I think for Java projects Bazel is a very bad choice. Last time I've checked it was not even able to resolve dependencies transitively. And I doubt that it's faster than recent versions of Gradle.

The Bazel team published official rules for managing transitive dependencies from Maven: https://github.com/bazelbuild/rules_jvm_external

There are also community created solutions like https://github.com/johnynek/bazel-deps, and https://github.com/square/bazel_maven_repository.

Disclosure: I maintain rules_jvm_external.

Re: Bazel Release 1.0

#112

Post by hsivonen »

How’s Bazel documentation these days for people who haven’t worked at Google?

In April 2018, I tried to do a quick port of a tiny gsl::span-using toy app to absl::span, but I gave up, because Abseil wanted me to build my app using Bazel and Bazel docs seemed to assume that I already have some context that Googlers would have but I hadn’t.

(I emphasize that this was a _quick_ attempt at a toy program and not about making a serious time investment to learn a tool for a serious project.)

Re: Bazel Release 1.0

#114

Post by ceronman »

mrighele wrote: post #77
habitue wrote: post #35

Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0). The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplem…

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

I've worked with both and while Bazel definetely has a learning curve, mostly because is very different than Maven and Gradle, I actually find it considerably simpler than those two. Maven dependency management is really complex, and I'm tired of dealing with dependency hell. And Gradle doubles down on Maven complexity where you stop having declarative XML config and instead have actual Groovy/Kotlin programs.

So, please consider the difference between complex and unfamiliar.

Re: Bazel Release 1.0

#115

Post by swsieber »

oweiler wrote: post #109
mrighele wrote: post #77

Earlier quoted context omitted.

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

I think for Java projects Bazel is a very bad choice. Last time I've checked it was not even able to resolve dependencies transitively. And I doubt that it's faster than recent versions of Gradle.

I very much doubt that it's faster than Gradle, but Gradle does do quite a bit more than Gradle.

Re: Bazel Release 1.0

#116

Post by ceronman »

oweiler wrote: post #109
mrighele wrote: post #77

Earlier quoted context omitted.

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

I think for Java projects Bazel is a very bad choice. Last time I've checked it was not even able to resolve dependencies transitively. And I doubt that it's faster than recent versions of Gradle.

For a mono-repo setup I find Bazel much better than those two. If you have few hundred projects or more, Maven is a pretty bad choice. Gradle is slightly better, but still much slower than Bazel.

But it's not just speed, Bazel does do true CI: you make a change in a a lib and then you can immediately compile and run tests on anything that depends on that directly or indirectly. I have not been able to do that with Gradle, forget about Maven.

Finally, if you use other languages, with shared artifact such as protobuf files, Bazel is simply amazing: change a proto file and recompile everything that depends on that on every language.

Re: Bazel Release 1.0

#117

Post by maximente »

mrighele wrote: post #77
habitue wrote: post #35

Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0). The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplem…

What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is supposed to be faster but on the other side last time i checked it it was much more complex and time consuming (expecially compared to Maven). Are there other good reasons?

my organization's goals for java builds are consistency (we want to be able to build deterministic jars), reliability, and playing nicely with IDEs via tooling.

given that, as far as i can tell, there's nothing so compelling that it's worth switching over your project or organization. the tooling around maven is so good, and the inertia so strong (for my organization anyway), that there's no real incentive to switch.

we've found that non-maven developers grumble a lot when forced to use it but then find the system, while verbose, is really solid. we are certainly not willing to throw that all away to play with google's latest cool thing.

Re: Bazel Release 1.0

#118

Post by Quekid5 »

lhorie wrote: post #102
Quekid5 wrote: post #100

Earlier quoted context omitted.

Just trying to understand... so we would have ~5 (going by my original example figure) Bazel builds and then use "imports of published things" to have projects that depend on each other work?

You would have 5 workspaces. How they work together is sort of up to you. If you use `local_repository`, then you can link whatever's checked out from version control together. This can be dangerous since there's nothing that enforces what version of what works with what, but it's helpful for example, if you want to beta test a new version of a ruleset in a workspace that consumes it. If you want to be strict about p…

Thanks. Things may have changed since the last time I investigated Bazel -- I'll read up on this stuff.

I'm actually currently leaning towards something like Nix or Guix just because it really encompasses everything...

Re: Bazel Release 1.0

#119

Post by mdaniel »

lhorie wrote: post #82
gfunk911 wrote: post #34

Earlier quoted context omitted.

What helped you push through the steep learning curve when you started? Asking cause I was excited recently to try Bazel specifically for a Typescript monorepo, and the learning curve crushed me.

I started by going through the Java tutorial[1] to get a feel for it. It's fairly approachable and you don't actually need any Java knowledge. Once you familiarize yourself with the concept of rules and targets, you can follow the instructions for whichever ruleset you want to use. The official one for JS is rules_nodejs[2] Another thing that really helped me cement my understanding of Bazel was to deep dive into Sta…

Give the title of this thread, don't you mean https://docs.bazel.build/versions/1.0.0/tutorial/java.html ?
Post reply on HN