LWJGL Eclipse Update Site

[Matzon]

http://lwjgl.org/update/

The above URL contains an eclipse update site for LWJGL. The scripts and tools to create this was donated by Jens von Pilgrim, developer of GEF3D.

Currently it only contains a test view and is more or less only usable by plugin developers. He has created a LWJGL library that will get added to the update site shortly.

[jpilgrim]

Brian, thank you so much for making the plugin available via lwjgl.org. I posted a blog entry (http://jevopisdeveloperblog.blogspot.com/2008/12/lwjgl-plugin-at-lwjglorg.html) about the plugin and received a very enthusiastic comment. I want to forward the commendation to you, since you made it eventually available!

Jens

[Evil-Devil]

Very nice. Iam looking forward for the Standalone Application Plugin

[Villane]

I'm curious, why is there an Activator in the bundle? It seems to be doing something with native paths, looking at the bytecode with javap?

There is an OSGi standard for specifying native code location, albeit it is not well known: you just have to add a Bundle-NativeCode entry in the manifest.
http://litrik.blogspot.com/2007/08/secrets-of-bundle-nativecode.html

[Villane]

Also, if the Activator is used for this purpose only, could it be removed?

And if the Activator is removed, can the dependency on org.eclipse.core.runtime be removed? Otherwise, the plug-in cannot be used in standalone OSGi applications.

[Villane]

Very nice. Iam looking forward for the Standalone Application Plugin

I just created a plug-in for Slick standalone applications. It depends on the org.lwjgl plugin from your update site. Thought you might be interested to know. It doesn't work perfectly, yet, and only on Windows currently. UPDATE: this is already fixed (and the site updated).
Here's a forum post about it: http://slick.javaunlimited.net/viewtopic.php?p=9054
And the update site (probably temporary) is: http://villane.org/slick/update/

jpilgrim, are you developing the LWJGL plug-in for standalone apps? Is the current source available online? I would be interested in looking at it since I haven't figured out how to do everything correctly yet. If you ran into any troubles, I'll be happy to share my code as well.

[jpilgrim]

@Villane: The Activator class is used to set "org.lwjgl.librarypath" property, which is then used by LWJGL to locate the native libraries. But it doesn't look at the bytecode. Maybe it is possible using OSGi mechanisms, I'm not sure about that, it surely would be a better solution. I have also written the plugin for standalone applications, although I'm not using it myself (it was a service for the LWJGL community). I'm using the LWJGL plugin only for the GEF3D project (see http://www.eclipse.org/gef3d).
I have sent all code to Brian Matzon, I'm not sure if he has already submitted the code to LWJGL's code repository. The plug providing the LWJGL library (which is useful for launching standalone applications with LWJGL from Eclipse) is quite small, I've attached the Eclipse project to this posting.

Cheers

Jens

[Villane]

Thanks. It looks like we both used the JUnit plug-in for inspiration My plug-in is actually very similar to yours

If you are willing to go the OSGi Manifest route with the native library path, it would be something like this in the Manifest.MF:

Bundle-NativeCode: /native/win32/jinput-dx8.dll; /native/win32/jinput-raw.dll; /native/win32/lwjgl.dll; /native/win32/OpenAL32.dll; osname=win32, /native/macosx/libjinput-osx.jnilib; /native/macosx/liblwjgl.jnilib; /native/macosx/openal.jnilib; osname=macosx, /native/linux/ ... (32-bit libs) ... ; osname=linux ;processor=x86 , /native/linux/ ... (64-bit libs) ... ; osname=linux ;processor=x86-64 , ... (solaris)

(Note: not tested ) But it certainly works, actually I have done it with LWJGL two years ago (but it was just a private test then).

I really recommend doing it over modifying a system property at runtime (what if another bundle decides to modify the same property?). And removing unnecessary dependencies (e.g. org.eclipse.core.runtime) is really important for some users. There are definitely use cases for this plug-in outside of Eclipse (for example, an OSGi based game engine)

Also, on the same note (but this is way less important):
In Eclipse 3.4 (or maybe in 3.3 already) there is a new way for specifying source code location. Instead of adding a plugin.xml and declaring an extension, you could do it like this in the Manifest of the source bundle:

Eclipse-SourceBundle: org.lwjgl;version="2.0.1";roots:="lwjglsrc,lwjgl_utilsrc,lwjgl_util_appletsrc"

(and the sources should then be unzipped in the folders /lwjglsrc etc.)
i.e. if in the binary bundle, there is /x.jar, then the source bundle should have /xsrc
http://wiki.eclipse.org/PDEBuild/Individual_Source_Bundles

But this doesn't really matter as much as I don't see anyone wanting to use sources outside of the IDE.

[jpilgrim]

Yes, I had a look at the JUnit plug-in... "monkey sees, monkey does", as described in the book by Gamma and Beck ;-)

Villane, you will find the sources of the current LWJGL plugins in the LWJGL CVS. So maybe you could try to change it yourself and talk to Brian about how to handle your improvements and how to update. Currently, the plugin is build using an ant build, and it is not integrated into the LWJGL build system. Maybe you can improve that, too ;-) Unfortunately I don't have the time to change or update it myself.

Cheers

Jens

[Villane]

Villane, you will find the sources of the current LWJGL plugins in the LWJGL CVS. So maybe you could try to change it yourself and talk to Brian about how to handle your improvements and how to update. Currently, the plugin is build using an ant build, and it is not integrated into the LWJGL build system. Maybe you can improve that, too ;-) Unfortunately I don't have the time to change or update it myself.

Ok, I'll look at it this week or so.

