[
https://jira.codehaus.org/browse/MNG-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cintia DR updated MNG-5565:
---------------------------
Description:
If you have a aggregator-style plugin with requiresDependencyResolution, maven
will try to download artefacts from remote (if they are not in your local
repository or if you have a 'always' policy for that remote repository).
Binding the plugin to different phases or calling from CLI didn't change the
behaviour.
If the artefact actually exists in your remote repository, maven will download
it. Even worse if you include this aggregator-styte plugin as part of the
lifecycle of a module, because then the dependencies downloaded will be used -
instead of the ones built in the reactor - for the rest of the build. It's
pretty scary to build artefacts half reactor/half remote maven as a side effect
of calling a plugin that just wants to print the dependencies' names.
If the artefact doesn't exist in your maven local repo or remote, maven will
continue and the following warning:
{noformat}
The following dependencies could not be resolved at this point of the build but
seem to be part of the reactor
{noformat}
That lead me to MNG-2277, and I would happily accept the warning if maven
wasn't actually downloading and using the downloaded dependencies instead of
the ones built in the reactor.
If the artefact exists in your local repo, looks like that one is being used
(I'm not sure here).
The workaround I've found (only in maven 3) is to use
requiresDependencyCollection (instead of requiresDependencyResolution), then I
have to identify which ones are in the reactor, and just resolve the other
ones. It doesn't feel right, I kinda trust maven to identify what is the
reactor and what is not (even for aggregator-style plugins), and never override
the reactor. I don't want to call "mvn install myplugin:goal", I need it to be
part of the build as it produces resources included in my jars and wars.
Full log:
{noformat}
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] my-nice-project
[INFO] child1
[INFO] child2
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building my-nice-project 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/maven-metadata.xml
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/maven-metadata.xml
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/child1-1.0-SNAPSHOT.jar
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/child1-1.0-SNAPSHOT.jar
[WARNING] The following dependencies could not be resolved at this point of the
build but seem to be part of the reactor:
[WARNING] o com.mycompany.project:child1:jar:1.0-SNAPSHOT (compile)
[WARNING] Try running the build up to the lifecycle phase "package"
[INFO]
[INFO] --- myaggregator-maven-plugin:1.0-SNAPSHOT:list-deps (default-cli) @
my-nice-project ---
[INFO] >>>>>> Project: my-nice-project
[INFO] ---------------
[INFO] >>>>>> Project: child1
[INFO] - junit:junit:jar:4.11
[INFO] - org.hamcrest:hamcrest-core:jar:1.3
[INFO] ---------------
[INFO] >>>>>> Project: child2
[INFO] - com.mycompany.project:child1:jar:1.0-SNAPSHOT
[INFO] - junit:junit:jar:4.11
[INFO] - org.hamcrest:hamcrest-core:jar:1.3
[INFO] - org.apache.logging.log4j:log4j-api:jar:2.0-beta9
[INFO] ---------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] my-nice-project ................................... SUCCESS [4.280s]
[INFO] child1 ............................................ SKIPPED
[INFO] child2 ............................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.495s
[INFO] Finished at: Fri Jan 17 17:10:10 EST 2014
[INFO] Final Memory: 6M/143M
[INFO] ------------------------------------------------------------------------
{noformat}
I've attached the simplest example I could think of.
- Open zip file
- cd my-aggregator-plugin; mvn install
- rm -rf ~/.m2/repository/com/mycompany/project/
- cd my-nice-project; mvn
com.mycompany.mavenplugin:myaggregator-maven-plugin:1.0-SNAPSHOT:list-deps
was:
If you have a aggregator-style plugin with requiresDependencyResolution, maven
will try to download artefacts from remote (if they are not in your local
repository or if you have a 'always' policy for that remote repository).
Attaching the plugin to different phases or CLI didn't change the behaviour.
If the artefact actually exists in your remote repository, maven will download
it. Even worse if you include this aggregator-stype plugin as part of the
lifecycle of module, because then the dependencies downloaded will be used
instead of the one built in the reactor for the rest of the build. It's pretty
scary to build artefacts half reactor/half remote maven as a side effect of
calling a plugin that just wants to print the dependencies' names.
If the artefact doesn't exist in your maven local repo or remote, maven will
continue and the following warning:
{noformat}
The following dependencies could not be resolved at this point of the build but
seem to be part of the reactor
{noformat}
That lead me to MNG-2277, and I would happily accept the warning if maven
wasn't actually downloading and using the downloaded dependencies instead of
the ones built in the reactor.
If the artefact exists in your local repo, looks like that one is being used
(I'm not sure here).
The workaround I've found (only in maven 3) is to use
requiresDependencyCollection (instead of requiresDependencyResolution), then I
have to identify which ones are in the reactor, and just resolve the other
ones. It doesn't feel right, I kinda trust maven to identify what is the
reactor and what is not (even for aggregator-style plugins), and never override
the reactor. I don't want to call "mvn install myplugin:goal", I need it to be
part of the build as it produces resources included in my jars and wars.
Full log:
{noformat}
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] my-nice-project
[INFO] child1
[INFO] child2
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building my-nice-project 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/maven-metadata.xml
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/maven-metadata.xml
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/child1-1.0-SNAPSHOT.jar
Downloading:
https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/child1-1.0-SNAPSHOT.jar
[WARNING] The following dependencies could not be resolved at this point of the
build but seem to be part of the reactor:
[WARNING] o com.mycompany.project:child1:jar:1.0-SNAPSHOT (compile)
[WARNING] Try running the build up to the lifecycle phase "package"
[INFO]
[INFO] --- myaggregator-maven-plugin:1.0-SNAPSHOT:list-deps (default-cli) @
my-nice-project ---
[INFO] >>>>>> Project: my-nice-project
[INFO] ---------------
[INFO] >>>>>> Project: child1
[INFO] - junit:junit:jar:4.11
[INFO] - org.hamcrest:hamcrest-core:jar:1.3
[INFO] ---------------
[INFO] >>>>>> Project: child2
[INFO] - com.mycompany.project:child1:jar:1.0-SNAPSHOT
[INFO] - junit:junit:jar:4.11
[INFO] - org.hamcrest:hamcrest-core:jar:1.3
[INFO] - org.apache.logging.log4j:log4j-api:jar:2.0-beta9
[INFO] ---------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] my-nice-project ................................... SUCCESS [4.280s]
[INFO] child1 ............................................ SKIPPED
[INFO] child2 ............................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.495s
[INFO] Finished at: Fri Jan 17 17:10:10 EST 2014
[INFO] Final Memory: 6M/143M
[INFO] ------------------------------------------------------------------------
{noformat}
I've attached the simplest example I could think of.
- Open zip file
- cd my-aggregator-plugin; mvn install
- rm -rf ~/.m2/repository/com/mycompany/project/
- cd my-nice-project; mvn
com.mycompany.mavenplugin:myaggregator-maven-plugin:1.0-SNAPSHOT:list-deps
> Aggregator style plugin with requiresDependencyResolution retrieving
> artefacts from remote instead of reactor
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-5565
> URL: https://jira.codehaus.org/browse/MNG-5565
> Project: Maven 2 & 3
> Issue Type: Bug
> Affects Versions: 3.0.5
> Reporter: Cintia DR
> Attachments: aggregator.zip
>
>
> If you have a aggregator-style plugin with requiresDependencyResolution,
> maven will try to download artefacts from remote (if they are not in your
> local repository or if you have a 'always' policy for that remote
> repository). Binding the plugin to different phases or calling from CLI
> didn't change the behaviour.
> If the artefact actually exists in your remote repository, maven will
> download it. Even worse if you include this aggregator-styte plugin as part
> of the lifecycle of a module, because then the dependencies downloaded will
> be used - instead of the ones built in the reactor - for the rest of the
> build. It's pretty scary to build artefacts half reactor/half remote maven as
> a side effect of calling a plugin that just wants to print the dependencies'
> names.
> If the artefact doesn't exist in your maven local repo or remote, maven will
> continue and the following warning:
> {noformat}
> The following dependencies could not be resolved at this point of the build
> but seem to be part of the reactor
> {noformat}
> That lead me to MNG-2277, and I would happily accept the warning if maven
> wasn't actually downloading and using the downloaded dependencies instead of
> the ones built in the reactor.
> If the artefact exists in your local repo, looks like that one is being used
> (I'm not sure here).
>
> The workaround I've found (only in maven 3) is to use
> requiresDependencyCollection (instead of requiresDependencyResolution), then
> I have to identify which ones are in the reactor, and just resolve the other
> ones. It doesn't feel right, I kinda trust maven to identify what is the
> reactor and what is not (even for aggregator-style plugins), and never
> override the reactor. I don't want to call "mvn install myplugin:goal", I
> need it to be part of the build as it produces resources included in my jars
> and wars.
> Full log:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] my-nice-project
> [INFO] child1
> [INFO] child2
> [INFO]
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building my-nice-project 1.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> Downloading:
> https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/maven-metadata.xml
> Downloading:
> https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/maven-metadata.xml
> Downloading:
> https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/child1-1.0-SNAPSHOT.jar
> Downloading:
> https://mynexus.com/content/groups/internal/com/mycompany/project/child1/1.0-SNAPSHOT/child1-1.0-SNAPSHOT.jar
> [WARNING] The following dependencies could not be resolved at this point of
> the build but seem to be part of the reactor:
> [WARNING] o com.mycompany.project:child1:jar:1.0-SNAPSHOT (compile)
> [WARNING] Try running the build up to the lifecycle phase "package"
> [INFO]
> [INFO] --- myaggregator-maven-plugin:1.0-SNAPSHOT:list-deps (default-cli) @
> my-nice-project ---
> [INFO] >>>>>> Project: my-nice-project
> [INFO] ---------------
> [INFO] >>>>>> Project: child1
> [INFO] - junit:junit:jar:4.11
> [INFO] - org.hamcrest:hamcrest-core:jar:1.3
> [INFO] ---------------
> [INFO] >>>>>> Project: child2
> [INFO] - com.mycompany.project:child1:jar:1.0-SNAPSHOT
> [INFO] - junit:junit:jar:4.11
> [INFO] - org.hamcrest:hamcrest-core:jar:1.3
> [INFO] - org.apache.logging.log4j:log4j-api:jar:2.0-beta9
> [INFO] ---------------
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] my-nice-project ................................... SUCCESS [4.280s]
> [INFO] child1 ............................................ SKIPPED
> [INFO] child2 ............................................ SKIPPED
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 4.495s
> [INFO] Finished at: Fri Jan 17 17:10:10 EST 2014
> [INFO] Final Memory: 6M/143M
> [INFO]
> ------------------------------------------------------------------------
> {noformat}
> I've attached the simplest example I could think of.
> - Open zip file
> - cd my-aggregator-plugin; mvn install
> - rm -rf ~/.m2/repository/com/mycompany/project/
> - cd my-nice-project; mvn
> com.mycompany.mavenplugin:myaggregator-maven-plugin:1.0-SNAPSHOT:list-deps
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
