A quick update: 1) I add a flag to control if we generate the distro-specific configuration files or manifest.jar at the top level or under the name of the distro 2) I add the code to generate the build-path.xml which can be directly included into the sample build.xml 3) I add a bit logic to name the distro folder as feature-<xyz> instead of tuscany-distribution-<xyz>.
Thanks, Raymond From: Simon Laws Sent: Tuesday, January 27, 2009 2:27 AM To: [email protected] Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions 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. 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. I think we need to try different granularity of groups to see what works. The smallest granularity is propably an extension and multiple extensions in a group produce the "features" that are in svn now. I'll post more as they come to mind. Simon [1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html
