R1.1 - Sample/demo ant builds

[Simon Laws <si...@googlemail.com>]

For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a change,
based on the ant generator plugin, to bring some automation to the process
of building the ant files for the samples and demos. For any sample or demo
that requires explicit dependencies, e.g. the webapp samples, I've replaced
the static ant file with and automatically generated one. In the case that
some hand crafted ant script is needed, for example, to generate SDOs, then
I have the ant generator just build build-dependency.xml which has the
dependencies listed and which can then be included in the manually generated
build.xml script.

I haven't applied this change to all of the samples but it could be done. If
we did have all of the dependencies explicitly described for all of the
samples can we get rid of the "all" and "manifest" jars?

Simon

Re: R1.1 - Sample/demo ant builds

[ant elder <an...@gmail.com>]

On Jan 2, 2008 10:53 AM, Mike Edwards <mi...@gmail.com>
wrote:

<snip>

We should be building:
>
> a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc)
>
> b) applications, containing only the code and other artifacts required
> for the application itself
>
> and then have some regular means of deploying the applications to
> appropriate runtimes - some applications could be deployed to "almost
> any" SCA runtime while others need specific runtime capabilities such as
> a Web server and Servlet support.
>

Which incidentally is what I've been starting trying to do in
modules/runtime, modules/runtime-*, and distribution/tomcat and
distribution/webapp etc, its a ways from being ready though.

   ...ant

Re: R1.1 - Sample/demo ant builds

[Simon Nash <na...@hursley.ibm.com>]

Comments inline.

   Simon

Simon Laws wrote:

