Am Sonntag, den 10.09.2006, 15:20 +0200 schrieb Stefano Bagnara: > 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
I really like your proposal. Im +1 bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
