- Fix Polish po file
- Install as a service by default on Windows again
- Change CPUID getters to package private
- Split new jbigi install messages into two lines
- Javadocs
Add an icon (in OSX parlance, a 'bundle') to the installation folder to start
I2P.
While there might be a better way to handle this (admittedly, I don't know OSX
that well), it is my belief that this way is less 'hackish' than the various
OSX 'installers' that I've seen floating around.
With this checkin I'm trying to lessen the occurences of ticket #474:
If a user installs I2P on top of an already existing I2P installation with the service
enabled, the installer will hang. The Quit button cannot be clicked. Clicking
the X in the corner seems to roll back the installation.
Also #472: service is not removed when I2P is uninstalled
for use with a 32 bit JRE.
Rationale:
On an x64 system using a 32 bit jvm Without the 32 bit libwrapper, messages
like this will be shown in wrapper.log with the wrapper in MTN & I2P >= 0.8.7:
-----------------------
Launching a JVM...
WrapperManager: Initializing...
WrapperManager:
WrapperManager: WARNING - Unable to load the Wrapper's native library 'libwrapper.so'.
WrapperManager: The file is located on the path at the following location but
WrapperManager: could not be loaded:
WrapperManager: $I2P/lib/libwrapper.so
WrapperManager: Please verify that the file is both readable and executable by the
WrapperManager: current user and that the file has not been corrupted in any way.
WrapperManager: One common cause of this problem is running a 32-bit version
WrapperManager: of the Wrapper with a 64-bit version of Java, or vica versa.
WrapperManager: This is a 32-bit JVM.
WrapperManager: Reported cause:
WrapperManager: $I2P/lib/libwrapper.so: $I2P/lib/libwrapper.so:
wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
WrapperManager: System signals will not be handled correctly.
-----------------------
With libwrapper.so removed, one sees the following:
WrapperManager: WARNING - Unable to load the Wrapper's native library because none of the
WrapperManager: following files:
WrapperManager: libwrapper-linux-x86-32.so
WrapperManager: libwrapper.so
WrapperManager: could be located on the following java.library.path:
WrapperManager: $I2P
WrapperManager: $I2P/lib
WrapperManager: Please see the documentation for the wrapper.java.library.path
WrapperManager: configuration property.
WrapperManager: System signals will not be handled correctly.
-----------------------
The 32 bit lib names, when installed on an x64 system, will match the alternate
names that the wrapper looks for.
The Tanuki Software website states "64-bit Windows versions of the Java Service Wrapper
are not currently being made available in the Community Edition." The Makefile
for x86_64 is missing from the upstream tarball as well.
Well...included in this checkin is a diff against
$WRAPPER-3.5.9-SRC/src/c/Makefile-windows-x86-32.nmake (see the README in
installer/libs/wrapper/win64.
- removing from /build.xml
- moving recent changes from installer/resources/postinstall.bat to installer/install.xml
- dropping installer/resources/postinstall.bat
* Remove the last reference to my eepsite as a "news.xml" source,
and likewise stop my public key from being included
among valid release signing keys.
- Don't cd to script location, no longer required
* RouterLaunch:
- If no wrapper, put wrapper.log in system temp dir
unless specified with -Dwrapper.logfile=/path/to/wrapper.log
or it already exists in CWD (for backward compatibility)
- Append rather than replace wrapper.log
- Pass wrapper log location to router as a property, so that logs.jsp can find it
* logs.jsp:
- Get wrapper log location from a property too
* runplain.sh:
- Add path substitution to runplain.sh on install
- Pass I2P base dir to the router as a property
* wrapper.config:
- Put wrapper.log in system temp dir for new installs
- Pass I2P base dir to the router as a property
* WorkingDir:
- Don't migrate an existing install by default
- Never migrate the data (too hard)