> On Jan 2, 2008 1:23 PM, ant elder <an...@gmail.com> wrote:
> 
> 
>>On Jan 2, 2008 12:00 PM, Simon Laws <si...@googlemail.com> wrote:
>>
>>
>>>On Jan 2, 2008 10:53 AM, Mike Edwards <mi...@gmail.com>
>>>wrote:
>>>
>>>
>>>>Folks,
>>>>
>>>>Some comments....
>>>>
>>>>Yours,  Mike.
>>>>
>>>>ant elder wrote:
>>>>
>>>>>On Jan 2, 2008 8:58 AM, Simon Laws <si...@googlemail.com>
>>
>>wrote:
>>
>>>>>>For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
>>>>>>change,
>>>>>>based on the ant generator plugin, to bring some automation to the
>>>>
>>>>process
>>>>
>>>>>>of building the ant files for the samples and demos. For any sample
>>>
>>>or
>>>
>>>>>>demo
>>>>>>that requires explicit dependencies, e.g. the webapp samples, I've
>>>>>>replaced
>>>>>>the static ant file with and automatically generated one. In the
>>
>>case
>>
>>>>that
>>>>
>>>>>>some hand crafted ant script is needed, for example, to generate
>>>
>>>SDOs,
>>>
>>>>>>then
>>>>>>I have the ant generator just build build-dependency.xml which has
>>>
>>>the
>>>
>>>>>>dependencies listed and which can then be included in the manually
>>>>>>generated
>>>>>>build.xml script.
>>>>>>
>>>>>>I haven't applied this change to all of the samples but it could be
>>>>
>>>>done.
>>>>
>>>>>>If
>>>>>>we did have all of the dependencies explicitly described for all of
>>>
>>>the
>>>
>>>>>>samples can we get rid of the "all" and "manifest" jars?
>>>>>>
>>>>>>Simon
>>>>>
>>>>>
>>>>>
>>>>>I think its better if applications don't have to know or care about
>>>>
>>>>Tuscany
>>>>
>>>>>internals, that includes knowing all the different Tuscany module
>>>
>>>names
>>>
>>>>and
>>>>
>>>>>all the dependencies they use.
>>>>
>>>>+1 - applications should ideally have ZERO dependence on Tuscany
>>>>internals.  They should be deployed to an "SCA capable runtime"
>>
>>without
>>
>>>>having to know anything about that runtime.
>>>>
>>>>
>>>>>We haven't got this right yet so each time we
>>>>>release our sample Ant builds break as the build.xml files get out
>>
>>of
>>
>>>>date -
>>>>
>>>>>this will be happening for any Ant builds our users have as well.
>>
>>The
>>
>>>>"all"
>>>>
>>>>>jar is an attempt to fix this, its a better way IMHO than having
>>>>>applications specify every Tuscany module but theres a bit of work
>>>
>>>still
>>>
>>>>to
>>>>
>>>>>do to make it work better for webapps. We've also talked before
>>
>>about
>>
>>>>>changing all the samples to be simple sca contributions that don't
>>>
>>>need
>>>
>>>>any
>>>>
>>>>>mention of the Tuscany internals, this is something I think we
>>
>>really
>>
>>>>need
>>>>
>>>>>to do. Both of those things seem better to me than messing about
>>>
>>>trying
>>>
>>>>to
>>>>
>>>>>generate build scripts.
>>>>
>>>>I agree with this sentiment.  We should be building:
>>>>
>>>>a) runtimes of various kinds (SCA standalone, embedded within Tomcat,
>>>
>>>etc)
>>>
>>>>b) applications, containing only the code and other artifacts required
>>>>for the application itself
>>>>
>>>>and then have some regular means of deploying the applications to
>>>>appropriate runtimes - some applications could be deployed to "almost
>>>>any" SCA runtime while others need specific runtime capabilities such
>>
>>as
>>
>>>>a Web server and Servlet support.
>>>>
>>>>
>>>>>   ...ant
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>We are describing configuration scenarios in this thread that are not
>>>
>>>currently well covered in the samples that ship with Tuscany. Take the
>>>following steps as an example,
>>>
>>>1 - choose a runtime
>>>2 - configure the runtime
>>>3 - start the runtime
>>>4 - assemble application(s)
>>>5 - contribute the application(s)
>>>6 - make top level contributed composites available
>>>
>>>90% of our samples currently assume that
>>>
>>>1-3 means start a standalone runtime with all features enabled by using
>>>the
>>>"all" jar
>>>4-6 means add a single contribution with a single composite
>>>
>>>The ant scripts we have target step 2 and have no impact on 4,5,6. The
>>
>>ant
>>
>>>scripts do not imply that the "applications have to know or care about
>>>Tuscany internals". I think you are confusing the act of starting the
>>>runtime with that of contributing the application. It just so happens
>>
>>that
>>
>>>in our samples these steps all happen in close proximity, I.e. our
>>
>>samples
>>
>>>generally include a runtime and the application itself. In the
>>
>>particular
>>
>>>case of webapps the ant scripts configure the runtime (the war in this
>>>case)
>>>so that it contains just enough to run and no more in order to reduce
>>
>>the
>>
>>>size of the war.
>>>
>>
>>Maybe if we had a way to say "Tuscany standalone with all extensions" or
>>"Tuscany Tomcat with BPEL, WS and JavaScript" then ok but if the
>>application
>>build process has to mention tuscany-assembly, tuscany-core,
>>tuscany-definitions, tuscany-databinding and all the other dozens of
>>required jars then that does seems like "knowing and caring about Tuscany
>>internals" to me.
>>
> 
> This is the case as at some point someone decided to package our samples
> along with the runtime that will run them. So to configure the runtime you
> need to configure the sample build. There is no hardwired relationship
> though between the runtime build and the application build.
> 
> The case where we do need to build the two together is when we package the
> runtime within the WAR that holds the application. There have been numerous
> posts during previous releases about reducing the size of these wars which I
> believe is why the WAR builds were different from the standalone runtime
> builds. We could take the view that we always package everything and make
> the build simpler.But I prefer what you are suggesting of being able to
> describe required features rather than the explicit jars that implement a
> feature.
> 
Surely all this should be automatic.  The runtime should load in the
pieces that are needed by the applications that are deployed to run
on it.  It should not be necessary to predict ahead of time what
runtime pieces will be needed and configure a statically tailored
runtime containing exactly those pieces.  The base runtime should
include whatever bootstrap code is needed to load in the extensions
that are needed by applications.  I'd be very interested to work on
implementing such an approach.

>>
>>>Having said this I still agree that having the samples be just
>>>applications
>>>that are then contributed to a runnning runtime of your choice is a more
>>>well rounded target to aim for.  I note that there a series of modules
>>>under
>>>construction.
>>>
>>>tuscany-runtime
>>>tuscany-runtime-tomcat
>>>tuscany-runtime-war
>>>
>>>which could be extended to include tuscany-runtime-standalone,
>>>tuscany-runtime-jms or whatever else is required.
>>>
>>>We still need a mechanism for configuring these runtimes. In particular
>>
>>we
>>
>>>have binding, databinding and implementation extensions that can be
>>>included/excluded. Also some of these extensions may provided
>>
>>alternative
>>
>>>implementations that must be selected explicitly. It seems that steps 1,
>>
>>2
>>
>>>and 3 resolve to
>>>
>>>1 - choose hosting approach
>>>2 - choose extensions
>>>3 - build useable runtime
>>>
>>>It may be that the "all" jar can satisfy many of the cases now as we
>>
>>don't
>>
>>>currently have any cases of alternative extension implementations.
>>
>>However
>>
>>>I
>>>would be nervous in the long run because of the lack of step 2. If
>>
>>nothing
>>
>>>else we should remove the hosting options from the all jar.
>>>
>>
>>I think the "all" jar worked ok as a point in time thing to make the
>>releases more usable after all the problems with M2 but now Tuscany is
>>getting more complex it might be coming to the end of its useful life.
>>
>>Agree about removing the hosting options from it, they seem like they
>>should
>>be separate things, maybe what we need is to separate out all the runtime
>>environment stuff from the all the other code so there's a jar for each
>>environment and a jar with all the common stuff and you'd use them
>>together,
>>eg:
>>
>>tuscany-runtime-standalone.jar and tuscany-sca.jar
>>or
>>tuscany-runtime-tomcat.jar and tuscany-sca.jar
>>or
>>tuscany-runtime-geronimo.jar and tuscany-sca.jar
>>
>>And the various runtime jars would include the impls for the specific
>>environment so tuscany-runtime-geronimo.jar would include the Geronimo
>>specific impls of things like the Tuscany ServletHost and JMS host etc.
> 
> 
> Yes. this is the kind of thing I was thinking. Maybe we ship
> tuscany-sca.jarwith everything in it and provide a build script that
> creates it based on a
> selection of feature names if you want/need to cut is down for whatever
> reason.
> 
You mean everything except the environmental modules, I presume?

>>
>>
>>>Can we enumerate the concrete scenarios we want to satisfy to help us.
>>>I've
>>>seen the following so far. SCA applications running with
>>>
>>>A - a standalone runtime
>>>B - a war runtime
>>>C - Tomcat with no Tuscany code in the war but with Tuscany embedded in
>>>Tomcat
>>>D - Geronimo with no Tuscany code in the war but with Tuscany embedded
>>
>>in
>>
>>>Geronimo
>>>E - a standalone runtime and a JMS provider
>>>
>>>Also the distributed store tutorial brings up the case where the SCA
>>>application uses SCA components to describe a service running outside
>>
>>the
>>
>>>SCA runtime, i.e. the host has no Tuscany runtime but you can wire to
>>
>>it's
>>
>>>services.
>>>
>>>What else do we need to cover?
>>>
>>>Simon
>>
>>
>>Those A to D sound like a good start to me, not sure about E, why is JMS
>>different than say RMI - does A include the RMI host?
> 
> 
> Maybe this is just my misunderstanding of what the JMS host does. I thought
> it was ultimately going to be an optional extra in the case that you needed
> to support the JMS binding with an auto started JMS broker (as the samples
> do currently) as opposed to some existing broker. From you question it
> sounds like you are expecting it to be around all the time in which as it
> would be the same as A
> 
I believe the auto-starting JMS broker is the same as case A.  If I run
a standalone application that exposes an SCA service with a Web Service
binding, the Tuscany standalone runtime will automatically expose a
SOAP/HTTP endpoint using Tomcat or Jetty.  This is case A, and I'd expect
RMI or JMS services to work the same way.

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: R1.1 - Sample/demo ant builds

[Simon Laws <si...@googlemail.com>]

On Jan 2, 2008 1:23 PM, ant elder <an...@gmail.com> wrote:

> On Jan 2, 2008 12:00 PM, Simon Laws <si...@googlemail.com> wrote:
>
> > On Jan 2, 2008 10:53 AM, Mike Edwards <mi...@gmail.com>
> > wrote:
> >
> > > Folks,
> > >
> > > Some comments....
> > >
> > > Yours,  Mike.
> > >
> > > ant elder wrote:
> > > > On Jan 2, 2008 8:58 AM, Simon Laws <si...@googlemail.com>
> wrote:
> > > >
> > > >> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> > > >> change,
> > > >> based on the ant generator plugin, to bring some automation to the
> > > process
> > > >> of building the ant files for the samples and demos. For any sample
> > or
> > > >> demo
> > > >> that requires explicit dependencies, e.g. the webapp samples, I've
> > > >> replaced
> > > >> the static ant file with and automatically generated one. In the
> case
> > > that
> > > >> some hand crafted ant script is needed, for example, to generate
> > SDOs,
> > > >> then
> > > >> I have the ant generator just build build-dependency.xml which has
> > the
> > > >> dependencies listed and which can then be included in the manually
> > > >> generated
> > > >> build.xml script.
> > > >>
> > > >> I haven't applied this change to all of the samples but it could be
> > > done.
> > > >> If
> > > >> we did have all of the dependencies explicitly described for all of
> > the
> > > >> samples can we get rid of the "all" and "manifest" jars?
> > > >>
> > > >> Simon
> > > >
> > > >
> > > >
> > > > I think its better if applications don't have to know or care about
> > > Tuscany
> > > > internals, that includes knowing all the different Tuscany module
> > names
> > > and
> > > > all the dependencies they use.
> > >
> > > +1 - applications should ideally have ZERO dependence on Tuscany
> > > internals.  They should be deployed to an "SCA capable runtime"
> without
> > > having to know anything about that runtime.
> > >
> > > > We haven't got this right yet so each time we
> > > > release our sample Ant builds break as the build.xml files get out
> of
> > > date -
> > > > this will be happening for any Ant builds our users have as well.
> The
> > > "all"
> > > > jar is an attempt to fix this, its a better way IMHO than having
> > > > applications specify every Tuscany module but theres a bit of work
> > still
> > > to
> > > > do to make it work better for webapps. We've also talked before
> about
> > > > changing all the samples to be simple sca contributions that don't
> > need
> > > any
> > > > mention of the Tuscany internals, this is something I think we
> really
> > > need
> > > > to do. Both of those things seem better to me than messing about
> > trying
> > > to
> > > > generate build scripts.
> > >
> > > I agree with this sentiment.  We should be building:
> > >
> > > a) runtimes of various kinds (SCA standalone, embedded within Tomcat,
> > etc)
> > >
> > > b) applications, containing only the code and other artifacts required
> > > for the application itself
> > >
> > > and then have some regular means of deploying the applications to
> > > appropriate runtimes - some applications could be deployed to "almost
> > > any" SCA runtime while others need specific runtime capabilities such
> as
> > > a Web server and Servlet support.
> > >
> > > >
> > > >    ...ant
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > We are describing configuration scenarios in this thread that are not
> > currently well covered in the samples that ship with Tuscany. Take the
> > following steps as an example,
> >
> > 1 - choose a runtime
> > 2 - configure the runtime
> > 3 - start the runtime
> > 4 - assemble application(s)
> > 5 - contribute the application(s)
> > 6 - make top level contributed composites available
> >
> > 90% of our samples currently assume that
> >
> > 1-3 means start a standalone runtime with all features enabled by using
> > the
> > "all" jar
> > 4-6 means add a single contribution with a single composite
> >
> > The ant scripts we have target step 2 and have no impact on 4,5,6. The
> ant
> > scripts do not imply that the "applications have to know or care about
> > Tuscany internals". I think you are confusing the act of starting the
> > runtime with that of contributing the application. It just so happens
> that
> > in our samples these steps all happen in close proximity, I.e. our
> samples
> > generally include a runtime and the application itself. In the
> particular
> > case of webapps the ant scripts configure the runtime (the war in this
> > case)
> > so that it contains just enough to run and no more in order to reduce
> the
> > size of the war.
> >
>
> Maybe if we had a way to say "Tuscany standalone with all extensions" or
> "Tuscany Tomcat with BPEL, WS and JavaScript" then ok but if the
> application
> build process has to mention tuscany-assembly, tuscany-core,
> tuscany-definitions, tuscany-databinding and all the other dozens of
> required jars then that does seems like "knowing and caring about Tuscany
> internals" to me.
>
This is the case as at some point someone decided to package our samples
along with the runtime that will run them. So to configure the runtime you
need to configure the sample build. There is no hardwired relationship
though between the runtime build and the application build.

The case where we do need to build the two together is when we package the
runtime within the WAR that holds the application. There have been numerous
posts during previous releases about reducing the size of these wars which I
believe is why the WAR builds were different from the standalone runtime
builds. We could take the view that we always package everything and make
the build simpler.But I prefer what you are suggesting of being able to
describe required features rather than the explicit jars that implement a
feature.

