On Sat, Jan 17, 2009 at 10:01 AM, ant elder <[email protected]> wrote:
> 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 classpathand > main class to call. Then provide several > config files for the various environments and runtimes we want to support. > The launcher jar and config files would go in separate "bin" folder in the > distribution (or maybe the top level folder), and like the old > tuscanymanifest 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 > osgi sample.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 > > Eclipse also does something similar behind eclipse.exe. Sounds like it's worth investigating to me. It satisfies my desire to have a place where you can just go and run contribution while easily making some decisions about the environment you're going to run in and what options to set. Need to keep it simple though as there's a danger of getting carried away with this kind of thing. Simon
