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 <[email protected]> wrote: > On Sat, Apr 14, 2012 at 2:18 PM, Dawid Weiss > <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