>
>
> >
> > Having said this I still agree that having the samples be just
> > applications
> > that are then contributed to a runnning runtime of your choice is a more
> > well rounded target to aim for.  I note that there a series of modules
> > under
> > construction.
> >
> > tuscany-runtime
> > tuscany-runtime-tomcat
> > tuscany-runtime-war
> >
> > which could be extended to include tuscany-runtime-standalone,
> > tuscany-runtime-jms or whatever else is required.
> >
> > We still need a mechanism for configuring these runtimes. In particular
> we
> > have binding, databinding and implementation extensions that can be
> > included/excluded. Also some of these extensions may provided
> alternative
> > implementations that must be selected explicitly. It seems that steps 1,
> 2
> > and 3 resolve to
> >
> > 1 - choose hosting approach
> > 2 - choose extensions
> > 3 - build useable runtime
> >
> > It may be that the "all" jar can satisfy many of the cases now as we
> don't
> > currently have any cases of alternative extension implementations.
> However
> > I
> > would be nervous in the long run because of the lack of step 2. If
> nothing
> > else we should remove the hosting options from the all jar.
> >
>
> I think the "all" jar worked ok as a point in time thing to make the
> releases more usable after all the problems with M2 but now Tuscany is
> getting more complex it might be coming to the end of its useful life.
>
> Agree about removing the hosting options from it, they seem like they
> should
> be separate things, maybe what we need is to separate out all the runtime
> environment stuff from the all the other code so there's a jar for each
> environment and a jar with all the common stuff and you'd use them
> together,
> eg:
>
> tuscany-runtime-standalone.jar and tuscany-sca.jar
> or
> tuscany-runtime-tomcat.jar and tuscany-sca.jar
> or
> tuscany-runtime-geronimo.jar and tuscany-sca.jar
>
> And the various runtime jars would include the impls for the specific
> environment so tuscany-runtime-geronimo.jar would include the Geronimo
> specific impls of things like the Tuscany ServletHost and JMS host etc.

Yes. this is the kind of thing I was thinking. Maybe we ship
tuscany-sca.jarwith everything in it and provide a build script that
creates it based on a
selection of feature names if you want/need to cut is down for whatever
reason.

>
>
>
> >
> > Can we enumerate the concrete scenarios we want to satisfy to help us.
> > I've
> > seen the following so far. SCA applications running with
> >
> > A - a standalone runtime
> > B - a war runtime
> > C - Tomcat with no Tuscany code in the war but with Tuscany embedded in
> > Tomcat
> > D - Geronimo with no Tuscany code in the war but with Tuscany embedded
> in
> > Geronimo
> > E - a standalone runtime and a JMS provider
> >
> > Also the distributed store tutorial brings up the case where the SCA
> > application uses SCA components to describe a service running outside
> the
> > SCA runtime, i.e. the host has no Tuscany runtime but you can wire to
> it's
> > services.
> >
> > What else do we need to cover?
> >
> > Simon
>
>
> Those A to D sound like a good start to me, not sure about E, why is JMS
> different than say RMI - does A include the RMI host?

Maybe this is just my misunderstanding of what the JMS host does. I thought
it was ultimately going to be an optional extra in the case that you needed
to support the JMS binding with an auto started JMS broker (as the samples
do currently) as opposed to some existing broker. From you question it
sounds like you are expecting it to be around all the time in which as it
would be the same as A

>
>
>   ...ant
>

Re: R1.1 - Sample/demo ant builds

[ant elder <an...@gmail.com>]

On Jan 2, 2008 12:00 PM, Simon Laws <si...@googlemail.com> wrote:

