Maven
  1. Maven
  2. MNG-2871

Subartifact (ejb-client, test-jar etc.) are not reselved as active project artifacts in build phases prior to package

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.4, 2.0.5
    • Fix Version/s: 3.0-alpha-1
    • Component/s: Dependencies
    • Labels:
      None
    • Environment:
      Not platform dependent
    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Patch Submitted:
      Yes
    • Number of attachments :
      6

      Description

      I have prepared simple project to show the bug.
      It contains three artifacts:

      -root
      --- ejb3
      --- client

      Client depends on ejb3 with <type>ejb-client</type>.

      The local and remote repository must not contain those artifacts.
      When I do "mvn -X compile" (or even integration-tests) on root project I will
      get those errors:

      ...
      [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -->
      [DEBUG] (f) filters = []
      [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes
      [DEBUG] (f) project = org.apache.maven.project.MavenProject@f6a17377
      [DEBUG] (f) resources = [org.apache.maven.model.Resource@4f34b07e]
      [DEBUG] – end configuration –
      [INFO] [resources:resources]
      [INFO] Using default encoding to copy filtered resources.
      [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null)
      [DEBUG] junit:junit:jar:3.8.1:test (selected for test)
      [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile)
      [DEBUG] Skipping disabled repository Newitech-repository
      [DEBUG] Skipping disabled repository central
      [DEBUG] ejb3: using locally installed snapshot
      [DEBUG] Trying repository Newitech-snapshots-repository
      Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
      [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots)
      [DEBUG] Skipping disabled repository Newitech-repository
      [DEBUG] Trying repository Newitech-publiczne
      Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
      [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/)
      [DEBUG] Trying repository Maven Snapshots
      Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
      [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository)
      [DEBUG] Trying repository codehausSnapshots
      Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar
      [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2)
      [DEBUG] Skipping disabled repository central
      [DEBUG] Unable to download the artifact from any repository

      Try downloading the file manually from the project website.

      Then, install it using the command:
      mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
      -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file

      Path to dependency:
      1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
      2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

      pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT

      from the specified remote repositories:
      Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
      central (http://repo1.maven.org/maven2),
      codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
      Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
      Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
      Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech)

      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Failed to resolve artifact.

      Missing:
      ----------
      1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

      Try downloading the file manually from the project website.

      Then, install it using the command:
      mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
      -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file

      Path to dependency:
      1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
      2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

      ----------
      1 required artifact is missing.

      for artifact:
      pl.waw.tabor:client:jar:1.0-SNAPSHOT

      from the specified remote repositories:
      Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
      central (http://repo1.maven.org/maven2),
      codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
      Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
      Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
      Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech)

      [INFO] ------------------------------------------------------------------------
      [DEBUG] Trace
      org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
      ----------
      1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

      Try downloading the file manually from the project website.

      Then, install it using the command:
      mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
      -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file

      Path to dependency:
      1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
      2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

      ----------
      1 required artifact is missing.

      for artifact:
      pl.waw.tabor:client:jar:1.0-SNAPSHOT

      from the specified remote repositories:
      Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
      central (http://repo1.maven.org/maven2),
      codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
      Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
      Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
      Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech)

      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
      at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
      at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
      at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
      at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
      at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
      at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
      Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
      ----------
      1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

      Try downloading the file manually from the project website.

      Then, install it using the command:
      mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \
      -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file

      Path to dependency:
      1) pl.waw.tabor:client:jar:1.0-SNAPSHOT
      2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT

      ----------
      1 required artifact is missing.

      for artifact:
      pl.waw.tabor:client:jar:1.0-SNAPSHOT

      from the specified remote repositories:
      Maven Snapshots (http://people.apache.org/maven-snapshot-repository),
      central (http://repo1.maven.org/maven2),
      codehausSnapshots (http://snapshots.maven.codehaus.org/maven2),
      Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots),
      Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/),
      Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech)

      at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305)
      at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
      at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
      at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1142)
      at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:374)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
      ... 16 more
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 8 seconds
      [INFO] Finished at: Mon Mar 12 20:34:44 CET 2007
      [INFO] Final Memory: 6M/15M
      [INFO] ------------------------------------------------------------------------
      ==================================================================================================

      I am sure, the most important line from this log is:
      [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile)

      I would like to see
      "[DEBUG] active project artifact:
      artifact = pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile;
      project: org.apache.maven.project.MavenProject@e82f22ea (selected for compile)"
      instead.

      If I do "mvn install" -> The source will compile (because ejb3-client artifact will be found in local repository).

      I investigated the source, and found that the reason is in org.apache.maven.project.MavenProject class in
      replaceWithActiveArtifact (method):
      The line "if (( ref.getArtifact().getDependencyConflictId().equals( pluginArtifact.getDependencyConflictId() ))"
      fails because ref.getArtifact().getDependencyConflictId() is pl.waw.tabor:ejb3:ejb-client:client and
      pluginArtifact.getDependencyConflictId() is pl.waw.tabor:ejb3.

      It is my workaround. I know - it is very messy.
      If you helped me - where is the best place to correct it - i would prepare a proper
      patch.

      Index: components/maven-project/src/main/java/org/apache/maven/project/MavenProject.java
      ===================================================================
      — components/maven-project/src/main/java/org/apache/maven/project/MavenProject.java (wersja 517335)
      +++ components/maven-project/src/main/java/org/apache/maven/project/MavenProject.java (kopia robocza)
      @@ -1582,7 +1582,14 @@
      if ( ref != null && ref.getArtifact() != null )
      {
      // TODO: if not matching, we should get the correct artifact from that project (attached)

      • if ( ref.getArtifact().getDependencyConflictId().equals( pluginArtifact.getDependencyConflictId() ) )
        + if (( ref.getArtifact().getDependencyConflictId().equals( pluginArtifact.getDependencyConflictId() ))
        + || (
        + (ref.getArtifactId().equals(pluginArtifact.getArtifactId()))&&
        + (ref.getGroupId().equals(pluginArtifact.getGroupId()))&&
        + (ref.getArtifact().getType().equals("ejb"))&&
        + (pluginArtifact.getType().equals("ejb-client"))
        + )
        + )
        {
        // if the project artifact doesn't exist, don't use it. We haven't built that far.
        if ( ref.getArtifact().getFile() != null && ref.getArtifact().getFile().exists() )
      1. MavenProject.java
        52 kB
        Chris Wewerka
      2. MNG-2871-core-integration-testing-2.diff
        2 kB
        Piotr Tabor
      3. MNG-2871-core-integration-tests.diff
        16 kB
        Piotr Tabor
      4. MNG-2871-maven-project.diff
        1 kB
        Piotr Tabor
      5. MNG-2871-maven-project-2.1-SNAPSHOT.diff
        1 kB
        Piotr Tabor
      6. root.tar
        190 kB
        Piotr Tabor

        Issue Links

          Activity

          Hide
          Piotr Tabor added a comment -

          The simple project - to repeat the bug.

          Show
          Piotr Tabor added a comment - The simple project - to repeat the bug.
          Hide
          Piotr Tabor added a comment -

          The bug is very serious - because it happens every time you use
          mvn release:prepare plugin (because there are started integration-tests in embedded maven session) - and
          they always fail - because there is no such a artifact in maven local repository after increasing version number.

          Show
          Piotr Tabor added a comment - The bug is very serious - because it happens every time you use mvn release:prepare plugin (because there are started integration-tests in embedded maven session) - and they always fail - because there is no such a artifact in maven local repository after increasing version number.
          Hide
          Chris Wewerka added a comment -

          Maven 2.0.6 with release plugin 2.0-beta 5 also has the problem. See http://jira.codehaus.org/browse/MRELEASE-161

          Show
          Chris Wewerka added a comment - Maven 2.0.6 with release plugin 2.0-beta 5 also has the problem. See http://jira.codehaus.org/browse/MRELEASE-161
          Hide
          Chris Wewerka added a comment -

          I tested the supplied patch (extended for test-jars) by piotr (i know it's a hack, but we need it working too) with maven 2.0.6 and release plugin 2.0-beta-5, and it doesn't work during release:prepare.

          I've added some sysouts to track down the problem (see attached MavenProject.java) and I think the problem in m2.0.6(at least with test-jars) lies in a loss of the type information "test-jar".

          Attached artifact: org.apache.maven.project.artifact.AttachedArtifact
          Attached artifact: release-test-module-one:com.o2.release-test:jar:null
          attached.getDependencyConflictId(): com.o2.release-test:release-test-module-one:jar:tests ;pluginArtifact.getDependencyConflictId():com.o2.release-test:release-test-module-one:test-jar:tests

          Here you can see that "attached.getDependencyConflictId()" returns com.o2.release-test:release-test-module-one:jar:tests.
          I would expect com.o2.release-test:release-test-module-one:test-jar:tests, so the next code line returns false during release:prepare:
          ...
          if( attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())
          ...

          So what I`ve done is to add the following hack:

          if( attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())

          (
          attached.getArtifactId().equals(pluginArtifact.getArtifactId()) &&
          attached.getGroupId().equals(pluginArtifact.getGroupId()) &&
          attached.getClassifier() != null &&
          attached.getClassifier().equals(pluginArtifact.getClassifier())
          )
          ) {
          ...

          But I'm very sure the real problem lies somewhere else.

          Show
          Chris Wewerka added a comment - I tested the supplied patch (extended for test-jars) by piotr (i know it's a hack, but we need it working too) with maven 2.0.6 and release plugin 2.0-beta-5, and it doesn't work during release:prepare. I've added some sysouts to track down the problem (see attached MavenProject.java) and I think the problem in m2.0.6(at least with test-jars) lies in a loss of the type information "test-jar". Attached artifact: org.apache.maven.project.artifact.AttachedArtifact Attached artifact: release-test-module-one:com.o2.release-test:jar:null attached.getDependencyConflictId(): com.o2.release-test:release-test-module-one:jar:tests ;pluginArtifact.getDependencyConflictId():com.o2.release-test:release-test-module-one:test-jar:tests Here you can see that "attached.getDependencyConflictId()" returns com.o2.release-test:release-test-module-one:jar:tests. I would expect com.o2.release-test:release-test-module-one:test-jar:tests, so the next code line returns false during release:prepare: ... if( attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId()) ... So what I`ve done is to add the following hack: if( attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId()) ( attached.getArtifactId().equals(pluginArtifact.getArtifactId()) && attached.getGroupId().equals(pluginArtifact.getGroupId()) && attached.getClassifier() != null && attached.getClassifier().equals(pluginArtifact.getClassifier()) ) ) { ... But I'm very sure the real problem lies somewhere else.
          Hide
          Chris Wewerka added a comment -

          Hack in MavenProject.java (Line 1643 ff.) and commented sysouts.

          Show
          Chris Wewerka added a comment - Hack in MavenProject.java (Line 1643 ff.) and commented sysouts.
          Hide
          Piotr Tabor added a comment - - edited

          New integrating tests for the issue (ejb-client) and (test-jar) attached.

          ejb-client test passes.
          test-jar test fails.

          The dependency types (classifiers) are the most popular... but the problem probably touch all classified (sub-)dependences.

          Show
          Piotr Tabor added a comment - - edited New integrating tests for the issue (ejb-client) and (test-jar) attached. ejb-client test passes. test-jar test fails. The dependency types (classifiers) are the most popular... but the problem probably touch all classified (sub-)dependences.
          Hide
          Piotr Tabor added a comment -

          Chris, could you check if your problem is resolved with current (SVN/SNAPSHOT) version of maven-jar-plugin.
          I hope MJAR-75 that was fixed, resolved this issue too.

          Thank you

          Show
          Piotr Tabor added a comment - Chris, could you check if your problem is resolved with current (SVN/SNAPSHOT) version of maven-jar-plugin. I hope MJAR-75 that was fixed, resolved this issue too. Thank you
          Hide
          Chris Wewerka added a comment -

          Piotr, I've tested it and it's working with test jars. Thanks. Hopefully the new version of the jar plugin is to be released soon!

          Show
          Chris Wewerka added a comment - Piotr, I've tested it and it's working with test jars. Thanks. Hopefully the new version of the jar plugin is to be released soon!
          Hide
          Piotr Tabor added a comment -

          "New" test case (that is only update to currently existing test
          that make the current it-120 covering the problem too).

          (I'm author of it-120 - so I am sure this patch will not destroy the idea of original test case)

          Show
          Piotr Tabor added a comment - "New" test case (that is only update to currently existing test that make the current it-120 covering the problem too). (I'm author of it-120 - so I am sure this patch will not destroy the idea of original test case)
          Hide
          Piotr Tabor added a comment -

          Clean patch for this issue.

          Show
          Piotr Tabor added a comment - Clean patch for this issue.
          Hide
          Piotr Tabor added a comment - - edited

          Clean (i hope) view of this issue:

          The problem could be called "internal dependencies" in reactor when everything is build by phase lower then "package". The real
          jar's for such a dependencies like client-jar or test-jar are created and attached to original artifacts in "package" phase.
          So if we call "mvn test" for a parent pom we will not get this (client-jar, test-jar) files build - so the dependencies will not be resolved internally... They
          will be resolved from repository (if they exist there - so not actual version may be used) or the build will fail.

          I see there two options:
          a) Close this bug as WON'T BE FIXED (because it's design issue) and answer is 'don't call "mvn test"' to do the tests... call
          mvn package instead.

          at least we can add warning in a such a case: "Dependency ... has not been resolved internally. Calling 'mvn package' or greater phase may
          resolve your problem." If we decide to this solution, I can prepare such a patch.

          or

          b) Apply currently attached patches (MNG-2871-maven-project.diff, MNG-2871-core-integration-testing-2.diff) that
          will make things much better in case of ejb and ejb-client artifacts (that is IMHO the most frequent and important usage of attached artifact).
          I don't like exception's, but it may be worth. The main disadvantages are that it is exception and that we will provide more then client would need (declared ejb-client but we will link to whole jar).

          The problem is most annoying because maven-release-plugin calls "mvn test" after upgrading version's number... So it leads to
          "mvn release:prepare" failure in case of ejb-client dependencies.

          Show
          Piotr Tabor added a comment - - edited Clean (i hope) view of this issue: The problem could be called "internal dependencies" in reactor when everything is build by phase lower then "package". The real jar's for such a dependencies like client-jar or test-jar are created and attached to original artifacts in "package" phase. So if we call "mvn test" for a parent pom we will not get this (client-jar, test-jar) files build - so the dependencies will not be resolved internally... They will be resolved from repository (if they exist there - so not actual version may be used) or the build will fail. I see there two options: a) Close this bug as WON'T BE FIXED (because it's design issue) and answer is 'don't call "mvn test"' to do the tests... call mvn package instead. at least we can add warning in a such a case: "Dependency ... has not been resolved internally. Calling 'mvn package' or greater phase may resolve your problem." If we decide to this solution, I can prepare such a patch. or b) Apply currently attached patches ( MNG-2871 -maven-project.diff, MNG-2871 -core-integration-testing-2.diff) that will make things much better in case of ejb and ejb-client artifacts (that is IMHO the most frequent and important usage of attached artifact). I don't like exception's, but it may be worth. The main disadvantages are that it is exception and that we will provide more then client would need (declared ejb-client but we will link to whole jar). The problem is most annoying because maven-release-plugin calls "mvn test" after upgrading version's number... So it leads to "mvn release:prepare" failure in case of ejb-client dependencies.
          Hide
          Jason van Zyl added a comment -

          Piotr is preparing the patch for trunk, and I will apply it.

          Show
          Jason van Zyl added a comment - Piotr is preparing the patch for trunk, and I will apply it.
          Hide
          Piotr Tabor added a comment -

          Patch for trunk (2.1-SNAPSHOT) (rev. 572195)

          Show
          Piotr Tabor added a comment - Patch for trunk (2.1-SNAPSHOT) (rev. 572195)
          Hide
          Jason van Zyl added a comment -

          Patch applied to maven-project and the ITs.

          Show
          Jason van Zyl added a comment - Patch applied to maven-project and the ITs.
          Hide
          Chris Wewerka added a comment -

          May there be any hope that this very annoying bug will also be fixed in 2.0.x version of maven?

          Show
          Chris Wewerka added a comment - May there be any hope that this very annoying bug will also be fixed in 2.0.x version of maven?

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Piotr Tabor
            • Votes:
              5 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: