lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [DISCUSS] Build/deploy Maven artifacts outside of Lucene/Solr
Date Mon, 23 Apr 2012 23:31:55 GMT
On Mon, Apr 23, 2012 at 7:21 PM, Robert Muir <rcmuir@gmail.com> wrote:
> On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>
>> Thus, I claim that this debate is fundamentally about package
>> renaming, not publication.
>>
>> Shall I be maximally annoying and mention OSGi again?
>>
>
> Its not really a debate, its 'how do we do this'. (I can argue your
> claim is wrong, but i won't, ive said it before and I stick with what
> I've said)...
>
> The current problem is for releases, how to handle this stuff is
> currently confusing. There are a few ideas here, and some of them
> maybe are possible, but we need to come to some sort of agreement on
> how to handle these kind of situations. Currently we have no patched
> jars, magically, but since we depend on over 100 of them, the
> probability of this situation staying the same for any length of time
> is very low.
>
> I don't really care what we do, but i just want:
> * a process for dealing with patched dependencies (that doesn't
> involve illegal publication of other people's stuff in maven under our
> name)
> * a process for dealing with dependencies that aren't in maven (that
> doesn't involve illegal publication of other people's stuff in maven
> under our name)
> * the two processes to not be the release manager's job to deal with.
> * the two processes to be easy enough to understand to pmc members so
> they actually understand WTF is going on with our releases without it
> being a huge mystery.
>
> One implication of what I want is that 'for development' (whats
> committed to trunk) is the same as 'for releases'. Because anything
> else is just a big 'RM, you go deal with fixing this later'. So I
> don't think we should let trunk get all kinds of screwy dependencies
> and leave it to release managers to fix up the mess.
>
> Another is that even if we work and figure all this out, its still so
> crazy complicated that a bunch of people here just say 'this isnt
> worth it, as a PMC member i dont understand all this, this is supposed
> to be a search engine project' (I'm not trying to call out Mike on
> this, but his email maybe alludes that some people could possibly feel
> this way about maven).
>
> And as a side note: Uwe's ideas bring up a nice potential compromise
> for simplification: maybe just lucene (as an API) should be in maven
> and not solr (as an application?). Its worth thinking about: solr has
> many many more third-party dependencies.  Dependencies are really
> really expensive.
>

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).

If I or others can hand you a simple enough prescription for how to
extend that to Maven builds and Maven releases, we're done. If we
can't, we're also done, where 'enough' is of course defined by the
consensus of the community, not just you and me.

For things that are not Apache, there's an very simple way to deal
with all this using Apache Extras, and no need to spill email over it
so far.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message