Hi Dana, you are absolutely right, but there are a few things Maven could do to improve speed : using multiple threads/cpus : - Maven downloads stuff. Now, since the network exists, it exists latency, and all net applications work best when multithreaded. Is maven currently parallelizing the jar downloads/the connections it makes to test if there are new releases of the artifacts? That could speed up a lot, expecially on first time users, first time they download stuff, first time they see maven as slow :) - Unit tests are, by DEFINITION, parallelizable. Maven could create more of one instance of the test runner, create a shared list of test methods, and have various instances run on different threads and pick a test method from the list. Failure of a test does not stop execution of other tests in the same package, so it's safe to do so.
On the build process itself, it has no meaning to parallelize it as you properly pointed out. Simone Lacoste, Dana (TSG Software San Diego) wrote: > The situation below (deploying to multiple J2EE platforms in the build) > is already easily supported: you're using ant to do it, and ant supports > a "parallel" section http://ant.apache.org/manual/CoreTasks/parallel.html > > So, inside a maven-antrun-plugin section you can do a <parallel> with > no hesitation. > > The main issue, though, gets back to one of "The Maven Way" > > Maven was designed with a very heavy emphasis on the "right" way to do > things, and with most projects (breaking into modules, providing single-file > artifact build results, assumed "src/java" layout, etc.) the only "parallel" > part that could really work would be when compiling the classes from the > **/*java files. This would theoretically result in "quicker" java compiling, > but I question if the result would be a significant gain, unless you had > a SERIOUSLY large number of classes in that jar! And with a 6 minute build, > you really don't :) > > For NON-JAVA src files, you can turn on the make flags appropriately already > (in other words, if maven isn't doing the build, it's just calling ant to > call make or something, then you can get the make command to parallelize) > (I remember an old comparison of gcc vs. kylix in this area: gcc benefits > from the "make -j" to such a large extent because it's really horrible at > building each file: kylix, with Pascal's simpler compile rules, was so much > faster they weren't even in the same league!) > > But that's really just "the way it is" : there's no real way that maven can > parallelize things without causing a lot of issues. Threading output of > the build, handling build failures, ensuring dependency order: it would add > a LOT of complexity to the build with not a lot of benefit. > > And, just for the record, my maven project has 100 (wow, 100 exactly. hadn't > counted before) modules and a full build of EVERYTHING takes about 330 minutes > on my fastest build machine: if there was a way that I could speed this up > I would GLADLY do so, but there really isn't : any speedup that's caused by > a change in how maven works would result in serious usability and stability > issues that would NOT be worth it, IMNSHO. > > Dana Lacoste > > -----Original Message (Trimmed for content)----- > From: Jorg Heymans [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 10, 2008 8:36 AM > To: Maven Users List > Subject: Re: Multiple CPUs > > well imagine that during your integration build you have to deploy 10 EARs, > and each of them to a number of application servers (weblogic, websphere etc > etc). That adds up pretty quick. I don't know the effort involved, but if the > ant runner for example could be made to run in a different thread for each > invocation that could speed things up drastically only for this use case. > > Jorg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
