-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore /META-INF/versions/9/module-info.class by default #33
Comments
Wondering if the mentioned PR mentioned above would get merged? |
Hi, thanks for the ping. This is related to multi-release jars and requires a more comprehensive change to the plugin. I am planning to do this when I find time. As a workaround, you can add this pattern in your pom as well. |
Thanks for the quick reply. I have added the ignore pattern to my pom for the time being. Thanks for your work on producing a very useful plugin!! |
See basepom/duplicate-finder-maven-plugin#33 for details. Change-Id: I582fc1447dbe6db09888c78eb6ed95ae2cb62250
This problem is continuing to spread -- latest releases of very popular jars like |
I need to find time to work out how to deal with multi-release jars. PRs very welcome |
Use more care when deciding whether a given file is a class file or a resource. Align closer to the java specification (and what the class loaders consider a valid class name). Add an integration test for issue 33 that tests the example from basepom#33.
Use more care when deciding whether a given file is a class file or a resource. Align closer to the java specification (and what the class loaders consider a valid class name). Add an integration test for issue 33 that tests the example from #33.
This is fixed in the next version. I am planning that the next version will be the last one that runs on JDK8 and the one after will be JDK9+ exclusive. In that version, I am planning to do more work with multi-release jars; currently there is a corner case where a duplicate class is not detected:
the current plugin would not detect this conflict when running under JDK9. To be able to manage these type of conflicts, the code must analyze the Multi-Release flag from the manifest and then build a map on which classes are actually visible on the class path. Very doable but I see no point in doing this for the JDK 8 version. |
We have the same issue with
/META-INF/versions/9/module-info.clas
files as in #31.e.g. https://travis-ci.org/zalando/logbook/jobs/448681344 or #31 comment
The text was updated successfully, but these errors were encountered: