The app in my work is a maven application with a pom file inherited from a parent pom file. I followed the migration doc and did a scan for both maven and gradle build. But I noticed some dependency has a few additional child dependencies included in the gradle build? How to fix it?
Which also mentions that the conversion is maybe not 100% and that you might have to manually do things, latest when plugins are used.
And that was not my question.
I do see in the parent pom there is <dependency> <groupId>com.oracle.ojdbc</groupId> <artifactId>osdt_cert</artifactId> <version>19.3.0.0</version> </dependency> .
I suppose Maven automatically override the original com.oracle.jdbc:osdt_cert:12.2.0.1 with the dependency above since ojdbc is newer version of jdbc.
Can gradle handle that as well? I can not manually change all similar cases since there may be dozens or more.
As you are refusing to show your POM I can only guess about your situation or give general information.
The versionconflict resolution strategies of Gradle and Maven are pretty different.
Maven uses the first nearest wins algorithm which imho is non-sense, but it means that if you depend on A version 1 and B version 1 while B version 1 depends on A version 2, you end up with A version 1 as that dependency is nearer.
Gradle by default uses the newest wins algorithm which makes usually more sense, as it is much more likely that something that works with A v1 also works with A v2 while the opposite is most often not the case. And if you want, you can still forcibly downgrade some version.
Optional dependencies in POMs have no relevance at all.
Maven ignores them completely and so does Gradle. (It used to at least add them as constraints in some preview version but that didn’t work out good)
Ah, it seems the optional is not recognized properly as there are spaces inside the optional tag.
I think you found a bug that you should report and as a work around you either need to fix the POM or exclude the optional dependencies manually.
I have the same permissions than you.
But Bugs should not be reported here anyway which probably is the cause for the closed category, but at Issues · gradle/gradle · GitHub.
Regarding the excludes you tried, they are working fine for me.
Or rather you have a typo in the first where you have jdbcs instead of jdbc and you forgot three more.
But the three you typed correctly are excluded for me.
Btw. actually, exclude is not the idiomatic solution for fixing bad (or as in this case misinterpreted) metadata, but instead a component metadata rule should be the tool of choice.
You can read more about them at Gradle User Manual: Version 6.8.3
With a concrete example of what you need at Gradle User Manual: Version 6.8.3
Thanks for the provided doc link. I’ve read that and tried to create a new rule in my setting.gradle. But the interface ComponentMetadataRule does not exist, what am I missing?
What do you mean with “does not exist”? Did you import the class? Does it only display red in the IDE but works when building? What error do you get where?
I tried executing gradle build but I got this error Could not find method dependencyResolutionManagement() for arguments [settings_4xqc88jl6ee4ndtpq14ymbpqt$_run_closure1@3bd01347] on settings 'myApp' of type org.gradle.initialization.DefaultSettings.
In IDE the class and import are both red.
dependencyResolutionManagement in the settings script was added in 6.8.
You should not read the documentation of 6.8.3 and apply it 1:1 to your 6.0 build.
Either read the documentation fitting your Gradle version or update your Gradle version to the one you are reading the documentation of.
If you cannot update your Gradle version, you need to use the rule in the projects, not in the settings script.