On Mon, Apr 23, 2012 at 7:45 PM, Robert Muir <rcm...@gmail.com> wrote: > On Mon, Apr 23, 2012 at 7:31 PM, Benson Margulies <bimargul...@gmail.com> > wrote: >> I have a suggestion for how to get from here to the exit. >> >> Forget about maven for the moment, and please explain to me exactly >> how you'd like to handle bugfixes to other Apache items in releases if >> all you had to worry about was ant(+ivy). >> > > OK (but this is just my opinion, and I'm sure a ton of people disagree). > > we have to separate out how to handle each product, in my opinion > lucene/solrj/and solr are all different here. > > for Lucene, as i mentioned, I dont think we ever have to really > include any jars in anything (not even the binary release). > You can look at 2.9's binary release, it has no third party jars > (except servlet-api.jar, which was unnecessary). People managed and > got anything they needed on their own. > Most lucene modules don't depend on third party stuff... its just a > fact, and for a long time nobody ever complained about this. > Instead we could just generate (maybe with XSLT) a .txt file listing > the dependencies and their versions and people get them on their own. > That frees us totally from jars completely for lucene. Source release > can download with ivy, patch with ant, who cares. > > for Solr, as an application, maybe we should just be making a massive > solr.jar anyway for the binary release that you java -jar (leaving the > webapp as an implementation detail or something): really I have no > idea. We could jarjar all 'jars that are implementation details' just > as a matter of course and there would never be any issues at all. > > for Solrj, this is really a client library, so i think its different. > but its dependencies (similar, but not the same as lucene's) are very > minimal... perhaps the solrj binary release could include these jars > since there just isnt that many of them to make it easy for people to > integrate solrj, or not, doesn't matter. > > So thats my idea of something that would really simplify all of this: > * simplifying and making lucene releases smaller, instead in binary > releases just documenting what we depend on (even if thats -PATCHED). > * hiding third-party dependencies in solr releases as an implementation > detail. > * some kind of hybrid (maybe just what we do today) for solrj. >
If you go to this point, yes, indeed, all this bother about patched dependencies goes away. I completely agree. And you get a cigar from Roy Fielding, who reminds us all periodically that 'Apache Releases are Source Releases', and all these binaries are irrelevant noise. And perhaps some of us would indeed club together to do maven publication on the side, though we couldn't call the results 'org.apache.' anything in naming the artifacts. However, you(all) accepted all of Steve's commits because a bunch of noisy users like me begged and pleaded for this project to act like a whole raft of other projects that publish binaries out to Maven Central. I think that you are spot-on in diagnosing the difference between the full release package of Solr and everything else. If there's one thing you want to deliver in binary, with working dependencies, that's it. And, I believe, you could defend a decision to deliver patched binaries with unrenamed packages in such a package, since you would't be publishing them into application classpaths. I can't personally guarantee smooth sailing there, but I'd be willing to help push for a rational view at the Foundation level. However, that leaves us annoying whiners who wanted Lucene, and the Solr modules we need as dependencies when building our own Solr plugins, and maybe even embeddable Solr, as Maven dependencies. Personally, I could live with a policy in which you publish these with unpatched dependencies and document the situation and the dependencies, or a number of other schemes in which you don't thread the needle of publishing bugfix binaries without offending people, up to and including a downloadable source package that automates local creation of patched binaries that the user can then choose to use as dependencies. It's also really quite wonderful that I can download the trunk, run a script, type mvn, and incorporate your latest and greatest into my stuff. At the bottom line here, it seems to me, you're looking hard at real flaws in the combination of Java and the repository/dependency systems we have, and bridling at participating. All I can tell you is that there's an awful lot of successful participation out there in spite of the flaws. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
