6 ms·

I know nothing about Bazel, but I've never understood the JVM community's obsession with getting off Maven. My experience of Gradle is Gradle projects require

by bedobi 6y ago

I know nothing about Bazel, but I've never understood the JVM community's obsession with getting off Maven. My experience of Gradle is Gradle projects require a PhD in Gradle AND intimate familiarity with the tastes of whoever implemented that particular project .gradle files likes to use it. Is Bazel like that too? When we inherit codebases from other teams, often one of the first things we do is convert it from Gradle to Maven. I honestly couldn't care less about how flexible and powerful Gradle or Bazel or some other build tool is compared to Maven. Maven is simple, the same in every project (this is huuuuuge), just works and gets out the way.

Freak_NL 6y ago
> […] the same in every project (this is huuuuuge) […] Hard to overstate how useful that is. Configuring something in a Maven build may be verbose or sometimes hard, but most of the time the build just does its thing, and all developers know at least `mvn clean install`.
- brown9-2 6y ago
  One of the main goals of the project was “convention over configuration” and it succeeded well at that.
utf_8x 6y ago
Exactly. You could have a million line pom.xml and you'd still most likely just need `mvn clean package` to get a usable JAR. XML is a nasty format but it just works...
Traubenfuchs 6y ago
Maven is one of the most stable and "good enough" tools there is -which is why a significant part of software engineers hate it. If you enjoy using gradle for its customizability and flexibility and power -you are doing it wrong. You have created an overengineered monster I would dread to work with. I don't want to learn groovy, I want to develop applications.
- chii 6y ago
  > which is why a significant part of software engineers hate it. i used to hate maven - i was a big fan of Ant. But as time went on, i saw how useful maven was. Being _exactly_ the same in every project, requiring the same project file structure, requiring the same build steps, and the same build commands, etc. People who own projects seem to believe their project's build is special and require custom stuff to make it work. It rarely is actually the case. Just shoehorn your project into maven.
pas 6y ago
Bazel's selling point is that it's designed to be integrated into various pipelines, handling complexity (multiple languages, platforms, targets, etc) AND being fast (cache what you can, so incremental builds are first class things). Of course under the hood it's just a very complicated 'make', like every build tool is. This likely just means unnecessary complexity for a simple Java project where the development just happens in IDEA (or Eclipse or even NetBeans) and the IDE builds and checks everything, and ... at release time someone just builds a package and it's done. But in case of a project with a lot of services, dependencies, there's arguably some advantage to setting up Bazel to help with development. (Though the build/bzl files all look ugly and unintuitive, a bit like CMake :[ )
- skinkestek 6y ago
  Does it encourage every team and every dev to create their own custom config that takes two hours to figure out like Gradle, or is it more like Maven where you only specify anything that isn't bog standard?
  - foota 6y ago
    It's very standardized. I don't have any experience with using it with things outside a Java binary, but for that use case you basically have no choice but a number of java_library rules and a java_binary. E.g., a simple project with no outside deps might be like (and I typed this out on my phone): java_binary(name = "grep_bin", srcs = ["grep_main.java"], deps=["grep_lib"]) java_library(name="grep_lib", srcs =["grep_lib.java"]) Things get more opinionated when you pull in outside libraries, but even then bazel makes it fairly painless and integrates with other build systems where needed. Take a look at the docs here for more info: https://docs.bazel.build/versions/master/be/java.html https://docs.bazel.build/versions/master/be/java.html
  - pas 6y ago
    It has support for many languages (called rules [0]) and it has support for many tools for that specific language ecosystem. For example the Scala rules have specs2 (a unit testing lib/harness/framework/thing) [1] I have no idea how this all works in practice. [0] https://github.com/bazelbuild/bazel/blob/master/site/docs/rules.md#rules https://github.com/bazelbuild/bazel/blob/master/site/docs/ru... [1] https://github.com/bazelbuild/rules_scala/blob/master/examples/testing/specs2_junit_repositories/example/BUILD https://github.com/bazelbuild/rules_scala/blob/master/exampl...
