Re: Help getting m2 poms for 3.0.2 release

On Mar 21, 2007, at 3:33 AM, Simone Bordet wrote:
> Hi Jason,
>
>> > mvn clean install -Dtest=false
>>
>> Why -Dtest=false?  Just wondering?
>
> Because tests do not pass cleanly yet, and if they don't the build  
> stops.
> The command above allows also to compile test classes (using
> -Dmaven.test.skip=true skips also tests compilation).

Yup I know... I hoped you would have been able to get the tests to  
pass ;-)


>> > Is there a way to tell maven that test classes in one module  
>> depend on
>> > test classes of another module ? Or I am forced to write a dummy
>> > module that only contains a couple of base test classes ?
>>
>> Er... not really... not that I know of at least.  Best to put classes
>> which are common into the test-support module and then include that
>> in the dependents cp with <scope>test</scope>.
>
> Well, it turns out there is a way, and it's described in chapter 8.6.2
> of the book "Better Builds with Maven".

I forgot about test-jar... ;-)


> Now on to fixing the tests (it will take a while).
>
> The poms should be fairly good. I marked as optional most
> dependencies, so that one does not need to download the world when
> using MX4J and only using bits that do not need dependencies.
>
> Jason, if you have time to check the poms, will be great.

Ya, I will look at them later today.


> Then tell me what is your idea about deploying Maven2 mx4j artifacts.
> SourceForge does not have a Maven repo, as far as I know, but I guess
> we can use the web space to create a deployment area at sourceforge.

Yup, that is the easiest thing to do.  You can use that to hold on to  
your releases and stage them to central... though be sure to get them  
on to central, as IMO its bad to force users to add more repos if  
they don't need to.  Maybe one day m2 will allow repos to be  
configured with a set of groupIds that are allowed to be pulled from  
that source, but until then adding new repos will cause projects to  
look for *everything* in there, which will cause more traffic and  
slow down builds :-(


> Or in the meanwhile, we can package MX4J 3.1.0-beta1 (even if tests
> fails) so that the upload request to ibiblio passes and the G guys can
> work against mx4j-3.1.0-beta1.

No rush, we are using 3.0.2 now for G 1.2, and hopefully going to  
release that soon... as soon as the AMQ folks get their crypto papers  
filed.  Not going to be changing much in there for now.  G 2.0  
requires JDK 1.5 and is piggy backing on the VM's jmx support at the  
moment.

--jason




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV