Thanks very much for finding the time to respond, comments inline. ...ant
On Jan 10, 2008 11:18 AM, Simon Nash <[EMAIL PROTECTED]> wrote: > 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 < [EMAIL PROTECTED]> 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. I agree we should keep the number of different downloads on the download page to a minimum, is that what you mean? But what if there are available flavours that are only in Maven repositories or only available for use from build scripts and not up as downloadable distributions on the download page? > >>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. > Well how to do that is part of what I'm looking for with this discussion :) If samples become just simple sca contribution jars with no mention of Tuscany we need somewhere to run them. The distribution/war is an attempt at a complete runtime for this for a webapp container, its about 30meg and could be a single separate distribution download. If we want to run samples outside of a webapp container, say standalone, then we need a runtime for that which would also be about 30 meg. That could be a separate download from the war distribution which then makes two downloads, or both combined into one distribution which is then 60 meg. If we want a pre-built runtime for tomcat deep integration then thats another 30 meg runtime which could be a separate download or bundled with one of the others, and if we want something like a webapp distribution (see below) then thats another 30 meg to be either downloadable separately or bundled up with something making the download even bigger. One alternative is to find a way to share some of the jars between runtimes, eg, if the standalone distribution includes all the jars then it is possible to get Tomcat deep integration to work running off those jars outside of the Tomcat install. So that way we could have both the standalone and tomcat deep integration working from one 30 meg download sharing dependency jars and a single sca contribution repository with all the samples, and only a little manual configuration required in Tomcat. I can't see how to do that with webapps though, either we don't ship them prebuilt or they need a runtime included for each sample. The WAR distribution is an attempt to have one single prebuilt WAR that runs all the samples. The webapp runtime is as you described below, i guess it is actually pretty much the same code as used in the WAR distribution, just the WAR distribution is a prebuilt WAR which includes all the sample contribution jars whereas the webapp runtime is just for when you're building you own webapps with your own sca contributions, so the webapp runtime would not be a separately downloadable distribution. Maybe the name "standalone" distribution is wrong, if we can get it including the webapp and tomcat tuscany jars but have those jars ignored when running standalone , and have the standalone Jetty module ignored when running in webapps or tomcat, then its more a binary distribution that can be use for standalone, tomcat deep, and when building webapps locally without using maven with a remote maven repository. So that would be just two distributions the binary and the war, and thats like what a lot of other projects do. > > >> 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? Yes thats what i was thinking. And the application in the webapp (eg WEB-INF/classes) would be treated as the SCA contribution, perhaps with optionally being able to put other contributions in another location. > I think an ant tool to do this, based > on a locally installed runtime, would be useful. > Ok, and that would need all the required jars bundled with something like the binary distribution. Also we could possibly look at Ivy to get dependencys from maven repositories. > > >>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 < [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] > >> > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
