Seperating this one out to its own email as its a bit long...
On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws <[email protected]>wrote:
Separate launchers vs parameterized launcher.
> I probably marginally favour a parameterized purely from the point of
> view that it gives Tuscany a persona but I haven't considered the technical
> complications this presents
> - java -jar vs java -cp
> We can allow both quite easily but which to document. I find the -far
> version a bit mysterious so favour -cp but that's just a personal
> preference.
>
>
I agree with these launcher comments, but using a launcher does have some
benefits so here's a proposal for if we do end up using one:
Separate out the "launcher" functionality to its own module which focuses
purely on setting up a classpath and calling some main class, with no code
to do anything like calling Tuscany specific Node APIs etc, and have that
launcher configured by external config files which define the classpath and
main class to call. Then provide several config files for the various
environments and runtimes we want to support. The launcher jar and
configfiles would go in separate "bin" folder in the distribution (or
maybe the
top level folder), and like the old tuscany manifest jar the launcher jar
name wouldn't include a version number to make it simple and consistent
across releases.
So a distribution would look something like:
tuscany-2.0/
bin/launcher.jar
bin/default.config
bin/osgi.config
bin/manager.config
bin/myCustomConfigThatUsesJMSandJDK6.config
lib/...
samples/...
To run something like the calculator sample with the standalone
runtimeyou'd do: "java -jar bin/launcher.jar sample.calculator.jar"
which would use
the default.config and to use one of the other config files you'd set a
property or use an additional parameter,eg: "java -jar
bin/launcher.jar osgisample.calculator.jar".
The config files could be simple Java properties files defining the jars and
folders to add to the classpath and the class with the main method to run,
and support some simple wildcards, eg:
mainClass=org.apache.tuscany.sca.node.NodeMain
classpath1=../lib/core/*
classpath2=../lib/jetty/*
classpath3=../lib/webservices/*
Could even be a bit more fancy and support some simple conditionals in the
classpath properties to enable only setting a classpath for specific
JDKlevels etc.
The advantages of this approach is that its parameterized and its no longer
mysterious what the launcher is doing. It also makes things very flexible
and easy to customize the runtime environment without changing any code, and
it goes along with the "modularity story" by not munging the launcher and
tuscany node startup code into one module.
What we're trying to do is common for many other projects, I've looked at a
whole bunch to see what they do, there are several common approaches from
using bat scripts, proprietary launchers to 3rd party launcher projects etc,
this particular approach seems best to me, its based on the approach used by
Jetty: http://docs.codehaus
.org/display/JETTY/A+look+at+the+start.jar+mechanism
...ant
