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 [email protected]: > 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/13589358-abd2-4a03-8a1c-d04bd7255132n%40googlegroups.com.
