On Mon, Jan 19, 2009 at 3:32 PM, Simon Laws <[email protected]>wrote:
> > > 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 >> 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 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 > Ok no objections after a week so I've raised JIRA TUSCANY-2789 to track getting this done. ...ant
