Hello Guest

Project packaging messiness

  • 2 Replies
  • 9828 Views
Project packaging messiness
« on: January 05, 2006, 11:09:41 »
Hey all,

I installed SWT 3.2M3, and LWJGL .99 into Eclipse 3.1.  
SWT was imported as an independent project in the workspace and placed in the Required Projects List. LWJGL was unzipped into an independent directory and linked via the run configuration through the Run menu (as per the site installation doc).

When I tried to run this, it wouldn't work since it wouldn't find a SWT dll.  SWT was working on its own previously.  I guess SWT internally sets the lib path, and now they were conflicting.  My only solution was to copy all the .dlls into the lwjgl dir, and the SWT lwjgl/swt snippet195 ran:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet195.java?rev=HEAD&content-type=text/vnd.viewcvs-markup

Copying the .dlls to me is a less than optimal and a pretty messy work around since those files dont belong in the lwjgl directory.  I'd rather have lwjgl installed as its own project, but when I tried to do that it wouldn't work.

Does anyone have a better way to manage these so they dont conflict and are organized well?

Thanks in advance, this board and this library rocks btw, I haven't been this excited about Java in a looong time (and I've been excited about Java generally lately! :) )

Project packaging messiness
« Reply #1 on: January 05, 2006, 17:56:25 »
Why don't you add the SWT and the LWJGL as library to your project?
Eclipse support user library and so on. Just define one, add it to your project and all should be fine.
And to run it, don't forget to add the LWJGL natives to the -Djava.library.path
Maybe the SWT natives have to be added there too.

Evil

Project packaging messiness
« Reply #2 on: January 09, 2006, 08:32:18 »
Did you extract the swt zip in the eclipse directory? Because that's propably not a good idea. Just put them in its own directory and and the jar to the project's classpath and add the path to -Djava.library.path in the run  configuration. Works propably best like that.