[
https://issues.apache.org/jira/browse/MPOM-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818080#comment-17818080
]
Christopher Tubbs commented on MPOM-468:
----------------------------------------
[~michael-o], I'm using the 3.9.6, but I don't know what version was used by
the release manager who prepared our last release candidate, where I noticed
the issue. It was my understanding that Nexus created the .md5 and .sha1 files,
though, not Maven. Perhaps I'm wrong? I really don't know what part creates
that, because they don't seem to be created when I do `mvn verify` or even `mvn
install`, so I can't really reproduce except by doing another `deploy`.
Re your general question: it's my understanding that it was added because some
people had a desire to have Maven generate their SHA512 that was required for
the SVN/dist area. For projects I'm on, we have no audience for this file
whatsoever, at least not the one the Mavem build is producing.
I agree with you about how it should be presented in the dist area.
Regarding "Why does it need to be on Central at all?". That's kind of a red
herring, because even if you intend to delete the source-release artifact, and
not put it in Maven Central, the generation of these extra checksum files is
still an added inconvenience. For the purposes of this issue, I think it's fine
to just accept that there may be some use cases to have source-release
artifacts in Maven Central, and other use cases where it doesn't make sense.
It's not really important for this issue, though.
I think [~cstamas] has a really good point. Using this plugin isn't needed at
all, since Maven 3.9 has the ability to produce sha512 files built-in. So,
that's another reason to remove it... perhaps even more important than any of
the reasons I listed.
> Remove or provide option to disable checksum-maven-plugin
> ---------------------------------------------------------
>
> Key: MPOM-468
> URL: https://issues.apache.org/jira/browse/MPOM-468
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
> Affects Versions: ASF-31
> Reporter: Christopher Tubbs
> Priority: Critical
>
> Currently, the net.nicoulaj.maven.plugins:checksum-maven-plugin is used to
> generate .sha512 files for the source-release classifier artifact in the
> apache-release profile.
> There are many problems with this plugin that justify removing it or making
> it easier to disable:
> 1. Not everybody wants this. It is intended to help construct SHA512 files in
> the Nexus staging repository, so people can easily have something to copy
> over into their DIST area in SVN. But, it's expected that people delete these
> from the staging repository before releasing the staging repo to Maven
> central after a successful release vote. Well, not everybody uses this
> pattern. Some people, like those pushing for MPOM-282, generate sha512 files
> differently (with the filename, so it can be easily verified with standard
> tooling). It is inconvenient for this plugin to create extra files in the
> staging repo that we must deal with, leading to more room for user error
> during the release process.
> 2. In the case where users actually don't want to modify the staging repo,
> but actually release the repo with the source-release artifact (there are
> many use cases for that), this creates more work, because those people only
> have to remove stuff from the staging repo *because* of this plugin. It
> doesn't make it more convenient... it makes it less convenient... to do a
> release.
> 3. It doesn't just generate .sha512 files. It also results in .sha512.md1 and
> .sha512.sha1 files, which are just excessive to deal with.
> 4. The plugin has not been maintained in 2 years.
> 5. The plugin's website with all of its generated plugin documentation is no
> longer functional.
> 6. The plugin doesn't appear to have a standard "-DmyPluginPrefix.skip"
> method of disabling the plugin to bypass it. So, one must specifically
> override the plugin by duplicating the apache-release profile, and creating
> an execution with the same ID, but with different config to force it to be
> overridden.
> 7. None (or very few) of the configuration properties seem to have user
> properties to set them as a system property or in the POM's properties
> section. So, that makes it cumbersome to modify the configuration.
> 8. Because of number 7, this ASF parent POM, must set everything in the XML,
> and since it hasn't created proxy properties to set things indirectly, the
> only way to override it is to create a local apache-release profile
> containing the same plugin, with the same execution id, but with different
> configuration.
> For all of these reasons, and probably more, I think this plugin should be
> removed from the ASF parent POM. If not that, then it should at least be
> moved to a different profile and disabled by default. If not that, then it
> should at least be moved to a different profile so it can be easily disabled
> by choice. If not that, then at the very least, create a proxy property to
> set the includeClassifiers (and other important options) as properties, so we
> don't have to jump through hoops to try to override and disable this plugin
> when a project doesn't want to use it.
> For reference: https://github.com/nicoulaj/checksum-maven-plugin
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