> On Jan 2, 2008 10:53 AM, Mike Edwards <mi...@gmail.com>
> wrote:
>
> > Folks,
> >
> > Some comments....
> >
> > Yours,  Mike.
> >
> > ant elder wrote:
> > > On Jan 2, 2008 8:58 AM, Simon Laws <si...@googlemail.com> wrote:
> > >
> > >> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> > >> change,
> > >> based on the ant generator plugin, to bring some automation to the
> > process
> > >> of building the ant files for the samples and demos. For any sample
> or
> > >> demo
> > >> that requires explicit dependencies, e.g. the webapp samples, I've
> > >> replaced
> > >> the static ant file with and automatically generated one. In the case
> > that
> > >> some hand crafted ant script is needed, for example, to generate
> SDOs,
> > >> then
> > >> I have the ant generator just build build-dependency.xml which has
> the
> > >> dependencies listed and which can then be included in the manually
> > >> generated
> > >> build.xml script.
> > >>
> > >> I haven't applied this change to all of the samples but it could be
> > done.
> > >> If
> > >> we did have all of the dependencies explicitly described for all of
> the
> > >> samples can we get rid of the "all" and "manifest" jars?
> > >>
> > >> Simon
> > >
> > >
> > >
> > > I think its better if applications don't have to know or care about
> > Tuscany
> > > internals, that includes knowing all the different Tuscany module
> names
> > and
> > > all the dependencies they use.
> >
> > +1 - applications should ideally have ZERO dependence on Tuscany
> > internals.  They should be deployed to an "SCA capable runtime" without
> > having to know anything about that runtime.
> >
> > > We haven't got this right yet so each time we
> > > release our sample Ant builds break as the build.xml files get out of
> > date -
> > > this will be happening for any Ant builds our users have as well. The
> > "all"
> > > jar is an attempt to fix this, its a better way IMHO than having
> > > applications specify every Tuscany module but theres a bit of work
> still
> > to
> > > do to make it work better for webapps. We've also talked before about
> > > changing all the samples to be simple sca contributions that don't
> need
> > any
> > > mention of the Tuscany internals, this is something I think we really
> > need
> > > to do. Both of those things seem better to me than messing about
> trying
> > to
> > > generate build scripts.
> >
> > I agree with this sentiment.  We should be building:
> >
> > a) runtimes of various kinds (SCA standalone, embedded within Tomcat,
> etc)
> >
> > b) applications, containing only the code and other artifacts required
> > for the application itself
> >
> > and then have some regular means of deploying the applications to
> > appropriate runtimes - some applications could be deployed to "almost
> > any" SCA runtime while others need specific runtime capabilities such as
> > a Web server and Servlet support.
> >
> > >
> > >    ...ant
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > We are describing configuration scenarios in this thread that are not
> currently well covered in the samples that ship with Tuscany. Take the
> following steps as an example,
>
> 1 - choose a runtime
> 2 - configure the runtime
> 3 - start the runtime
> 4 - assemble application(s)
> 5 - contribute the application(s)
> 6 - make top level contributed composites available
>
> 90% of our samples currently assume that
>
> 1-3 means start a standalone runtime with all features enabled by using
> the
> "all" jar
> 4-6 means add a single contribution with a single composite
>
> The ant scripts we have target step 2 and have no impact on 4,5,6. The ant
> scripts do not imply that the "applications have to know or care about
> Tuscany internals". I think you are confusing the act of starting the
> runtime with that of contributing the application. It just so happens that
> in our samples these steps all happen in close proximity, I.e. our samples
> generally include a runtime and the application itself. In the particular
> case of webapps the ant scripts configure the runtime (the war in this
> case)
> so that it contains just enough to run and no more in order to reduce the
> size of the war.
>

Maybe if we had a way to say "Tuscany standalone with all extensions" or
"Tuscany Tomcat with BPEL, WS and JavaScript" then ok but if the application
build process has to mention tuscany-assembly, tuscany-core,
tuscany-definitions, tuscany-databinding and all the other dozens of
required jars then that does seems like "knowing and caring about Tuscany
internals" to me.


>
> Having said this I still agree that having the samples be just
> applications
> that are then contributed to a runnning runtime of your choice is a more
> well rounded target to aim for.  I note that there a series of modules
> under
> construction.
>
> tuscany-runtime
> tuscany-runtime-tomcat
> tuscany-runtime-war
>
> which could be extended to include tuscany-runtime-standalone,
> tuscany-runtime-jms or whatever else is required.
>
> We still need a mechanism for configuring these runtimes. In particular we
> have binding, databinding and implementation extensions that can be
> included/excluded. Also some of these extensions may provided alternative
> implementations that must be selected explicitly. It seems that steps 1, 2
> and 3 resolve to
>
> 1 - choose hosting approach
> 2 - choose extensions
> 3 - build useable runtime
>
> It may be that the "all" jar can satisfy many of the cases now as we don't
> currently have any cases of alternative extension implementations. However
> I
> would be nervous in the long run because of the lack of step 2. If nothing
> else we should remove the hosting options from the all jar.
>

I think the "all" jar worked ok as a point in time thing to make the
releases more usable after all the problems with M2 but now Tuscany is
getting more complex it might be coming to the end of its useful life.

Agree about removing the hosting options from it, they seem like they should
be separate things, maybe what we need is to separate out all the runtime
environment stuff from the all the other code so there's a jar for each
environment and a jar with all the common stuff and you'd use them together,
eg:

tuscany-runtime-standalone.jar and tuscany-sca.jar
or
tuscany-runtime-tomcat.jar and tuscany-sca.jar
or
tuscany-runtime-geronimo.jar and tuscany-sca.jar

And the various runtime jars would include the impls for the specific
environment so tuscany-runtime-geronimo.jar would include the Geronimo
specific impls of things like the Tuscany ServletHost and JMS host etc.


