lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Maven artifacts for Lucene.*
Date Wed, 11 Apr 2007 13:33:04 GMT
Initial thoughts and then more inline below, and keep in mind I long  
ago drank the Maven kool-aid and am a big fan.  :-)

I know it is a pain to a few, but realistically speaking there has  
not been all that much noise about Maven artifacts not being  
available.  We use Maven for everything we do and all I ever do when  
there is a new release of Lucene is put the new jars in our remote  
repository and everything works.  It takes two or three steps and  
about 5 minutes of my time, and would be less if I scripted it.  I  
frankly don't get what the big deal is.  OK, it does save a few bytes  
on a server somewhere and we have our own group/artifact names  
(lucene/lucene), but chances are it is more reliable than trying to  
get it from one of the mirrors and it will be faster and the names  
are clear cut and easy to remember.  I would venture anyone with  
Maven installed has their own repository to store their own, private,  
artifacts, so it isn't like they need to add some new, complex process.

On Apr 10, 2007, at 4:20 AM, Sami Siren wrote:

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

Couldn't we just add various ANT targets that package the jars per  
the Maven way, and even copy them to the appropriate places?  I  
wonder how hard it would be
to have ANT output the POM and create Maven Jars.  I know it is  
backwards, but, it would be less complicated and could be hooked  
right into the ANT script and require very little from the RM.

Ideally, I would love to see the release process automated so that it  
became push button (I know Maven goes a long way toward this)

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

Does this just mean it would be in two places?  I don't think that is  
a big deal.

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

If I'm understanding correctly, you want to change the whole package  
structure by adding one more level?  Wouldn't this break every single  
user of Lucene?   We are still on M1 but are in the process of  
migrating, which is not straightforward, but, alas, the writing is on  
the wall concerning M1.

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

I think that would be fine to unify the 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

Grant Ingersoll
Center for Natural Language Processing

Read the Lucene Java FAQ at 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message