Hi, I have created a wiki page [1] to list the different cases you described. I hope it will become part of the user guide once we have it agreed and implemented.
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Runtime+Launching Thanks, Raymond From: Simon Laws Sent: Friday, January 16, 2009 7:45 AM To: dev@tuscany.apache.org Subject: Re: [2.x] [DISCUSS] Tuscany runtime launching On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng <enjoyj...@gmail.com> wrote: It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond From: Simon Laws Sent: Tuesday, January 13, 2009 7:20 AM To: dev@tuscany.apache.org Subject: Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items. Apologies for the slight pause here. I've tried to reorganize the list somewhat based on what people have said, see below. I've tried to note in [] where Tuscany has to deliver some specific support. From my point of view the main point of contention seems to be how we organize command line launching for UT2. - How to support the different options that can be specified. 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. Coming back to Ant's early question this is about finding the way that we think is nest to support these different types of users. Thoughts? Simon ======================================== User Type 1: Wants to run a contribution/composite with not further coding and have a container that already embeds the Tuscany runtime to allow them to do this. Supported mechanisms: a.. Contribution Zip/Jar/Directory a.. Use container specific mechanisms for loading contribution b.. Webapp (SCA) a.. construct a WAR and contribute to SCA enable container c.. Enterprise (SCA) a.. construct an EAR and contribute to SCA enabled container User Type 2: Wants to run a contribution/composite with not further coding. I.e. They don't want to write a mainline to start a node instead they want to treat Tuscany as a pre-compiled application. They will have downloaded a binary Tuscany distribution Supported mechanisms: a.. Tooling a.. Eclipse plugin, right click on composite file in contribution project. Relies on [Eclipse Plugin] b.. Command line (includes running from Ant) a.. see * below, this relies on a [TuscanyLauncher] c.. Webapp (Generic) a.. construct a WAR with appropriately configured web.xml using [TuscanyServletFilter] or [ TuscanyContextListener] as appropriate. * Command line. There are a number of variables we need to take account of here. OSGi/J2SE Standalone Node/Domain/Node registering with domain Normal/Debug (I just made this up) Two obvious approaches 1/ Different launcher classes to do different things. 2/ One launcher that is parameterized based on what you want it to do. User Type 3 Wants to start the runtime from code as they want to embed it for some reason. Their reason could range from just wanting to automate testing right through to wanting to extend some existing software with SCA runtime capabilities. Will have downloaded a binary distribution. The pre-condition here is they have written some kind of mainline that uses Tuscany classes. It could fire up nodes using the NodeFactory or other parts Tuscany such as the model processing. Supported mechanisms: a.. Tooling a.. dependency on Tuscany library from [Eclipse Plugin] b.. dependency on Tuscany modules from distribution. Set up manually c.. dependency on Tuscany modules from local maven repo (mvn -Peclipse) b.. Command line(includes running from Ant) a.. java MyClass.jar a.. Specify the required jars on the classpath either manually or with [tuscany-sca-manifest.jar] c.. Mvn a.. include a dependency on appropriate [Tuscany feature distributions/modules] d.. OSGi a.. Construct a bundle which uses some Tuscany classes. Add all the appropriate tuscany jars and dependencies to your OSGi environment. Start the application bundle. User Type 4 Wants to contribute to the Tuscany project or build extensions to Tuscany. Will have a source distribution. They may use various means to test infrastructure changes including the mechanisms used by User Types 1, 2 & 3. Supported mechanisms: a.. Tooling a.. With mainline that uses either the launcher or other Tuscany classes include a dependency on the Tuscany loaded classes in the Eclipse workspace so any changes are picked up as they happen without a mvn compile. This can be achieved by including appropriate Tuscany modules from workspace (mvn -Peclipse). As we build Tuscany module as bundles using the PDE we rely on the [PDE target distribution] to configure the Eclipse evironment. b.. Mvn a.. With mainline that uses either the launcher or other Tuscany classes include a dependency on [Tuscany feature distributio/modules]
