Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.6, 4.0-ALPHA
    • Fix Version/s: 4.0-ALPHA
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      We need a way to stage Maven artifacts to the Apache release repository.

      1. LUCENE-3964.patch
        8 kB
        Steve Rowe
      2. LUCENE-3964.patch
        8 kB
        Steve Rowe

        Activity

        Hide
        Steve Rowe added a comment -

        Committed to trunk.

        Show
        Steve Rowe added a comment - Committed to trunk.
        Hide
        Steve Rowe added a comment -

        Patch fixing a bug in the naming of the Solr war's POM.

        After fixing the POM name problem, I successfully staged Solr 3.6.0 RC0 here: https://repository.apache.org/content/repositories/orgapachelucene-016/.

        I think it's ready to commit, but I'll wait until tomorrow to do so.

        Show
        Steve Rowe added a comment - Patch fixing a bug in the naming of the Solr war's POM. After fixing the POM name problem, I successfully staged Solr 3.6.0 RC0 here: https://repository.apache.org/content/repositories/orgapachelucene-016/ . I think it's ready to commit, but I'll wait until tomorrow to do so.
        Hide
        Robert Muir added a comment -

        OK cool, my questions are mostly about process (not technicals).

        As far as adding scripts to deploy to maven, I'm happy with whatever you figure out.
        I was planning on bailing on this part and leaving it to more capable hands anyway...

        Show
        Robert Muir added a comment - OK cool, my questions are mostly about process (not technicals). As far as adding scripts to deploy to maven, I'm happy with whatever you figure out. I was planning on bailing on this part and leaving it to more capable hands anyway...
        Hide
        Steve Rowe added a comment -

        But again: this is for deployment correct?

        Yes.

        I don't want to change our release process for 3.6

        +1

        Show
        Steve Rowe added a comment - But again: this is for deployment correct? Yes. I don't want to change our release process for 3.6 +1
        Hide
        Steve Rowe added a comment -

        Confused about the component: build.

        Feel free to change it to a more appropriate component (not sure what that would be).

        I certainily hope the build need not be changed to do this (certainly not for 3.6)

        No, it does not. As I mentioned in my previous post on this issue, the patch is against trunk, and it works against your 3.6.0 RC0 (Lucene only at this point; Solr still needs to be tested.)

        I think we should generate an RC like we do now, putting it on p.a.o, vote on it, and this is merely a deployment issue.

        +1

        If there are any scripts involved in this, i think they should go in dev-tools instead, (like other release deployment scripts)?

        Yup, that's what I've done.

        This is a work in progress - please review if you're interested!

        Show
        Steve Rowe added a comment - Confused about the component: build. Feel free to change it to a more appropriate component (not sure what that would be). I certainily hope the build need not be changed to do this (certainly not for 3.6) No, it does not. As I mentioned in my previous post on this issue, the patch is against trunk, and it works against your 3.6.0 RC0 (Lucene only at this point; Solr still needs to be tested.) I think we should generate an RC like we do now, putting it on p.a.o, vote on it, and this is merely a deployment issue. +1 If there are any scripts involved in this, i think they should go in dev-tools instead, (like other release deployment scripts)? Yup, that's what I've done. This is a work in progress - please review if you're interested!
        Hide
        Robert Muir added a comment -

        But again: this is for deployment correct?

        I don't want to change our release process for 3.6

        Show
        Robert Muir added a comment - But again: this is for deployment correct? I don't want to change our release process for 3.6
        Hide
        Steve Rowe added a comment -

        Trunk patch for a new target stage-maven-artifacts in lucene/common_build.xml, which:

        1. calls a Perl script in dev-tools/scripts/ to recurse over the Maven dist directory (specified via property maven.dist.dir, which has default values under lucene/ and solr/) to find Maven artifacts, and then write an Ant build file (by default ./build/stage_maven_build.xml); and
        2. invokes the stage-maven target in the Ant build file produced by the Perl script to stage each artifact, along with its POM, sources and javadoc jars, and signatures for each, to the staging repository specified in properties m2.repository.id and m2.repository.url.

        Also included in the patch: a shell script to crawl Maven release distribution artifacts using wget: dev-tools/scripts/crawl.maven.release.dist.sh

        I have successfully run this target on the Lucene artifacts in Robert's RC0 release candidate, and then "closed" the resulting staging repository ("closing" disallows further uploads to the staging repository, and also does some quality checks, e.g. valid POMs, valid signatures) using this cmdline:

        ant clean stage-maven-artifacts -Dmaven.dist.dir=~/temp/lucene -Dm2.repository.id=apache.releases.https -Dm2.repository.url=https://repository.apache.org/service/local/staging/deploy/maven2

        The process took a little less than ten minutes.

        Although this patch is against trunk, it will work on any version's release, so I think it won't be necessary to commit it to branch_3x.

        Left to do: test against the RC0 Solr artifacts.

        Show
        Steve Rowe added a comment - Trunk patch for a new target stage-maven-artifacts in lucene/common_build.xml , which: calls a Perl script in dev-tools/scripts/ to recurse over the Maven dist directory (specified via property maven.dist.dir , which has default values under lucene/ and solr/ ) to find Maven artifacts, and then write an Ant build file (by default ./build/stage_maven_build.xml ); and invokes the stage-maven target in the Ant build file produced by the Perl script to stage each artifact, along with its POM, sources and javadoc jars, and signatures for each, to the staging repository specified in properties m2.repository.id and m2.repository.url . Also included in the patch: a shell script to crawl Maven release distribution artifacts using wget : dev-tools/scripts/crawl.maven.release.dist.sh I have successfully run this target on the Lucene artifacts in Robert's RC0 release candidate, and then "closed" the resulting staging repository ("closing" disallows further uploads to the staging repository, and also does some quality checks, e.g. valid POMs, valid signatures) using this cmdline: ant clean stage-maven-artifacts -Dmaven.dist.dir=~/temp/lucene -Dm2.repository.id=apache.releases.https -Dm2.repository.url=https://repository.apache.org/service/local/staging/deploy/maven2 The process took a little less than ten minutes. Although this patch is against trunk, it will work on any version's release, so I think it won't be necessary to commit it to branch_3x. Left to do: test against the RC0 Solr artifacts.
        Hide
        Robert Muir added a comment -

        Confused about the component: build.

        I certainily hope the build need not be changed to do this (certainly not for 3.6)

        I think we should generate an RC like we do now, putting it on p.a.o, vote on it,
        and this is merely a deployment issue.

        If there are any scripts involved in this, i think they should go in dev-tools instead,
        (like other release deployment scripts)?

        Show
        Robert Muir added a comment - Confused about the component: build. I certainily hope the build need not be changed to do this (certainly not for 3.6) I think we should generate an RC like we do now, putting it on p.a.o, vote on it, and this is merely a deployment issue. If there are any scripts involved in this, i think they should go in dev-tools instead, (like other release deployment scripts)?

          People

          • Assignee:
            Steve Rowe
            Reporter:
            Steve Rowe
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development