[
https://issues.apache.org/jira/browse/MPOM-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818187#comment-17818187
]
Herve Boutemy commented on MPOM-468:
------------------------------------
bq. 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)
> 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)
