lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sami Siren" <>
Subject Maven artifacts for Lucene.*
Date Tue, 10 Apr 2007 08:20:27 GMT
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

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

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 (it is now org.apache.lucene
within the currently released artifacts). The initial list of artifacts (the
new proposed structure) is listed below:

lucene-parent (pom) (a top level pom defining lucene wide stuff that
gets inherited to sub project modules)
java-parent (pom)
 lucene-core (jar)
 lucene-demos (jar)
 contrib-parent (pom)
 lucene-analyzers (jar)
 lucene-benchmark (jar)
 lucene-misc (jar)
 lucene-queries (jar)
 lucene-regex (jar)
 lucene-snowball (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

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message