On Fri, Jan 16, 2009 at 5:48 PM, Raymond Feng <[email protected]> wrote:

>  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 <[email protected]>
> *Sent:* Friday, January 16, 2009 7:45 AM
> *To:* [email protected]
> *Subject:* Re: [2.x] [DISCUSS] Tuscany runtime launching
>
>
>
> 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] *
>
>
> ooo - nice, thx raymond.

Simon

Reply via email to