Hi Brian, When did you do that? The current patch tries first to use attached artifact - and when it will fail then links to the orginal project. So the current should work better then the "old" patch...
I am likely to agree that this (patching) will cause additional mess and we had better with a) option. Thank you, Piotr Brian E. Fox pisze: > Piotr, I did some investigation for a related MDEP issue. I found that > in the compile phase, the artifact is resolved with a path to the > classes folder. This works for compiling, but obviously doesn't work so > well for trying to copy a jar. In the package phase, the artifact is > resolved to the jar in the target folder. In >install, the artifact has > the file in the local repo. > > --Brian > > -----Original Message----- > From: Piotr Tabor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 22, 2007 10:54 PM > To: Maven Developers List > Subject: MNG-2871 - internal dependencies and phases below "package" > > I would like you to ask for your opinion about MNG-2871: > > 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 > <http://jira.codehaus.org/browse/MNG-2871>-maven-project.diff, MNG-2871 > <http://jira.codehaus.org/browse/MNG-2871>-core-integration-testing-2.di > ff) > 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. > > Thank you, > Piotr Tabor > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
