Le 12/08/2020 à 22:12, Tim Boudreau a écrit :
- Maven is here to stay. Yes, it's slower than Ant, but as hardware
gets faster, that is less and less relevant. And probably there are
tons of optimizations that could be done to Maven to make it much faster
But it is not just about raw speed. Netbeans Ant projects are more
fine-grained. The Ant file generated by Netbeans has a lot of targets
for very specific tasks, which is probably a reason why daily work with
Ant is faster. For example we can easily recompile a specific file (by
pressing F9 key) before executing a main(String[]) method, which I find
useful for quick tests without being forced to fix immediately
compilation errors in files not used by that test. By contrast, Maven
apparently can only build the whole module (even if it can skip
unmodified files); the F9 key has no effect. So there is design choices
impacting not only what can be fixed by optimization, but also the way
we work.
We way argue that Maven approach reduces the risk of mistakes by new
users. But it also reduces (admittedly only slightly) productivity of
experimented developers. This drawback is also illustrated by Maven
counter-intuitive <useIncrementalCompilation> option, which must
actually be set to false for enabling incremental (and consequently
faster) compilation [1].
(…snip…) Gradle's scriptability aims the evolution of a project's
build squarely at the bad old days of needing magic properties files
in special locations, and things like that:
https://timboudreau.com/blog/maven/read - basically, whenever
possible, the workflow to onboarding with a new project should be "git
clone foo; cd foo; do-the-build"
Yes I agree that scriptability is a problem when it makes the build more
difficult than above steps. But Maven rigidity is also a problem when it
makes difficult to follow industry evolution. In particular Maven is
currently not very Jigsaw-friendly. For example we can not build a
Jigsaw multi-modules Javadoc (Maven aggregated javadoc is not a Jigsaw
multi-module javadoc). The same problem happens with other tools such
asannotation processors, which (to my knowledge) can not be executed in
a Jigsaw multi-modules project with Maven.
More generally javac, javadoc, etc. can work on many Jigsaw modules
together, but this capability is ignored by Maven which builds each
module separately. Aggregated javadoc simulates the effect of building
modules together, but the result is not the same and (in my
understanding) the process uses hacks not generalizable to e.g. an
aggregated annotation processor. Improving that situation would require
that we break some Maven assumptions (e.g. "1 Maven module = 1 Jigsaw
module"), but that would require modifications in Maven plugins. By
contrast scriptable build systems allow easier evolution. Indeed the
first projects that I have see moving to Jigsaw (e.g. Apache Derby) are
Ant-based. NetBeans also provided quickly an Ant-based form for Jigsaw
projects, while I still see no equivalent in Maven world. Today, I'm not
aware of a way other than Ant for creating a "real" Jigsaw multi-modules
project in NetBeans (i.e. a project on which we can generate a "real"
multi-modules javadoc).
I created two years ago a wiki page with some thought about possible
solution [2], but never had the time to start the work yet. Also it is
quite possible that my analysis is wrong.
Regards,
Martin
[1] https://issues.apache.org/jira/browse/MCOMPILER-209
[2] https://github.com/Geomatys/maven-plugins/wiki
