Maven 1.x Multi-Project Plugin
  1. Maven 1.x Multi-Project Plugin
  2. MPMULTIPROJECT-11

multiproject:artifact builds do not use local project artifacts for dependencies

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      WinXP
    • Number of attachments :
      0

      Description

      Suppose I have a "multiproject" with 3 subprojects, called "api", "ri" and "tck", each with a current version of "1.0-b1-SNAPSHOT".

      The dependencies are setup as follows:
      ri-1.0-b1-SNAPSHOT -> api-1.0-b1-SNAPSHOT
      tck-1.0-b1-SNAPSHOT -> api-1.0-b1-SNAPSHOT

      When I use multiproject plugin to build, the dependencies are not picked up as expected.

      > maven multiproject:artifact

      Starting the reactor...
      Our processing order:
      api
      ri
      tck

      +----------------------------------------

      Executing multiproject:artifact-callback api
      Memory: 4M/6M
      +----------------------------------------
      ...
      [echo] Running jar:jar for api
      ...

      +----------------------------------------

      Executing multiproject:artifact-callback Oracle EL RI
      Memory: 7M/9M
      +----------------------------------------

      BUILD FAILED
      File...... [maven.repo.local]/plugins/maven-multiproject-plugin-1.0/
      Element... maven:reactor
      Line...... 191
      Column.... 9
      The build cannot continue because of the following unsatisfied dependency:

      api-1.0-b1-SNAPSHOT.jar

      This is happening because the api artifact is not present in the local maven repository and cannot therefore be resolved by the ri project.

      It would be much more convenient if this multiproject:artifact goal worked without needing to install artifacts into the local repository.

      The reactor has already figured out the build order based on the dependency chain, so it is already quite clear which project dependencies are satisfied by other projects being built during the same multiproject:artifact execution.

      These specific dependencies could be overridden by multiproject during a subproject build, and instead point to the local target area of the corresponding peer project.

      So, for example, the ri subproject $

      {pom}

      processed by multiproject:artifact-callback could be modified to point to "$

      {basedir}

      /../api/target/api-1.0-SNAPSHOT.jar" for the api dependency, instead of pointing at the local maven repository.

      This would have 3 distinct advantages.

      1. multiproject:artifact builds would succeed when the local maven repository does not contain the peer subproject dependencies.

      2. multiproject:artifact builds would succeed when the local maven repository contains stale peer subproject dependencies previously downloaded from the remote maven repository.

      3. multiproject:artifact builds would succeed even for peer subproject SNAPSHOT dependencies which would otherwise be overwritten in the local maven repository when the stale api SNAPSHOT jar is re-downloaded from the remote maven repository, during the build of the ri subproject.

      Note. This strategy would also allow multiproject:install to work for 1.0-b1-SNAPSHOT version, without forcing an offline build. Requiring the build to be offline in this case is inconvenient because other dependencies cannot be downloaded on demand to the local maven repository.

        Activity

        Hide
        John Fallows added a comment -

        Btw, I upgraded to maven-multiproject-plugin-1.0 to test this out.
        (maven-multiproject-plugin-1.0-SNAPSHOT is bundled with maven-1.0-beta-10)

        Show
        John Fallows added a comment - Btw, I upgraded to maven-multiproject-plugin-1.0 to test this out. (maven-multiproject-plugin-1.0-SNAPSHOT is bundled with maven-1.0-beta-10)
        Hide
        dion gillard added a comment -

        Use multiproject:install to do this if the dependencies are out of date.

        Show
        dion gillard added a comment - Use multiproject:install to do this if the dependencies are out of date.
        Hide
        dion gillard added a comment -

        reopening as there are some good ideas here

        Show
        dion gillard added a comment - reopening as there are some good ideas here
        Hide
        Daniel Bonniot added a comment -

        I'd be interested to get this working. Any idea how to do it? I thought about using maven.jar.override=on and maven.jar.<id>=/local/jar
        The problem is to understand how contexts work. Is it possible to access the list of reactor projects from the 'callback', which is executed in each project's context, so that the properties can be set in all the other projects? Or to set "globally" the maven.jar.override=on and maven.jar.<id>=/local/jar?

        Show
        Daniel Bonniot added a comment - I'd be interested to get this working. Any idea how to do it? I thought about using maven.jar.override=on and maven.jar.<id>=/local/jar The problem is to understand how contexts work. Is it possible to access the list of reactor projects from the 'callback', which is executed in each project's context, so that the properties can be set in all the other projects? Or to set "globally" the maven.jar.override=on and maven.jar.<id>=/local/jar?
        Hide
        John Fallows added a comment -

        The multiproject plugin uses the reactor internally, which can provide access to all the subprojects, but only after the reactor has completed.

        Perhaps we could first use the reactor with a no-op goal to obtain a reference to all the subprojects, then use that information during a second reactor execution for the multiproject goal's normal use, and set the jar overrides, as you suggest.

        Show
        John Fallows added a comment - The multiproject plugin uses the reactor internally, which can provide access to all the subprojects, but only after the reactor has completed. Perhaps we could first use the reactor with a no-op goal to obtain a reference to all the subprojects, then use that information during a second reactor execution for the multiproject goal's normal use, and set the jar overrides, as you suggest.

          People

          • Assignee:
            Unassigned
            Reporter:
            John Fallows
          • Votes:
            4 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: