You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Chris Kilding <ch...@chriskilding.com> on 2021/07/28 10:10:46 UTC
Feature proposal: Dependency deprecation indicators
Hello,
I would like to propose a new Maven feature: dependency deprecation indicators.
In a nutshell, the idea is to let maintainers set a 'deprecated' metadata indicator on a Maven artifact in a repository. This will indicate to users that the artifact should no longer be used.
The Maven CLI tools could then react to deprecation indicators in the appropriate ways:
- `mvn` itself: Print a warning when deprecated dependencies are seen.
- Maven Enforcer Plugin: Add a <banDeprecatedDependencies> rule which throws an error when deprecated dependencies are seen.
- Maven Dependency Tree: Print a [deprecated] notice next to any deprecated dependency in the tree.
- ...and so on
We can also envisage automated agents like Dependabot using these indicators to alert developers about deprecated dependencies in their stacks, and assisting developers to remove them.
Some of the major build tools outside the JVM already have deprecation indicators:
- NPM: https://docs.npmjs.com/cli/v7/commands/npm-deprecate
- Nuget: https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages
- Composer / Packagist: https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-without-leaving-anyone-behind/
So the feature has precedent, and I believe it would be useful to have in Maven. If there is demand for it, I am willing to work on it.
There are definitely several good questions to be answered about what exactly the feature would look like, so questions and comments are welcome :)
Regards,
Chris Kilding
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
It looks like OGA Maven plugin has some overlap, but isn't quite the same as the proposed feature...
In my view, deprecation is largely orthogonal to alternatives:
- Alternatives exist at all stages of an artifact's lifecycle, not just during deprecation.
- Some artifacts are one-of-a-kind and have no (direct) alternatives.
- Developers may need to use an alternatives system at any stage of an artifact's lifecycle, not just during deprecation. E.g. a company may discover that an artifact has a disallowed license and ask its developers to find an alternative.
- Alternatives themselves come and go, so if an artifact maintainer recommends an alternative in a deprecation notice, this recommendation itself may become outdated. There may also be a better alternative that the maintainer does not know about.
Therefore I see no reason to limit or tightly couple an alternatives system to the deprecation phase of an artifact. Developers may often use them together, but not exclusively.
To my untrained eye, OGA Maven Plugin seems to address a bit of the alternatives piece and a bit of the deprecation piece, but only where there is a 1-for-1 replacement and the new library is the direct continuation of the old library?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Nick Stolwijk <ni...@gmail.com>.
Isn't this exactly what the Old GroupIds Alerter - Maven Plugin[1] is doing?
Only instead of adding metadata to Central it keeps a list [2] of
replaced/deprecated artifacts.
[1] https://github.com/jonathanlermitage/oga-maven-plugin
[2]
https://raw.githubusercontent.com/jonathanlermitage/oga-maven-plugin/master/uc/og-definitions.json
With regards,
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Mon, Aug 2, 2021 at 10:04 PM Chris Kilding <ch...@chriskilding.com>
wrote:
> @Oliver:
>
> Yes, a GitHub repo to write some kind of spec for this feature would be
> great. Is there an existing Maven enhancement proposals repo we can use
> (along the lines of what the Jenkins project does in
> https://github.com/jenkinsci/jep), or is a new one needed?
>
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
I have now created a Jira issue to move this forward:
https://issues.apache.org/jira/browse/MNG-7238
Regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
I'd like to try out some options for this feature by modifying Maven source. I could use some help knowing which parts of Maven would need to be modified...
## maven core
I assume any new deprecation property would need to be added to maven-repository-metadata/src/main/mdo/metadata.mdo, and then the MDO plugin would codegen the relevant classes from it.
The property will be optional (not required), so if it's not present then Maven should behave the same as it does today.
After that, I'd like to add something to the `mvn validate` phase that detects dependencies with deprecation markers and prints warnings about them. Where would I add this logic?
## maven dependency tree
I'd like to change maven-dependency-tree plugin so that it prints a [deprecated] marker next to any deprecated dependency.
Example:
com.example:myproject:jar:1.0-SNAPSHOT
\- com.example:foobar:jar:1.2.3:compile [deprecated]
I assume I'd have to modify DefaultDependencyNode#toNodeString() to do that. Would I also need to make the same change to VerboseDependencyNode?
Additionally it seems like this plugin depends on quite an old version of Maven (3.0.5). If I propose a change to the Maven repo metadata format in the main repo, would this mean that maven-dependency-tree has to depend on the latest Maven (3.8.3 or similar) in order to have access to the new deprecation property? Would updating the plugin's Maven dependency have any compatibility ramifications for users with old Maven versions?
Regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
I have uploaded the feature proposal to GitHub for now at the following location:
https://github.com/p4em/maven-enhancement-proposals/tree/main/proposals/artifact-deprecation
This is to encourage feedback from the community, since all you need is a GitHub account to comment or make pull requests on it.
I've also started a couple of issues to discuss some topics that were raised:
- Where to locate the deprecation indicator: https://github.com/p4em/maven-enhancement-proposals/issues/2
- Which fields (if any) should a deprecation indicator have: https://github.com/p4em/maven-enhancement-proposals/issues/1
If there's some traction on this, then I can see about signing up to Apache and doing the ICLA, then transferring the proposal to the Maven wiki.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
I have written up a proposal document. All things being equal it would be easier to have these things on GitHub, but if we follow 'the Apache way' I believe the right place for this is in the Proposals section of the wiki (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567).
I'd like to avoid creating spurious online accounts if possible (ASF Confluence and Jira have their own signup mechanisms, but I think you're meant to have an Apache account to benefit from single sign-on?), so could someone let me know what the next move is to be able to post to the wiki page?
Regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Oliver Fischer <o....@swe-blog.net>.
Hi Chris,
I created an Github organisation with one repository:
https://github.com/p4em
The repository is currently empty. For the beginning, it should be
enough to start with a freestyle document with a similar structure like
the JEP Template for Jenkins. If the process itself will work, then we
could start to formalize the process.
What do you think?
Oliver
Am 05.08.21 um 16:30 schrieb Chris Kilding:
> My GitHub user is @chriskilding
>
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
My GitHub user is @chriskilding
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Oliver Fischer <o....@swe-blog.net>.
Hi Chris,
I am not aware of it and I am even do not know if such an approach
causes any conflicts with the way the Maven PMC runs the project. So
please, if someone here knows any reason not to setup such repository,
please object.
@Chris: I will set it up today. Do you have a GH handle?
Oliver
Am 02.08.21 um 22:04 schrieb Chris Kilding:
> @Oliver:
>
> Yes, a GitHub repo to write some kind of spec for this feature would be great. Is there an existing Maven enhancement proposals repo we can use (along the lines of what the Jenkins project does in https://github.com/jenkinsci/jep), or is a new one needed?
>
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
@Oliver:
Yes, a GitHub repo to write some kind of spec for this feature would be great. Is there an existing Maven enhancement proposals repo we can use (along the lines of what the Jenkins project does in https://github.com/jenkinsci/jep), or is a new one needed?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Oliver Fischer <o....@swe-blog.net>.
Hi all,
I would like to suggest to write a small specification of the feature
you brought up. I have somethink in mind similar to the JEP process for
Java.
I could create a repo at Github, so that we can work there on the
feature description and ask other people to review it or to contribute
to it.
WDYT?
Oliver
Am 28.07.21 um 12:10 schrieb Chris Kilding:
> Hello,
>
> I would like to propose a new Maven feature: dependency deprecation indicators.
>
> In a nutshell, the idea is to let maintainers set a 'deprecated' metadata indicator on a Maven artifact in a repository. This will indicate to users that the artifact should no longer be used.
>
> The Maven CLI tools could then react to deprecation indicators in the appropriate ways:
>
> - `mvn` itself: Print a warning when deprecated dependencies are seen.
> - Maven Enforcer Plugin: Add a <banDeprecatedDependencies> rule which throws an error when deprecated dependencies are seen.
> - Maven Dependency Tree: Print a [deprecated] notice next to any deprecated dependency in the tree.
> - ...and so on
>
> We can also envisage automated agents like Dependabot using these indicators to alert developers about deprecated dependencies in their stacks, and assisting developers to remove them.
>
> Some of the major build tools outside the JVM already have deprecation indicators:
>
> - NPM: https://docs.npmjs.com/cli/v7/commands/npm-deprecate
> - Nuget: https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages
> - Composer / Packagist: https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-without-leaving-anyone-behind/
>
> So the feature has precedent, and I believe it would be useful to have in Maven. If there is demand for it, I am willing to work on it.
>
> There are definitely several good questions to be answered about what exactly the feature would look like, so questions and comments are welcome :)
>
> Regards,
>
> Chris Kilding
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Hervé BOUTEMY <he...@free.fr>.
[...]
> A comparison with other systems:
>
> - NPM puts deprecation indicators in repository metadata.
do you know where these repository metadata are visible?
> - Nuget puts deprecation indicators in repository metadata.
do you know where these repository metadata are visible?
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Andreas Sewe <an...@buildingblobs.com>.
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>
Re: Feature proposal: Dependency deprecation indicators
Posted by Slawomir Jaranowski <s....@gmail.com>.
Hi,
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/
Another case when we don't have source code of an artifact we can do a new
pom with relocation information and release the next version.
In this case I am afraid that the maintainer of the artifact doesn't want
to take care about its or not exist ... so nobody will not use deprecation
possibility for such artifacts ...
czw., 29 lip 2021 o 15:15 Chris Kilding <ch...@chriskilding.com>
napisał(a):
> 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.
>
> A comparison with other systems:
>
> - NPM puts deprecation indicators in repository metadata.
> - Nuget puts deprecation indicators in repository metadata.
> - Cocoapods puts its `deprecated` property in the Podspec (the equivalent
> of the POM). This means you have to compile a new version of a pod just to
> un/deprecate it. I believe it also means that Cocoapods clients must scan
> forward from a Podspec's current dependency versions to find the closest
> future versions that have a `deprecated` marker. I think is the wrong
> approach for the reasons explained above.
>
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sławomir Jaranowski
https://twitter.com/SlawekJaran
https://github.com/slawekjaranowski
https://linkedin.com/in/slawomirjaranowski
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
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.
A comparison with other systems:
- NPM puts deprecation indicators in repository metadata.
- Nuget puts deprecation indicators in repository metadata.
- Cocoapods puts its `deprecated` property in the Podspec (the equivalent of the POM). This means you have to compile a new version of a pod just to un/deprecate it. I believe it also means that Cocoapods clients must scan forward from a Podspec's current dependency versions to find the closest future versions that have a `deprecated` marker. I think is the wrong approach for the reasons explained above.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
Re the Enforcer plugin rule breaking builds that passed before:
Yes, can see the problem there. There would be a couple of ways to address it:
- Add a property on the rule (equivalent to Surefire's -DskipTests) which skips the deprecation errors, effectively restoring default warning behavior and negating the existence of the rule.
- Add a flag on `mvn` itself (equivalent to -C / --strict-checksums, which turns checksum warnings into errors), which would turn dependency deprecation warnings into errors. This would remove the need for an enforcer rule. But it would add another flag to `mvn`, which already has many. Maybe there is an appropriate flag already that we could piggyback on?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
https://github.com/hboutemy/mcmm-yaml could gain some additional
post-publication meta info :)
Re: Feature proposal: Dependency deprecation indicators
Posted by Hervé BOUTEMY <he...@free.fr>.
> There are definitely several good questions to be answered about what
> exactly the feature would look like, so questions and comments are welcome
> :)
sure, many questions...
here are my first thoughts:
- we have relocation, which is far from well known and easy to use, but that
is probably quite related [1], even if I'm convinced that implementation in
pom.xml is causing issues that repository metadata [2] could solve (even if
the workfloaw remains to be defined)
- on the banDeprecatedDependencies rule for Enforcer, warning: such a rule
could make a perfectly rebuildable release not buildable any more in the
future, then it absolutely require a flag to ignore such rule when rebuilding a
past release
[1] https://maven.apache.org/guides/mini/guide-relocation.html
[2] https://maven.apache.org/ref/3.8.1/maven-repository-metadata/repository-metadata.html
Le mercredi 28 juillet 2021, 12:10:46 CEST Chris Kilding a écrit :
> Hello,
>
> I would like to propose a new Maven feature: dependency deprecation
> indicators.
>
> In a nutshell, the idea is to let maintainers set a 'deprecated' metadata
> indicator on a Maven artifact in a repository. This will indicate to users
> that the artifact should no longer be used.
>
> The Maven CLI tools could then react to deprecation indicators in the
> appropriate ways:
>
> - `mvn` itself: Print a warning when deprecated dependencies are seen.
> - Maven Enforcer Plugin: Add a <banDeprecatedDependencies> rule which throws
> an error when deprecated dependencies are seen. - Maven Dependency Tree:
> Print a [deprecated] notice next to any deprecated dependency in the tree.
> - ...and so on
>
> We can also envisage automated agents like Dependabot using these indicators
> to alert developers about deprecated dependencies in their stacks, and
> assisting developers to remove them.
>
> Some of the major build tools outside the JVM already have deprecation
> indicators:
>
> - NPM: https://docs.npmjs.com/cli/v7/commands/npm-deprecate
> - Nuget: https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages
> - Composer / Packagist:
> https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-witho
> ut-leaving-anyone-behind/
>
> So the feature has precedent, and I believe it would be useful to have in
> Maven. If there is demand for it, I am willing to work on it.
>
> There are definitely several good questions to be answered about what
> exactly the feature would look like, so questions and comments are welcome
> :)
>
> Regards,
>
> Chris Kilding
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
@Sławomir:
I know the POM and the contents of the artifact itself don't change after publication (at least on Central). This is one reason I suggested putting deprecation indicators in something like maven-metadata.xml instead. Are you saying that maven-metadata.xml is immutable as well?
I think conscientious maintainers would be glad of a formal mechanism to indicate that libraries should no longer be used. Each deprecation helps the ecosystem, so we still get value even if not everybody does it. There are plenty of libraries out there today with READMEs or blog posts saying 'deprecated - do not use': each one of those is a maintainer trying to do the right thing with the only informal mechanism they've got. Let's give them something better.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
@Hervé:
The NPM `deprecated` property exists in NPM registry package metadata. (Some of this is derived from package.json, but it is not the same as package.json.)
It is described here: https://github.com/npm/registry/blob/master/docs/responses/package-metadata.md
The library which NPM itself uses to retrieve this metadata is called 'packument': https://github.com/vweevers/packument
NPM metadata lists all versions of a package. Each version object has an optional `deprecated` string property. This string is the deprecation warning message for that version. If the property is absent, NPM infers the package is still active.
(For comparison, this is simpler than NuGet's deprecation object which contains several fields.)
Example snippet:
{
"name": "<package-name>",
"modified": "2017-03-21T21:40:18.939Z",
"dist-tags": {
"latest": "<semver-compliant version string>",
"<dist-tag-name>": "<semver-compliant version string>"
},
"versions": {
"<version>": {
"name": ...,
"deprecated": "please don't use this" // this version is deprecated
},
"<version>": {
"name": ... // this version is actively developed
}
}
}
The `npm deprecate` command essentially retrieves the package metadata with packument, sets the `deprecated` message on the specified version(s), and uploads it with packument.
The `npm outdated` command prints the message as a warning if it is seen.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
@Hervé:
The NuGet `deprecation` object exists in the NuGet package metadata.
It is described here: https://docs.microsoft.com/en-us/nuget/api/registration-base-url-resource#package-deprecation
Example snippet from the docs:
{
"@id": "https://api.nuget.org/v3/registration3/nuget.protocol.v3.example/1.0.729-unstable.json",
"@type": "Package",
"commitId": "e0b9ca79-75b5-414f-9e3e-de9534b5cfd1",
"commitTimeStamp": "2017-10-26T14:12:19.3439088Z",
"catalogEntry": {
"@id": "https://api.nuget.org/v3/catalog0/data/2015.02.01.18.22.05/nuget.protocol.v3.example.1.0.729-unstable.json",
"@type": "PackageDetails",
"authors": "NuGet.org Team",
"deprecation": {
"reasons": [
"CriticalBugs"
],
"message": "This package is unstable and broken!",
"alternatePackage": {
"id": "Newtonsoft.JSON",
"range": "12.0.2"
}
},
"iconUrl": "https://www.nuget.org/Content/gallery/img/default-package-icon.svg",
"id": "NuGet.Protocol.V3.Example",
"licenseUrl": "http://www.opensource.org/licenses/ms-pl",
"listed": false,
"packageContent": "https://api.nuget.org/v3-flatcontainer/nuget.protocol.v3.example/1.0.729-unstable/nuget.protocol.v3.example.1.0.729-unstable.nupkg",
"projectUrl": "https://github.com/NuGet/NuGetGallery",
"published": "1900-01-01T00:00:00+00:00",
"requireLicenseAcceptance": true,
"summary": "This package is an example for the V3 protocol.",
"title": "NuGet V3 Protocol Example",
"version": "1.0.729-Unstable"
},
"packageContent": "https://api.nuget.org/v3-flatcontainer/nuget.protocol.v3.example/1.0.729-unstable/nuget.protocol.v3.example.1.0.729-unstable.nupkg",
"registration": "https://api.nuget.org/v3/registration3/nuget.protocol.v3.example/index.json"
}
...
}
NuGet has chosen to pack some extra fields into their `deprecation` object, rather than make it a simple boolean flag. I'm not sure all of them are really necessary, or whether the deprecation object is the right place for some of them. But that's all up for discussion of course.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi Chris,
working for some clients in the last years, I saw nearly all of them
struggling with their dependency management. Sad, but true.
I see various use cases for the feature you propose, not only in the
public space. This feature could be also very interessting for
companies, if they would like to prohibit the usage of specific
components, internal and external ones, because of their own regulations.
Oliver
Am 30.07.2021 um 11:00 schrieb Chris Kilding:
> Hi,
>
> @Oliver:
>
> Glad of the help :) My definition of 'deprecated' would be roughly 'this artifact is not actively developed and should not be used any more'.
>
> One example I have in mind for deprecation is Joda Time - a library which was superseded years ago by java.time in Java 8 and Android API 26. It stopped receiving feature updates a while back, and now receives only timezone data updates. Nevertheless, it's not going away - in fact it's spreading into more projects over time: GitHub says it had 110,000 public dependents in Jan 2021, and 118,000 in July 2021. It's a textbook de-facto deprecated dependency, but at the moment, there is no formal mechanism to warn the downstream consumers about this. The only indicator today is a deprecation note in the README.
>
> Yes, I agree that the relocation feature seems to address a different use case.
>
> Chris
>
> On Thu, 29 Jul 2021, at 10:15 PM, Oliver Fischer wrote:
>> Hi Chris,
>>
>> I also see the need for such a feature and would like to support you as
>> friendly tester.
>>
>> Some people in this thread pointed out, that there is already the
>> relocation feature. I think it addresses a different use case. BTW, I
>> have not been aware of it until today.
>>
>> Furthermore I think it is needed to define what you mean by
>> "deprecated". For some people it means, that there is a newer version
>> out there. For me it could mean that you should not use this version or
>> artifact anymore.
>>
>> I can imaging situations where you simply would like to deprecate the
>> latest version of an artifact for some reason, for example for security
>> reasons, without having a plan to release any newer version.
>>
>> Oliver
>>
>>
>>
>> Am 28.07.21 um 12:10 schrieb Chris Kilding:
>>> Hello,
>>>
>>> I would like to propose a new Maven feature: dependency deprecation indicators.
>>>
>>> In a nutshell, the idea is to let maintainers set a 'deprecated' metadata indicator on a Maven artifact in a repository. This will indicate to users that the artifact should no longer be used.
>>>
>>> The Maven CLI tools could then react to deprecation indicators in the appropriate ways:
>>>
>>> - `mvn` itself: Print a warning when deprecated dependencies are seen.
>>> - Maven Enforcer Plugin: Add a <banDeprecatedDependencies> rule which throws an error when deprecated dependencies are seen.
>>> - Maven Dependency Tree: Print a [deprecated] notice next to any deprecated dependency in the tree.
>>> - ...and so on
>>>
>>> We can also envisage automated agents like Dependabot using these indicators to alert developers about deprecated dependencies in their stacks, and assisting developers to remove them.
>>>
>>> Some of the major build tools outside the JVM already have deprecation indicators:
>>>
>>> - NPM: https://docs.npmjs.com/cli/v7/commands/npm-deprecate
>>> - Nuget: https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages
>>> - Composer / Packagist: https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-without-leaving-anyone-behind/
>>>
>>> So the feature has precedent, and I believe it would be useful to have in Maven. If there is demand for it, I am willing to work on it.
>>>
>>> There are definitely several good questions to be answered about what exactly the feature would look like, so questions and comments are welcome :)
>>>
>>> Regards,
>>>
>>> Chris Kilding
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Chris Kilding <ch...@chriskilding.com>.
Hi,
@Oliver:
Glad of the help :) My definition of 'deprecated' would be roughly 'this artifact is not actively developed and should not be used any more'.
One example I have in mind for deprecation is Joda Time - a library which was superseded years ago by java.time in Java 8 and Android API 26. It stopped receiving feature updates a while back, and now receives only timezone data updates. Nevertheless, it's not going away - in fact it's spreading into more projects over time: GitHub says it had 110,000 public dependents in Jan 2021, and 118,000 in July 2021. It's a textbook de-facto deprecated dependency, but at the moment, there is no formal mechanism to warn the downstream consumers about this. The only indicator today is a deprecation note in the README.
Yes, I agree that the relocation feature seems to address a different use case.
Chris
On Thu, 29 Jul 2021, at 10:15 PM, Oliver Fischer wrote:
> Hi Chris,
>
> I also see the need for such a feature and would like to support you as
> friendly tester.
>
> Some people in this thread pointed out, that there is already the
> relocation feature. I think it addresses a different use case. BTW, I
> have not been aware of it until today.
>
> Furthermore I think it is needed to define what you mean by
> "deprecated". For some people it means, that there is a newer version
> out there. For me it could mean that you should not use this version or
> artifact anymore.
>
> I can imaging situations where you simply would like to deprecate the
> latest version of an artifact for some reason, for example for security
> reasons, without having a plan to release any newer version.
>
> Oliver
>
>
>
> Am 28.07.21 um 12:10 schrieb Chris Kilding:
> > Hello,
> >
> > I would like to propose a new Maven feature: dependency deprecation indicators.
> >
> > In a nutshell, the idea is to let maintainers set a 'deprecated' metadata indicator on a Maven artifact in a repository. This will indicate to users that the artifact should no longer be used.
> >
> > The Maven CLI tools could then react to deprecation indicators in the appropriate ways:
> >
> > - `mvn` itself: Print a warning when deprecated dependencies are seen.
> > - Maven Enforcer Plugin: Add a <banDeprecatedDependencies> rule which throws an error when deprecated dependencies are seen.
> > - Maven Dependency Tree: Print a [deprecated] notice next to any deprecated dependency in the tree.
> > - ...and so on
> >
> > We can also envisage automated agents like Dependabot using these indicators to alert developers about deprecated dependencies in their stacks, and assisting developers to remove them.
> >
> > Some of the major build tools outside the JVM already have deprecation indicators:
> >
> > - NPM: https://docs.npmjs.com/cli/v7/commands/npm-deprecate
> > - Nuget: https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages
> > - Composer / Packagist: https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-without-leaving-anyone-behind/
> >
> > So the feature has precedent, and I believe it would be useful to have in Maven. If there is demand for it, I am willing to work on it.
> >
> > There are definitely several good questions to be answered about what exactly the feature would look like, so questions and comments are welcome :)
> >
> > Regards,
> >
> > Chris Kilding
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature proposal: Dependency deprecation indicators
Posted by Oliver Fischer <ma...@swe-blog.net>.
Hi Chris,
I also see the need for such a feature and would like to support you as
friendly tester.
Some people in this thread pointed out, that there is already the
relocation feature. I think it addresses a different use case. BTW, I
have not been aware of it until today.
Furthermore I think it is needed to define what you mean by
"deprecated". For some people it means, that there is a newer version
out there. For me it could mean that you should not use this version or
artifact anymore.
I can imaging situations where you simply would like to deprecate the
latest version of an artifact for some reason, for example for security
reasons, without having a plan to release any newer version.
Oliver
Am 28.07.21 um 12:10 schrieb Chris Kilding:
> Hello,
>
> I would like to propose a new Maven feature: dependency deprecation indicators.
>
> In a nutshell, the idea is to let maintainers set a 'deprecated' metadata indicator on a Maven artifact in a repository. This will indicate to users that the artifact should no longer be used.
>
> The Maven CLI tools could then react to deprecation indicators in the appropriate ways:
>
> - `mvn` itself: Print a warning when deprecated dependencies are seen.
> - Maven Enforcer Plugin: Add a <banDeprecatedDependencies> rule which throws an error when deprecated dependencies are seen.
> - Maven Dependency Tree: Print a [deprecated] notice next to any deprecated dependency in the tree.
> - ...and so on
>
> We can also envisage automated agents like Dependabot using these indicators to alert developers about deprecated dependencies in their stacks, and assisting developers to remove them.
>
> Some of the major build tools outside the JVM already have deprecation indicators:
>
> - NPM: https://docs.npmjs.com/cli/v7/commands/npm-deprecate
> - Nuget: https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages
> - Composer / Packagist: https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-without-leaving-anyone-behind/
>
> So the feature has precedent, and I believe it would be useful to have in Maven. If there is demand for it, I am willing to work on it.
>
> There are definitely several good questions to be answered about what exactly the feature would look like, so questions and comments are welcome :)
>
> Regards,
>
> Chris Kilding
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org