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 <[email protected]> > *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 >
