Possibly interesting: here's a proposal for converting Gerrit's open source build to Buck. Includes GWT-specific macros (in lib/DEFS)
6 plus ones
Shared publicly•View activity
View 7 previous comments
- Ah yes, the maven-compiler-plugin's staleness check is really broken, but it can't be fixed without adding more work. One problem is that it doesn't run in isolation: the output folder can already have files in it (starting with classes from a previous build), and the produced classes can be processed afterwards (not to mention that the inputs can be fed from other plugins so they can possibly change between builds, depending on build options/properties). If the output was in a clean folder, staleness check would be easier, but it'd mean copying the classes to target/classes afterwards.
And then there's the attempt at incremental compilation, which rules out the “clean folder” approach (but might just be an attempt at fixing the wrong issue).
I think it's a problem many build-systems have actually, not just Maven.
As for managed dependencies, downloading is one thing, tracking transitive dependencies (when you have to declare all of them explicitly) is another, and then there's conflict mediation.
I'd be more than OK with something that'd have downloading as a separate step (so you could do that once in a while, commit files in a VCS if you like, etc.); but handling transitive deps and conflict-mediation by hand, no thanks. In GWT, despite being hand-managed, we had at least 2 or 3 copies of javax.servlet in the classpath, in different versions; and I believe we still have several copies of a few other libs (Guava, Protocol Buffers; things that come bundled in other dependencies –closure-compiler– and you have to know what version they used in their build –because it's not really a transitive dependency, it's bundled in the JAR).
Conflict mediation is hard, and Maven is not even the best. Dart's Pub seems to do a good job (form what I've read).May 1, 2013
- What do you mean by “this is what Scala does”? SBT? AFAIK SBT downloads dependencies on-demand, like Maven.
BTW, the build-rule is what Shawn did for Gerrit+Buck.May 1, 2013
- Interesting; the bits and pieces of the Google build system I know about sound nifty, so I'd been meaning to look into Buck. So, thanks for the link, Brian.
It was already mentioned above, but, yeah, integrating Buck with something like Ivy to talk to Maven repos seems key for playing nicely in the Java ecosystem.May 1, 2013
- The only place I get spurious fails that require clean are using the javac annotation processors, unless I package the generated source outside of /target.
And the reason no-op is faster in parallel is because I'm building 30+ modules at once. So ten seconds to load all the poms, check all the files and run all the tests (except gwt, which is part of fullBuild) is actually pretty decent, methinks.May 1, 2013
- Also, one thing that's often overlooked: Maven (along with a few others) isn't just a build tool, it's a “software project management and comprehension tool” . Noticeable features beyond building:
• publishing artifacts to a central server for reuse by others (as Lex pointed out on his blog , it also has issues, or is part of the problem)
• releasing: update version, tag in the SCM, build and publish to central server in one go (OK, actually 2 steps; and it's slow as hell and does strange things in your SCM so some people prefer to do all of it by hand)
• tools around managed dependencies (check for new versions of your dependencies with “versions:display-plugin-updates”, download all your dependencies transitively to some folder with “mvn dependency:copy-dependencies”, warm-up your artifact cache/local-repo with “mvn dependency:resolve” and “mvn dependency:resolve-plugins” –of course it won't take into accounts those dependencies downloaded at runtime by some plugins–)
There are also plugins to run your app for development (“mvn tomcat7:run” runs your webapp in an embedded Tomcat that automatically redeploys the app whenever files change on the filesystem; and “mvn gwt:run” can run the DevMode, automatically configured with the correct classpath), and standard variable expansion (filtering) in files.
AFAICT, Buck is really only about building your app (and possibly install it on an Android device if it's an Android app), so you have to develop external tools around Buck for those other things.
I'm not saying it's a problem, just something to be aware of. Gerrit is not just switching to a new way to build the project, but also a new way to develop it (how do you run a test server? how do you run the UI in DevMode?) and to release it (that was actually the reason for the switch; but when you publish API libs –for plugins–, you'll have to take an additional step to deploy them to Central for those people using Maven/Gradle/Ivy/etc.)
 blog.lexspoon.org/2012/12/recursive-maven-considered-harmful.htmlMay 1, 2013
- I actually love the structure of maven. Putting build files in the source tree just feels wrong to me (though it may just be Stockholm syndrome on my part). I like that my modules can't compile in the ide if they access code not explicitly added to the pom. I like that my modules are completely isolated. I like that my modules are not tied to any ide, but still work in those ides. I like build lifecycles that will let me transitively add a given process in a parent pom that defines when it should run without manually calling a macro every time it is needed. I like being able to write a plugin that can extract the classpath of any given module and use it to run instrumentation or launch a given process.
For example, I have a plugin to launch gwt super dev mode from any module's classpath. It works on any module with an entry point in a gwt.xml, with zero config needed in said module, and it's portable to any module because the dependency management is completely standardised. I'm not sure if gradle is capable of such things, but I do know that every ant script for a gwt project always has to define a gwtc macro, a dev mode macro and a call to said macro for each entry point used. With one maven plugin, the work needed to launch a dev mode server on a new module is: cd $DIR && mvn xapi:codeserver.
It all comes down to using the right tools for the job at hand. Maven definitely isn't right for everyone or every use case, but it provides a lot more functionality than just building jars; it provides a standardised, interoperable means of accessing class paths and settings across units of code that are completely ignorant of each other. For me, that is a huge amount of value. ... I'm actually working on a javafx GUI to load up any pom, scan it's source roots, display dependencies, show buttons to run goals... To make a single interface that exposes the functionality in each module without requiring users to read all the XML, or even to use maven as a runtime launcher for production functionality (mostly other build tools, like 'regenerate code' or 'rebuild and restart server' or 'find gwt modules'; other developer's build environment is my prod). Without the standardisation, it would be impossible to reuse those build tools. I'm not sure if ant or gradle provide a runtime api to load and manipulate the project model, but I do know that using maven means my tools will be portable regardless of ide or project configuration. That portability alone sells me, regardless of the many plugins I use to do things like reuse server launch configs or build shaded jars or drop in any lib with a single snippet of XML off the web. =}May 1, 2013