[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434311#comment-17434311
]
Gary D. Gregory edited comment on MNG-7316 at 10/26/21, 12:10 PM:
------------------------------------------------------------------
I'd prefer [~chtompki] to reply since I think he authored that part of the
plugin.
Allow me to point out our big picture here at the risk of outlining a topic you
may already know. Strictly speaking, Apache releases tar/zip sources. These
source files go to the Apache svn repo, which in turn makes them visible to the
world, and get mirrored all over by 3rd parties. Tar/zip, binaries are a bonus,
and they sit next to the tar/zip sources. As a double-bonus, we publish to
Nexus, then Maven Central, not a strict requirement either. For all of this, we
want to publish release candidates, then actual releases. A release candidate
is tar/zip sources, tar/zip binaries, a website, plus artifacts in the Apache
Maven Nexus repository. If the RC goes well, then all that moves from the dev
to the release folder of the Apache svn repo, same releasing the RC out of
Nexus to Maven Central. If an RC fails, the RC files go away, the git tag
stays, no need to burn release numbers. We have 2 plugins that help us do all
that. The latest Maven release breaks all that, bummer.
This is obviously a regression. The choices appear to me:
* Simplest: put it back to the way it was
* Provide the remove functionality in whichever way you want, and we'll have to
update our code
If the MavenProject class is so concerned with duplicates, why is it using a
List instead of a Set to track attached artifacts? Wouldn't a LinkedHashSet
reflect this intent best? You get order and uniqueness.
was (Author: garydgregory):
I'd prefer [~chtompki] to reply since I think he authored that part of the
plugin.
Allow me to point out our big picture here at the risk of outlining a topic you
may already know. Strictly speaking, Apache releases tar/zip sources. These
source files go to the Apache svn repo, which in turn makes them visible to the
world, and get mirrored all over by 3rd parties. Tar/zip, binaries are a bonus,
and they sit next to the tar/zip sources. As a double-bonus, we publish to
Nexus, then Maven Central, not a strict requirement either. For all of this, we
want to publish release candidates, then actual releases. A release candidate
is tar/zip sources, tar/zip binaries, a website, plus artifacts in the Apache
Maven Nexus repository. If the RC goes well, then all that moves from the dev
to the release folder of the Apache svn repo, same releasing the RC out of
Nexus to Maven Central. If an RC fails, the RC files go away, the git tag
stays, no need to burn release numbers. We have 2 plugins that help us do all
that. The latest Maven release breaks all that, bummer.
This is obviously a regression. The choices appear to me: * Simplest: put it
back to the way it was
* Provide the remove functionality in whichever way you want, and we'll have
to update our code
If the MavenProject class is so concerned with duplicates, why is it using a
List instead of a Set to track attached artifacts? Wouldn't a LinkedHashSet
reflect this intent best? You get order and uniqueness.
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> ---------------------------------------------------------
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.8.2, 3.8.3
> Reporter: Gary D. Gregory
> Assignee: Michael Osipov
> Priority: Critical
> Fix For: 3.8.x-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
