> > On the build process itself, it has no meaning to parallelize it as you > properly pointed out. >
May this is true on Java... But on flex is not. Flex compilation always use 100% on a single core computer and never use more them 50% on multi core. Well, if we got downloads and tests multithreaded I will be very very happy =D VELO On Fri, Apr 11, 2008 at 2:21 PM, Simone Gianni <[EMAIL PROTECTED]> wrote: > 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] > >
