On Tue, Jan 27, 2009 at 10:27 AM, Simon Laws <[email protected]>wrote:
> > > On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <[email protected]> wrote: > >> Hi, >> >> Please see my comments inline. >> >> Thanks, >> Raymond >> >> >> From: Simon Laws >> Sent: Monday, January 26, 2009 7:00 AM >> To: [email protected] >> Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align >> samples with the distributions >> >> >> [[snip]] >> >> Hi >> >> I'm adding the three samples I've been playing with to the build and the >> distribution so we can experiment with the process/scripts. I'd like to >> exploit M1 to get the process a slick as we can while we have a small number >> of modules. The binding-ws-calculator and host-webapp-calculator samples >> don't actually work yet as samples. The related function still needs some >> work. >> >> +1 to use samples to validate the distribution structure and grouping. >> >> Looking through the distribuion I have some questions/comments; >> >> - why "ejava"? Any relation to [1]:-) >> >> "ejava" stands for "Enterprise Java". It will potentially include >> Enterprise Java related pieces such as binding.rmi, binding.ejb, >> binding.jms, implementation.ejb, implementation.web etc. >> >> - How to get hold of the list of jars for a given feature so that I can >> build a war including the minimum set of jars. It could be an option if the >> war just referenced an external tuscany distribution but users may not have >> the option to install one so we probably still need to include the runtime >> in the war. Is there a trick to extract this info from a manifest. I'd >> rather not generate another ant script with that info if we can avoid it. >> >> How do you produce the WAR file? If you are using maven, then you can add >> the dependency to the distribution pom project, such as >> tuscany-distribution-core:pom. For ANT, it's typically done via the war ant >> task which has the lib element that defines a fileSet. We can easily >> generate something like modules.lst for each distribution for easy parsing. >> > > Currently I just include everything in modules which is not ideal... > > <fileset id="tuscany.jars" dir="${distro.root}/modules"> > <include name="*.jar" /> > <include name="*/*.jar" /> > </fileset> > <war destfile="${sample.war}" > webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml"> > <fileset dir="${sample.root}/src/main/webapp"/> > <lib refid="tuscany.jars"/> > <classes dir="${sample.root}/target/classes"/> > </war> > > If we want to allow people to build wars from ant scripts then we need to > have a way for building a lib path from selected features. An alternative is > to say that people can;t do this with ant but need to use maven to build > wars and use the maven dependencies. A step back from what we have in 1.x > though so I'd rather we continue to support any compiles in this case. > That seems to be getting to the root of what this is about - how to best support building webapps with Ant - or more generally - how can people not using Maven know what Tuscany jars and dependencies they need to be using. There's lots a different ways we could do that, from just manually documenting it in a text file to using custom plugins to generate lists. If we seperate that from what the distributions look like it may help to see what the best options are. > We could generate the "fileset" for each feature an maybe this is the > easiest way but I was interested to know if you had something in mind > without generating more files. > > >> - tuscany-distribution-ejava etc. This is a question about naming really. >> I'm undecided as to whether we should actually distribute these things but I >> am very keen that our distribution(s) are structured so that people can >> depend on sensible chunks of function rather than all of it. Do we >> anticipate that there will be groups of function here that aren't named >> distribution, e.g. tuscany-extension-implementation-bpel or >> tuscany-extension-binding-jms so that people can include manifests for >> individual extensions rather than larger groups of them? >> I think it's about granularity and different combinations of functional >> modules. Tuscany can only ship a limited number of distros. If we get >> the technique very simple to declare a "feature", then we can potentially >> make many configurations available. With what we have, "feature" can extend >> from one or more features and features can also have overlaps. In fact, we >> don't have to build a distro for every single feature we define. We can have >> much less distros than features. For example, one "all" distro can have >> configurations for "core", "ejava", "webservice" features. >> > > I agree that the idea of having groups of jars represented in the all > distribrio and the though that these groups might be separately distributed > are different points. > Yes, and if we keep them separate then we can decouple the two and that will help find good solutions for each. And I think we're all starting to agree on this and its whats being suggested over on the point 2 in this post: http://apache.markmail.org/message/2vumrlwjr7ylu3zp ...ant
