Closed rimadoma closed 6 years ago
I believe some of these were fixed by @skalarproduktraum at the scenery level. In general, the solution should be to add exclusions at the scenery and/or sciview levels, so that downstream projects like bonej can just depend on sciview without any worries.
I tried adding
<dependency>
<groupId>net.coremem</groupId>
<artifactId>CoreMem</artifactId>
<version>0.4.3</version>
<exclusions>
<exclusion>
<groupId>com.google.android.tools</groupId>
<artifactId>dx</artifactId>
</exclusion>
</exclusions>
</dependency>
like in scenery, but this didn't remove the errors about duplicate classes between com.google.android.tools:dx
and junit:junit
. I also tried adding the same exclusion to sc.iview:sciview
.
You can use mvn dependency:tree
, as well as the dependency hierarchy visualization of your IDE, to troubleshoot where these dependencies are coming from. Since com.google.android.tools:dx
is already excluded under CoreMem
at the Scenery level, chances are it's coming in also from somewhere else. I think it's likely you don't need this dx
artifact, and we should change scenery and/or sciview to stop requiring it as a dependency.
/cc @kephale @skalarproduktraum
Hey guys,
sorry for the late reply, I must have missed the notification.
The issue that @rimadoma describes is known (to me :-D) and fixed in https://github.com/scenerygraphics/scenery/commit/f701942017d72384204082721992e2ee23665745, which is in the current SNAPSHOT version (0.2.4-SNAPSHOT
). You could depend on that for the moment, or wait for 0.2.4, which will probably be out within the first two weeks of 2018.
The root cause for this whole issue is JavaCL (and associates), which is not maintained anymore, but we needed to keep it in ClearCL for compatibility reasons.
The root cause for this whole issue is JavaCL (and associates), which is not maintained anymore, but we needed to keep it in ClearCL for compatibility reasons.
Would it make sense for each ClearCL backend to be its own artifact? So then you just depend on the backend of your choice as a dependency? Then people who don't need the JavaCL backend specifically wouldn't inherit those dependencies. Or do I misunderstand how ClearCL is intended to work?
@skalarproduktraum I added
<dependency>
<groupId>graphics.scenery</groupId>
<artifactId>scenery</artifactId>
<version>0.2.4-SNAPSHOT</version>
</dependency>
and the rendering window (with Vulkan) stopped appearing altogether. With OpenGL it shows, but is completely black (like before). The build errors reported above disappeared, but I got new ones:
- For duplicate transitive dependencies, add dependency exclusions.
- For duplications between direct dependencies, resolve or add
ignored classes to this rule's configuration.
Found in:
org.lwjgl:lwjgl-openvr:jar:3.1.6-SNAPSHOT:compile
org.lwjgl:lwjgl-jemalloc:jar:natives-windows:3.1.6-SNAPSHOT:runtime
org.lwjgl:lwjgl-glfw:jar:natives-windows:3.1.6-SNAPSHOT:runtime
org.lwjgl:lwjgl-openvr:jar:natives-windows:3.1.6-SNAPSHOT:runtime
org.lwjgl:lwjgl-jemalloc:jar:3.1.6-SNAPSHOT:compile
org.lwjgl:lwjgl-opengl:jar:natives-windows:3.1.6-SNAPSHOT:runtime
org.lwjgl:lwjgl-glfw:jar:3.1.6-SNAPSHOT:compile
org.lwjgl:lwjgl-opengl:jar:3.1.6-SNAPSHOT:compile
org.lwjgl:lwjgl-vulkan:jar:3.1.6-SNAPSHOT:compile
org.lwjgl:lwjgl:jar:natives-windows:3.1.6-SNAPSHOT:runtime
Duplicate classes:
module-info.class
[WARNING] Rule 5: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: org.lwjgl:lwjgl-openvr:jar:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-jemalloc:jar:natives-windows:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-glfw:jar:natives-windows:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-openvr:jar:natives-windows:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-jemalloc:jar:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-opengl:jar:natives-windows:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-glfw:jar:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-opengl:jar:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl-vulkan:jar:3.1.6-SNAPSHOT
Found Banned Dependency: org.lwjgl:lwjgl:jar:natives-windows:3.1.6-SNAPSHOT
I'll report what happens when I've get JDK 9 installed. With the scenery snapshot, should I also use the latest sciview snapshot?
No, I've been trying to keep SciView attached to release versions of scenery only, now that more folks are starting to poke around at it. @skalarproduktraum was going to cut a release this or next week though.
I have some comments, the last set of errors posted are missing the heading, because there still are duplicate classes.
These seem to come from bridj which is pulling in com.google.android.tools:dx
The bytecode enforcement seems to come from something going on in lwjgl:
"Restricted to JDK 1.8 yet
The bytecode enforcement seems to come from something going on in lwjgl: "Restricted to JDK 1.8 yet contains module-info.class targeted to JDK 1.9"
It looks like the enforcer is not special-casing the module-info.class
—but it should. This is a new thing for Java 9, which needs to be excluded from these rules—both the duplicate classes rule and the bytecode version rule.
The module-info.class
for a project does need to be compiled with JDK9+, even if the rest of the project targets an earlier version of Java. The earlier versions of Java will ignore it, whereas Java 9's module system will consume it. See here for some details.
Hi @rimadoma, @kephale and @ctrueden ,
the OpenGL bug has been fixed in a newer SNAPSHOT, it was actually just there for a few hours -- and you managed to get it! :-D Please only use the SNAPSHOT releases for testing, otherwise use the latest preview release version, which is 0.2.3 at the moment. The JDK9-related issue comes from an enforcer rule and is easy to fix in the pom, though. Have a look at scenerygraphics/SciView#63.
The fixes for the duplicate class issues came after 0.2.3, so you'd have to stick with -Denforcer.skip=true
for the moment, or alternatively, use the newest SNAPSHOT. I'll try to hurry with 0.2.4 👍
Fixed in 2fd5f210cc901544209dd1661421a499eef78078 with the right combo of exclusions.
Analysis showed that the duplicate classes came from dependencies of sciview
mvn dependency:tree -Dincludes=com.nativelibs4java
[INFO] org.bonej:wrapperPlugins:jar:0.3.0-SNAPSHOT
[INFO] \- sc.iview:sciview:jar:0.0.1:compile
[INFO] +- net.coremem:CoreMem:jar:0.4.3:compile
[INFO] | \- com.nativelibs4java:bridj:jar:0.7.0:compile
[INFO] \- graphics.scenery:scenery:jar:0.2.2:compile
[INFO] +- net.clearvolume:clearcl:jar:0.4.5:compile
[INFO] | \- com.nativelibs4java:javacl:jar:1.0.0-RC4:compile
[INFO] | \- com.nativelibs4java:javacl-core:jar:1.0.0-RC4:compile
[INFO] | +- com.nativelibs4java:opencl4java:jar:1.0.0-RC4:compile
[INFO] | \- com.nativelibs4java:nativelibs4java-utils:jar:1.6:compile
[INFO] \- com.nativelibs4java:jnaerator-runtime:jar:0.12:compile
[INFO] \- com.nativelibs4java:ochafik-util:jar:0.12:compile
and
mvn dependency:tree -Dincludes=com.google.android.tools
[INFO] org.bonej:wrapperPlugins:jar:0.3.0-SNAPSHOT
[INFO] \- sc.iview:sciview:jar:0.0.1:compile
[INFO] \- net.coremem:CoreMem:jar:0.4.3:compile
[INFO] \- com.nativelibs4java:bridj:jar:0.7.0:compile
[INFO] \- com.google.android.tools:dx:jar:1.7:compile
@ctrueden @skalarproduktraum @kephale thanks for your help!
@rimadoma Ideally, you would just depend on scenery and you wouldn't need to exclude anything.
@skalarproduktraum @kephale Should we add these exclusions (com.nativelibs4java:javacl-core
, com.nativelibs4java:ochafik-util
, com.nativelibs4java:bridj
, com.google.android.tools:dx
) to pom-scijava dependencyManagement? Or will it be magically fixed with scenery 0.2.4?
Adding dependency to the
sc.iview:sciview
towrapperPlugins
(in branch sciview) Maven artefact causes a massive list of duplicate dependency errors while trying to build the project (see list below).I've tried to add exclusions, for example
but they haven't helped.