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
