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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
