Re: Help getting m2 poms for 3.0.2 release

Aight maybe I'll look at it sooner than that... can't turn down a  
build-related challenge ;-)

If this is building using m2, then why are these still here:

     build/*
     src/*
     lib/*

Should keep directory names the same as their artifactIds... so for  
example:

     jsr003 -> mx4j-jsr003
     jsr160 -> mx4j-jsr160
     ...

You should use the top-level pom's <dependencyManagement> section to  
define all versions for deps used by child modules.

*Always* specify the version of plugins which are used in the top- 
level pom's <pluginManagement> section.  This will save you a ton of  
trouble when someone releases a new version of a plugin which breaks  
your build.

*Do not* use ${pom.version} or ${project.version} to reference the  
version of your projects in a dependencies <version>.  This will  
cause mad-headaches when deploying snapshots, as the deployed poms  
won't have the correct version.  Instead, define a property in the  
top-level pom named 'version', set that to the same value as the  
project/version and then use ${version} in all of your dependencies  
<version> elements.  Until the m2 folks fix this bug, it is dangerous  
to use ${pom.version}/${project.version} directly.

What is the tests module for?  These are just supporting classes to  
be used in other module's tests?  You might want to rename this to  
'test-support', since there aren't really any runnable tests in there  
at all ;-)

Your scm configuration is not correct... should be the path into the  
codeline:

     scm:svn:https://mx4j.svn.sourceforge.net/svnroot/mx4j/trunk/mx4j

NOTE, because the root of your project isn't trunk/ you will need to  
make some extra configuration to setup the distributionManagement.   
Normally I would expect that checking out trunk would have the top- 
level pom.  ie.

     svn co scm:svn:https://mx4j.svn.sourceforge.net/svnroot/mx4j/ 
trunk mx4j
     cd mx4j
     mvn install

I'd actually recommend you change this, it will simplify some  
configuration for you.  I'd:

     svn mv https://mx4j.svn.sourceforge.net/svnroot/mx4j//trunk/ 
website https://mx4j.svn.sourceforge.net/svnroot/mx4j/website

If you want to have versions of the site, then:

     svn mkdir https://mx4j.svn.sourceforge.net/svnroot/mx4j//website
     svn mv https://mx4j.svn.sourceforge.net/svnroot/mx4j//trunk/ 
website https://mx4j.svn.sourceforge.net/svnroot/mx4j/website/trunk

Looks like you are building the javax.* and mx4j.* stuff in the same  
modules.  If you still want to be able to distribute those separately  
then I would split them up into their own module.  You can use  
transitive dependencies to get them picked up, but you can also use  
the maven-assembly-plugin to make uberjars for folks that prefer the  
all-in-one jars too.  We do this for javamail:

     https://svn.apache.org/repos/asf/geronimo/javamail/trunk/ 
geronimo-javamail_1.3.1/geronimo-javamail_1.3.1_mail/

What are the requirements for testing your stuff?  I saw you had some  
${java.home}/bin/java stuff... thats probably not a good idea.  Can  
you explain what your testing needs are so I can advise how to set  
that up?

  * * *

FYI, I can give you a patch which should fix many of the issues  
listed above if you are interested.

Cheers,

--jason


On Mar 16, 2007, at 2:48 AM, Simone Bordet wrote:

> Hi Jason,
>
>> I folks, I'm trying to get the mx4j 3.0.2 release artifacts published
>> to the central m2 repository.  The repo admins want dependencies in
>> the poms... was currious if you guys have any idea what they  
>> should be.
>>
>> There is an opened issue here for this:
>>
>>      http://jira.codehaus.org/browse/MAVENUPLOAD-1220
>>
>> Its got a set of bundle files, which is the artifact + pom.  If
>> anyone knows what the deps should be for these, or knows of any other
>> details that should make it into the poms can you please update the
>> issue?
>
> SVN head builds mx4j with Maven 2, so everything should be in there.
> Unfortunately I did not have time to fix the tests (classloader
> issues), but the artifacts build fine. Never tried any maven deploy
> though.
>
> I guess moving mx4j to a maven build would fix the issue 1220 and  
> help G.
>
> If you want to take a look and/or help, I guess we can exit with a
> 3.1.0 built on Maven that should be ok for the future.
> I'll try to find some time to complete the build port to Maven 2.
>
> I'd be interested in your thoughts.
>
> Simon
> -- 
> http://bordet.blogspot.com


-------------------------------------------------------------------------
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