BUILDING.txt

You should be able to develop (or just use) the source either from
the commandline or Eclipse.  The tool was originally developed in
Eclipse, but EGit (Eclipse's Git interface) turned out to be kind of
annoying, which was all the urging I needed to abandon the crutch of
handy autocompletion for the warm comforts of my beloved vim (which,
yes, I know, can do autocompletes if you coerce it into doing so).

Anyway, either way you want to do it, there's a couple of path/file
considerations first:

1) The build expects the LWJGL libraries and a few other Jar files in
   the "lib" directory.  Specifically it's looking for:
   
       AppleJavaExtensions.jar (presumably just for OSX)
       jinput.jar
       lwjgl_test.jar
       lwjgl_util_applet.jar
       lwjgl_util.jar
       lwjgl.jar
       lzma.jar
   
   ... Possibly some of those are optional, but you may as well leave them
   in.  Inside lib/native, make sure that you've got the "native" LWJGL
   files, as well.  These will be .dll if you're on Windows, and .so on
   Linux.

2) If you want to build a Windows EXE (which is required for ant's "dist"
   target), you'll also need the launch4j files contained in
   support/launch4j-dist.  Note that the tools distributed in this archive
   (and available through Git) will only work on Linux.

At that point, if you're on the commandline, you can use Ant to build/run,
etc.  "ant run" should be sufficient to run the app (it will compile up
a debug version automatically).  "ant dist" will package it up as if you're
doing a release, though again note that right now that step will only work
on Linux, since the Windows EXE generation oddly enough will only work on
Linux out-of-the-box.  See build.xml for other options.

If you want to use Eclipse, there's a couple of extra steps.  I feel that
both of them really *should* have workarounds which would prevent them from
being needed, but I never did figure it out.  Anyway:
   
1) In Eclipse, go to Window -> Preferences -> Java -> Build Path -> Classpath
   Variables, then click the "New" button and create a variable called
   "XRAY_CLASSPATH".  Point that directory at the "lib" dir underneath the
   X-Ray project.  This should let you compile the app.
   
   (As an aside, the ".classpath" file distributed with the original X-Ray
   distribution specified its jar files with relative paths, such as
   "lib/lwjgl.jar".  I could never get that to actually work, though, which
   is why they're all prefixed with that XRAY_CLASSPATH var now.  It'd be
   nice to know why, and equally nice to be able to get rid of having to
   set up that variable.)
   
2) To actually RUN the app through Eclipse, right-click on the top project
   in Package Explorer, go to Properties -> Run/Debug Settings -> XRay, and
   click on "Edit".  In the Arguments tab, set the VM arguments to:
   
   	 -Xms256m -Xmx1024m -Djava.library.path=/path/to/workspace/xray/lib/native
   
   ... replacing the "/path/to/workspace" with the path to your actual
   Eclipse workspace.  If anyone's got a way around having to do that, let
   me know.
   
   You MIGHT have to go into the Classpath tab there, as well, and add in
   the JARs under lib/ again (which would show up under that XRAY_CLASSPATH
   var), though I don't remember if that automatically happens or not.

The various build.xml targets will work fine inside Eclipse, too, of course.