[#MNG-2871] Subartifact (ejb-client, test-jar etc.) are not reselved as active project artifacts in build phases prior to package - jira.codehaus.org

Details

Type: Bug
Status: Closed
Priority: 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

[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

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

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() )

More Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

MavenProject.java

10/May/07 9:52 AM

52 kB

Chris Wewerka
MNG-2871-core-integration-testing-2.diff

22/Aug/07 7:55 PM

2 kB

Piotr Tabor
MNG-2871-core-integration-tests.diff

02/Jun/07 7:40 AM

16 kB

Piotr Tabor
MNG-2871-maven-project.diff

22/Aug/07 8:57 PM

1 kB

Piotr Tabor
MNG-2871-maven-project-2.1-SNAPSHOT.diff

02/Sep/07 7:23 PM

1 kB

Piotr Tabor
root.tar

12/Mar/07 2:51 PM

190 kB

Piotr Tabor

Issue Links

This issue relates to:
MNG-2921	ejb-client dependency no longer resolved in reactor build
MNG-2959	Version defined in dependencyManagement section of parent pom overwrites version of current artifact
MNG-3043	Allow 'mvn test' to work with test-jar dependencies in a reactor
MNG-2045	Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
MRELEASE-326	Doens't resolve multiproject dependencies properly
MNG-4248	CLONE -Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)

This issue is related to:
MRELEASE-161	If there is more than one artifact with the same artifactId in dependencyManagement only the first one is updated
MNG-3420	In a reactor, attached artifacts with classifier should be used when generating classpath, instead of the whole output directory of the related project

This issue depends upon:
MJAR-75	[PATCH] Wrong artifact type attached to the project by the test-jar goal

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Piotr Tabor added a comment - 12/Mar/07 2:51 PM

The simple project - to repeat the bug.

Show

Piotr Tabor added a comment - 12/Mar/07 2:51 PM The simple project - to repeat the bug.

Hide

Permalink

Piotr Tabor added a comment - 12/Mar/07 2:55 PM

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 - 12/Mar/07 2:55 PM 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

Permalink

Chris Wewerka added a comment - 10/May/07 3:56 AM

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 - 10/May/07 3:56 AM Maven 2.0.6 with release plugin 2.0-beta 5 also has the problem. See http://jira.codehaus.org/browse/MRELEASE-161

Hide

Permalink

Chris Wewerka added a comment - 10/May/07 9:50 AM

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 - 10/May/07 9:50 AM 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

Permalink

Chris Wewerka added a comment - 10/May/07 9:52 AM

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

Show

Chris Wewerka added a comment - 10/May/07 9:52 AM Hack in MavenProject.java (Line 1643 ff.) and commented sysouts.

Hide

Permalink

Piotr Tabor added a comment - 02/Jun/07 7:40 AM - 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 - 02/Jun/07 7:40 AM - 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

Permalink

Piotr Tabor added a comment - 15/Aug/07 11:24 AM

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 - 15/Aug/07 11:24 AM 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

Permalink

Chris Wewerka added a comment - 16/Aug/07 2:55 AM

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 - 16/Aug/07 2:55 AM 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

Permalink

Piotr Tabor added a comment - 22/Aug/07 7:55 PM

"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 - 22/Aug/07 7:55 PM "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

Permalink

Piotr Tabor added a comment - 22/Aug/07 8:57 PM

Clean patch for this issue.

Show

Piotr Tabor added a comment - 22/Aug/07 8:57 PM Clean patch for this issue.

Hide

Permalink

Piotr Tabor added a comment - 22/Aug/07 9:42 PM - 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.

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 - 22/Aug/07 9:42 PM - 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

Permalink

Jason van Zyl added a comment - 02/Sep/07 6:39 PM

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

Show

Jason van Zyl added a comment - 02/Sep/07 6:39 PM Piotr is preparing the patch for trunk, and I will apply it.

Hide

Permalink

Piotr Tabor added a comment - 02/Sep/07 7:23 PM

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

Show

Piotr Tabor added a comment - 02/Sep/07 7:23 PM Patch for trunk (2.1-SNAPSHOT) (rev. 572195)

Hide

Permalink

Jason van Zyl added a comment - 02/Sep/07 7:55 PM

Patch applied to maven-project and the ITs.

Show

Jason van Zyl added a comment - 02/Sep/07 7:55 PM Patch applied to maven-project and the ITs.

Hide

Permalink

Chris Wewerka added a comment - 09/Jul/08 5:26 AM

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 - 09/Jul/08 5:26 AM 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

Vote (5)

Watch (9)

Dates

Created:

12/Mar/07 2:49 PM

Updated:

21/Jul/09 4:47 AM

Resolved:

02/Sep/07 7:55 PM

Maven 2 & 3

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

Details

Description

Attachments

Issue Links

Activity

People

Dates