[MPOM-468] Remove or provide option to disable checksum-maven-plugin

[jira-importer]

Christopher Tubbs opened MPOM-468 and commented

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

---

Affects: ASF-31

Remote Links:

• Contents should include checksum and filename in standard format

0 votes, 5 watchers

[jira-importer]

Michael Osipov commented

Regarding 3: Which Maven version are you using? It was an issue with previous Resolver versions.

General question: Who is the target audience for this file? Vote participants? Maven Resolver? Please note: This file is NOT intended for verification, it is transport only. See https://maven.apache.org/resolver/about-checksums.html. Verification is signatures only.

If the source release should only be in the dist area then it should be accompanied with a BSD style hash file for external verification and not be present on Maven Central at all.

My personal question has always been: Why does it need to be on Central at all?!

Tamas Cservenak, Herve Boutemy.

[jira-importer]

Tamas Cservenak commented

With Maven 3.9.x this plugin is really not needed, as you can just configure Maven to produce SHA512 as well (also it will prevent creation of .sha512.sha1 files as well)

See aether.checksums.algorithms in https://maven.apache.org/resolver/configuration.html

[jira-importer]

Christopher Tubbs commented

Michael Osipov, 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 Tamas Cservenak 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.

[jira-importer]

Herve Boutemy commented

If the source release should only be in the dist area then it should be accompanied with a BSD style hash file for external verification and not be present on Maven Central at all. My personal question has always been: Why does it need to be on Central at all?!

this one is true, but nobody understands it = the separation between rules for Apache dist area and Maven Central and in theory, yes, this difference at checksum level should be visible at format level (whatever checksum strength: old md5 and sha1, or newer sha512): Apache checksum should be BSD style (i.e. with file name) while Maven Central is raw checksum (i.e. without filename)

really enforcing this difference in format would be ideal, but creates headaches: same checksum file name, but different content

people who are taking time to drop .sha512 from staging directory are wasting their time for being picky: they should probably be more picky at clarifying file format

on Tamas idea with Maven 3.9, technically also true: I just hate that this sha512 checksum is added on every Maven Central file, just because Aapche dist area should have it on 1 source-release (and in BSD format, if we went precise)

perhaps putting the plugin in a separately skippable profile would be a way to make everyone happy (half happy because it's a compromise on all the diverging good points that were cited in this issue)

[jira-importer]

Herve Boutemy commented

notice: on adding a skip parameter to the plugin, I don't see any PR https://github.com/nicoulaj/checksum-maven-plugin I know Julien, he can work on the plugin if there is something to do (which does not happen so such on a checksum plugin)

[jira-importer]

Slawomir Jaranowski commented

Project issues moved to GitHub, please copy to it.