[ 
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). 
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 dependency 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.  



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.   


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 dependency 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.  



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). 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 dependency 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.  
> 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

Reply via email to