[feature] EOL tracking with release date of current dependency version

[TorstenKruse]

We are searching for a tool to support EOL management of dependencies. I'll try to explain our idea and would like to know, if a pull request of this kind is interesting for others as well and would be accepted - or if this is out of scope of this plugin.

The current report via "dependency-updates-report" is great to be informed for possible updates and so it ensures that the projects don't use real old dependency versions if newer are available.

But what if there is no newer version for a dependency since years? It will never show in the report, because there is no update. We would like to visualize this dependencies too - so the project can decide what to do with this old dependencies. Is it still ok to use them or should they be replaced by another dependency? Maybe just the GAV was changed? Or there is a fork? Or something completely new?

An outline of what changes would be required to make this possible:
a) a new config parameter like "eolBefore" which contains a date and advices the report to treat all dependencies with a release date before this to be old
b) the release date of each dependency needs to be determinded (e.g. a request like https://search.maven.org/solrsearch/select?q=a:jasypt-spring3+AND+g:org.jasypt&rows=1&wt=json to get the "timestamp") - or does somebody know a better source?
c) the dependency-updates-report should contain one more column which contains the release date of the dependency
d) the dependency-updates-report should contain one more category "# of dependencies using the latest version available which is older than "

Only if in a) the config parameter is used, b), c) and d) will be executed.

[TorstenKruse]

Hi @jarmoniuk @stephenc
Could you give me a feedback about my feature proposal? Or whom should I ask?

[stephenc]

@slachiewicz is probably your best bet. I'm dragged to a different language by work so not super active in JVM 😭

[TorstenKruse]

Thanks for info. So @slachiewicz do you think my feature idea would be valuable for the plugin?

[slawekjaranowski]

I would like to simple add next - option c

We can call it as libyear - https://libyear.com/

There is a example plugin:

mvn eu.maveniverse.maven.plugins:toolbox:gav-libyear -Dgav=org.codehaus.mojo:versions-maven-plugin:2.16.2

@cstamas is a autor of it

[cstamas]

Much better source is Central itself, just do a HEAD against artifact and you will get the "published date" of artifact. It works for all "recently published" artifacts, while some (pre)historic artifacts migrated from old Central have it off, but IMHO is ok.

You can use search-api w/ RR backend (as it does all for you):
https://github.com/apache/maven-indexer

(smo-backend is the Sonatype search you showed example with, that is central only, while remoterepo backend is a limited functionality but usable for against all repoitories).

Or, you can reuse "shared" module from toolbox:
https://github.com/maveniverse/toolbox

[TorstenKruse]

Thanks for your suggestions @slawekjaranowski and @cstamas .

I checked them and libyear looks really great to get an idea about the "age" of a projects dependencies. Really better than "bad" or "really bad". :)

But...like the version plugin the reports from libyear are just missing the dependencies which are on the latest version but this version being e.g. 10 years old. An example for this is commons-beanutils:commons-beanutils. And exactly this possible EOL dependencies I would like to catch and handle.

Before your suggestions my question was "would the version plugin" accept my feature?". Now the question seems to be if the version plugin is the right place or if even libyear would accept such a feature.

As the aim of libyear is to calculate the "libyears behind", the best it could do is to add "current but old" dependencies e.g. with their age to the libyears. But this still does not clearly identify "current but old" dependencies.

So I'm still on the version plugin on would like to implement this, if the project will accept it.

But that's just my point of view. What do you think about?

[cstamas]

For creating a "libyear"-alike feature for versions plugins, sure, why not. We happily accept PRs 😉

If you look at https://libyear.com/ site (right hand bottom of the page), you will see there are different approaches, libyear ("year sum of the lagging libs age") is just one approach, while there are other ones as well (not implemented in toolbox, and I am not affiliated to libyear com!): --releases is sum of count of releases since, and --versions that looks like ruby specific.

"Last release age" is easy to add, and will in fact do it in toolbox as sounds really useful, but again, for libyear you should contact authors of papers behind https://libyear.com/ (page very bottom).

[cstamas]

Example of added "age": https://gist.github.com/cstamas/fe8d4b006a4b47f638dd7f8d59af04a8

[cstamas]

Showing up to date deps age as well
https://gist.github.com/cstamas/28b53ad146ec7e1af51df65358e1eaac

[TorstenKruse]

Your last example including the up to date deps is exactly what is driving me.
Deps like "javax.inject:javax.inject:jar 1 (2009-10-14) [age 14.67 years]" I would like to identify.

So if a PR as described by me in the first post of this issue would be accepted, I'll go into further details of how to implement including your hints about possible implementations.

Thanks so far.