lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <dawid.we...@cs.put.poznan.pl>
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.

Dawid

On Sat, Apr 14, 2012 at 8:44 PM, Robert Muir <rcmuir@gmail.com> wrote:
> On Sat, Apr 14, 2012 at 2:18 PM, Dawid Weiss
> <dawid.weiss@cs.put.poznan.pl> 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?
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

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


Mime
View raw message