maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Tabor <p...@newitech.com>
Subject Re: MNG-2871 - internal dependencies and phases below "package"
Date Thu, 23 Aug 2007 15:24:16 GMT
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:ptab@newitech.com] 
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message