Lucene - Core
  1. Lucene - Core
  2. LUCENE-3951

get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.6
    • Fix Version/s: 3.6
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      see title

      1. LUCENE-3951-handle-ivy.default.ivy.user.dir.patch
        2 kB
        Steve Rowe
      2. LUCENE-3951.patch
        0.6 kB
        Robert Muir
      3. LUCENE-3951.patch
        3 kB
        Steve Rowe

        Activity

        Hide
        Robert Muir added a comment -

        But this is really specific to 'the maven build' right?

        dist-maven works correctly for releasing.

        So this could also be solved in dev-tools/maven, in its executions
        it could call whatever ant stuff it needs to work.

        Show
        Robert Muir added a comment - But this is really specific to 'the maven build' right? dist-maven works correctly for releasing. So this could also be solved in dev-tools/maven, in its executions it could call whatever ant stuff it needs to work.
        Hide
        Steve Rowe added a comment -

        There are no longer any non-mavenized jars in the build, so ivy resolve is not a requirement before running the maven build

        Show
        Steve Rowe added a comment - There are no longer any non-mavenized jars in the build, so ivy resolve is not a requirement before running the maven build
        Hide
        Steve Rowe added a comment -

        Hmm, JIRA lost a comment I made on this issue before resolving (or I screwed up by editing the issue before submitting a comment I was making) - it was something like:

        I confused releasing and enabling 'the maven build', which involves putting the POMs in place via ant get-maven-poms and installing non-mavenized dependencies into the user's local maven repository via mvn -P bootstrap install. The source of the non-mavenized dependencies was the lib/ directories, which are empty until ivy resolve is done, so ivy resolve is a prerequisite.

        However, since there are no longer any non-mavenized dependencies (see SOLR-3308, LUCENE-3930, and SOLR-3310 - thanks Robert Muir and Chris Male), ivy resolve is no longer a prerequisite for running 'the maven build'. I'll resolve this issue as Invalid.

        Show
        Steve Rowe added a comment - Hmm, JIRA lost a comment I made on this issue before resolving (or I screwed up by editing the issue before submitting a comment I was making) - it was something like: I confused releasing and enabling 'the maven build', which involves putting the POMs in place via ant get-maven-poms and installing non-mavenized dependencies into the user's local maven repository via mvn -P bootstrap install . The source of the non-mavenized dependencies was the lib/ directories, which are empty until ivy resolve is done, so ivy resolve is a prerequisite. However, since there are no longer any non-mavenized dependencies (see SOLR-3308 , LUCENE-3930 , and SOLR-3310 - thanks Robert Muir and Chris Male), ivy resolve is no longer a prerequisite for running 'the maven build'. I'll resolve this issue as Invalid.
        Hide
        Robert Muir added a comment -

        so we can remove generate-maven-artifacts task totally?

        Then we just have the releasing task: dist-maven

        Show
        Robert Muir added a comment - so we can remove generate-maven-artifacts task totally? Then we just have the releasing task: dist-maven
        Hide
        Steve Rowe added a comment -

        dist-maven isn't recursive - generate-maven-artifacts provides dist-maven recursion.

        I'm missing some dots you've connected here - how is it that 'the maven build' not needing ant resolve to function means that generate-maven-artifacts is not necessary?

        Show
        Steve Rowe added a comment - dist-maven isn't recursive - generate-maven-artifacts provides dist-maven recursion. I'm missing some dots you've connected here - how is it that 'the maven build' not needing ant resolve to function means that generate-maven-artifacts is not necessary?
        Hide
        Robert Muir added a comment -

        ok i see: maven build still requires this task, it just doesnt need the libs resolved...

        Show
        Robert Muir added a comment - ok i see: maven build still requires this task, it just doesnt need the libs resolved...
        Hide
        Robert Muir added a comment -

        on 3.x i think it wants the jetty jars to be there.
        but this can be solved by simply adding an <ant dir="solr/example" target="resolve">
        to this top-level task only needed by the maven build.

        This way it wont interfere with any release tasks.

        Show
        Robert Muir added a comment - on 3.x i think it wants the jetty jars to be there. but this can be solved by simply adding an <ant dir="solr/example" target="resolve"> to this top-level task only needed by the maven build. This way it wont interfere with any release tasks.
        Hide
        Steve Rowe added a comment -

        ok i see: maven build still requires this task, it just doesnt need the libs resolved...

        'The maven build' doesn't require generate-maven-artifacts, and never has.

        Show
        Steve Rowe added a comment - ok i see: maven build still requires this task, it just doesnt need the libs resolved... 'The maven build' doesn't require generate-maven-artifacts , and never has.
        Hide
        Robert Muir added a comment -

        reopening since i want a maven build before rc for 3.x

        Show
        Robert Muir added a comment - reopening since i want a maven build before rc for 3.x
        Hide
        Robert Muir added a comment -

        patch for 3.x

        Show
        Robert Muir added a comment - patch for 3.x
        Hide
        Steve Rowe added a comment -

        on 3.x i think it wants the jetty jars to be there.
        but this can be solved by simply adding an <ant dir="solr/example" target="resolve">
        to this top-level task only needed by the maven build.

        Yes, you're right, only on branch_3x, where jetty and jetty-util are still locally-modified non-released test dependencies, 'the maven build' (specifically running tests under Maven) needs these two jars to be in solr/example/lib. Re-opening...

        Show
        Steve Rowe added a comment - on 3.x i think it wants the jetty jars to be there. but this can be solved by simply adding an <ant dir="solr/example" target="resolve"> to this top-level task only needed by the maven build. Yes, you're right, only on branch_3x, where jetty and jetty-util are still locally-modified non-released test dependencies, 'the maven build' (specifically running tests under Maven) needs these two jars to be in solr/example/lib . Re-opening...
        Hide
        Robert Muir added a comment -

        'The maven build' doesn't require generate-maven-artifacts, and never has.

        well at least hudson needs to call the logic in my patch (somehow) because
        the maven bootstrap uses:

         <file>solr/example/lib/jetty-${patched.jetty.version}.jar</file>
        
        Show
        Robert Muir added a comment - 'The maven build' doesn't require generate-maven-artifacts, and never has. well at least hudson needs to call the logic in my patch (somehow) because the maven bootstrap uses: <file>solr/example/lib/jetty-${patched.jetty.version}.jar</file>
        Hide
        Robert Muir added a comment -

        And it seems that maven could do this itself in its executions?
        see http://search.maven.org/remotecontent?filepath=org/apache/rat/apache-rat-tasks/0.8/apache-rat-tasks-0.8.pom
        for an example?

        Show
        Robert Muir added a comment - And it seems that maven could do this itself in its executions? see http://search.maven.org/remotecontent?filepath=org/apache/rat/apache-rat-tasks/0.8/apache-rat-tasks-0.8.pom for an example?
        Hide
        Steve Rowe added a comment -

        'The maven build' doesn't require generate-maven-artifacts, and never has.

        well at least hudson needs to call the logic in my patch (somehow) because the maven bootstrap uses:

        <file>solr/example/lib/jetty-${patched.jetty.version}.jar</file>

        Your patch puts ant resolve in the wrong place.

        mvn -P bootstrap install is run by the jenkins script before attempting to run mvn install and mvn test, but ant genenerate-maven-artifacts is called by the jenkins script after running all of these (to deploy snapshots), so ant resolve should happen before any of the mvn ... stuff.

        And it seems that maven could do this itself in its executions?
        see http://search.maven.org/remotecontent?filepath=org/apache/rat/apache-rat-tasks/0.8/apache-rat-tasks-0.8.pom for an example?

        Yes, you're right - the ant build shouldn't have to deal with this at all. I'll make a patch.

        Show
        Steve Rowe added a comment - 'The maven build' doesn't require generate-maven-artifacts, and never has. well at least hudson needs to call the logic in my patch (somehow) because the maven bootstrap uses: <file>solr/example/lib/jetty-${patched.jetty.version}.jar</file> Your patch puts ant resolve in the wrong place. mvn -P bootstrap install is run by the jenkins script before attempting to run mvn install and mvn test , but ant genenerate-maven-artifacts is called by the jenkins script after running all of these (to deploy snapshots), so ant resolve should happen before any of the mvn ... stuff. And it seems that maven could do this itself in its executions? see http://search.maven.org/remotecontent?filepath=org/apache/rat/apache-rat-tasks/0.8/apache-rat-tasks-0.8.pom for an example? Yes, you're right - the ant build shouldn't have to deal with this at all. I'll make a patch.
        Hide
        Robert Muir added a comment -

        ok thanks... i'm admittedly lost in how the maven build uses these tasks,
        I just know that packaging works and was trying to think of solutions that
        don't mess with that... thanks!

        Show
        Robert Muir added a comment - ok thanks... i'm admittedly lost in how the maven build uses these tasks, I just know that packaging works and was trying to think of solutions that don't mess with that... thanks!
        Hide
        Steve Rowe added a comment -

        Patch invoking the resolve target in solr/example/build.xml via the maven-antrun-plugin from the bootstrap profile in the Lucene/Solr grandfather POM.

        The Ivy jar included on the classpath for the maven-antrun-plugin is from the user's Maven local repository, apparently because maven-antrun-plugin doesn't look in ~/.ant/lib/: http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html.

        Works for me locally (from the top-level dir):

        • ant clean clean-jars get-maven-poms
        • mvn -N -P bootstrap install -Divy.default.ivy.user.dir=...
        • mvn -DskipTests install
        • mvn test

        Committing shortly.

        Show
        Steve Rowe added a comment - Patch invoking the resolve target in solr/example/build.xml via the maven-antrun-plugin from the bootstrap profile in the Lucene/Solr grandfather POM. The Ivy jar included on the classpath for the maven-antrun-plugin is from the user's Maven local repository, apparently because maven-antrun-plugin doesn't look in ~/.ant/lib/ : http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html . Works for me locally (from the top-level dir): ant clean clean-jars get-maven-poms mvn -N -P bootstrap install -Divy.default.ivy.user.dir=... mvn -DskipTests install mvn test Committing shortly.
        Hide
        Steve Rowe added a comment -

        The nightly Jenkins branch_3x Maven job failed because of ivy.default.ivy.user.dir sysprop problems (passing through the non-interpolated reference):

        [INFO] An Ant BuildException has occured: The following error occurred while executing this line:
        /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/solr/example/build.xml:39: java.lang.IllegalArgumentException: ivy.default.ivy.user.dir must be absolute: ${ivy.default.ivy.user.dir}
        around Ant part ...<ant inheritall="false" target="resolve" antfile="solr/example/build.xml">... @ 4:77 in /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/lucene/build/lucene-solr-grandparent/antrun/build-main.xml

        This patch fixes the maven-antrun-plugin setup by defining two executions, one for the case where ivy.default.ivy.user.dir is set, and another for where it is not.

        Committing shortly.

        Show
        Steve Rowe added a comment - The nightly Jenkins branch_3x Maven job failed because of ivy.default.ivy.user.dir sysprop problems (passing through the non-interpolated reference): [INFO] An Ant BuildException has occured: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/solr/example/build.xml:39: java.lang.IllegalArgumentException: ivy.default.ivy.user.dir must be absolute: ${ivy.default.ivy.user.dir} around Ant part ...<ant inheritall="false" target="resolve" antfile="solr/example/build.xml">... @ 4:77 in /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/lucene/build/lucene-solr-grandparent/antrun/build-main.xml This patch fixes the maven-antrun-plugin setup by defining two executions, one for the case where ivy.default.ivy.user.dir is set, and another for where it is not. Committing shortly.
        Hide
        Steve Rowe added a comment -

        Same patch, with the right issue number in the name this time.

        Show
        Steve Rowe added a comment - Same patch, with the right issue number in the name this time.
        Hide
        Steve Rowe added a comment -

        The most recent Jenkins nightly branch_3x Maven job made it past Ant resolution and compilation, though it had a failure in one of the Solr contribs. That test failure is unrelated to this issue, though, so I'm resolving as fixed.

        Show
        Steve Rowe added a comment - The most recent Jenkins nightly branch_3x Maven job made it past Ant resolution and compilation, though it had a failure in one of the Solr contribs. That test failure is unrelated to this issue, though, so I'm resolving as fixed.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development