lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Fwd: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
Date Tue, 24 Apr 2012 01:10:55 GMT
On Mon, Apr 23, 2012 at 8:42 PM, Chris Male <> wrote:
> I'm with Steve here, -1.  I think the arguments have already been well
> articulated and the issue seems to be about dependency management in general
> not just about Maven.  However I also absolutely agree with Robert that we
> need to make this easier somehow.
> One thing I thought, is there any way we can get our own repo? In
> organisations that use Maven for their projects, that's how they tend to
> handle this situation.  They have their own repo for dependencies they need
> to manage and they use repo1 for the rest.   As an ASF project, do we get
> any help in this regards?


I'm getting a bit tired of reading my own writing here, and I bet a
lot of other people are, too, so I'll try to answer your question
concisely and then disappear from this for at least 12 hours.

The rule we are dealing with goes as follows, stated pseudo-biblically:

* No PMC shall publish a JAR file containing modified versions of some
other PMC's output unless you change the package names.

So it doesn't matter if it's a special repo created on, or Central, or something else. If it's under
the direction of this PMC, it's not supposed to contain patched
binaries. That's where my list of alternatives came from: either (a)
don't make the publication an act of the PMC (in which case you can
use github+OSSRH), or (b) come up with a scheme to change the package
names. In spite of all my argument, now that Rob states the problem in
terms of RM overload, I don't feel very enthusiastic about pushing for
a complex solution involving option (b).

Some of us could try to make a case at the Foundation level for some
modification to this rule, particularly to serve the problem of
something like a Solr release package. If started a thread that might
go there if I find any sympathy.

For things that aren't patched Apache binaries, OSSRH does the job of
pushing them to Central. No big deal.

In response to Rob, there is a Maven mechanism that could offer a
simplication: optional dependencies. Quick sketch:

a) big solr binary package: incorporate exactly what you want.
b) non-apache things that aren't in maven -- volunteers go and push
them via ossrh.
c) apache things with problems: declare dependencies on the best
available release, but mark them <optional>true</optional>.

This will force the end-users to declare the dependencies for
themselves, choosing to either use the standard buggy version or some
other version that they acquire or build. In other words, the Maven
moral equivalent of your lean release package from history.

Good Night All.

> On Tue, Apr 24, 2012 at 12:28 PM, Benson Margulies <>
> wrote:
>> > Its definitely overwhelming right now, the size of the codebase and
>> > the number of dependencies, given what we have. I think we should be
>> > considering all options. Maven packaging just adds to the complexity
>> > due to the fact of how it manages dependencies (they must themselves
>> > be in maven somehow).
>> If you like (or can live with) everything about the situation except
>> for the additional Maven burden, then it's worthwhile for us
>> Maven-heads to offer schemes that purport to do Maven without making
>> it (much) worse. But if the situation has grown beyond what the RMs
>> should have to deal with even without Maven, then we're (or at least
>> I'm) just adding noise.
>> If the Maven straw that breaks the camel's back is 'how do we get the
>> fixed binaries into the Maven universe," I want to underline my
>> previous failure to be clear when talking about 'the github trick'. If
>> a group of folks wants to make forks on github of whatever, Apache or
>> not, and apply bugfixes and push, they can do that. If they organize
>> their work on this list or in this list's JIRA, they might take some
>> flak. They might win the resulting argument. Especially if in each
>> case they can document that they diligently tried to work with the
>> upstream.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Chris Male | Software Developer | DutchWorks |

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message