[ 
https://issues.apache.org/jira/browse/MPOM-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817903#comment-17817903
 ] 

Tamas Cservenak edited comment on MPOM-468 at 2/16/24 10:16 AM:
----------------------------------------------------------------

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]


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

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

> 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)

Reply via email to