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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
