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