versions-maven-plugin and libyear-maven-plugin

[Martin Foot]

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

[Andrzej Jarmoniuk]

Hi Martin,

Thanks for writing. As one of the main contributors, DisplayDependencyUpdatesMojo and other mojos from the plugin is not public API. It's also subject to ongoing development and its private, protected and public members change, since there's no intention of exposing the interface nor supporting extensions. It's highly possible that an update to the plugin will break dependencies on your plugin unless you're willing to adapt. If you're going to accept that, feel free to extend the internal classes, but be aware that any update on our side may break your dependencies.

Instead of extending the implementation classes, I'd rather duplicate them inside your project.

We're currently working on public API (the versions-api module) which is supposed to be used and is supposed to be stable.

Best regards,

Andrzej

Op woensdag 4 januari 2023 om 10:25:04 UTC+1 schreef mar...@mfoot.com: