BUILDING.txt

You're best off checking out the project from Git, rather than
using the bundled sourcecode in the release .zip and .tbz2 archives.
If you do want to use the bundled source rather than checking out the
project, you'll have to do some file copying:

   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
       snakeyaml-1.9.jar
       log4j-1.2.16.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.

   Additionally, technically speaking you'd want to copy the "textures"
   directory over into the source tree as well.

At that point, you should theoretically be good to go.

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).

COMMANDLINE
-----------

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 note that right now that step will only work
on Linux.  I've never taken the time to figure out how to get launch4j to
work on other platforms.  See build.xml for other ant targets.

ECLIPSE
-------

First, a disclaimer: as I mentioned above, I haven't actually used Eclipse
with this project in some time, so it's possible that you'll need to do
more work than is mentioned here.  I believe that these docs should be
sufficient, but let me know if it's not.

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 -Dlog4j.configuration=file:support/log4j.properties
   
   ... 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 should work fine inside Eclipse, too, of course.