>
> Can we enumerate the concrete scenarios we want to satisfy to help us.
> I've
> seen the following so far. SCA applications running with
>
> A - a standalone runtime
> B - a war runtime
> C - Tomcat with no Tuscany code in the war but with Tuscany embedded in
> Tomcat
> D - Geronimo with no Tuscany code in the war but with Tuscany embedded in
> Geronimo
> E - a standalone runtime and a JMS provider
>
> Also the distributed store tutorial brings up the case where the SCA
> application uses SCA components to describe a service running outside the
> SCA runtime, i.e. the host has no Tuscany runtime but you can wire to it's
> services.
>
> What else do we need to cover?
>
> Simon


Those A to D sound like a good start to me, not sure about E, why is JMS
different than say RMI - does A include the RMI host?

   ...ant

Re: R1.1 - Sample/demo ant builds

[Simon Laws <si...@googlemail.com>]

On Jan 2, 2008 10:53 AM, Mike Edwards <mi...@gmail.com>
wrote:

> Folks,
>
> Some comments....
>
> Yours,  Mike.
>
> ant elder wrote:
> > On Jan 2, 2008 8:58 AM, Simon Laws <si...@googlemail.com> wrote:
> >
> >> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> >> change,
> >> based on the ant generator plugin, to bring some automation to the
> process
> >> of building the ant files for the samples and demos. For any sample or
> >> demo
> >> that requires explicit dependencies, e.g. the webapp samples, I've
> >> replaced
> >> the static ant file with and automatically generated one. In the case
> that
> >> some hand crafted ant script is needed, for example, to generate SDOs,
> >> then
> >> I have the ant generator just build build-dependency.xml which has the
> >> dependencies listed and which can then be included in the manually
> >> generated
> >> build.xml script.
> >>
> >> I haven't applied this change to all of the samples but it could be
> done.
> >> If
> >> we did have all of the dependencies explicitly described for all of the
> >> samples can we get rid of the "all" and "manifest" jars?
> >>
> >> Simon
> >
> >
> >
> > I think its better if applications don't have to know or care about
> Tuscany
> > internals, that includes knowing all the different Tuscany module names
> and
> > all the dependencies they use.
>
> +1 - applications should ideally have ZERO dependence on Tuscany
> internals.  They should be deployed to an "SCA capable runtime" without
> having to know anything about that runtime.
>
> > We haven't got this right yet so each time we
> > release our sample Ant builds break as the build.xml files get out of
> date -
> > this will be happening for any Ant builds our users have as well. The
> "all"
> > jar is an attempt to fix this, its a better way IMHO than having
> > applications specify every Tuscany module but theres a bit of work still
> to
> > do to make it work better for webapps. We've also talked before about
> > changing all the samples to be simple sca contributions that don't need
> any
> > mention of the Tuscany internals, this is something I think we really
> need
> > to do. Both of those things seem better to me than messing about trying
> to
> > generate build scripts.
>
> I agree with this sentiment.  We should be building:
>
> a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc)
>
> b) applications, containing only the code and other artifacts required
> for the application itself
>
> and then have some regular means of deploying the applications to
> appropriate runtimes - some applications could be deployed to "almost
> any" SCA runtime while others need specific runtime capabilities such as
> a Web server and Servlet support.
>
> >
> >    ...ant
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> We are describing configuration scenarios in this thread that are not
currently well covered in the samples that ship with Tuscany. Take the
following steps as an example,

1 - choose a runtime
2 - configure the runtime
3 - start the runtime
4 - assemble application(s)
5 - contribute the application(s)
6 - make top level contributed composites available

90% of our samples currently assume that

1-3 means start a standalone runtime with all features enabled by using the
"all" jar
4-6 means add a single contribution with a single composite

The ant scripts we have target step 2 and have no impact on 4,5,6. The ant
scripts do not imply that the "applications have to know or care about
Tuscany internals". I think you are confusing the act of starting the
runtime with that of contributing the application. It just so happens that
in our samples these steps all happen in close proximity, I.e. our samples
generally include a runtime and the application itself. In the particular
case of webapps the ant scripts configure the runtime (the war in this case)
so that it contains just enough to run and no more in order to reduce the
size of the war.

Having said this I still agree that having the samples be just applications
that are then contributed to a runnning runtime of your choice is a more
well rounded target to aim for.  I note that there a series of modules under
construction.

tuscany-runtime
tuscany-runtime-tomcat
tuscany-runtime-war

which could be extended to include tuscany-runtime-standalone,
tuscany-runtime-jms or whatever else is required.

We still need a mechanism for configuring these runtimes. In particular we
have binding, databinding and implementation extensions that can be
included/excluded. Also some of these extensions may provided alternative
implementations that must be selected explicitly. It seems that steps 1, 2
and 3 resolve to

1 - choose hosting approach
2 - choose extensions
3 - build useable runtime

