Hi, I have made some good progress (IMO :-) to bring up the distribution story in 2.x toward M1. The current "all" distribution contains "core" and "ejava" (binding.rmi only). You can try to build it with the following command:
cd sca/distribution mvn clean install -Pdistribution Please build the tools and modules first. tuscany-maven-bundle-plugin is used to produce some parts of the distribution. The current story is documented at [1]. Feedbacks are welcome. [1] http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1 Thanks, Raymond From: ant elder Sent: Friday, January 23, 2009 2:03 AM To: [email protected] Subject: Re: [2.0] Align samples with the distributions On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <[email protected]> wrote: On Thu, Jan 22, 2009 at 11:59 AM, ant elder <[email protected]> wrote: On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <[email protected]> wrote: On Thu, Jan 22, 2009 at 11:14 AM, ant elder <[email protected]> wrote: On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <[email protected]> wrote: On Thu, Jan 22, 2009 at 6:44 AM, ant elder <[email protected]> wrote: I asked early but no ones replied so I'm still missing the point of what these manifest classpaths would be used for? If there we use some type of launcher there is no need for a manifest classpath is there? A problem with that one below is that it includes more than just the core dependencies which makes it a little misleading. ...ant On Wed, Jan 21, 2009 at 5:00 PM, Raymond Feng <[email protected]> wrote: I have added the support to generate the manifest jars which contain the classpath for a given distribution. JSE users can just use the manifest jar alone to point to the distro he/she wants. For example, to use "core" distro, we generate "startup/tuscany-distribution-core-manifest.jar" with the following MANIFEST.MF. Please note it works well with the flat structure under "modules" for all the jars. Manifest-Version: 1.0 Implementation-Vendor: The Apache Software Foundation Implementation-Title: Apache Tuscany SCA Core Distribution Implementation-Version: 2.0-SNAPSHOT Implementation-Vendor-Id: org.apache Class-Path: ../modules/jaxb-api-2.1/jaxb-api-2.1.jar,../modules/tuscan y-definitions-xml-2.0-SNAPSHOT.jar,../modules/runtime-3.3.100-v200705 30.jar,../modules/XmlSchema-1.4.2.jar,../modules/tuscany-policy-secur ity-2.0-SNAPSHOT.jar,../modules/tuscany-assembly-xml-2.0-SNAPSHOT.jar ,../modules/tuscany-workspace-impl-2.0-SNAPSHOT.jar,../modules/tuscan y-interface-wsdl-2.0-SNAPSHOT.jar,../modules/tuscany-interface-wsdl-x ml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-jaxb-2.0-SNAPSHOT. jar,../modules/jobs-3.3.0-v20070423.jar,../modules/tuscany-node-launc her-equinox-2.0-SNAPSHOT.jar,../modules/common-3.3.0-v20070426.jar,.. /modules/tuscany-policy-xml-2.0-SNAPSHOT.jar,../modules/tuscany-works pace-xml-2.0-SNAPSHOT.jar,../modules/activation-1.1/activation-1.1.ja r,../modules/tuscany-interface-2.0-SNAPSHOT.jar,../modules/tuscany-co re-spi-2.0-SNAPSHOT.jar,../modules/tuscany-interface-java-jaxws-2.0-S NAPSHOT.jar,../modules/contenttype-3.2.100-v20070319.jar,../modules/j sr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar,../modules/tuscany-policy-2. 0-SNAPSHOT.jar,../modules/tuscany-binding-sca-xml-2.0-SNAPSHOT.jar,.. /modules/tuscany-sca-api-2.0-SNAPSHOT.jar,../modules/geronimo-stax-ap i_1.0_spec-1.0.1.jar,../modules/tuscany-monitor-2.0-SNAPSHOT.jar,../m odules/wstx-asl-3.2.4/wstx-asl-3.2.4.jar,../modules/registry-3.3.0-v2 0070522.jar,../modules/tuscany-implementation-node-runtime-2.0-SNAPSH OT.jar,../modules/tuscany-contribution-namespace-2.0-SNAPSHOT.jar,../ modules/jsr250-api-1.0/jsr250-api-1.0.jar,../modules/tuscany-host-htt p-2.0-SNAPSHOT.jar,../modules/preferences-3.2.100-v20070522.jar,../mo dules/cglib-nodep-2.2/cglib-nodep-2.2.jar,../modules/tuscany-interfac e-java-xml-2.0-SNAPSHOT.jar,../modules/tuscany-databinding-2.0-SNAPSH OT.jar,../modules/tuscany-node-launcher-2.0-SNAPSHOT.jar,../modules/t uscany-implementation-java-2.0-SNAPSHOT.jar,../modules/tuscany-contri bution-2.0-SNAPSHOT.jar,../modules/tuscany-core-2.0-SNAPSHOT.jar,../m odules/tuscany-definitions-2.0-SNAPSHOT.jar,../modules/asm-all-3.1.ja r,../modules/tuscany-xsd-2.0-SNAPSHOT.jar,../modules/tuscany-node-imp l-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-java-2.0-SNAPSHOT. jar,../modules/tuscany-implementation-node-2.0-SNAPSHOT.jar,../module s/tuscany-extensibility-2.0-SNAPSHOT.jar,../modules/tuscany-implement ation-java-runtime-2.0-SNAPSHOT.jar,../modules/tuscany-extensibility- equinox-2.0-SNAPSHOT.jar,../modules/tuscany-node-api-2.0-SNAPSHOT.jar ,../modules/tuscany-workspace-2.0-SNAPSHOT.jar,../modules/jaxws-api-2 .1/jaxws-api-2.1.jar,../modules/tuscany-endpoint-2.0-SNAPSHOT.jar,../ modules/servlet-api-2.5/servlet-api-2.5.jar,../modules/tuscany-core-d atabinding-2.0-SNAPSHOT.jar,../modules/tuscany-contribution-xml-2.0-S NAPSHOT.jar,../modules/tuscany-assembly-2.0-SNAPSHOT.jar,../modules/t uscany-assembly-xsd-2.0-SNAPSHOT.jar,../modules/wsdl4j-1.6.2/wsdl4j-1 .6.2.jar,../modules/osgi-3.3.0-v20070530.jar,../modules/tuscany-imple mentation-java-xml-2.0-SNAPSHOT.jar,../modules/jaxb-impl-2.1.9/jaxb-i mpl-2.1.9.jar,../modules/tuscany-binding-sca-2.0-SNAPSHOT.jar,../modu les/tuscany-interface-java-2.0-SNAPSHOT.jar,../modules/tuscany-xsd-xm l-2.0-SNAPSHOT.jar,../modules/app-1.0.0-v20070606.jar From: ant elder Sent: Wednesday, January 21, 2009 1:36 AM To: [email protected] Subject: Re: [2.0] Align samples with the distributions On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <[email protected]> wrote: Hi, More comments inline. Thanks, Raymond From: Simon Laws Sent: Tuesday, January 20, 2009 8:41 AM To: [email protected] Subject: Re: [2.0] Align samples with the distributions Agreed. It's just a local repo. Do you think adding a little structure add technical difficulty or is a flat structure a personal preference? I'm interested in situations like this where we have some people who want solution A and others want solution B (where both solutions are valid). How do we come to a conclusion? In the past this has tended to stall us a little so this is a good chance to see if we can do better;-) I'm seeing some technical issues: 1) Adding a little structure will make the distribution incompatible with Equinox OSGi launcher and PDE target platform. I believe this is a statement about how it works just now rather than a statement about blockers for change. I more view it as a block for introducing structural changes. The current layout can be directly used as an Equinox installation of bundles or PDE target location. That seems like FUD to me, I don't see any reason it can't be made to work with either structure. This seems to be the main objection so if we can show it can work then can we lay this debate to rest? ...ant I had planned to use the manfiest as the compile dependency in sample ant scripts. It seems a useful shorthand to describe a feature. What i'm not understanding is why you'd want a compile dependency on a "feature"? I can see you might want tot use the specific dependencies you know you need, or use wildcards to add all the jars in a folder, or use a launcher to manage the dependencies for you. But as a feature includes multiple different extension types why would you want to use it as a dependency? ...ant "But as a feature includes multiple different extension types why would you want to use it as a dependency? " Well it depends what you think a feature is. Some here think features have lots of things in them, others think they could have a few things in them. I fall into the latter category. Some people think that features should be separately distributable some think that people will mostly want the all jar. Again I fall into the latter category but I would like to build the all jar out of a separate set of features rather than all the individual jars. Why do I want to do that? So that I can refer to individual features from my Ant scripts. Simon I've understood we've been using the term "feature" to mean the collection of distributions as was done in the equinox fork. If we change the term to mean something thats more tightly coupled to each individual extension that starts to make more sense to me. I'd still wonder if we really need them if we change to using a launcher, and if we had a structured lib folder then there doesn't seem any need at all. So what a proposal could be for 2.0 M1 would be have a single "all" type distribution thats just like the 1.x distribution but instead of a single tuscany-all jar and manifest jar have multiple manifest jars for each extension (or group of extensions if there are some really tightly coupled ones). ...ant Sounds good to me. It gives us a place to start so we can establish how each type of user we anticipate will exploit the distribution. Doing this will hopefully give us a more complete view. So how about we set this up, close this thread and start a new thread(s) to discuss how each of the different launching options we have already started to discuss will work. Simon Ok if i don't hear any objections I'll start doing this first thing next week. ...ant
