JOGL Maven Dependency

[Shaddow]

Hallo,
ich habe gerade mein projekt auf Maven umgestellt und die Dependency für JOGL eingebaut.

Nun bekomme ich eine Exception:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: java.nio.DirectByteBuffer cannot be cast to com.sun.opengl.impl.windows.JAWT_Win32DrawingSurfaceInfo
	at com.sun.opengl.impl.windows.WindowsOnscreenGLDrawable.lockSurface(WindowsOnscreenGLDrawable.java:189)
	at com.sun.opengl.impl.windows.WindowsOnscreenGLContext.makeCurrentImpl(WindowsOnscreenGLContext.java:57)
	at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:412)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
	at javax.media.opengl.GLCanvas.paint(GLCanvas.java:277)
	at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)
	at sun.awt.RepaintArea.paint(RepaintArea.java:224)
	at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:306)
	at java.awt.Component.dispatchEventImpl(Component.java:4706)
	at java.awt.Component.dispatchEvent(Component.java:4460)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Ich kann die leider nicht nachvollziehen. Hat damit jemand Erfahrung?

 

[Guest2]

Moin,

was genau hast Du den da für eine Dependency angegeben?

Ich versuche mich gerade auch an JOGL und Maven und da mir keine offizielle / aktuelle Maven Dependency bekannt ist (oder das Repository in dem sie liegt) fake ich das über meine Webseite (POMs von da, JARs per redirekt auf Index of /media/jogl/jsr-231-2.x-webstart-next/). Eclipse, Archiva und Continuum kommen inzwischen damit klar (auch die surefire Tests auf dem Continuum laufen durch). Aber letztendlich bleibt das (durch die nativen Abhängigkeiten) ein Krampf.

Wenn es da was Besseres gibt, währe ich für einen Tipp sehr dankbar!

Bei Deiner Fehlermeldung würde ich auf einen Versionskonflikt zwischen Gluegen / JOGL / den nativen Bibliotheken tippen.

Gruß,
Fancy

(P.S.: Das Chaos um die JOGL Maintainer mach es im Moment auch nicht besser, eigentlich mache ich mir sogar ein wenig sorgen um JOGL (JOGL is dead. Long live JOGL))

 

[Shaddow]

Nach ein bisschen gegoogle hab ich diese Dependency gefunden:

<dependency>
  <groupId>net.java.dev.jogl</groupId>
  <artifactId>jogl</artifactId>
  <version>1.1.1-rc6</version>
</dependency>

Ich hab noch gar nicht nach Aktualität geschaut, ich wollte erstmal nur die "harte" Dependency, die vorher bestandteil der nativen Lib war, als Maven Dependency einfügen. Ich hab das schonmal vor einer ganzen Weile versucht, habs dann aber wieder aufgegeben, weil ich einfach keine vernünftige Dependency gefunden hab. mich nervt das ganze auch ziemlich - JOGL erweckt derzeit den Eindruck, dass es kaum noch gewartet oder weiterentwickelt wird. Auch wenn man immer mal liest, dass Sun Jogl in die Standardbibliotheken aufnehmen will.. Ich überlege schon seit einer Weile, meine Programme auf LWJGL umzustellen... vllt ist das mal wieder einen Gedanken wert...

Edit: Ich weiss allerdings noch immer nicht welchen Versionskonflikt es da geben soll. Die obige Dependencydeklaration lädt jogl und gluegen rein und ich wüsste nicht, warum das nicht passen sollte.

 

[Guest2]

Ok, dann bezieht sich das wohl vermutlich auf den Versuch dieses JOGL Nutzers: contribution - maven deploy: some pom and a shell script


Verwunderlich ist, das der bei Dir überhaupt soweit kommt. Kann es sein das Du noch irgendwelche JOGL JARs oder DLLs im Class bzw. Library Pfad hast?

So wie Du die Abhängigkeit nämlich definiert hast, werden keine nativen Abhängigkeiten aus dem Repository geladen (sondern nur die JARs) und die Anwendung dürfte gar nicht starten. Zusammen mit den DLLs von hier: http://download.java.net/maven/2/ne...586/1.1.1-rc6/jogl-windows-i586-1.1.1-rc6.jar (müssen manuell entpackt und der java.library.path entsprechend gesetzt werden) sollte es aber gehen.

Aber dann ist praktisch auch die ""harte" Dependency" wieder da.


Alternativ kannst Du es auch so versuchen (basierend auf der von Dir verwendeten Dependency) (und auch dann muss Dein Class/Library Pfad vollkommen JOGL frei sein) :

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>test</groupId>
	<artifactId>test</artifactId>
	<version>0.0.1-SNAPSHOT</version>

	<repositories>
		<repository>
			<id>maven2-repository.dev.java.net</id>
			<name>Java.net Repository for Maven</name>
			<url>http://download.java.net/maven/2/</url>
			<layout>default</layout>
		</repository>
	</repositories>


	<dependencies>
		<dependency>
			<groupId>net.java.dev.jogl</groupId>
			<artifactId>jogl-windows-i586</artifactId>
			<version>1.1.1-rc6</version>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-dependency-plugin</artifactId>
				<executions>
					<execution>
						<id>unpack</id>
						<phase>compile</phase>
						<goals>
							<goal>unpack</goal>
						</goals>
						<configuration>
							<artifactItems>
								<artifactItem>
									<groupId>net.java.dev.jogl</groupId>
									<artifactId>jogl-windows-i586</artifactId>
									<version>1.1.1-rc6</version>
									<type>jar</type>
									<overWrite>true</overWrite>
									<includes>*.dll</includes>
									<outputDirectory>/native</outputDirectory>
								</artifactItem>
							</artifactItems>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>

