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: u...@thetaphi.de > -----Original Message----- > From: Michael McCandless [mailto:luc...@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-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
