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
