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
