Hi all, The problem: we have products (jspf and mime4j) that use maven2 as build system. We now rely on "SNAPSHOT" projects (james-project and the james maven-skin) and on a temporary repository I setup in my minotaur home directory.
Of course this is no good because we can't publish official releases including references to my home or including references to SNAPSHOT projects. Here is my proposal: please note that I don't think this is the "final" solution for the "james/maven relationship" but I think that it is the smaller concrete step we have to do and I think we can afford this task now. 1) "james-project" (1.0-SNAPSHOT) and "maven-skin" (1.0-SNAPSHOT) artifacts are now in james/sandbox. We should find a better place for them. My proposal is to move them to the root james folder and to rename james-project to "project": /james |-project |-maven2-skin |-server |-jspf |-mime4j '-.... To keep consistency in the repository we should create branches/trunk/tags subfolder. As a sidenote I would prefer a structure where we have trunk/branches/tags at the top and having a clean structure inside trunk. But I don't want to discuss this now: let's move by small steps. 2) "james-project" currently declare "apache:apache:3" as its parent pom. I think we should keep james-project as parent (and remove apache:apache:3) until apache will find a common way to publish a "controlled" repository for third party libraries. So I would copy useful things from apache:apache:3 to our james-project root pom. 3) we should introduce a james project third party library repository where we'll include every "non-apache" library used by our releases. Fortunately now that we don't include junit in our releases and that sun released javamail/activation under CDDL we can safely put all our needed libraries in that repository (we already put that library in different folders of our repository). I propose to create a "repository" (or "repositories" or "repo") folder in our "james" repository and create a "third-party-m1" subfolder where I would commit at least the "org.bouncycastle" stuff from http://people.apache.org/~bago/maven/dist-m1/ . We could also commit there every non-apache library our maven2 releases will use: dnsjava for jspf. Both jspf and mime4j have junit as a "test" dependency: imho we could leave with this "problem" now and don't include junit in our repository. People can build and use our releases without running tests if they don't want to take risks downloading junit from ibiblio. 4) we should prepare non-snapshots releases for our "project" and "maven-skin" and maybe we should make the same thing for jspf (0.9) and mime4j (0.3). 5) Vote the release and publish them to the m2-ibiblio-rsync-repository as they will start being official james artifacts so I can remove any reference to my home on minotaur. 6) Please note that our "jspf" released artifact pom will include a reference to svn.apache.org/repo/asf/james/repository/third-party-m1/dnsjava/dnsjava-2.0.1.jar and people downloading the source distribution for jspf and running maven will automatically download it from our (ASF) svn server. This is indeed BAD to do for packages that may have a big user base so I think that we can safely do this only for jspf/mime4j/postage/jsieve, but this is not a solution for james. Btw we'll have much more time before we decide to move the official build for james from ant to maven2 and I really hope that the maven and repository teams will have found a solution to 3rd party and security by that time. My "optional" proposal is to export the "james/repository/third-party-m1" under a subfolder of our website (http://james.apache.org/repo/third-party-m1-repository/) and use that url in our poms. This would let us to avoid "hard references" to subversion and let us using the apache mirroring system already in place for the website infrastructure. I think we could also add both urls (website/svn) in the pom but declaring the svn one as a snapshot repository so that it will not be used by final releases. So, what do you think? Alternative proposals are welcome: keep in mind that the goal is being able to make official jspf and mime4j releases soon with a realistic roadmap. Stefano