[Odeamus]

The current eclipse plugin has a small problem. When using it in a RCP application the jinput library fails to load its native lib, as it's not defined in the java.library.path property. This is not a problem if you just want the rendering part of LWJGL, but for headless RCP applications and Slick the jinput is required.

This all might be easily solved with the above Bundle-NativeCode manifest header.

O.

[Villane]

I managed to forget about this somehow. I'll try to find time to help with the Bundle-NativeCode etc. before the next LWJGL release.

Odeamus, yes, Bundle-NativeCode header should fix this AFAIK.

[Villane]

I got the build working for my platform and started by patching the 'org.lwjgl' plug-in. This is the Manifest for the binary org.lwjgl bundle as it is generated now (from the archives of build #241):

Code:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: LWJGL Lightweight Java Game Library
Bundle-SymbolicName: org.lwjgl
Bundle-Version: 2.2.0
Bundle-Vendor: LWJGL.org
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Import-Package: javax.swing
Export-Package: LZMA,com.apple.eawt,com.apple.eio,net.java.games.input
 ,net.java.games.util,net.java.games.util.plugins,org.lwjgl,org.lwjgl.
 input,org.lwjgl.openal,org.lwjgl.opengl,org.lwjgl.util,org.lwjgl.util
 .applet,org.lwjgl.util.glu,org.lwjgl.util.glu.tessellation,org.lwjgl.
 util.input,org.lwjgl.util.jinput,org.lwjgl.util.vector
Bundle-ClassPath: AppleJavaExtensions.jar,jinput.jar,lwjgl-debug.jar,l
 wjgl.jar,lwjgl_test.jar,lwjgl_util.jar,lwjgl_util_applet.jar,lzma.jar
Bundle-NativeCode: /native/windows/jinput-dx8.dll; /native/windows/jin
 put-raw.dll; /native/windows/lwjgl.dll; /native/windows/OpenAL32.dll;
  osname=win32; processor=x86,/native/windows/jinput-dx8_64.dll; /nati
 ve/windows/jinput-raw_64.dll; /native/windows/lwjgl64.dll; /native/wi
 ndows/OpenAL64.dll; osname=win32; processor=x86-64,/native/macosx/lib
 jinput-osx.jnilib; /native/macosx/liblwjgl.jnilib; /native/macosx/ope
 nal.dylib; osname=macosx,/native/solaris/liblwjgl.so; /native/solaris
 /libopenal.so; osname=solaris; processor=x86,/native/solaris/liblwjgl
 64.so; /native/solaris/libopenal.so; osname=solaris; processor=x86-64
 ,/native/linux/libjinput-linux.so; /native/linux/liblwjgl.so; /native
 /linux/libopenal.so; osname=linux; processor=x86,/native/linux/libjin
 put-linux64.so; /native/linux/liblwjgl64.so; /native/linux/libopenal.
 so; osname=linux; processor=x86-64

There is no more code in that plug-in and I would also like to remove unnecessary stuff from the other plug-ins later. Could you take a look at this, Matzon? I am not sure about a few things. Added stuff:

• Bundle-RequiredExecutionEnvironment: J2SE-1.4 -- is this correct? it means Java 1.4+
• Import-Package: javax.swing -- is this optional?

There are some new jars (AppleJavaExtensions.jar, lzma.jar, lwjgl-debug.jar) -- should these be included with the plug-in distribution now?

Native libraries: Someone might want to double check if I got this right. Here's how I specified it in case the manifest syntax is not clear:

Windows (32-bit): jinput-dx8.dll; jinput-raw.dll; lwjgl.dll; OpenAL32.dll
Windows (64-bit): jinput-dx8_64.dll; jinput-raw_64.dll; lwjgl_64.dll; OpenAL64.dll
Mac OS X: libjinput-osx.jnilib; liblwjgl.jnilib; openal.dylib
Solaris (32-bit): liblwjgl.so; libopenal.so
Solaris (64-bit): liblwjgl64.so; libopenal.so
Linux (32-bit): libjinput-linux.so; liblwjgl.so; libopenal.so
Linux (64-bit): libjinput-linux64.so; liblwjgl64.so; libopenal.so

Where should I send the patch when it's done?

[Villane]

I updated the source bundle as well. Now uses Eclipse-SourceBundle headers instead of plugin.xml and extension points. This is the way most Eclipse source bundles are done now so it should be the latest "best practice". Also, it's no longer zips inside the jar, but folders. And I excluded "tests" and "examples" packages from the sources for lwjgl.jar.

Not sure if the docs or test bundles need changing.

I'm attaching the patch, I hope this patch format is ok

[edit]uploaded a new version of the patch. I think I now understand that the AppleJavaExtensions.jar is the only new one that needs to be included. Am I right? Also fixed the bundle classpath and export-package calculation to take into account the right jars (I did not let it export the com.apple packages because this might cause conflicts in the future)

[Villane]

I started taking a closer look at the other plug-ins and features. I don't think the 'test' plug-in should be included with the main feature. It should be possible to install LWJGL without ending up with a "LWJGL test view" installed, which serves no function other than showing that LWJGL works.

Would it be ok to split that into a separate feature (installable unit)? It might even make sense to have a binary-only feature without sources and docs. In that case, there would be three features:
* LWJGL Library (binaries only)
* LWJGL SDK (includes the Library feature, plus docs and source)
* LWJGL Example (example view, maybe the actual example should not be even installed into the workspace, but could be a project template selectable from "New -> Example...")

Personally, I would split it into two:
* LWJGL SDK (library, docs, sources)
* LWJGL Example (example view)