Migration guide

[boris-petrov]

Important

(edit by @jjohannes) As we never got around to write a migration guide from one of the predecessor plugins, this issue serves as the guide. If you migrate from one of the following plugins to this one and have questions, please ask in this issue.

• https://plugins.gradle.org/plugin/org.gradlex.java-ecosystem-capabilities
• https://plugins.gradle.org/plugin/dev.jacomet.logging-capabilities

Congratulations on releasing version 2 of this awesome plugin! And thanks for the hard work on it!

But it would be nice to have a migration path from 1.5.3 to 2.0. Here's what I did:

1. Replace:

id 'org.gradlex.java-ecosystem-capabilities' version '1.5.3'
id 'dev.jacomet.logging-capabilities' version '0.11.1'

With:

id 'org.gradlex.jvm-dependency-conflict-resolution' version '2.0'

I guess I don't need to also specify the detection plugin as the resolution one depends on it?

2. Replace my loggingCapabilities configuration with jvmDependencyConflicts.logging (based on this).

Run my build. I was hoping that to immediately work but it didn't. :D I got a few Could not resolve net.bytebuddy:byte-buddy:1.14.13. ... Cannot find a version of 'net.bytebuddy:byte-buddy' that satisfies the version constraints:. I'm not really sure why. I see that some transitive dependencies require different versions of byte-buddy - but isn't Gradle supposed to just take the latest version and call it a day? What has changed in the plugin? What must I do?

Thanks!

[jjohannes]

Hi @boris-petrov thank you for the prompt feedback. You should need to replace:

1. Plugins java-ecosystem-capabilities and logging-capabilities with jvm-dependency-conflict-resolution.
2. loggingCapabilities with jvmDependencyConflicts.logging
3. If you did your own capability conflict resolution (via Gradle's API) and used classes/constants from the plugin, you would need to adjust them. This was restructured. Also, capabilities now are org.gradlex:<capability-name>. Maybe that's the issue and some of your capabilitiesResolution strategies no longer apply as expected? (If this is not your issue, can you share more of the error you are seeing?)

And you are right, we have to add that to the docs. Especially (3) can be tricky/unexpected. Thanks for this issue, will see that we address it.

[boris-petrov]

@jjohannes thanks for the support!

As far as I understand, I've done 1 and 2, right? Your points look exactly like mine so I think that's done.

As for point 3, I have a few things in my Gradle file:

java {
	consistentResolution {
		useRuntimeClasspathVersions()
	}
}

configurations.configureEach {
	resolutionStrategy {
		failOnNonReproducibleResolution()

		capabilitiesResolution {
			withCapability('javax.activation:activation') { ...
			withCapability('javax.servlet:servlet-api') { ...
			withCapability('javax.websocket:javax.websocket-api') { ...

I think that's the relevant parts. But note that the error I get is on byte-buddy which I have absolutely no configuration about. The only place in my code that mentions it is in dependencies - testRuntimeOnly 'net.bytebuddy:byte-buddy:1.14.13'. That's it. And, of course, some of my transitive dependencies bring their own versions which I guess cause the conflict. But, as I mentioned above, shouldn't Gradle just pick the highest version and be done with it? Why that doesn't happen here now that I've updated this plugin's version?

Thanks again!

[jjohannes]

You have to replace this:

withCapability('javax.activation:activation') { ...
withCapability('javax.servlet:servlet-api') { ...
withCapability('javax.websocket:javax.websocket-api') { 

...with...

withCapability('org.gradlex:javax-activation-api') { ...
withCapability('org.gradlex:javax-servlet-api') { ...
withCapability('org.gradlex:javax-websocket-api') { 

You should also make sure to disable the default resolution strategy jvmDependencyConflicts.conflictResolution.deactivateResolutionStrategy when you use Gradle's standard withCapability to add your own resolution (because this issue may give trouble 😞 ).

OR use the new jvmDependencyConflicts.conflictResolution.select { ... } DSL and then the corresponding enum values from CapabilityDefinition instead of the Strings, which also keeps care of disabling the default strategy automatically.

Not to self:
For this kind of stuff we need that migration guide!

---

I don't know why you get the "byte-buddy:1.14.13" conflict. Maybe you have a different order of dependencies or more dependencies if some conflicts were resolved differently. Can you share the complete error message that tells which versions you have from where?

[boris-petrov]

OK, so after a lot of trial and error, I understood the following: dev.jacomet.logging-capabilities was suppressing some errors (this with byte-buddy and a couple of others) which were due to java.consistentResolution.useCompileClasspathVersions. This is an example script:

plugins {
	id 'java'
	// id 'dev.jacomet.logging-capabilities' version '0.11.1'
}

repositories {
	mavenCentral()
}

java {
	consistentResolution {
		useCompileClasspathVersions()
	}
}

dependencies {
	implementation platform('com.fasterxml.jackson:jackson-bom:2.17.0')
	implementation 'org.camunda.bpm.extension.reactor:camunda-bpm-reactor-core:2.1.2'
	runtimeOnly 'net.bytebuddy:byte-buddy:1.14.13'
}

Running, say, ./gradlew test on that will fail. Uncommenting the commented-out line makes it work (which is wrong I think). But no matter, that's a problem in the "old" plugin so no need to spend time fixing it.

I removed all my capabilitiesResolution.withCapability rules and replaced them with just:

conflictResolution {
	select(CapabilityDefinition.JAVAX_ACTIVATION_API, 'com.sun.activation:jakarta.activation')
	select(CapabilityDefinition.JAVAX_SERVLET_API, 'org.apache.tomcat:tomcat-servlet-api')
}

Which seems to work great.

All in all I managed to fix all my issues so thanks for the time and help! You might close this issue whenever you see fit. And thanks again for the hard work on this awesome plugin!