You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Piotr Tabor <pt...@newitech.com> on 2007/08/23 04:53:58 UTC
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.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.
Thank you,
Piotr Tabor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: MNG-2871 - internal dependencies and phases below "package"
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:ptab@newitech.com]
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: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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-2871 - internal dependencies and phases below "package"
Posted by Piotr Tabor <pt...@newitech.com>.
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
RE: MNG-2871 - internal dependencies and phases below "package"
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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