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) b) applications, containing only the code and other artifacts required for the application itself 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. 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. So what do people think about this approach? Does everyone agree we should be doing those (a) and (b) suggested above? ...ant ---------- Forwarded message ---------- From: Mike Edwards <[EMAIL PROTECTED]> Date: Jan 2, 2008 10:53 AM Subject: Re: R1.1 - Sample/demo ant builds To: [email protected] Folks, Some comments.... Yours, Mike. ant elder wrote: > On Jan 2, 2008 8:58 AM, Simon Laws <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
