I have been hoping to put up mechanism for (easier) deployment of m2 artifacts to maven repositories (both Apache snapshot repository and the main maven repository at ibiblio).
The most convenient way would be to use maven2 to build the various lucene projects but as the mailing list conversation about this subject indicates there is no common interest for changing the (working) ant based build system to a maven based. The next best thing IMO would be using ant build as normally for the non maven2 releases and use maven2 for building the maven releases (.jar files, optionally also packages for sources used to build the binary and packages for javadocs) with related check sums and signatures. To repeat it one more time: what I am proposing here is not meant to replace the current solid way of building the various Lucene projects - I am just trying to provide a convenient way to make the release artifacts to be deployed to maven repositories. I have put together an initial set of poms (for lucene-java) to do this quite easily, basically what is required is installation of maven2 binaries and the set of pom files and a checkout of the lucene version to build. The various jars are build, packaged, check summed, signed and optionally deployed with single mvn command. So IMO it is quite easy thing to do in addition to normal release process. I can also, for undefined time, volunteer to do these builds if it is too much of burden for RMs. There are however couple of things I need your opinion about (or at least attention): 1. There are differencies when comparing to ant build jars (due to release policy of a.o) the built jars will contain LICENSE.txt, NOTICE.txt in /META-INF. Is this a problem? 2. I propose that we add additional folder level so the groupId for lucene java would be org.apache.lucene.java (it is now org.apache.lucene within the currently released artifacts). The initial list of artifacts (the new proposed structure) is listed below: groupId:org.apache.lucene lucene-parent (pom) (a top level pom defining lucene wide stuff that gets inherited to sub project modules) groupId:org.apache.lucene.java java-parent (pom) lucene-core (jar) lucene-demos (jar) contrib-parent (pom) lucene-analyzers (jar) lucene-benchmark (jar) lucene-highlighter(jar) lucene-misc (jar) lucene-queries (jar) lucene-regex (jar) lucene-snowball (jar) lucene-spellchecker(jar) lucene-surround (jar) lucene-swing (jar) lucene-wordnet (jar) lucene-xml-query-parser (jar) groupId:org.apache.lucene.nutch (TODO) nutch-parent (pom) nutch-core (jar) nutch-plugins (pom) nutch-plugin-x (jar) (as soon as nutch plugins can be of format .jar) ... groupId:org.apache.lucene.hadoop (TODO) hadoop-parent (pom) hadoop-core (jar) hadoop-streaming (jar) ... groupId:org.apache.lucene.solr (TODO) solr-parent (pom) solr-core (jar) ... 3. Where to put poms? They need to be put somewhere. I think it's not smart at this point pollute the ant driven folder structure with poms - they are better of in separate dir structure. What is (in your opinion) the most convenient place for them? I would propose that every sub project would have dir named maven (or something similar) that would contain poms for that particular sub project. Other possibility would be putting a lucene level dir for maven stuff and the poms would be maintained there. The text above was my initial thought about this, however there have been concerns that the procedure described here might not be most optimal one. So far the arguments have been the following: 1. Two build systems to maintain True. However I don't quite see that so black and white: You would anyway need to maintain the poms manually (if you care about the quality of poms) or you would have to build some mechanism to build those. Of course in situation where you would not actually build with maven the poms could be a bit more simple. 2. Two build systems producing different jars, would maven2 releases require a separate vote? Yes the artifacts (jars) would be different, because you would need to add LICENSE and MANIFEST into them (because of apache policy). I don't know about the vote, how do other projects deal with this kind of situation, anyone here to tell? One solution to jar mismatch would be changing the ant build to put those files in produced jars. 3. Additional burden for RM, need to run additional command, install maven There will be that external step for doing the maven release and you need to install maven also. But compared to current situation where you would have to extract jars, put some more files into them, sign them, modify poms to reflect correct version numbers, upload them to repositories manually. The other way to do is would be changing the current build system to be more maven friendly. This would probably mean following things: -add poms for artifacts into svn repository (where?) -adding LICENSE and NOTICE into jars. -add ant target to -sign jars -push artifacts into staging dir or to repository (or leave it as additional manual step) -optionally build javadoc jars (if currently not done) -optionally build source jars (if currently not done) Are there any technical arguments in favour or against the proposed solutions or is there perhaps one that outperforms them both. Please share your thoughts about all this :) -- Sami Siren
