You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the dependencies in my project have identically named files at the same paths. Like LICENSEs and module-infos:
(a screenshot where I already raised the duplicatesStrategy to WARN)
When the plugin tried to create a JMH JAR without the shadow plugin, i.e. by using the createStandardJmhJar method, the task (jmhJar) just silently did nothing. It didn't fail, but it also didn't produce a JAR. It's hard to tell why, because a regular JAR task at least leaves the JAR, but in my case the resulting JAR was absent.
This is a big deal, because JMH doesn't give you a sane error report in this case. Here is what I get, for example:
java.lang.IllegalArgumentException: Benchmark does not match a class
at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:94)
at org.openjdk.jmh.runner.BenchmarkHandler.<init>(BenchmarkHandler.java:72)
at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:232)
at org.openjdk.jmh.runner.BaseRunner.doSingle(BaseRunner.java:138)
at org.openjdk.jmh.runner.BaseRunner.runBenchmarksForked(BaseRunner.java:75)
at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:72)
at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:86)
Caused by: java.lang.ClassNotFoundException: me.madhead.tempa.jmh_generated.PredicatesBenchmark_companion_jmhTest
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:73)
... 6 more
While the classes were clearly there, note the lib directory is empty! Again, I am not sure why, and this is not the behavior of the JAR task. It either fails with a stacktrace or produces a JAR. But I suspect it's due to those dups, because when I changed the strategy to DuplicatesStrategy.EXCLUDE it began to work.
This issue is really hard to understand.
If the duplicateClassesStrategy would not be set to any default or if it would be set to WARN the user would at least see some clues in the logs in this case.
The text was updated successfully, but these errors were encountered:
Some of the dependencies in my project have identically named files at the same paths. Like
LICENSE
s andmodule-info
s:(a screenshot where I already raised the
![image](https://private-user-images.githubusercontent.com/577360/284916723-28484a0f-425a-46b0-a6e1-bd165aa5c204.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk2NTkxMjMsIm5iZiI6MTczOTY1ODgyMywicGF0aCI6Ii81NzczNjAvMjg0OTE2NzIzLTI4NDg0YTBmLTQyNWEtNDZiMC1hNmUxLWJkMTY1YWE1YzIwNC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjE1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxNVQyMjMzNDNaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mYWZkOWY2NjgwNDQ1ZDgyNWVkNzIzMGYxMTMzYzA4YTc2NDY0YjkwYzI4NDlhYzg1NzUzM2MwNGZmNTMzNzc4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.ezUOxThSYvquEveL05b9_WHH6KDnATIcfM7WyBlEf74)
duplicatesStrategy
toWARN
)When the plugin tried to create a JMH JAR without the
shadow
plugin, i.e. by using thecreateStandardJmhJar
method, the task (jmhJar
) just silently did nothing. It didn't fail, but it also didn't produce a JAR. It's hard to tell why, because a regular JAR task at least leaves the JAR, but in my case the resulting JAR was absent.This is a big deal, because JMH doesn't give you a sane error report in this case. Here is what I get, for example:
While the classes were clearly there, note the
![image](https://private-user-images.githubusercontent.com/577360/284919128-f8a3200d-4891-4bf3-9490-14ee243fb8db.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk2NTkxMjMsIm5iZiI6MTczOTY1ODgyMywicGF0aCI6Ii81NzczNjAvMjg0OTE5MTI4LWY4YTMyMDBkLTQ4OTEtNGJmMy05NDkwLTE0ZWUyNDNmYjhkYi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjE1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxNVQyMjMzNDNaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zOWEwZjI4MTU2MmFkNDA4OGQxNDBmMjUwOGFlMzNhMzA5N2M4YjFiNGYyNTNjMjRkYTk4YTEwNTE1OGRjMmU0JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.RR2yInXkaASbUViEA0nGC5Ci0OKBjVdgBKFgln1iC14)
lib
directory is empty! Again, I am not sure why, and this is not the behavior of the JAR task. It either fails with a stacktrace or produces a JAR. But I suspect it's due to those dups, because when I changed the strategy toDuplicatesStrategy.EXCLUDE
it began to work.This issue is really hard to understand.
If the
duplicateClassesStrategy
would not be set to any default or if it would be set toWARN
the user would at least see some clues in the logs in this case.The text was updated successfully, but these errors were encountered: