Am 09.02.2013 um 01:50 schrieb Dominique Pellé <dominique.pe...@gmail.com>:
> Richard Eckart de Castilho wrote: > > Without having had a look at the build, I would expect at least two things to > cause: > 1) Maven (like ant) is a Java application and it takes a moment to fire up > the JVM. > "make" is a native application. 2) The "package" goal always runs the full > packaging (building of ZIPs and JARs from the compiled sources). So even > if the compile is up-to-date, doing the packaging takes a moment. If further > plugins, e.g. JavaDoc, have been activated during normal builds, they may > further slow down the build. > > Understood for the overhead of running the JVM (multiple times?) > during the build. As far as I know, the JVM is started once for the main build and may be started again for running tests, so that tests are well isolated in their own JVM. Depending on the configuration of the surefire plugin, the JVM may be started more than once (see "forkMode" parameter). > But why would Maven "mvn package" always re-create the ZIPs and JARs > when nothing has changed? There might be a good reason, but at first sight > it seems like a waste of time. Shouldn't a build system try to do the least > amount of work and rebuild only the targets for which at least one of their > dependencies has changed, based on a DAG (Directed Acyclic Graph) > of target/dependencies? For Java classes, the tool knows the dependencies between files and can avoid to recompile files. As far as I know, for artifacts, Maven does not know or maintain a record of what files go into the artifacts. It may also be that zip/jar archives are not necessarily the best file format for incremental updates and need to be rewritten from scratch every time they are changed. > Running "mvn compile" when nothing has changed is faster than > "mvn package" but not really fast either. "mvn compile" takes 6.5 sec > on my laptop when nothing has changed (nothing to compile), which is > presumably much more than what the JVM needs to initialize when > launching mvn. I'm probably also spoilt by Eclipse's incremental compile and by Jenkins. In both cases, I do run into these problems. In cases where I do run Maven on the command line, I probably got used to the build times. Anyway, firing up the JVM is likely much less than 6.5s, but then the application is not initialized. I am pretty sure that Maven performs some heavy self-configuration during startup, checking that its modules are available, wiring them all together internally and so on. Maven itself is build in a highly modular way. I would expect this initialization is taking a major part of the startup time. > I was also searching for parallel builds in the hope of speeding up > (something like "make -j4" with GNU make). I found this... > > http://stackoverflow.com/questions/581465/maven-how-to-do-parallel-builds > > ... but it does not work. I never was successful with that, but I had tried it on a way more complex build. You might want to update to the version 2.6 of the resources plugin and see if that supports parallel builds. Cheers, -- Richard ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
