Just recently with 2.0.7 and 2.0.8...it's always been that way. The current mdep issue caused by this is: http://jira.codehaus.org/browse/MDEP-98 I added an IT for it, but currently it's committed to execute the package phase so it doesn't fail. (haven't fixed the plugin yet) If you change it to compile, it will fail cause you can't unpack a folder.
-----Original Message----- From: Piotr Tabor [mailto:[EMAIL PROTECTED] Sent: Thursday, August 23, 2007 11:24 AM To: Maven Developers List Subject: Re: MNG-2871 - internal dependencies and phases below "package" 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
