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
