Hello all and Happy New Year!
I've recently come across the concept of "libyears"[1], and I've found it
quite
useful as a method for quantifying dependency debt when speaking to team
leads
and managers about prioritisation. I noticed it doesn't have an
implementation
for Maven projects. It reminded me of the MojoHaus Versions Maven Plugin
and I
thought this would be a fun project to learn how Maven plugin projects are
built
and packaged.
After some testing, the idea seems viable and I've now got a GitHub project
for
the plugin[2]. There is no release version yet but you can clone it and
build it
locally to test it. Architecturally it is simple. The project has a
dependency
on org.codehaus.mojo:versions-maven-plugin and has a single mojo called
LibYearMojo that is very similar to DisplayDependencyUpdatesMojo, but with
fewer
supported configuration options. The difference is that instead of
displaying
the available updates it makes an API call[3] to find the release date of
the
current and latest version and then shows the time difference between them.
The
output looks like this:
```
[INFO] --- libyear-maven-plugin:0.0.1-SNAPSHOT:libyear-report (default-cli)
@ libyear-maven-plugin ---
[INFO]
[INFO] The following dependencies in Dependencies have newer versions:
[INFO] org.apache.maven.plugin-tools:maven-plugin-annotations . 0.79
libyears
[INFO] org.apache.maven.resolver:maven-resolver-api ........... 1.56
libyears
[INFO] org.apache.maven:maven-compat .......................... 0.52
libyears
[INFO] org.apache.maven.wagon:wagon-provider-api .............. 0.98
libyears
[INFO] org.apache.maven:maven-model ........................... 0.52
libyears
[INFO] org.apache.maven:maven-plugin-api ...................... 0.52
libyears
[INFO] org.mockito:mockito-junit-jupiter ...................... 0.04
libyears
[INFO] org.apache.maven:maven-artifact ........................ 0.52
libyears
[INFO] org.apache.maven:maven-core ............................ 0.52
libyears
[INFO]
[INFO] Total years outdated: 5.96
```
Before I do the work to make an initial release I wanted to contact this
mailing
list to ask a few questions. I'd really appreciate if anybody has time to
answer
them, thanks!
1) Is this functionality that versions-maven-plugin would want to support?
It
initially felt to me that libyear support is something too
unofficial/out-of-scope but I wanted to verify that before releasing a
new
plugin. If it's something to support here, I will happily raise a merge
request for discussion.
2) Refactoring. Since my mojo is incredibly similar to
DisplayDependencyUpdatesMojo, ideally I could inherit from that class and
hook in some code to the logUpdates method to perform my dependency age
calculations. Right now I can't really do this because the class isn't
designed to be used as a library. As a result I've had to copy most of
the
code in the class which creates an unnecessary maintenance burden for
tracking upstream changes and adds some license compliance concern. I've
also
had to delete bits that I don't understand yet or don't intend to
support,
but with this inheritance approach I may be able to support all of the
features and configuration that DisplayDependencyUpdatesMojo supports
while
having my mojo be a very small and easy-to-maintain class with no
duplicated
business logic. Is there something I'm not considering properly here, and
would you be OK with me trying some refactoring to find something that
works
and then proposing it back for discussion?
3) License compliance. This is my primary concern. I want to make absolutely
sure that I'm complying with Apache 2.0 and not making any copyright
infringements. In particular:
- I have copied DisplayDependencyUpdatesMojo.dependenciesMatch into my
project[4]. It is a protected static method and I was wondering if it
could
either be made public or moved into a public helper class inside
org.codehaus.mojo:versions-common. This would let me remove it from my
project entirely.
- I have copied some of the @Parameter fields and their documentation[5].
- I have copied some of the code in the execute[6] and logUpdates methods
into
my class because there's currently no way to hook in my display logic.
I'm hoping that with a small refactoring and by inheriting from
DisplayDependencyUpdatesMojo, I can inherit all of the parameters and the
business logic that processes them. This would let me delete a large
chunk of
copied dependency inspection logic as my class would now only need to
implement display logic. Until that happens though, I'd appreciate it if
anybody has suggestions on labelling the copied areas.
Thanks a lot for reading this far. I'd greatly appreciate any
thoughts/comments/suggestions.
Martin
[1] https://libyear.com/
[2] https://github.com/mfoo/libyear-maven-plugin
[3] API call is to https://search.maven.org, docs at
https://central.sonatype.org/search/rest-api-guide/
[4]
https://github.com/mfoo/libyear-maven-plugin/blob/ec812e2f848e58152977f15c609727caa9c800c9/src/main/java/com/mfoot/mojo/libyear/LibYearMojo.java#L305
[5]
https://github.com/mfoo/libyear-maven-plugin/blob/ec812e2f848e58152977f15c609727caa9c800c9/src/main/java/com/mfoot/mojo/libyear/LibYearMojo.java#L112
[6]
https://github.com/mfoo/libyear-maven-plugin/blob/ec812e2f848e58152977f15c609727caa9c800c9/src/main/java/com/mfoot/mojo/libyear/LibYearMojo.java#L329
[7]
https://github.com/mfoo/libyear-maven-plugin/blob/ec812e2f848e58152977f15c609727caa9c800c9/src/main/java/com/mfoot/mojo/libyear/LibYearMojo.java#L391
--
You received this message because you are subscribed to the Google Groups
"mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mojohaus-dev/5f05a95d-cc76-4581-bc41-3b105912169en%40googlegroups.com.