skinkestek 6y ago
> Maven is simple, the same in every project (this is huuuuuge), just works and gets out the way. Recently tried to find the correct and canonical way to set up a new, small spring boot project for a customer. No one could tell me how: "we just use spring initializr and copy the relevant files" From where? Uh, oh. So I tried to find a canonical solution. Did some research. At least 14 variants..! No clear winner. Nobody really understands it it sees but at least they don't have to use the dreaded Maven. (For those who don't know, Mavens main disadvantage is that it is written in xml. Since Maven files frequently gets over 30 lines long - especially if people don't know what they are doing - and (parent projects) needs to be updated twice a month on average because of updates to dependencies this is a living nightmare to some people ;-) Might contain traces of both sarcasm, irony, exaggerations and other literary tools. Those who get it, feel free to laugh. Those who don't: After ~15 years in the field I've not seen anything working as well as Maven on the kind of projects and teams I work on and I also don't think I've seen any other project getting as much undeserved flak.
- twic 6y ago
  > Mavens main disadvantage is that it is written in xml I would say that this is Maven's most obvious disadvantage. Its main disadvantage is its inflexibility. I'm working on a little library right now that is sort of a facade for two possible backend libraries. Some code is shared, some depends on backend A, some on backend B. I want to separate the three kinds of source code, compile and test each against the correct dependencies (none, A, or B), and then put all the class files in one jar file. In Gradle i would define some extra configurations for the A and B sides, then customise the standard jar task to include their output. What would i do in Maven? My Maven knowledge is pretty out of date, but i think the Maven answer would be "don't do that, create three modules and build and publish three artifacts". Or, to put it another way "our tool can't do that, so you should make life worse for your users, but we're going to insist that our way is actually the proper way to do it, for mysterious quasi-mystical reasons".
  - vips7L 6y ago
    > What would i do in Maven? Typically customization of maven goals is done via profiles. You can modify the configuration of the plugins depending on which profile is active. Though I'm obviously not sure if it will solve your problem without knowing exact details.
nimrody 6y ago
Maven just hides the complexity in its plugins which are implemented in Java. If you don't need any plugin - then, yes, it's simple. But once you need specialized plugins it's no better than gradle/bazel. The latter two lets you add some logic in the build scripts - so at least it's visible to users. If you need special functionality in Maven you have to write a plugin or gather a few plugins. And when it breaks down (as all tools do) -- it's difficult to find the code and understand the problems.
- krzyk 6y ago
  Writing Maven plugins is quite easy and doesn't require you to learn another language (like in case of gradle, you have to know groovy).
  - tn1 6y ago
    At least with Groovy, most Java programs are also valid groovy programs (the converse is not true, but not too different).
    - krzyk 6y ago
      Yes, but with groovy you get magnitude slower compilation time, less efficient autocomplete. And a language that has sometimes strange design choices. Groovy is like PHP, if I need to upgrade from Java it would be Scala. At least I get a superior language for also magnitude slower builds.
      - tn1 6y ago
        Gradle has a Kotlin Script build script option these days too. I haven't tried it yet, so I'm not sure if it's any better.
