Unpacking primary artifact from sibling module uses repository rather than reactor

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 2.0-alpha-4
  • Fix Version/s: 2.3
  • Component/s: unpack
  • Labels:
    None

Description

Running dependency:unpack referencing a project in the reactor has the following output which shows it is scanning for repository artifacts rather than the artifact in the reactor:

[INFO] [dependency:unpack \{execution: unpack-tests}]
[INFO] Configured Artifact: com.example.app:app-acceptance-test:2.6-SNAPSHOT:jar
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking for updates from snapshots
[INFO] snapshot com.example.app:app-acceptance-test:2.6-SNAPSHOT: checking for updates from m1-repo
Downloading: http://m2proxy:8081/artifactory/repo/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-20070829.025709-409.jar
9125K downloaded
[INFO] Expanding: /Users/mryall/.m2/repository/com/example/app/app-acceptance-test/2.6-SNAPSHOT/app-acceptance-test-2.6-SNAPSHOT.jar into /Users/mryall/src/example/app/app-webapp/target/it-classes

To explain the scenario: to build reusable acceptance tests, I have the following sub-modules of my project:

  • app-core (jar)
  • app-acceptance-tests (jar)
  • app-webapp (war)

The acceptance tests are packaged this way for further use in testing, and also run against the webapp in the integration-test phase. This is where the problem arises.

Running 'mvn clean integration-test' does the following relevant tasks:

  • in the app-acceptance-test module, compiles and packages a JAR of tests
  • in the app-webapp module, uses the dependency:unpack goal to extract the tests into target/it-classes in the pre-integration-test phase, and test:test to run them in the integration test phase.

I don't think this is caused by the snapshot version, because the release plugin also fails because it is unable to find the 2.6 version when it runs 'mvn clean verify'. There, it scans all the repositories for the acceptance test artifact before failing with the usual error:

[INFO] Failed to resolve artifact.

GroupId: com.example.app
ArtifactId: app-acceptance-test
Version: 2.6

Reason: Unable to download the artifact from any repository

Maven details:

$ mvn -version
Maven version: 2.0.7
Java version: 1.4.2_12
OS name: "mac os x" version: "10.4.10" arch: "i386"

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. MDEP-316 dependency:copy and dependency:unpack behave differently with M2 and M3 (should always search the reactor for artifacts)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MDEP-44 unpacking/copying of attached artifacts from reactor projects doesn't work

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MDEP-153 Active dependencies being unpacked but not listed as normal dependencies are not used by the reactor in determing build order

  • Critical - Crashes, loss of data, severe memory leak.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dennis Lundberg added a comment -

As mentioned in MNG-2877, this doesn't seem to be a bug in the Dependency Plugin itself, but rather a bug in the dependency resolution code in Maven core. We've just ran into this very problem. Using Maven 2.0.11 or 2.2.1 the build fails, but using Maven 3.0-beta-1 it is successful.

Show
Dennis Lundberg added a comment - As mentioned in MNG-2877, this doesn't seem to be a bug in the Dependency Plugin itself, but rather a bug in the dependency resolution code in Maven core. We've just ran into this very problem. Using Maven 2.0.11 or 2.2.1 the build fails, but using Maven 3.0-beta-1 it is successful.
Hide
Permalink
Brian Fox added a comment -

It conceivably could be fixed in the plugin to check the reactor, but I'm unlikely to do it since M3 solves this for us. If someone wants to attach a patch then I'll take a look

Show
Brian Fox added a comment - It conceivably could be fixed in the plugin to check the reactor, but I'm unlikely to do it since M3 solves this for us. If someone wants to attach a patch then I'll take a look
Hide
Permalink
Samuel Le Berrigaud added a comment -

If you want to unpack dependencies that are in the reactor the dependency:unpack-dependencies is the goal you're after. To my understanding dependency:unpack will only ever look in the local and remote repositories.

Show
Samuel Le Berrigaud added a comment - If you want to unpack dependencies that are in the reactor the dependency:unpack-dependencies is the goal you're after. To my understanding dependency:unpack will only ever look in the local and remote repositories.
Hide
Permalink
Stephen Connolly added a comment -

MDEP-316

Show
Stephen Connolly added a comment - MDEP-316
Hide
Permalink
Matt Ryall added a comment -

Thanks for the update, Stephen.

Show
Matt Ryall added a comment - Thanks for the update, Stephen.

People

  • Assignee:
    Brian Fox
    Reporter:
    Matt Ryall
Vote (5)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: