Hi, I was previously just lurking here but following the discussion with interest. Here are my 2 cents:
Chris Kilding wrote: > I think we could begin by working out some constraints for the feature... > > First, I think it should be possible to deprecate (or undeprecate) an > artifact without compiling a new version of it. > > This is because: > > - In some legacy code situations (e.g. when the code was not checked in to > VCS), nobody can compile the artifact any more. We would not want this to > prevent us deprecating the artifact. > - Deprecation and undeprecation should be quick operations. Compiling and > releasing new versions can take significant time. > > This constraint suggests that a deprecation indicator should be something > applied *to* an artifact rather than part *of* an artifact. It would lead us > towards putting the indicator in the repository metadata, not the POM. Could we not simply upload an artifact with a classifier like "deprecation" to the repository. AFAICT, this would even work after the fact, i.e., after the initial release. Say we have following files in our repository: foo-1.0.0.pom foo-1.0.0.jar foo-1.0.0-javadoc.jar foo-1.0.0-sources.jar Deprecating Foo 1.0.0 would then simply add another file: foo-1.0.0-deprecation.xml That way, tools that are unaware of the deprecation mechanism would operate as before. Also, the stability requirements of the Central Repository that Slawomir mentioned would AFAIK not we violated; none of the artifacts (or their checksums or signatures) are touched -- only the maven-metadata.xml needs to be updated with a new <lastUpdated>. Slawomir Jaranowski wrote: > Changing status / metadata of artifacts will break "Release Stability" of > Central Repository > Once artifacts was release should never change ... > https://central.sonatype.org/faq/can-i-change-a-component/ Now, a tool that is aware of the deprecation mechanism would simply download the deprecation.xml as well. In fact, you would not even need to build this mechanism into Maven itself; a simple maven-deprecation-plugin would do. A goal like deprecation:deploy would upload a deprecation.xml to an existing GAV (and might not even require a project, as the original code may not have been checked into VCS, as Chris mentioned above). A goal like deprecation:check could be bound to the validate phase and warn (or fail the build) if a deprecated dependency is used. This goal might need some extra option like <checkPluginDependencies> to also include a plugin's <dependencies> and not just the projects, however. (FYI, the pgpverify-maven-plugin, which tries to verify the PGP signatures of all dependencies, faces similar challenges [1]). WDYT? Best wishes, Andreas [1] <https://www.simplify4u.org/pgpverify-maven-plugin/check-mojo.html#verifyPluginDependencies>
OpenPGP_signature
Description: OpenPGP digital signature
