lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
Date Tue, 24 Apr 2012 11:12:49 GMT
This thread is impossible for me to keep up with!  Some responses:

> In fact, I expect if there is real demand, a downstream contributor
> would easily pick this up.

Exactly: just like the numerous useful Linux repositories... it's
clearly not this PMC's job to push to all of those repositories.  Why
should it be our job to push to this one (Maven central)?

I completely agree many users legitimately find the Maven artifacts
useful, and I fully expect if we (the PMC) stop officially pushing
artifacts to Maven as part of our officially released artifacts that
someone else will step up to do so, just like other people step up to
publish our artifacts in the popular Linux repositories.

> Do you, Mike, fully understand all of Lucene/Solr's code?

No.

> If the answer is no, then how can you be comfortable voting for a
> release?

Because I feel there is "enough" overall coverage on the PMC, across
all of us, for all of Lucene/Solr's functionality.

I don't feel the same about the artifacts we push to Maven, the
"policies" of Maven central, nor the build process that produces those
artifacts.  Benson (and others) getting involved will certainly help
with that over time...

Steve, I realize you work wonderful magic with Maven, but it's still
magic and it entails clear risks / distractions to the Lucene project.

The recent board brouhaha was just one example of "what can go wrong
when a PMC votes on/publishes artifacts into something it doesn't
understand" (though: I do agree, there were additional "factors" at
play, as Benson described...).

I do agree the response for the followon (3.6.0) release was swift and
amazing (big thank you to Robert & others!): we've either masqueraded
(commons-csv), worked around bugs (XERCESJ-1257), forked & pulled
patched versions from github (Tomcat) or "released anew" via github
(noggit) so that our deps are now clean/legal.

So, yes, we've fixed the current "known risk" on publishing Maven
artifacts... but the risk and distraction nevertheless remains, in my
opinion.  We should be spending our time building a great search
engine/app, not on distractions like this.

That said, unless others speak up, it does look like there's no point
calling a vote here (I appear to have the minority opinion here), so
we will likely continue officially releasing into Maven for now (and I
can accept that).

> I don't know how maven is of relevance here.

I disagree.

As Robert described, anyone may fork commons-csv, Xerces, Tomcat, etc,
on github, patch them with their critical bug fixes and send pull
requests to get those fixes back upstream (eventually, hopefully).

This is the beauty of git/github.  It's fully decentralized: fork
away.

Your fork is "out there" on the wild wild internet, available for
anyone to use, or, not.  And, no, you don't have to change the package
names: the point of the fork is clear (eg "Xerces 2.9.1 with Unicode
surrogates bug fixed", "Tomcat with unicode bugs fixed").

It could be over time your fork becomes popular.  Anyone parsing
Wikipedia's XML exports will need that patch on XERCESJ-1257.  Maybe
you patch a few other unicode releated issues over time, etc.  This
can then eventually be useful information for the origin
project... it's like voting with your feet (hmm I guess fingertips).

The Maven repository, in contrast, is centralized, has certain
"rules", and so the mere act of putting your dependency in there
without masquerading the package names is (reasonably?) seen as a
stealing someone else's namespace.

I think hiding/masquerading dependencies (shade/jarjar/etc.) is a bad
hack (and I'd love to stop doing this for Solr's commons-csv dep).

> I think more important than our code being correct is that our
> distributions work correctly.

+1

> And as a side note: Uwe's ideas bring up a nice potential compromise
> for simplification: maybe just lucene (as an API) should be in maven
> and not solr (as an application?). Its worth thinking about: solr has
> many many more third-party dependencies.  Dependencies are really
> really expensive.

+1

> Shall I be maximally annoying and mention OSGi again?

OSGi does seem promising on paper... but I don't understand it (and
the number of patches/iterations on the issue is spooky).  It
(LUCENE-1344) is currently the top-voted Jira issue for Lucene...

But I'm not sure it really helps (yet)?  Not everyone/enough of our
users consumes Lucene/Solr via OSGi...

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


Mime
View raw message