cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Faster CXF builds and test ports....
Date Thu, 03 Jun 2010 16:36:34 GMT

As some of you may have noticed, I've been doing some commits to make things 
work better with the Maven 3 betas.   One reason is to achieve faster builds.   
My new notebook has 4 cores (8 threads) and 12GB of RAM and I'd like to get to 
a point where they are useful.  :-)

Maven 3 has a "parallel" mode (abbreviated // )  where it can build non-
dependent projects in parallel.  That would allow better use of extra cores 
and such.   With my latest changes along with an update to the Checkstyle 
plugin which I committed to Maven yesterday, (needs the snapshot version which 
isn't deployed yet) I can now build CXF in // mode as long as the tests are 
mvn clean
mvn install -Dmaven.test.skip.exec=true -T 12

The // mode cuts about a minute and a half off the install.  (from 6.5 minutes 
down to 5 minutes) which is good.  Subsequent  "mvn -Pfastinstall" builds drop 
from 43 seconds to 34 seconds.   Also good.

However, the real win will be if I can get the tests running in parallel as 
well.     The major problem with the tests is the port usage.   We pretty much 
use ports in the 9000-9100 range for everything with MANY tests using the same 
ports.   One reason is that we use the ports burned into the wsdl's rather 
than overriding them as part of the test  cases.   Thus, I'd like to start 
going through the tests and get them to override the wsdl specified ports with 
unique ports.   Now, the question comes: how to allocate the ports.   There 
are basically two options:

1) Assign each module a "range" of ports to use and update the tests to use 
that range.

2) Use the buildhelper:reserve-network-port maven plugin to try and 
dynamically allocate some ports and somehow get them passed into the test 
suites to use.   

(1) is definitely easier, but I kind of like (2).   I might try and get the 
buildhelper thing to allocate a range of like 10 ports per module and save 
them to a properties file or something and update the testing harness things 
to load them up to make them avail.   Not really sure yet.

The other trick thing will be the non-http ports we use in the tests.  Mostly, 
that is the JMS broker stuff and the CORBA binding IOR things.   Those may 
also require some extra investigation.

Anyway, just wanted to provide a quick update on the progress.   :-)

Daniel Kulp

View raw message