- move deprecated installer-only classes (Exec, Delete, and Copy) from
i2p.jar into installer/
- replace installer/resources/fixpaths.cmd with an improved method in java
- combine the installer-only utility classes into a single jar and call the
classes from within izpack
To import a branch of trunk into Eclipse, create a new workspace based in the
root directory of the checked-out branch, and then select "File -> Import..."
then "General -> Existing Projects into Workspace", then for "Select root
directory" choose the root directory of the branch (and of the workspace).
Select all projects that appear, so that dependencies are satisfied.
Currently left out are i2psnark, routerconsole and susimail, because they all
depend on jars in apps/jetty/jettylib, which seems to be auto-generated. Need
to check whether the existence of that folder (from having Eclipse files in it)
will prevent the jars being populated or not.
- Windows: Self-compiled with VS2010 in Windows 7. The icon has been
changed from Tanuki's default to Itoopie.
- FreeBSD: Self-compiled in FreeBSD 7.4 to eliminate the dependency on the
compat6x port and stripped.
- Linux PPC32: Self-compiled in Debian Squeeze and stripped
- Linux x86, Linux x64, Linux ARMv5, MacOSX & Solaris: Binares are from the
"community edition" deltapack offered by Tanuki. The Linux binaries have
been stripped.
- add kFreeBSD to NBI and CPUID
- add kFreeBSD to jcpuid/jbigi build scripts
- refresh debian patches to compensate for kFreeBSD changes
- i2prouter: Detect kFreeBSD and normalize its name
- clean up osid (switching to "elif") and adding support for detecting kFreeBSD
- update postinstall.sh; I2P cannot be installed using gij so postinstall.sh
will not be run. If/when openjdk finally comes to kFreeBSD, we'll be ready for it.
In my testing:
32 bit Windows (and, of course, 32 bit JRE) = Java added to the PATH
64 bit Windows and 64 bit JRE = Java added to the PATH
64 bit Windows and 32 bit JRE = Java *not* added to the PATH.
So...with this check-in:
- If the environment variable JAVA is set in the script, we'll use that
manually specified Java. We will not look in the registry, but we'll check to
make sure that the binary exists.
- If Java is found in the system path, we'll use it instead. We will not look in the
registry.
- If the variable is not set manually and Java is not in the system path we'll
look in the registry to find the java binary.
I've tested this in Windows XP, Vista, and 7 but it should work in any supported version
of Windows.
