On Mon, Jan 19, 2009 at 9:59 AM, Simon Laws <[email protected]>wrote:
> > > On Sat, Jan 17, 2009 at 9:18 AM, ant elder <[email protected]> wrote: > >> >> >> On Fri, Jan 16, 2009 at 3:49 PM, Simon Laws <[email protected]>wrote: >> >>> >>> >>> On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws >>> <[email protected]>wrote: >>> >>>> >>>> >>>> On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng <[email protected]>wrote: >>>> >>>>> It's a different way to classify how an SCA composite application can >>>>> be launched using Tuscany runtime. >>>>> >>>>> Thanks, >>>>> Raymond >>>>> >>>>> *From:* Simon Laws <[email protected]> >>>>> *Sent:* Tuesday, January 13, 2009 7:20 AM >>>>> *To:* [email protected] >>>>> *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: >>>> >>>> - >>>> >>>> Contribution Zip/Jar/Directory >>>> - >>>> >>>> Use container specific mechanisms for loading contribution >>>> - >>>> >>>> Webapp (SCA) >>>> - >>>> >>>> construct a WAR and contribute to SCA enable container >>>> - >>>> >>>> Enterprise (SCA) >>>> - >>>> >>>> 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: >>>> >>>> - >>>> >>>> Tooling >>>> - >>>> >>>> Eclipse plugin, right click on composite file in contribution >>>> project. Relies on [*Eclipse Plugin*] >>>> - >>>> >>>> Command line (includes running from Ant) >>>> - >>>> >>>> see * below, this relies on a *[TuscanyLauncher]* >>>> - >>>> >>>> Webapp (Generic) >>>> - >>>> >>>> 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: >>>> >>>> - >>>> >>>> Tooling >>>> - >>>> >>>> dependency on Tuscany library from *[Eclipse Plugin]* >>>> - >>>> >>>> dependency on Tuscany modules from distribution. Set up >>>> manually >>>> - >>>> >>>> dependency on Tuscany modules from local maven repo (mvn >>>> -Peclipse) >>>> - >>>> >>>> Command line(includes running from Ant) >>>> - >>>> >>>> java MyClass.jar >>>> - >>>> >>>> Specify the required jars on the classpath either manually >>>> or with *[tuscany-sca-manifest.jar]* >>>> - >>>> >>>> Mvn >>>> - >>>> >>>> include a dependency on appropriate *[Tuscany feature >>>> distributions/modules] * >>>> - >>>> >>>> OSGi >>>> - >>>> >>>> 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: >>>> >>>> >>>> >>>> - >>>> >>>> Tooling >>>> - >>>> >>>> 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. >>>> - >>>> >>>> Mvn >>>> - >>>> >>>> With mainline that uses either the launcher or other Tuscany >>>> classes include a dependency on *[Tuscany feature >>>> distributio/modules] * >>>> >>>> >>>> >>> oops, pressed send too early. In my first comment about deciding what the >>> command line approach should be I should have also added that someone >>> mentioned having a script like Tomcat does. So I guess the question should >>> be something like. >>> >>> java -jar vs java -cp vs tuscany >>> >>> Simon >>> >> >> One thing from earlier in the conversation was that it was established >> there could be multiple deployable composites within a contribution and that >> there may be multiple contributions, the runtime launching needs to be able >> to handle that. This impacts things like the command line startup, the Node >> APIs, and also things like the eclipse plugin which along with right >> clicking on a single .composite should be able to handle right clicking on a >> contribution project or multiple selected contribution projects and starting >> a runtime using all the deployable composites. >> > > Yes, we haven't moved that forward any. It's part of the domain scenario > discussion. > > >> >> >> A couple of places this mentions that Ant scripts would use the >> TuscanyLauncher, why would you do that? The Ant build can setup a classpath >> and call any main class itself can't it? > > > And setting up a classpath and calling a main is included under type2. But > it can also call a launcher. > >> >> >> This thread has been about all the different mechanisms we have used to >> date to start a runtime and there's quite a lot of ways. It would make >> things simpler of we could reduce all the different options so do we really >> need to support all these again in 2.x? For example some things are: Do we >> really need "java -cp", a launcher, Ant, and mvn options for running >> standalone? Do we even really need both the standalone runtime and the OSGi >> runtime? The vast majority of our users use the webapp runtime not the >> standalone runtime, not sure if anyone would really use the standalone stuff >> in production, and now we're putting a lot of focus on the OSGi runtime so >> we could use that instead of the old standalone runtime for most things >> making the OSGi runtime our primary environment outside of a webapp/jee. > > > Now we have a list of scenarios that I'm not hearing people say is widely > inaccurate we can boil it down to what we actually want to support. I'll > comment more explicitly in a bit. > > >> >> >> ...ant >> >> >> > I think it boils down to three main options; 1 - a launcher to support running tuscany in the "command line" style environments we have supported real command line (starting nodes and domain) test code (run from ant, maven or eclipse) 2 - web app support, TuscanyServletFilter/ContextListener 3 - Eclipse plugin for "right click" support The user is also able to use the SPI directly but then they have to manually specify the classpath, although we may give them some help with some aggregate (manifest?) jars. Simon
