More comments inline. Thanks, Raymond
From: ant elder Sent: Friday, January 30, 2009 9:23 AM To: [email protected] Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml On Fri, Jan 30, 2009 at 4:56 PM, Raymond Feng <[email protected]> wrote: A few comments: 1) Our distribution already contains the manifest.jar and equinox-manifest.jar: * manifest.jar has the Main-Class set to the node launcher and Class-Path set to the required Tuscany modules and 3rd party jars * equinox-manifest.jar has the Mani-Class set to the equinox node launcher and Class-Path set to the dependent jars for the launcher itself without pulling other Tuscany modules and 3rd party jars which are bundles under OSGi. We also have the configuration generated to list the bundles. It can be pointed using -Dosgi.configuration.area (system property). I suggest that our tuscany.bat to leverage that instead of using the osgi.config and default.config which require manual maintenance and ** classpath drags unnecessary jars. 2) Let's use -<option> instead of positional arguments. For example, tuscany -osgi contrib 3) We should allow the deployment composite to be used to launch the node, for example tuscany -composite <compositeURI> contrib1 contrib2 ... contribN The compositeURI can be a relative URI in one of the contribs or an absolute URI which points to an external composite file. 4) Do we prefer to have multiple commands for different purposes or one command with different options? Some of those sounds really good, just to explain, there are two things that led to it being as it is right now. Firstly lots of ML discussion about runtimes, launching, and running samples where aspects of how this should work came up, without giving links to all the emails an OTTOMH summary is - to have a Tuscany persona, to remove the mystery about what happens, to make it simple, intuitive and consistent, and to enable simple sample builds. The second reason its like this is to get something going quickly with minimum work as it wasn't obvious if eveyone agreed we wanted something like this. One other thing was to make the .bat/.sh scripts as simple as possible as they're hard to maintain. For (1) i'm nervous it makes it complicated and makes it hard to see whats going on. The current config file is simple and fairly intuitive so there is no mystery compared to digging around in a bat script to point to jars somewhere else which you then have to unzip and look in the manifest. <rfeng>I have a different take here for the following reasons: a) MANIFEST.MF is defined by the jar spec and "Main-Class" and "Class-Path" are standard headers b) The manifest.jar and equinox-manifest.jar have the accurate set of classpath entries. And we also support the different configurations based on the distro, such as one for core, and one for web service. They are automatically generated by Tuscany and no manual steps are required. c) The OSGi launcher should not pull in other Tuscany modules and 3rd party jars which are OSGi bundles. Having them on the launcher classpath is problematic. d) Arguing about mystery, the launcher is already on the magical path anyway. I'm trying to avoid intuitive directory scanning in non-development mode. </rfeng> For (2) absolutley. Its only like it is now as that was easy to code, to use -<option> is a little more work but much nicer. Would also be good to have abrevations so there's minimum to type once you know what you're doing. Same for (3), and maybe even multiple deployment composites. For (4) i'm not sure, what do others think? I kind of like that the single command as it gives a persona, and the help option on the one command shows everything possible without needing to know about other commands. And its minimum scripts which i like as they're a not much fun to write and maintain. ...ant