It may be that the "all" jar can satisfy many of the cases now as we don't
currently have any cases of alternative extension implementations. However I
would be nervous in the long run because of the lack of step 2. If nothing
else we should remove the hosting options from the all jar.

Can we enumerate the concrete scenarios we want to satisfy to help us. I've
seen the following so far. SCA applications running with

A - a standalone runtime
B - a war runtime
C - Tomcat with no Tuscany code in the war but with Tuscany embedded in
Tomcat
D - Geronimo with no Tuscany code in the war but with Tuscany embedded in
Geronimo
E - a standalone runtime and a JMS provider

Also the distributed store tutorial brings up the case where the SCA
application uses SCA components to describe a service running outside the
SCA runtime, i.e. the host has no Tuscany runtime but you can wire to it's
services.

What else do we need to cover?

Simon

Re: R1.1 - Sample/demo ant builds

[Mike Edwards <mi...@gmail.com>]

Folks,

Some comments....

Yours,  Mike.

ant elder wrote:
> On Jan 2, 2008 8:58 AM, Simon Laws <si...@googlemail.com> wrote:
> 
>> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
>> change,
>> based on the ant generator plugin, to bring some automation to the process
>> of building the ant files for the samples and demos. For any sample or
>> demo
>> that requires explicit dependencies, e.g. the webapp samples, I've
>> replaced
>> the static ant file with and automatically generated one. In the case that
>> some hand crafted ant script is needed, for example, to generate SDOs,
>> then
>> I have the ant generator just build build-dependency.xml which has the
>> dependencies listed and which can then be included in the manually
>> generated
>> build.xml script.
>>
>> I haven't applied this change to all of the samples but it could be done.
>> If
>> we did have all of the dependencies explicitly described for all of the
>> samples can we get rid of the "all" and "manifest" jars?
>>
>> Simon
> 
> 
> 
> I think its better if applications don't have to know or care about Tuscany
> internals, that includes knowing all the different Tuscany module names and
> all the dependencies they use. 

+1 - applications should ideally have ZERO dependence on Tuscany 
internals.  They should be deployed to an "SCA capable runtime" without 
having to know anything about that runtime.

> We haven't got this right yet so each time we
> release our sample Ant builds break as the build.xml files get out of date -
> this will be happening for any Ant builds our users have as well. The "all"
> jar is an attempt to fix this, its a better way IMHO than having
> applications specify every Tuscany module but theres a bit of work still to
> do to make it work better for webapps. We've also talked before about
> changing all the samples to be simple sca contributions that don't need any
> mention of the Tuscany internals, this is something I think we really need
> to do. Both of those things seem better to me than messing about trying to
> generate build scripts.

I agree with this sentiment.  We should be building:

a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc)

b) applications, containing only the code and other artifacts required 
for the application itself

and then have some regular means of deploying the applications to 
appropriate runtimes - some applications could be deployed to "almost 
any" SCA runtime while others need specific runtime capabilities such as 
a Web server and Servlet support.

> 
>    ...ant
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: R1.1 - Sample/demo ant builds

[ant elder <an...@gmail.com>]

On Jan 2, 2008 8:58 AM, Simon Laws <si...@googlemail.com> wrote:

> For http://issues.apache.org/jira/browse/TUSCANY-1608 I've put in a
> change,
> based on the ant generator plugin, to bring some automation to the process
> of building the ant files for the samples and demos. For any sample or
> demo
> that requires explicit dependencies, e.g. the webapp samples, I've
> replaced
> the static ant file with and automatically generated one. In the case that
> some hand crafted ant script is needed, for example, to generate SDOs,
> then
> I have the ant generator just build build-dependency.xml which has the
> dependencies listed and which can then be included in the manually
> generated
> build.xml script.
>
> I haven't applied this change to all of the samples but it could be done.
> If
> we did have all of the dependencies explicitly described for all of the
> samples can we get rid of the "all" and "manifest" jars?
>
> Simon



I think its better if applications don't have to know or care about Tuscany
internals, that includes knowing all the different Tuscany module names and
all the dependencies they use. We haven't got this right yet so each time we
release our sample Ant builds break as the build.xml files get out of date -
this will be happening for any Ant builds our users have as well. The "all"
jar is an attempt to fix this, its a better way IMHO than having
applications specify every Tuscany module but theres a bit of work still to
do to make it work better for webapps. We've also talked before about
changing all the samples to be simple sca contributions that don't need any
mention of the Tuscany internals, this is something I think we really need
to do. Both of those things seem better to me than messing about trying to
generate build scripts.

   ...ant