lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
Date Mon, 23 Apr 2012 23:45:49 GMT
On Mon, Apr 23, 2012 at 7:31 PM, Benson Margulies <bimargulies@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message