Re: Help getting m2 poms for 3.0.2 release

Hi Jason,

> If this is building using m2, then why are these still here:
>
>      build/*
>      src/*
>      lib/*

Vestige of the old build; to be removed.

> Should keep directory names the same as their artifactIds... so for
> example:
>
>      jsr003 -> mx4j-jsr003
>      jsr160 -> mx4j-jsr160

I've seen this many times, but I find it so redundant (where is dry ?).
Is there a particular reason for this, in your experience ?

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

I normally put in the top-level pom the common dependencies, while I
keep module specific ones in the module pom, where I find more
intuitive to look for. Again, do you see any problem in this (although
I have no problems in putting it as you suggest) ?

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

Ok.

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

Ok.

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

Ok.

> 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

This part is still in mixed mode between old and new build. I have not
taken a look at website directory yet, so I am open to suggestions to
eventually reorganize the website directory.

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

No, they will be distributed together.
The split was asked in the hope that one can use the JMX API without
their implementation, but unfortunately it's not the case (e.g.
javax.management.monitor.Monitor is a class that references an MX4J
class, so you cannot cleanly separate API from implementation).

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

That may be handy to ship jsr003 and jsr160 together.

> What are the requirements for testing your stuff?  I saw you had some
> ${java.home}/bin/java stuff... thats probably not a good idea.

For surefire, Maven picks up whatever "java" executable you have in
the path. On my system this was pointing to some old version of GNU
classpath so I just want that the JDK I use to invoke maven is also
the JDK used to run the (forked) tests.

> Can you explain what your testing needs are so I can advise how to set
> that up?

One feature I like of Maven which I'd like to keep is the fact that
tests and main classes have the same package. This allow tests to
invoke protected/package methods without too much reflection work.
But I have not squared out if there is any problem to have a FooTest
class in package javax.management.

Another need I have is to be able to test method compliance and
serialization compliance against the JMX RI.
Currently this is done loading MX4J in a classloader and JMXRI in a
sibling classloader.
I have not investigated the issue deeply, but seems that surefire
plays with classloaders, so I it seems to not work anymore. It may
even not be surefire's fault.

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

You already deserved commit rights :)
Tell me if it's fine for you, I guess it will save much time than
create/send/apply a patch.

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