lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
Date Mon, 23 Apr 2012 21:09:11 GMT
Hi,

You might all know me as "die, maven, die" person, but this special case is
definitely not related to the issue mentioned at all:

The problem we had with commons csv was *not* related to maven at all, it
also affected our standard artifacts. The problem was that we were releasing
code in the namespace of another projects in their namespace. This also
affects standard binary distribution (and at that time also source
distributions, because we were shipping a jar file using code with an
unreleased namespace of another project). I just repeat, that has nothing to
do with maven!

The second thing I wanted to say: Lucene was always shipping "maven
artifacts in the maven repository", and this is a really good thing! We were
always doing this and it helps users to use Lucene more easy. E.g., I never
download a Lucene release using the official binary JAR file, I always
download the JAR files using maven/ivy! By publishing maven artifacts, we
are not "centralized to maven", we simply offer another and very convenient
way to include Lucene into your App. On the other hand, I think, we should
*not* publish Solr using maven, because it is not a library, but a complete
application, so users must download the release to work with it.

So we must publish maven artifacts to be successful on the open source
market, sorry! (that's my opinion!) Publishing artifacts on behalf of other
parties is wrong (but that's unrelated). By publishing Maven artifacts, not
only people using Maven can have a better experience, also people using IVY
(and we are also using IVY) have a better experience and usability. As we
use Ivy, we should give back that to the community.

We also have a chicken and egg problem by using IVY. Lucene 3.6 downloads
the JAR file for backwards compatibility tests (Version 3.5) via IVY
fromMaven using the maven artifact ID. This version is only available via
IVY as Steven published them after releasing 3.5.

Finally, publishing maven artifacts has nothing to do with maven at all. We
don't need a maven build to do that! I love what Steven did, but in my
opinion, the old way of creating JAR files (which ANT does for us) and
copying them to the maven servers can be done completely without maven (at
least I did it in the past, maybe that has changed). It was simply a copy
operation of some JAR files and a metadata file (XML). As we are now using
IVY, we should maybe do the automated deploy using IVY instead of a parallel
maven build.

So my strong -1 to remove maven artifacts!

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Monday, April 23, 2012 4:15 PM
> To: Lucene/Solr dev
> Subject: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
> 
> I've had a lingering frustration with the recent blowup due to the solr-
> commons-csv Maven artifact (SOLR-3204).  We've worked around the
> particular issue (we now hide the dependency)...
> 
> But in thinking it over, and avoiding rehashing all the technical details,
what
> bothers me most about what happened is that the Lucene PMC is/was held
> accountable for "having released code in another project's namespace",
yet,
> none of us realized we had done so.  We are (or at least I am) generally
> ignorant of the consequences of deploying artifacts and dependencies into
> Maven.
> 
> I think that's bad: I'm not comfortable being held accountable for
something I
> don't understand.
> 
> I am very sorry (to the Apache Commons project) that we "released"
> their sources like that; I had no idea we were doing so.  Ignorance is not
an
> excuse and really the Lucene PMC is/was negligent...
> 
> I think, to fix this, we (the Apache Lucene PMC) should stop officially
posting
> artifacts to Maven ourselves.  I think it's great if Steve (and/or others)
continue
> to do so, just outside of the Apache Lucene project and outside of the
Lucene
> PMC.  This would mean the Maven build/deploy is fully downstream from our
> official releases, just like how the numerous other package
> managers/repositories (yum, apt, pkg, etc.) distribute our release
artifacts.
> 
> This can be beneficial for users who consume our artifacts via Maven as
well:
> for the 3.4.0 release, the Maven artifacts were broken, but we couldn't
change
> the already-released bits (SOLR-2770).  Had Maven been downstream, this
> should have been easily resolved since it'd just be a re-spin of Maven's
> artifacts, not Lucene/Solr's.
> 
> All of this being said, I'm very very grateful to Steve for working so
hard to
> understand Maven, and build/deploy the Lucene/Solr Maven artifacts, for
our
> releases.  I know it's a huge amount of work, and in general rather
thankless
> around here, being stuck between people who love Maven and people who
> don't, yet Steve has done an amazing job at it.
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message