tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws" <simonsl...@googlemail.com>
Subject Re: R1.1 - Sample/demo ant builds
Date Wed, 02 Jan 2008 12:00:03 GMT
On Jan 2, 2008 10:53 AM, Mike Edwards <mike.edwards.inglenook@gmail.com>

> Folks,
> Some comments....
> Yours,  Mike.
> ant elder wrote:
> > On Jan 2, 2008 8:58 AM, Simon Laws <simonslaws@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


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
D - Geronimo with no Tuscany code in the war but with Tuscany embedded in
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

What else do we need to cover?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message