</project>

Das entpackt, beim build, die notwendigen DLLs ins Projektverzeichnis unter /native, den java.library.path musst Du dann auf dieses Verzeichnis setzen, dann sollte es gehen.
(Mit <classifier></classifier> kann man das auch noch Betriebsystem unabhängig machen, aber es bleibt eben hässlich)

(Und die JOGL Version aus dem Repository ist noch von 2007)

Gruß,
Fancy

 

[Guest2]

Btw., da wir gerade dabei sind, das entpacken mit dem maven-dependency-plugin klappt ja nur wenn es im POM des aktuellen Projektes angegeben ist. Gibt es eine Möglichkeit diesen Abschnitt in das POM des Artifactes (das wäre dann z.B. bei mir jogl-native) auszulagern?
So das es immer noch bei einem build des lokalen Projektes ausgeführt wird?

(Das Problem bei meiner Lösung ist nämlich noch, das wenn ich das für alle nativen Abhängigkeiten und allen Betriebsystemen jedes Mal in die POM des Projektes schreiben muss, da immer direkt ne mindestens 500 Zeilen POM liegt)

Wenn das nämlich ginge, könnte ich auch meine JOGL/Maven/Repo url posten.
(Ich tue es jetzt noch nicht, da mir die Lösung so noch nicht gefällt und ich noch dran rumbastel)

Gruß,
Fancy

 

[maki]

Mit Profilen kann man mit Maven2 OS Abhängige Builds realisieren, d.h. dass je nach OS die entsprechende Lib herangezogen wird.

Als Beispiel kannst du dir ja mal den GWT Archetype ansehen.

 

[Shaddow]

Also ich hab die Pom mal entsprechend angeglichen:

[xml]
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>de.test</groupId>
<artifactId>test</artifactId>
<name>test</name>
<version>0.0.1-SNAPSHOT</version>


<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/2/</url>
<layout>default</layout>
</repository>
</repositories>


<dependencies>
<dependency>
<groupId>net.java.dev.jogl</groupId>
<artifactId>jogl-windows-i586</artifactId>
<version>1.1.1-rc6</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.1</version>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>compile</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>net.java.dev.jogl</groupId>
<artifactId>jogl-windows-i586</artifactId>
<version>1.1.1-rc6</version>
<type>jar</type>
<overWrite>true</overWrite>
<includes>*.dll</includes>
<outputDirectory>/native</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<downloadSources>true</downloadSources>
<downloadJavadocs>true</downloadJavadocs>
</configuration>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>de.stayinaction.embodyIt.core.test</mainClass>
<packageName>de.stayinaction.embodyIt</packageName>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.2</version>
<configuration>

</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>de.stayinaction.embodyIt.core.test</mainClass>
<packageName>de.stayinaction.embodyIt.core</packageName>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>

</project>
[/xml]

Immerhin laufen jetzt meine Tests durch, die schon einen GLContext benötigen. Der Build läuft vollständig durch, allerdings liegen keine JOGL.jars oder sowas im entstehenden package. ich sehe auch keinen nativeordner
Außerdem frag ich mich auch grad, wie ich diesen Ordner dann als Library angeb. Mach ich das in Maven als Configuration oder mach ich das ganz normal in Java unter Properties

Edit:
Wenn ich das ganze nicht mit mvn install laufen lasse, sondern das konfigurierte Assembly plugin mit "mvn assembly:assembly" nutze, dann öffnet sich beim starten der jar sogar der Frame. Allerdings bekomme ich dann die Exception von oben. Interessant ist allerdings, wenn ich diese jar jetzt öffne, liegen die Dependencies alle drin

 

[Guest2]

Moin,

sorry, voll verpeilt Dir zu antworten!

Also, das so ein Fenster aufgeht, wundert mich. Das Problem ist, das die nativen Abhängigkeiten wahrscheinlich mit im JAR liegen und der (so einfach) gar nicht darauf zugreifen kann. Meine Vermutung ist also (immer noch) das Du irgendwo im java.library.path eine andere, zu JOGL gehörende, Dll liegen hast (und die, die falsche Version hat).

Versuche doch mal ein

 System.out.println(System.getProperty("java.library.path"));

und siehe in den Verzeichnissen nach ob Du irgendwo was von JOGL finden kannst.


Wenn Du ein direkt startbares JAR (ohne externe Dateien) bauen willst, musst Du dafür sorgen das die Dlls zur Laufzeit aus dem JAR extrahiert werden (z.B. in ein temporäres Verzeichnis) und dann der java.library.path dynamisch auf dieses Verzeichnis gesetzt wird. (und zwar bevor das erste JOGL Objekt erzeugt wird)

Den java.library.path kannst Du zur Laufzeit so setzen:

 	public final static void setJavaLibraryPath(String path)
			throws NoSuchFieldException, IllegalAccessException {

		final String newPath = path + File.pathSeparator + System.getProperty("java.library.path");
		System.setProperty("java.library.path", newPath);

		final Field field = (java.lang.ClassLoader.class).getDeclaredField("sys_paths");
		if (field != null) {
			field.setAccessible(true);
			field.set((java.lang.System.class).getClassLoader(), null);
		}
		
	}

@maki: Danke Dir! War zwar noch nicht ganz das was ich suchte, aber es kürzt die POM schon mal um einiges. Mal sehen, vermutlich werde ich ein JOGL parent POM anlegen und alle Schritte die immer notwendig sind darin auslagern.

Gruß,
Fancy