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
