Renovate: Support Java

[rarkins]

This issue is for building up (a) support (please +1 if you would like to see Java support) and (b) requirements, e.g. helping suggest what scope is required and what APIs can be used.

[HealthPDU]

Could you elaborate on how you would like help to support Java? maven - and the marvellous pom file -
would seem like a excellent starting point that should cover most java projects.

keen to help but more info please :-)

[rarkins]

@HealthPDU the way I intend for it to work is that Renovate would call maven at relevant times via child processes and commercial and pass input/output either via stdin/stdout or via files.

If you are able to help with describing requirements and/or even the maven commands parts then I can help glue the rest of it together so that any maven expert helping would not need to spend much time to understand Renovate internals.

[HealthPDU]

Casting an eye over the different implementations from the lib/managers directory it looks like your starting point is to resolve the complete set of dependencies for a project? Hopefully the following information will help to kick things off and doesn't just document stuff you already know :-)

From a Java maven perspective, dependency resolution starts with the project's pom.xml (specifically the <dependencies> section) and then - for each listed dependency - looks into its own pom.xml (to find its dependencies) and so on... (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html)

These recursive checks can get pretty complex in order to derive the full dependency tree. Luckily, maven offers some command line utilities that will traverse the poms to resolve all project dependencies for you. This might serve as a good starting point for bringing Java to renovate with the maven dependency utility (https://maven.apache.org/plugins/maven-dependency-plugin/index.html) having a couple of useful commands.

mvn dependency:list on its own (in the project's directory) will output the full dependency list to standard out at INFO level. Running mvn dependency:list -DoutputFile=maven-list-output.log will output the dependencies to file maven-list-output.log without the INFO prefix making it easier to parse. An example output is below.

The following files have been resolved:
   org.apache.bcel:bcel:jar:5.2:test
   org.apache.qpid:qpid-broker-plugins-jdbc-provider-bone:jar:6.0.2:test
   org.apache.qpid:qpid-broker-plugins-management-http:jar:6.0.2:test
   com.fasterxml.jackson.core:jackson-annotations:jar:2.8.0:compile
   log4j:log4j:jar:1.2.17:compile
   org.eclipse.jetty:jetty-webapp:jar:9.4.6.v20170531:compile
   org.apache.derby:derby:jar:10.11.1.1:test
   org.apache.qpid:qpid-broker-plugins-amqp-0-8-protocol:jar:6.0.2:test
   org.eclipse.jetty:jetty-continuation:jar:9.4.6.v20170531:compile

The dependencies are listed as <groupId>:<artifactId>:<package-type>:<version>:<scope> and map to (one of the) maven repositories as https://repo.maven.apache.org/maven2/<groupId>/<artifactId> (and /<version>) with any dots in the <groupId> being translated to / for the package tree.

Does this help at all?

[rarkins]

Thanks. Its definitely the type of info that helps. I will look into the links you provided.

[audkar]

I would be very interested in seeing support for Gradle.

Both build tools (mvn and gradle) have existing plugins to check for possible updates. For Gradle exits - gradle-versions-plugin, for Maven - versions-maven-plugin.

These plugins already does half of a job. Maybe would be possible make existing solution work with renovate?

[ChristianMurphy]

Maven central provides a REST API that may be able to help. https://search.maven.org/#api

There are also a few wrappers around the Maven CLI (https://github.com/headcr4sh/node-maven and https://github.com/snyk/snyk-mvn-plugin) and Gradle CLI (https://github.com/macacajs/gradle and https://github.com/snyk/snyk-gradle-plugin)

[blindenvy]

+1 I would be interested in seeing support for maven as well.

[corecanarias]

Hi @rarkins would you consider a solution like this one https://github.com/renovatebot/renovate/pull/2610 ?

It has the advantages of using a gradle plugin to handle all the logic related to extracting the dependencies, finding the new versions and also doing the update. So the code in renovate is minimal.

The bad part as I see it is that it depends on gradle, so it has to be available in the renovate hosting. Also we would be running external code inside the renovate infrastructure I guess this would be a problem depending on how good the isolation for the renovate process is. I suppose this should be fine for self-hosted users.

If you think it could work, I would love to finish it, adding the tests and everything else. If not, I think the best solution would be to duplicate the functionality that the gradle plugin is providing inside renovate. I'm not sure if I will be able to do all that work at this time. I definitely want to see the gradle support in renovate, but not sure how long it will take me 😓

What do you think?

[rarkins]

@corecanarias yes, I think this is the right approach for package managers whose internal algorithms are challenging or impossible to reproduce. If any parts are considered "insecure" then they can at least be supported for self-hosted users until some time when it's secure enough for the hosted app.

I think the way we'd do it would be slightly different to your starter PR, but let's discuss in that PR instead and anyone who's super interested can subscriber there for updates while we discuss.

[renovate-bot]

:tada: This issue has been resolved in version 13.113.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: