lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
Date Tue, 24 Apr 2012 00:08:11 GMT
On Mon, Apr 23, 2012 at 7:45 PM, Robert Muir <> wrote:
> On Mon, Apr 23, 2012 at 7:31 PM, Benson Margulies <> 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

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

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

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:
For additional commands, e-mail:

View raw message