krzyk 6y ago
> My experience of Gradle is Gradle projects require a PhD in Gradle AND intimate familiarity with the tastes of whoever implemented that particular project .gradle files likes to use it. Is Bazel like that too? This, I was quite happy to try out gradle when it appeared and when I read few tutorials it came to be: This is just Ant all over again, but this time instead of xml I get groovy. Maven does one thing great: It forces you to use their build steps and every project has exactly the same steps. Gradle is like Ant or CMake.
psychiatrist24 6y ago
Yeah, my first thought "another build manager to worry about" - it's already annoying that some projects use Gradle, which I don't want to have to learn.
MaxBarraclough 6y ago
> My experience of Gradle is Gradle projects require a PhD in Gradle AND intimate familiarity with the tastes of whoever implemented that particular project .gradle files likes to use it. In the C++ world we have exactly the same problem with CMake.
- rualca 6y ago
  > In the C++ world we have exactly the same problem with CMake. "Modern cmake" (i.e., target-based projects made possible since the release of cmake v3.0) is terribly easy and straight-forward, provided that your devteam understands the need to stay in their lane. project(), add_executable()/add_library(), target_include_directories(), set_target_properties(), and add_directory(). This gets any MVP working, and any project 95% where they need to be. Add in set() to define helper cars like proj_SOURCES, proj_HEADERS, and proj_INTERFACES, and option() to get fancy cacheable settings. Cmake only becomes a problem if devteams have no idea on how to write simple code, and can't help themselves turning any hello world into a big bowl of spaghetti code. You don't need functions or macros or anything at all, unless you want to waste time feeling smart for writing towers of hanoi in cmake, or shoving square pegs into round holes. In spite of having about a decade of experience with cmake projects under my belt, the only place I ever defined functions in cmake was to add boilerplate code to add unit tests to crest by just passing the source file name, and even that was not worth the trouble. You can write stuff as convoluted and unmaintainable as you'd like, but that's on you, not the tool.
  - MaxBarraclough 6y ago
    > You can write stuff as convoluted and unmaintainable as you'd like, but that's on you, not the tool. In this case, it's also on the tool. CMake is a bad tool. Unfortunately it's the least bad one available for that task. I've rambled on this topic before. [0][1] My most recent adventure with CMake was with its SWIG support. This was as painful and error-prone as everything else in CMake, and I've used CMake for years. [0] https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172 [1] https://news.ycombinator.com/item?id=24565266 https://news.ycombinator.com/item?id=24565266
MrBuddyCasino 6y ago
Also, IDE integration works a lot better. IntelliJ with Maven is a joy, with Gradle its a dog-slow shit-show.
vbezhenar 6y ago
Gradle have sane multi project management. Maven is very strange in that regard. Another issue with Maven is kind of hacky configuration for Kotlin build. For single project Java build Maven is my favourite tool.
AzzieElbab 6y ago
“ but I've never understood the JVM community's obsession with getting off Maven” XML - if for whatever reason you decide to make a good product unpopular, just add XML
AtlasBarfed 6y ago
Maven issues: XML. Ugh, the XML. The backing company was a bit too eager to sell artifact repository software. The lingo was pointlessly obscure (coordinates? artifacts? "project object model"?) It didn't offer a couple key options (local jars without an artifact repository) so it was too inflexible. Gradle did fly off the handle too quickly, breaks wayyy too much stuff with each release, has way too many releases and examples that don't work anymore... but on the other hand you can usually cobble together what you want from a couple sample builds and some stackoverflow. What the JVM community probably needed was a YAML-based Maven with a bit more flexibility than maven provided.

by bedobi 6y ago

Freak_NL 6y ago

> […] the same in every project (this is huuuuuge) […] Hard to overstate how useful that is. Configuring something in a Maven build may be verbose or sometimes hard, but most of the time the build just does its thing, and all developers know at least `mvn clean install`.

brown9-2 6y ago
One of the main goals of the project was “convention over configuration” and it succeeded well at that.

utf_8x 6y ago

Exactly. You could have a million line pom.xml and you'd still most likely just need `mvn clean package` to get a usable JAR. XML is a nasty format but it just works...

Traubenfuchs 6y ago

Maven is one of the most stable and "good enough" tools there is -which is why a significant part of software engineers hate it. If you enjoy using gradle for its customizability and flexibility and power -you are doing it wrong. You have created an overengineered monster I would dread to work with. I don't want to learn groovy, I want to develop applications.

chii 6y ago
> which is why a significant part of software engineers hate it. i used to hate maven - i was a big fan of Ant. But as time went on, i saw how useful maven was. Being _exactly_ the same in every project, requiring the same project file structure, requiring the same build steps, and the same build commands, etc. People who own projects seem to believe their project's build is special and require custom stuff to make it work. It rarely is actually the case. Just shoehorn your project into maven.

pas 6y ago

Bazel's selling point is that it's designed to be integrated into various pipelines, handling complexity (multiple languages, platforms, targets, etc) AND being fast (cache what you can, so incremental builds are first class things). Of course under the hood it's just a very complicated 'make', like every build tool is. This likely just means unnecessary complexity for a simple Java project where the development just happens in IDEA (or Eclipse or even NetBeans) and the IDE builds and checks everything, and ... at release time someone just builds a package and it's done. But in case of a project with a lot of services, dependencies, there's arguably some advantage to setting up Bazel to help with development. (Though the build/bzl files all look ugly and unintuitive, a bit like CMake :[ )

skinkestek 6y ago
Does it encourage every team and every dev to create their own custom config that takes two hours to figure out like Gradle, or is it more like Maven where you only specify anything that isn't bog standard?
- foota 6y ago
  It's very standardized. I don't have any experience with using it with things outside a Java binary, but for that use case you basically have no choice but a number of java_library rules and a java_binary. E.g., a simple project with no outside deps might be like (and I typed this out on my phone): java_binary(name = "grep_bin", srcs = ["grep_main.java"], deps=["grep_lib"]) java_library(name="grep_lib", srcs =["grep_lib.java"]) Things get more opinionated when you pull in outside libraries, but even then bazel makes it fairly painless and integrates with other build systems where needed. Take a look at the docs here for more info: https://docs.bazel.build/versions/master/be/java.html https://docs.bazel.build/versions/master/be/java.html
- pas 6y ago
  It has support for many languages (called rules [0]) and it has support for many tools for that specific language ecosystem. For example the Scala rules have specs2 (a unit testing lib/harness/framework/thing) [1] I have no idea how this all works in practice. [0] https://github.com/bazelbuild/bazel/blob/master/site/docs/rules.md#rules https://github.com/bazelbuild/bazel/blob/master/site/docs/ru... [1] https://github.com/bazelbuild/rules_scala/blob/master/examples/testing/specs2_junit_repositories/example/BUILD https://github.com/bazelbuild/rules_scala/blob/master/exampl...

skinkestek 6y ago

> Maven is simple, the same in every project (this is huuuuuge), just works and gets out the way. Recently tried to find the correct and canonical way to set up a new, small spring boot project for a customer. No one could tell me how: "we just use spring initializr and copy the relevant files" From where? Uh, oh. So I tried to find a canonical solution. Did some research. At least 14 variants..! No clear winner. Nobody really understands it it sees but at least they don't have to use the dreaded Maven. (For those who don't know, Mavens main disadvantage is that it is written in xml. Since Maven files frequently gets over 30 lines long - especially if people don't know what they are doing - and (parent projects) needs to be updated twice a month on average because of updates to dependencies this is a living nightmare to some people ;-) Might contain traces of both sarcasm, irony, exaggerations and other literary tools. Those who get it, feel free to laugh. Those who don't: After ~15 years in the field I've not seen anything working as well as Maven on the kind of projects and teams I work on and I also don't think I've seen any other project getting as much undeserved flak.

twic 6y ago
> Mavens main disadvantage is that it is written in xml I would say that this is Maven's most obvious disadvantage. Its main disadvantage is its inflexibility. I'm working on a little library right now that is sort of a facade for two possible backend libraries. Some code is shared, some depends on backend A, some on backend B. I want to separate the three kinds of source code, compile and test each against the correct dependencies (none, A, or B), and then put all the class files in one jar file. In Gradle i would define some extra configurations for the A and B sides, then customise the standard jar task to include their output. What would i do in Maven? My Maven knowledge is pretty out of date, but i think the Maven answer would be "don't do that, create three modules and build and publish three artifacts". Or, to put it another way "our tool can't do that, so you should make life worse for your users, but we're going to insist that our way is actually the proper way to do it, for mysterious quasi-mystical reasons".
- vips7L 6y ago
  > What would i do in Maven? Typically customization of maven goals is done via profiles. You can modify the configuration of the plugins depending on which profile is active. Though I'm obviously not sure if it will solve your problem without knowing exact details.

nimrody 6y ago

Maven just hides the complexity in its plugins which are implemented in Java. If you don't need any plugin - then, yes, it's simple. But once you need specialized plugins it's no better than gradle/bazel. The latter two lets you add some logic in the build scripts - so at least it's visible to users. If you need special functionality in Maven you have to write a plugin or gather a few plugins. And when it breaks down (as all tools do) -- it's difficult to find the code and understand the problems.

