and then secondly fire up the router in a second java process when
extraction is completed. Gonna use "optional" type in C++ to make
global variables a bit less painful to use.
TLDR;
Howto? ant osxLauncher
Privacy Notes? If you don't got SBT, a bash script will trigger
download of SBT for you with task osxLauncher.
Results? open ./launchers/output
"Binary" App Bundle name: I2P.app
Runtime base directory? ~/Library/I2P
Runtime config directory? untouched.
After talk on IRC with zzz, I rewrote the logic since we could
start with a simple deploy, for a faster alpha version ready :)
SBT will build a zip file from the content of pkg-temp, which
CompleteDeployment.scala will again unzip in runtime. Right now
it's quite basic, but the plan is to add version detection, so
it's capable of upgrading a already deployed I2P base directory.
OSXDeployment.scala is renamed to PartialDeployment.scala for usage
in the browser bundle launcher, since it's going to be a subset of
the files found in pkg-temp.
A Info.plist is added to the launchers/macosx which is added to the
application bundle under building. Note that this differ from the one
in Start i2p router.app that's been here for years now.
process for I2P rather than trying to load Router via reflection or
anything runtime fancy stuff. Shell script is implemented in SBT now,
and can now link to download JRE script and so on.
installer resources with the fat jar (we add an exclusion list later)
which the base directory will be built(or updated if lacking files) upon
startup of the I2P router. This is done by the OSXDeployment class which
is an extension for the DeployProfile class written for Mac OS X.
Since the app bundle itself should be R/O, we use ~/Library/I2P as base path,
and continue using ~/Library/Application Support/i2p as config path. The BB
code will have other paths.
sbt-native-packager for future rpm/deb/windows and
maybe even OSX packages. Also, the macosx sbt project
now has a task named buildAppBundleTask and which will
produce an I2P.app and copy over needed directories/jars/wars
which later needs to be extracted to an writeable area which
would be i2p base directory in runtime.
The MacOSXRouterLauncherApp contains more information about how
the executable in the OS X bundle will locate our R/O i2pbase so
it can copy it to a writable area. The R/O is also to ensure valid
signature on the bundle.
At last, this approach is done casue letting an Mach-O binary load
libjvm.dylib was proved unstable, so MacOSXRouterLauncherApp will
rather use an JNI module to load the needed glue with the
Mac OS X system.
Browser Bundle i2p launcher, as well as the upcoming Mac OS X
i2p launcher. They share some few properties and how code has
to be managed for both system's update managers and so on.
More details will be documentated in README.md files as well as
in those commit messages I now write :)
