lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <>
Subject Re: Snapshot repositories and ivy.
Date Sat, 14 Apr 2012 19:18:25 GMT
Ok, clear. I'll just push a minor release of randomized runner to
maven central, so be it. And in the future, should anything like a
snapshot release be needed for a patch, it'll have to wait in jira (as
a patch) until a release is made and it can be committed in.


On Sat, Apr 14, 2012 at 8:44 PM, Robert Muir <> wrote:
> On Sat, Apr 14, 2012 at 2:18 PM, Dawid Weiss
> <> wrote:
>>> Right but trunk should be in releasable state at any time. While ivy
>> I think you're being idealistic.
> I don't think its too idealistic. We have to keep trunk releasable,
> otherwise it just shoves the burden on the release manager to clean
> things up before release.
> (and current trunk is still in a bad shape here, dependencies are now
> clean, but for example packaging is totally screwed)
> Fixing dependencies and stuff so that it works with ivy is easy, but
> maven shackles us more (I don't really know it, so maybe there are
> other ways it can download shit without it actually being in maven
> central: e.g. jar files from google code or whatever).
> As long as we release maven artifacts and our PMC is held accountable
> for them, then they can't get crazy and screwed up (fake maven
> releases of other people's software under lucene-xxx or solr-xxx,
> etc).
>>What if there is a critical issue in
>> one of the dependencies that needs to be addressed before an official
>> release of that dependency? Like the patched commons-csv?
> You can see how that one was handled in the current codebase: its
> imported in as o.a.solr.internal.xxxxx
>> I'm guessing
>> you want to put that JAR somewhere on the web and then point to it
>> from ivy.xml, right?
> That works for ivy but as mentioned above, does not work for maven.
>>> can simply point at any arbitrary URL and get a jar, maven cannot.
>> Everything can be done, it's just a matter of how long it's going to
>> take and how much trickery must be involved. Oh, and I'm not defending
>> Maven :)
> Right, and we have to shift the burden off of the release manager (and
> whatever guys he is able to bribe at release-cycle time), and onto the
> committers: same as we do with checking that we don't have javadocs
> warnings in the code, and checking that we aren't missing license
> headers.
> Speaking from experience, my sleep cycle and liver won't take another
> 'unfuck dependencies so that maven is clean' before release again.
> Release manager should be focusing on other things...
>>> We worked hard to clean this up ~ 3.6 timeframe and make it so that we
>>> werent issuing any 'fake maven releases' of any other code...
>> I know this, but this is not helping me solve me issue. So - I have an
>> interim JAR that I'd like to use in a non-released Lucene trunk. The
>> best solution so far seems to be to:
>> 1) put the JAR on the web somewhere,
>> 2) modify ivy.xml and provide an explicit URL to that JAR.
>> Am I right?
> Then how will the maven artifacts work if you committed this today?
> --
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message