On Sat, Jan 24, 2009 at 4:35 PM, Raymond Feng <[email protected]> wrote:
> a) I'm really puzzled. Have you ever looked into the "all" distribution > that the current code produces? I don't see big difference than what you > have said on the ML. > > 1) It's similar with the 1.x all-in-one distribution without the > tuscany-all jar > 2) 3rd-party non-OSGi jars are placed under individual folders to form > OSGi bundles > 3) Instead of one manifest.jar, it comes with multiple > tuscany-distribution-* folders that group the manifest.jar and osgi > configurations for a collection of functions. > > We now build the "all" distribution based on "core" and "ejava". And I also > mentioned in the PDF doc that we will only ship the "all" distro for 2.x M1. > > PLEASE elaborate what you are not happy with the "all" distro. I might have > missed or misunderstood the points. > > b) I'm sad too. It seems that my hours of work warrants some critics based > a misinterpretation on a smiley without good facts. I really meant to > welcome feedbacks from the community with the smiley. > > Thanks, > Raymond > > From: ant elder > Sent: Saturday, January 24, 2009 1:15 AM > To: [email protected] > Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples > with the distributions > > > > That seems to ignore what we agreed and has been said on the threads about > this, and i guess you know that as you said "(IMO :-)". Sad that flouting > consensus warrants a smiley. > > ...ant > > > On Fri, Jan 23, 2009 at 5:25 PM, Raymond Feng <[email protected]> wrote: > > 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 > 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. Looking through the distribuion I have some questions/comments; - why "ejava"? Any relation to [1]:-) - 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. - 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'll post more as they come to mind. Simon [1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html
