tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@hursley.ibm.com>
Subject Re: SCA runtimes
Date Thu, 10 Jan 2008 11:18:51 GMT
Comments inline.

   Simon

ant elder wrote:

> I know everyone is busy with the 1.1 release but any comments on this?
> 
>    ...ant
> 
> On Jan 7, 2008 6:03 PM, ant elder <ant.elder@gmail.com> wrote:
> 
> 
>>Spitting the email below out into a separate thread to discuss runtime:
>>
>>The suggestion is that we should be building:
>>
>>a) runtimes of various kinds (SCA standalone, embedded within Tomcat, etc)
>>
Yes in principle, but let's keep the number of different flavours of
the complete runtime down to the minimum.

>>b) applications, containing only the code and other artifacts required for
>>the application itself
>>
Yes, definitely.

>>To see what this looks like I've started creating some of this in the
>>sca/modules/runtime-* projects and associated projects in sca/distributions.
>>Applications become just jar files with no reference to Tuscany modules and
>>the runtimes pick up the contributions from a repository folder. Currently
>>the standalone, and war ones are working, eg you can build distribution/war
>>and it creates a tuscany.war that can be deployed in Tomcat.  The war
>>distribution includes repository  in the top-level webapp folder which
>>includes a couple of the Tuscany samples to show it works, or you can update
>>the web.xml to move the repository out of the webapp to make it easier to
>>add your own contributions.
>>
>>If we went for this I was thinking we'd have runtimes like standalone,
>>war, webapp, tomcat, etc.
 >
If we can do this with a smaller number of distinct runtimes, I think
that would be preferable to having the complete runtime in 4 or more
different packagings.

>>                          The current binary distribution would go away and
>>be replaced by the standalone and war distributions, the webapp one only be
>>distributed from the Maven repositories and used for building applications
>>using Tuscany in a webapp, and the tomcat one would be for the Tomcat deep
>>integration. The standalone and war distributions would come with all the
>>relevent samples included in their repository folders.
>>
Would the webapp distro be used to put a complete copy of the Tuscany
runtime in the webapp being built, for webapp containers that don't
know anything about Tuscany?  I think an ant tool to do this, based
on a locally installed runtime, would be useful.

>>So what do people think about this approach? Does everyone agree we should
>>be doing those (a) and (b) suggested above?
>>
I'd prefer a common core and environment-specific deltas for the various
flavours, if we can work out how to arrange that.  I have some ideas
which I'll send in a follow-up post.

   Simon

>>   ...ant
>>
>>---------- Forwarded message ----------
>>From: Mike Edwards <mike.edwards.inglenook@gmail.com>
>>Date: Jan 2, 2008 10:53 AM
>>Subject: Re: R1.1 - Sample/demo ant builds
>>To: tuscany-dev@ws.apache.org
>>
>>
>>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
>>
>>
>>



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


Mime
View raw message