jira-importer opened a new issue, #394: URL: https://github.com/apache/maven-apache-parent/issues/394
**[Christopher Tubbs](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ctubbsii)** opened **[MPOM-468](https://issues.apache.org/jira/browse/MPOM-468?redirect=false)** 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 ](https://github.com/nicoulaj/checksum-maven-plugin/issues/127) 0 votes, 5 watchers -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
