Updater: do not trust Windows when it says a file is executable

Windows would say your grandmother is executable, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Bundle the jar files into jars/ so the ImageJ launcher will pick them up

We will include the ImageJ launcher in a moment, and for
backwards-compatibility this developer thinks it'd be a good thing to keep
the name "jars/" of the directory containing the .jar files.

Since this breaks the precompiled Windows executable, it has been removed for
now, while the Windows batch file, the Shell script and the MacOSX
Info.plist files have been adjusted accordingly.

Unfortunately, the JavaApplicationStub is too limited to parse wildcards
in the classpath, therefore MacOSX continues broken (i.e. this patch does
not fix things).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Initial commit of the ImageJ launcher

Using the NAR plugin, we compile the ImageJ launcher now. Note that it
cannot run in-place because it is neither finding ij-launcher.jar nor the
ImageJ root directory.

Based on the ImageJ.c in fiji.git's 'master' branch as of Mon Mar 26
23:26:45 2012 -0500.

The launcher module requires a C compiler (gcc, to be precise), so it is
not included by default; Activate the 'launcher' profile to compile it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ Launcher: fix forgotten places expecting JAVA_HOME != NULL

This has been backported to fiji.git on Tue Mar 27 06:00:33 2012 -0500.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ Launcher (macosx): discover bundled Java3D again

The location used to be hardcoded, but we got rid of all command-line
defines. So let's discover the ext directory now.

This has been backported to fiji.git on Tue Mar 27 06:02:05 2012 -0500.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ Launcher (MacOSX): actually look for libjogl.lib in java/**/*

Our JAVA_HOME discovery wants a native library, so let's throw the
name of one in its vague direction.

Noticed by Curtis Rueden; symptom: the launcher returns and Fiji runs
in the background.

This has been backported to fiji.git on Fri Mar 30 14:54:07 2012 -0500.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ Launcher: fix another forgotten place expecting JAVA_HOME != NULL

This has been backported to fiji.git on Tue Mar 27 06:00:33 2012 -0500.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ launcher: avoid NullPointerException

The issue was caused by attempting to System.setProperty with a null
value. We now check for that.

Debugging was a little tricky because the error message was not printed
until DetachCurrentThread was called... so not calling
DetachCurrentThread appeared to fix the issue. But it actually only hid
the error message.

Cherry-picked from fiji.git.

Authored-by: Curtis Rueden <ctrueden@wisc.edu>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ launcher: launch ImageJ2 by default

Since the sources came straight from Fiji (which still relies on ImageJ1
to do its job), the ImageJ launcher defaulted to ImageJ1.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ Launcher: parse new-style ImageJ.cfg

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make ImageJ Launcher options dependent on the platform

For now, only i386 and amd64 Linux are supported.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Allow compilation of the ImageJ Launcher under 32-bit MinGW

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ-tiger: only try to exec(ImageJ-macosx) if it exists

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
ImageJ Launcher: support finding jars/ and plugins/ outside .app/

Our current application .zip has only stubs for MacOSX. It seems to be
the intention to leave the jars/ directory outside of the .app.

This has several advantages over the approach Fiji took (everything inside
the .app/ directory):

1) it is easy to put new stuff into the jars/ and plugins/ directories,

2) it is obvious how to have 32-bit and 64-bit MacOSX versions without
   duplicating the .jar files

3) users can inspect the components of ImageJ more conveniently.

However, there is also a drawback: it is no longer easy to quickly install
ImageJ into the Applications/ folder.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Allow the ImageJ launcher to be compiled on MacOSX

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Build the ImageJ Launcher for MacOSX Tiger (32-bit), too

The Tiger target is important, as even 64-bit Tigers can only launch
32-bit Java. But a 64-bit Launcher would not even come as far as
determining that it is running on Tiger; dyld would not even let the
program start.

To compile ImageJ-tiger on Leopard, you need to force the profile like
this:

	mvn -Dos.arch=i386 -P 'MacOSX Tiger' -P '!MacOSX Leopard'

(You need to set os.arch, otherwise NAR will mistake the artifact for a
64-bit one.)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Optionally build the ImageJ launchers in debug mode

By setting the property debug.option to -g, the launcher will be built
with debug information.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Bundle the native ImageJ Launchers into the application .zip file

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>