You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benson Margulies (JIRA)" <ji...@codehaus.org> on 2012/11/25 00:06:13 UTC
[jira] (MNG-5387) Add ability to replace an artifact in mid-build
Benson Margulies created MNG-5387:
-------------------------------------
Summary: Add ability to replace an artifact in mid-build
Key: MNG-5387
URL: https://jira.codehaus.org/browse/MNG-5387
Project: Maven 2 & 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.1.0
Reporter: Benson Margulies
To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.' This requires a new method in MavenProjectHelper.
While here, clean up some confusion with DuplicateArtifactAttachmentException: make MavenProject throw it since DefaultMavenProjectHelper is expecting it to be thrown and it's in the signature. This assm
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5387) Add ability to replace an artifact in mid-build
Posted by "Stephen Connolly (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314338#comment-314338 ]
Stephen Connolly commented on MNG-5387:
---------------------------------------
I agree with last wins. The only gotcha-cconcern I have is the forked life cycles. Specifically a cobertura or clover forked life cycle.
If the forked life cycle doesn't splat over then it's fine
> Add ability to replace an artifact in mid-build
> -----------------------------------------------
>
> Key: MNG-5387
> URL: https://jira.codehaus.org/browse/MNG-5387
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.1.0
> Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.'
> It turns out we already more or less have this method, due to a collection of historical conflict.
> At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for Maven to reject more than one call to attach the same artifact to the build. However, this proved an unacceptable incompatibility at the time. Instead, under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but otherwise ignore all calls to 'addArtifact' on MavenProject after the first for a G/A/V/C/T coordinate.
> This decision to take 'first wins' instead of 'last wins' doesn't help much of anyone. It prevents something like shade from intentionally displacing an earlier execution's results, and while it doesn't produce backtraces, ever, it can still be entirely confusing.
> Under this JIRA, I'm switching to 'last one wins'. This could still be confusing, and someone might argue that there should be some way to distinguish casual and incorrect user config that results in two plugins trying to deliver the same thing from something intentional. On the other hand, if two plugins are configured to attach the same G/A/V/C, having the last one win makes more sense, and has the effect of enabling the desired behavior in shade.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5387) Add ability to replace an artifact in mid-build
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies closed MNG-5387.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.1.0
Integration test in 1413359.
> Add ability to replace an artifact in mid-build
> -----------------------------------------------
>
> Key: MNG-5387
> URL: https://jira.codehaus.org/browse/MNG-5387
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.1.0
> Reporter: Benson Margulies
> Assignee: Benson Margulies
> Fix For: 3.1.0
>
>
> To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.'
> It turns out we already more or less have this method, due to a collection of historical conflict.
> At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for Maven to reject more than one call to attach the same artifact to the build. However, this proved an unacceptable incompatibility at the time. Instead, under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but otherwise ignore all calls to 'addArtifact' on MavenProject after the first for a G/A/V/C/T coordinate.
> This decision to take 'first wins' instead of 'last wins' doesn't help much of anyone. It prevents something like shade from intentionally displacing an earlier execution's results, and while it doesn't produce backtraces, ever, it can still be entirely confusing.
> Under this JIRA, I'm switching to 'last one wins'. This could still be confusing, and someone might argue that there should be some way to distinguish casual and incorrect user config that results in two plugins trying to deliver the same thing from something intentional. On the other hand, if two plugins are configured to attach the same G/A/V/C, having the last one win makes more sense, and has the effect of enabling the desired behavior in shade.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5387) Add ability to replace an artifact in mid-build
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies reassigned MNG-5387:
-------------------------------------
Assignee: Benson Margulies
> Add ability to replace an artifact in mid-build
> -----------------------------------------------
>
> Key: MNG-5387
> URL: https://jira.codehaus.org/browse/MNG-5387
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.1.0
> Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.' This requires a new method in MavenProjectHelper.
> While here, clean up some confusion with DuplicateArtifactAttachmentException: make MavenProject throw it since DefaultMavenProjectHelper is expecting it to be thrown and it's in the signature. This assm
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5387) Add ability to replace an artifact in mid-build
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314332#comment-314332 ]
Benson Margulies commented on MNG-5387:
---------------------------------------
Code changes in r1413286; IT to follow.
> Add ability to replace an artifact in mid-build
> -----------------------------------------------
>
> Key: MNG-5387
> URL: https://jira.codehaus.org/browse/MNG-5387
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.1.0
> Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.' This requires a new method in MavenProjectHelper.
> While here, clean up some confusion with DuplicateArtifactAttachmentException: make MavenProject throw it since DefaultMavenProjectHelper is expecting it to be thrown and it's in the signature. This assm
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5387) Add ability to replace an artifact in mid-build
Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benson Margulies updated MNG-5387:
----------------------------------
Description:
To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.'
It turns out we already more or less have this method, due to a collection of historical conflict.
At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for Maven to reject more than one call to attach the same artifact to the build. However, this proved an unacceptable incompatibility at the time. Instead, under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but otherwise ignore all calls to 'addArtifact' on MavenProject after the first for a G/A/V/C/T coordinate.
This decision to take 'first wins' instead of 'last wins' doesn't help much of anyone. It prevents something like shade from intentionally displacing an earlier execution's results, and while it doesn't produce backtraces, ever, it can still be entirely confusing.
Under this JIRA, I'm switching to 'last one wins'. This could still be confusing, and someone might argue that there should be some way to distinguish casual and incorrect user config that results in two plugins trying to deliver the same thing from something intentional. On the other hand, if two plugins are configured to attach the same G/A/V/C, having the last one win makes more sense, and has the effect of enabling the desired behavior in shade.
was:
To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.' This requires a new method in MavenProjectHelper.
While here, clean up some confusion with DuplicateArtifactAttachmentException: make MavenProject throw it since DefaultMavenProjectHelper is expecting it to be thrown and it's in the signature. This assm
> Add ability to replace an artifact in mid-build
> -----------------------------------------------
>
> Key: MNG-5387
> URL: https://jira.codehaus.org/browse/MNG-5387
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.1.0
> Reporter: Benson Margulies
> Assignee: Benson Margulies
>
> To clean up how the shade plugin works, we need an API to allow it to say, 'please replace the jar file that the jar plugin has given you with this other one here.'
> It turns out we already more or less have this method, due to a collection of historical conflict.
> At some point in time, http://jira.codehaus.org/browse/MNG-3119 called for Maven to reject more than one call to attach the same artifact to the build. However, this proved an unacceptable incompatibility at the time. Instead, under http://jira.codehaus.org/browse/MNG-4013, Maven was changed to log but otherwise ignore all calls to 'addArtifact' on MavenProject after the first for a G/A/V/C/T coordinate.
> This decision to take 'first wins' instead of 'last wins' doesn't help much of anyone. It prevents something like shade from intentionally displacing an earlier execution's results, and while it doesn't produce backtraces, ever, it can still be entirely confusing.
> Under this JIRA, I'm switching to 'last one wins'. This could still be confusing, and someone might argue that there should be some way to distinguish casual and incorrect user config that results in two plugins trying to deliver the same thing from something intentional. On the other hand, if two plugins are configured to attach the same G/A/V/C, having the last one win makes more sense, and has the effect of enabling the desired behavior in shade.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira