Open garrettjonesgoogle opened 5 years ago
A simple design doc might be a good way to start. It's tricky because how do you know which other artifacts to look in? For example, if you're releasing javax.servlet:javax.servlet-api:3.1 could a program guess that it should compare against javax.servlet:servlet-api:2.5
How many versions?
What about third party forks? e.g. xom:xom vs. com.io7m.xom:xom?
I'll create a 1-page design doc. This issue (overlapping class) may be a subset of Java 9 module issue.
jdeps will report split packages
see https://blog.codefx.org/java/java-9-migration-guide/#Split-Packages
That's a nice article. (I happened to be reading his book today). I will check out jdeps.
Also I like this short-term fix for split packages:
If you indeed just have a couple of classes that split a package, the long-term solution is to remove the split. In case that is not possible in the short-term, you can patch the named module with the content from the class path. The option --patch-module $module=$artifact will merge all classes from $artifact into $module, putting all portions of the split package into the same module, thus mending split
Draft ready for review: http://go/jdd-jpms.
NoSuchMethodError when using Spring Spanner starter was caused by a overlapping class. I checked other overlapping classes in our BOM, but they seem fine. https://gist.github.com/suztomo/509e933925cc9c150ef3476db0148663
Specifically, we would want to run a checker to make sure that a new release of a library (e.g. google-cloud-java) wasn't creating new artifacts containing classes that other artifacts already contain.