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 > > >
