-
Notifications
You must be signed in to change notification settings - Fork 27
mvn integration-test site
fails enforce-ban-duplicate-classes
#270
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
Comments
(I should also point out that I'm unsure if this is a "real" problem in the final jars or a strange corner case.) |
Possible related, I see the following warning when doing
|
In general we shade and relocate dependencies for the primary java-manta-client jar. So The case of Within the multi-module project I don't have a clear model for when a dependency on Adding a bunch of <exclusion>
<groupId>com.twmacinta</groupId>
<artifactId>fast-md5</artifactId>
</exclusion> to the intra-model dependencies appears to resolve all issues. I don't think that is harmful, but it is also not entirely satisfying. @dekobon Do you have an historical context or advice on how to proceed? |
I can't seem to reproduce this error. In fact, I can't seem to make the enforce plugin run at all now:
|
So ``mvn integration-test site My understanding is that we can't |
I just tried again after doing |
Cloud steps:
Your keys listed on github should get you into 165.225.139.167 |
Dumping the dependency tree for java-manta-client-kryo-serialization doesn't show a direct dependency on com.twmacinta:fast-md5:
I also inspected all of the pom.xml files and I can't find a direct reference to that dependency. |
I can keep the error from happening by doing: <ignoreClasses>
<ignoreClass>com.twmacinta.util.*</ignoreClass>
</ignoreClasses> However, that doesn't address the root cause. It seems as though something is getting confused within the enforcer plugin. What is notable is that this is the only class that is being shaded but not relocated. |
I tried Many times when I'm setting up CI for Java, I will run different Maven goals in different stages because it helps to avoid this kind of weirdness. Most typically, I only run I see two fixes: 1. Suppress the check for the specific class in question. I've already verified that it isn't duplicated in any of the final JARs. 2. Leave it as is and make a note that site should be run after running install or integration-test. |
Latest Update on this issue since I am tracking it:
|
PR #285 will have to be merged safely due to |
The text was updated successfully, but these errors were encountered: