4 ms·

Looks to be a lot of useful experience summarised here. I've just skimmed parts so far, but will come back and read more as time allows. > https://github.com/b

Looks to be a lot of useful experience summarised here. I've just skimmed parts so far, but will come back and read more as time allows. > https://github.com/binkley/modern-java-practices#keep-your-build-fast https://github.com/binkley/modern-java-practices#keep-your-b... It boggles my mind that in this day in age, Maven still recompiles everything if you touch anything. The problem of figuring out what files need to be built and building only them was solved for C in I think the late 70s (makedepend). I don't know if Gradle is better in this respect. (It certainly can't be worse.)

bitcharmer 3y ago
Maven does not recompile everything each time. You have to do mvn clean to force it to. If you change a single class just that one class gets recompiled which is evident by Maven's output.
- fiddlerwoaroof 3y ago
  Yeah, although my experience is that people collect shell aliases and similar workflows that always do something like `mvn clean package` and then complain about build times.
  - sverhagen 3y ago
    Also, while I love Maven, I don't run it very often (or at least not directly on the command line). Most work happens in IntelliJ, and then I'll let the build server deal with it. Builds are short, so no harm if the build server fails and I have to fix something up...
- Calzifer 3y ago
  Depends on how you interpret 'everything' and 'each time'. The default compiler plugin configuration is quite eager to recompile allot if something changed. https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#useIncrementalCompilation https://maven.apache.org/plugins/maven-compiler-plugin/compi... "true (default) in this mode the compiler plugin determines whether [...] any source file was added, removed or changed since the last compilation. If this is the case, the compiler plugin recompiles _all_ sources.
iainmerrick 3y ago
I don't know if Gradle is better in this respect. (It certainly can't be worse.) Every Gradle project I’ve worked on has had non-deterministic builds where you sometimes need to manually clean and rebuild to fix it, and still does unnecessary work every time. I think it’s worse.
- zelos 3y ago
  This has got better with more recent Gradle versions, at the expense of stricter checks about task output directories.
- mike_hearn 3y ago
  I don't like Gradle much, but I have to defend it here. Gradle uses a proper task graph with cached incremental builds, out of the box. The only way to break this is if you add your own task types that don't follow their rules, which as a sibling comment observes, is something they've been tightening up in recent releases. Now it is too easy to break those rules and end up with weird problems, and that is a valid criticism of Gradle. But it's also one they're fixing. One of the reasons Gradle is so prevalent over Maven, especially at large companies, is because Gradle scales drastically better and has far better performance for large projects. A Maven project with hundreds of modules will become impractical quickly due to its lack of a proper task graph and poor support for incremental compilation. Gradle can handle this easily. The other reason Gradle has become so widespread is because the path for creating custom tasks is far smoother. Often in build systems you need to define ad-hoc tasks, which may grow over time into more powerful collections of build logic. This is easier and less verbose in Gradle than in Maven, which goes straight from declarative to "write everything as plain Java on your own" really fast. As a result of that there are tons of Gradle plugins available for different features and frameworks, and they are much easier to find. Gradle just has a bigger ecosystem and that means collectively it has a lot of features, which is hard to compete with. In fact, there are many frameworks that can only be used via Gradle for this reason. I've spent a lot of time studying how to make a build system that can compete well with Gradle and despite the product's obvious flaws, it's not as easy to beat as you might think.
  - 3y ago
jvmboi 3y ago
It's been a while since I used maven but if I recall correctly the reason for that is that javac (java compiler) actually doesn't do incremental compilation. It was such a problem that eclipse (the ide) had it's own java compiler that could do incremental compilation. This alternative compiler was so popular that you could even use it in Jetbrains IDE and I think you could configure maven to use it to get incremental compilation there to.
- akoboldfrying 3y ago
  Eclipse's own compiler is (impressively!) able to do truly incremental compilation: compiling the syntactically correct subset of methods in source files that aren't fully syntactically correct, and not bothering to recompile untouched methods. javac will compile every file you tell it to, plus any out-of-date immediate dependencies (and their out-of-date immediate dependencies, and so on, recursively), but if A uses B which uses C and you change C.java only, `javac A.java` doesn't "see" that all 3 need recompilation. Maven doesn't even offer javac's incomplete dependency checking by default, though I believe it can be forced to. (0.5 points for correctness over efficiency, I suppose.)

bitcharmer 3y ago

Maven does not recompile everything each time. You have to do mvn clean to force it to. If you change a single class just that one class gets recompiled which is evident by Maven's output.

fiddlerwoaroof 3y ago
Yeah, although my experience is that people collect shell aliases and similar workflows that always do something like `mvn clean package` and then complain about build times.
- sverhagen 3y ago
  Also, while I love Maven, I don't run it very often (or at least not directly on the command line). Most work happens in IntelliJ, and then I'll let the build server deal with it. Builds are short, so no harm if the build server fails and I have to fix something up...
Calzifer 3y ago
Depends on how you interpret 'everything' and 'each time'. The default compiler plugin configuration is quite eager to recompile allot if something changed. https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#useIncrementalCompilation https://maven.apache.org/plugins/maven-compiler-plugin/compi... "true (default) in this mode the compiler plugin determines whether [...] any source file was added, removed or changed since the last compilation. If this is the case, the compiler plugin recompiles _all_ sources.

iainmerrick 3y ago

I don't know if Gradle is better in this respect. (It certainly can't be worse.) Every Gradle project I’ve worked on has had non-deterministic builds where you sometimes need to manually clean and rebuild to fix it, and still does unnecessary work every time. I think it’s worse.

zelos 3y ago
This has got better with more recent Gradle versions, at the expense of stricter checks about task output directories.
mike_hearn 3y ago
I don't like Gradle much, but I have to defend it here. Gradle uses a proper task graph with cached incremental builds, out of the box. The only way to break this is if you add your own task types that don't follow their rules, which as a sibling comment observes, is something they've been tightening up in recent releases. Now it is too easy to break those rules and end up with weird problems, and that is a valid criticism of Gradle. But it's also one they're fixing. One of the reasons Gradle is so prevalent over Maven, especially at large companies, is because Gradle scales drastically better and has far better performance for large projects. A Maven project with hundreds of modules will become impractical quickly due to its lack of a proper task graph and poor support for incremental compilation. Gradle can handle this easily. The other reason Gradle has become so widespread is because the path for creating custom tasks is far smoother. Often in build systems you need to define ad-hoc tasks, which may grow over time into more powerful collections of build logic. This is easier and less verbose in Gradle than in Maven, which goes straight from declarative to "write everything as plain Java on your own" really fast. As a result of that there are tons of Gradle plugins available for different features and frameworks, and they are much easier to find. Gradle just has a bigger ecosystem and that means collectively it has a lot of features, which is hard to compete with. In fact, there are many frameworks that can only be used via Gradle for this reason. I've spent a lot of time studying how to make a build system that can compete well with Gradle and despite the product's obvious flaws, it's not as easy to beat as you might think.
- 3y ago

jvmboi 3y ago

It's been a while since I used maven but if I recall correctly the reason for that is that javac (java compiler) actually doesn't do incremental compilation. It was such a problem that eclipse (the ide) had it's own java compiler that could do incremental compilation. This alternative compiler was so popular that you could even use it in Jetbrains IDE and I think you could configure maven to use it to get incremental compilation there to.

akoboldfrying 3y ago
Eclipse's own compiler is (impressively!) able to do truly incremental compilation: compiling the syntactically correct subset of methods in source files that aren't fully syntactically correct, and not bothering to recompile untouched methods. javac will compile every file you tell it to, plus any out-of-date immediate dependencies (and their out-of-date immediate dependencies, and so on, recursively), but if A uses B which uses C and you change C.java only, `javac A.java` doesn't "see" that all 3 need recompilation. Maven doesn't even offer javac's incomplete dependency checking by default, though I believe it can be forced to. (0.5 points for correctness over efficiency, I suppose.)