|
From: Brian E. F. <br...@re...> - 2008-03-25 00:19:09
|
I'm trying to setup a bundle that looks like this:
/base
/container
/bin
/jsw
/[OS... windows/linux-x86-32 etc]
+--Scripts/wrapper.exe etc
/lib
+--Wrapper native libs
/conf
+---Wrapper.conf
/application
/foo
/foo2
The container folder and application folders will be bundled into
separate zips such that the application can be swapped out without
having to download and setup the container bundle. The problem is that
by default wrapper sets the current folder to the location of the jsw
executable. This means that to use relative paths in the application
bundle, I need to understand the layout of the container bundle. Worse,
it means if the users modify the container bundle, they need to change a
bunch of properties they shouldn't have to touch.
What I'd like to do is set the working dir to /base and then everything
knows where it is located from there and doesn't care about the layout
of the other bundle. I tried using wrapper.working.dir and this does
exactly what I need with one problem, it now doesn't know how to find
the wrapper library because the location of it actually depends on which
OS the user happens to be using.
I thought about assuming a given location for the binaries and or the
native wrapper library, but that means the user would have to select the
proper OS stuff and move it.
It would be awesome if the wrapper defined some property that could also
be used to mean "the location of the binary" in addition to the
wrapper.working.dir so that you could actually have two generic points
of reference.
Is there any way to accomplish what I'm trying to do currently? Is there
a better alternative that I'm missing?
Thanks,
Brian
|