http://lwjgl.org/update/
The above URL contains an eclipse update site for LWJGL. The scripts and tools (http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/eclipse-update/) to create this was donated by Jens von Pilgrim, developer of GEF3D (http://www.fernuni-hagen.de/se/personen/pilgrim/gef3d/index.html).
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.
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 (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
Very nice. Iam looking forward for the Standalone Application Plugin :)
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
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.
Quote from: Evil-Devil on December 16, 2008, 18:22:19
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.
@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
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.
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
Quote from: jpilgrim on February 10, 2009, 10:59:38
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.
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.
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.
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):
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-64There 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?
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)
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)
I also created a plug-in that adds a LWJGL Classpath container for Java projects. This makes it much easier to set up LWJGL projects, just select Add Library -> LWJGL Library -> check optional libs if you want to (lwjgl_util, lwjgl_util_applet, jinput, AppleJavaExtensions?) and the library is added to the Java Build Path, with attached sources (if available) and native file location.
However, I'm unable to build this with ant4eclipse (somewhy it doesn't resolve org.eclipse.jdt.ui) so I'm not sure how this could be added to LWJGL build. Maybe as a binary in SVN?
Was able to build it with Eclipse 3.4.2. The problem was with 3.5.0 and 3.5.1. I think 3.4.2 is a sensible requirement anyway so it makes sense to build with that actually.
There are still a few more details to work on, I'll attach a complete patch when I'm done.
I am leaning towards giving you svn commit access - if you want to maintain the eclipse-update section?
Quote from: Matzon on September 28, 2009, 18:58:47
I am leaning towards giving you svn commit access - if you want to maintain the eclipse-update section?
Thanks, I'd be glad to do that. My SourceForge.net username is villane, same as here
btw, I recommend visiting #lwjgl on freenode - a lot of discussion occurs there (sometimes on topic!) ;D
access granted
Quote from: Matzon on September 29, 2009, 18:03:00
access granted
Sorry for disappearing for a while. I was rather busy with day job and stuff, but I'll get back to this in a couple of days.
np
Quote from: Villane on November 25, 2009, 19:34:28
Quote from: Matzon on September 29, 2009, 18:03:00
access granted
Sorry for disappearing for a while. I was rather busy with day job and stuff, but I'll get back to this in a couple of days.
Has there been any progress on this? If you're too busy to finish it, I'd be willing to take a look. The packaging issues for LWJGL in Eclipse are causing me headaches, and I'd be happy to make those headaches go away.
This is no longer being maintained ...
Quote from: Matzon on July 16, 2010, 11:21:36
This is no longer being maintained ...
Um...is there any reason that the website had to actually be removed though?! Our projects have automated build dependencies on these which are now all broken. :o Is it possible to put this back up please, or at least provide a zip file somewhere?
http://lwjgl.org/forum/index.php/topic,3441.0.html
Unfortunately, I do not have that package lying around - so there is little I can do about it.
The actual script that does the work is still in svn (http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/eclipse-update/org.lwjgl.eclipseplugins/), maybe someone can update to make it work with 2.5?
Quote from: Matzon on September 09, 2010, 20:29:41
http://lwjgl.org/forum/index.php/topic,3441.0.html
Unfortunately, I do not have that package lying around - so there is little I can do about it.
The actual script that does the work is still in svn (http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/eclipse-update/org.lwjgl.eclipseplugins/), maybe someone can update to make it work with 2.5?
Thanks for the SVN link. Right now, I don't really care about 2.5, I'd just like the existing dependency on 2.2.1 to work. It's looking like I'll just need to do the build on my own and put it up somewhere besides the LWJGL site where I know it isn't going to disappear suddenly.
re: making it work with 2.5, the build instructions seem quite straightforward so it is really a matter of integrating that with whatever build system you're using.
http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/eclipse-update/org.lwjgl.eclipseplugins/readme.txt?revision=3163&view=markup
I suppose there are a number of things that might be useful here, including library support and making the binaries into real Eclipse plugins, i.e. with jars unpacked at top-level. I'll mention it to Jens and see if he thinks it is worth maintaining but it may be that we want to stick with the current binaries.
Oh, I'm sorry, I see that you just had a hard drive crash and lost a bunch of files. I thought that this had just been deleted willy nilly. If you'd like help getting the LWJGL update site back up and on LWJGL let me know. Are you using Hudson or anything like that for automated builds?
We are using hudson for nightly builds: https://www.newdawnsoftware.com/hudson/view/LWJGL/
It would be nice if the existing plugin-generator could be updated to support 2.5
Technically, I think I should be able to create the 2.2.1 release, based on the SVN tag. I will try this tonight.
added 2.2.1 to http://lwjgl.org/update
works?
Hi Matzon, I was able to install it.
I could not launch the Test View however -
Eclipse Exception message:
Could not create the view: Plug-in "org.lwjgl.test" was unable to instantiate class "org.lwjgl.testview.LWJGLTestView".
Note that it's my first time trying to use org.lwjgl, but the test application in the 2.5 download package did work for me.
It does indeed work. :D Thanks very much for getting to this so quickly. In the meantime, I went ahead and got Jen's build working for 2.5. I've put it up on:
http://metaabm.org/updates
**Please note that this is temporary -- folks should not expect this dependency to stick around**
Obviously you can feel free to just copy it over to lwjgl.org/updates but I'm not sure if that's the best thing to do or not. The not ideal part is that I have not really fixed Jen's build so that it is automated, and I have *not* tested it on anything but OS X 64bit. Here are the steps I took:
1. Imported org.lwjgl.eclipseplugins into my workspace.
2. Followed all of the directions in readme.txt. That failed with some sort of obscure eclipse dependency ant error. :) But what it did do was copy all of the artifacts needed into the plugin skeletons. This is actually the hard part.
3. Imported the projects in org.lwjgl.eclipseplugins/build/plugins into the same workspace. This could theoretically create issues with file synchronization but in practice I think it is alright. If you're super anal you could do that in a fresh workspace.
4. Made some fixes to the imported org.lwjgl. These are pretty obvious, but the most significant is to change new path to <classpathentry exported="true" kind="lib" path="native/windows/"/> from win32 and remove exported packages from MANIFEST.MF that don't exist anymore. If you want to repeat this and have problems feel free to contact me. milesparker @ the usual domain.
4. Copy org.lwjgl.updatesite/site.xml to org.lwjgl.feature/category.xml or wherever it makes sense.
5. Use the oh so passé and not at all automated PDE "Deployable Feature" export to create the site. The only change is to add the category.xml site under options.
Obviously, it would be nice to automate this and not so hard I think but there isn't much point to automating the part above without taking care of the stuff that the ant script is doing now. A job for Buckminster? :o..
Same with MilesParker's 2.5. I think I can safely blame my setup :)
Error loading LWJGL
java.lang.NullPointerException
at org.eclipse.core.internal.runtime.Activator.getURLConverter(Activator.java:313)
at org.eclipse.core.runtime.FileLocator.resolve(FileLocator.java:227)
at org.lwjgl.Activator.start(Activator.java:58)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
...
I wasn't actually testing using the test view but I just did and it works for both versions on my machine. So I can test for my own apps, what is your setup?
BTW if you're curious about what AMP project is doing with this, check out:
http://www.youtube.com/user/milestparker#p/u/0/IjEkdaLm2os
and..
http://www.youtube.com/user/milestparker#p/u/3/B9HzdKMItEA
(go to 7:40 to see the 3D stuff.)
You've probably already all seen the GEF3D project that AMP 3D relies on, but if not..
http://wiki.eclipse.org/GEF3D_SampleApps