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 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:
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
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