krzyk 6y ago
Writing Maven plugins is quite easy and doesn't require you to learn another language (like in case of gradle, you have to know groovy).
- tn1 6y ago
  At least with Groovy, most Java programs are also valid groovy programs (the converse is not true, but not too different).
  - krzyk 6y ago
    Yes, but with groovy you get magnitude slower compilation time, less efficient autocomplete. And a language that has sometimes strange design choices. Groovy is like PHP, if I need to upgrade from Java it would be Scala. At least I get a superior language for also magnitude slower builds.
    - tn1 6y ago
      Gradle has a Kotlin Script build script option these days too. I haven't tried it yet, so I'm not sure if it's any better.

krzyk 6y ago

> My experience of Gradle is Gradle projects require a PhD in Gradle AND intimate familiarity with the tastes of whoever implemented that particular project .gradle files likes to use it. Is Bazel like that too? This, I was quite happy to try out gradle when it appeared and when I read few tutorials it came to be: This is just Ant all over again, but this time instead of xml I get groovy. Maven does one thing great: It forces you to use their build steps and every project has exactly the same steps. Gradle is like Ant or CMake.

psychiatrist24 6y ago

Yeah, my first thought "another build manager to worry about" - it's already annoying that some projects use Gradle, which I don't want to have to learn.

MaxBarraclough 6y ago

rualca 6y ago
> In the C++ world we have exactly the same problem with CMake. "Modern cmake" (i.e., target-based projects made possible since the release of cmake v3.0) is terribly easy and straight-forward, provided that your devteam understands the need to stay in their lane. project(), add_executable()/add_library(), target_include_directories(), set_target_properties(), and add_directory(). This gets any MVP working, and any project 95% where they need to be. Add in set() to define helper cars like proj_SOURCES, proj_HEADERS, and proj_INTERFACES, and option() to get fancy cacheable settings. Cmake only becomes a problem if devteams have no idea on how to write simple code, and can't help themselves turning any hello world into a big bowl of spaghetti code. You don't need functions or macros or anything at all, unless you want to waste time feeling smart for writing towers of hanoi in cmake, or shoving square pegs into round holes. In spite of having about a decade of experience with cmake projects under my belt, the only place I ever defined functions in cmake was to add boilerplate code to add unit tests to crest by just passing the source file name, and even that was not worth the trouble. You can write stuff as convoluted and unmaintainable as you'd like, but that's on you, not the tool.
- MaxBarraclough 6y ago
  > You can write stuff as convoluted and unmaintainable as you'd like, but that's on you, not the tool. In this case, it's also on the tool. CMake is a bad tool. Unfortunately it's the least bad one available for that task. I've rambled on this topic before. [0][1] My most recent adventure with CMake was with its SWIG support. This was as painful and error-prone as everything else in CMake, and I've used CMake for years. [0] https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172 [1] https://news.ycombinator.com/item?id=24565266 https://news.ycombinator.com/item?id=24565266

MrBuddyCasino 6y ago

Also, IDE integration works a lot better. IntelliJ with Maven is a joy, with Gradle its a dog-slow shit-show.

vbezhenar 6y ago

Gradle have sane multi project management. Maven is very strange in that regard. Another issue with Maven is kind of hacky configuration for Kotlin build. For single project Java build Maven is my favourite tool.

AzzieElbab 6y ago

“ but I've never understood the JVM community's obsession with getting off Maven” XML - if for whatever reason you decide to make a good product unpopular, just add XML

AtlasBarfed 6y ago

Maven issues: XML. Ugh, the XML. The backing company was a bit too eager to sell artifact repository software. The lingo was pointlessly obscure (coordinates? artifacts? "project object model"?) It didn't offer a couple key options (local jars without an artifact repository) so it was too inflexible. Gradle did fly off the handle too quickly, breaks wayyy too much stuff with each release, has way too many releases and examples that don't work anymore... but on the other hand you can usually cobble together what you want from a couple sample builds and some stackoverflow. What the JVM community probably needed was a YAML-based Maven with a bit more flexibility than maven provided.