You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/01/23 18:25:13 UTC
[2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions
Hi,
I have made some good progress (IMO :-) to bring up the distribution story in 2.x toward M1. The current "all" distribution contains "core" and "ejava" (binding.rmi only). You can try to build it with the following command:
cd sca/distribution
mvn clean install -Pdistribution
Please build the tools and modules first. tuscany-maven-bundle-plugin is used to produce some parts of the distribution.
The current story is documented at [1].
Feedbacks are welcome.
[1] http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1
Thanks,
Raymond
From: ant elder
Sent: Friday, January 23, 2009 2:03 AM
To: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions
On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com> wrote:
On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:
On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com> wrote:
On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:
On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com> wrote:
On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> 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 <en...@gmail.com> 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: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions
On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
More comments inline.
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, January 20, 2009 8:41 AM
To: dev@tuscany.apache.org
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
Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
with the distributions
Posted by ant elder <an...@gmail.com>.
On Tue, Jan 27, 2009 at 10:27 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>>
>>
>> From: Simon Laws
>> Sent: Monday, January 26, 2009 7:00 AM
>> To: dev@tuscany.apache.org
>> Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align
>> samples with the distributions
>>
>>
>> [[snip]]
>>
>> Hi
>>
>> I'm adding the three samples I've been playing with to the build and the
>> distribution so we can experiment with the process/scripts. I'd like to
>> exploit M1 to get the process a slick as we can while we have a small number
>> of modules. The binding-ws-calculator and host-webapp-calculator samples
>> don't actually work yet as samples. The related function still needs some
>> work.
>>
>> +1 to use samples to validate the distribution structure and grouping.
>>
>> Looking through the distribuion I have some questions/comments;
>>
>> - why "ejava"? Any relation to [1]:-)
>>
>> "ejava" stands for "Enterprise Java". It will potentially include
>> Enterprise Java related pieces such as binding.rmi, binding.ejb,
>> binding.jms, implementation.ejb, implementation.web etc.
>>
>> - How to get hold of the list of jars for a given feature so that I can
>> build a war including the minimum set of jars. It could be an option if the
>> war just referenced an external tuscany distribution but users may not have
>> the option to install one so we probably still need to include the runtime
>> in the war. Is there a trick to extract this info from a manifest. I'd
>> rather not generate another ant script with that info if we can avoid it.
>>
>> How do you produce the WAR file? If you are using maven, then you can add
>> the dependency to the distribution pom project, such as
>> tuscany-distribution-core:pom. For ANT, it's typically done via the war ant
>> task which has the lib element that defines a fileSet. We can easily
>> generate something like modules.lst for each distribution for easy parsing.
>>
>
> Currently I just include everything in modules which is not ideal...
>
> <fileset id="tuscany.jars" dir="${distro.root}/modules">
> <include name="*.jar" />
> <include name="*/*.jar" />
> </fileset>
> <war destfile="${sample.war}"
> webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml">
> <fileset dir="${sample.root}/src/main/webapp"/>
> <lib refid="tuscany.jars"/>
> <classes dir="${sample.root}/target/classes"/>
> </war>
>
> If we want to allow people to build wars from ant scripts then we need to
> have a way for building a lib path from selected features. An alternative is
> to say that people can;t do this with ant but need to use maven to build
> wars and use the maven dependencies. A step back from what we have in 1.x
> though so I'd rather we continue to support any compiles in this case.
>
That seems to be getting to the root of what this is about - how to best
support building webapps with Ant - or more generally - how can people not
using Maven know what Tuscany jars and dependencies they need to be using.
There's lots a different ways we could do that, from just manually
documenting it in a text file to using custom plugins to generate lists. If
we seperate that from what the distributions look like it may help to see
what the best options are.
> We could generate the "fileset" for each feature an maybe this is the
> easiest way but I was interested to know if you had something in mind
> without generating more files.
>
>
>> - tuscany-distribution-ejava etc. This is a question about naming really.
>> I'm undecided as to whether we should actually distribute these things but I
>> am very keen that our distribution(s) are structured so that people can
>> depend on sensible chunks of function rather than all of it. Do we
>> anticipate that there will be groups of function here that aren't named
>> distribution, e.g. tuscany-extension-implementation-bpel or
>> tuscany-extension-binding-jms so that people can include manifests for
>> individual extensions rather than larger groups of them?
>> I think it's about granularity and different combinations of functional
>> modules. Tuscany can only ship a limited number of distros. If we get
>> the technique very simple to declare a "feature", then we can potentially
>> make many configurations available. With what we have, "feature" can extend
>> from one or more features and features can also have overlaps. In fact, we
>> don't have to build a distro for every single feature we define. We can have
>> much less distros than features. For example, one "all" distro can have
>> configurations for "core", "ejava", "webservice" features.
>>
>
> I agree that the idea of having groups of jars represented in the all
> distribrio and the though that these groups might be separately distributed
> are different points.
>
Yes, and if we keep them separate then we can decouple the two and that will
help find good solutions for each. And I think we're all starting to agree
on this and its whats being suggested over on the point 2 in this post:
http://apache.markmail.org/message/2vumrlwjr7ylu3zp
...ant
Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions
Posted by Raymond Feng <en...@gmail.com>.
A quick update:
1) I add a flag to control if we generate the distro-specific configuration files or manifest.jar at the top level or under the name of the distro
2) I add the code to generate the build-path.xml which can be directly included into the sample build.xml
3) I add a bit logic to name the distro folder as feature-<xyz> instead of tuscany-distribution-<xyz>.
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, January 27, 2009 2:27 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions
On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
Please see my comments inline.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, January 26, 2009 7:00 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions
[[snip]]
Hi
I'm adding the three samples I've been playing with to the build and the distribution so we can experiment with the process/scripts. I'd like to exploit M1 to get the process a slick as we can while we have a small number of modules. The binding-ws-calculator and host-webapp-calculator samples don't actually work yet as samples. The related function still needs some work.
+1 to use samples to validate the distribution structure and grouping.
Looking through the distribuion I have some questions/comments;
- why "ejava"? Any relation to [1]:-)
"ejava" stands for "Enterprise Java". It will potentially include Enterprise Java related pieces such as binding.rmi, binding.ejb, binding.jms, implementation.ejb, implementation.web etc.
- How to get hold of the list of jars for a given feature so that I can build a war including the minimum set of jars. It could be an option if the war just referenced an external tuscany distribution but users may not have the option to install one so we probably still need to include the runtime in the war. Is there a trick to extract this info from a manifest. I'd rather not generate another ant script with that info if we can avoid it.
How do you produce the WAR file? If you are using maven, then you can add the dependency to the distribution pom project, such as tuscany-distribution-core:pom. For ANT, it's typically done via the war ant task which has the lib element that defines a fileSet. We can easily generate something like modules.lst for each distribution for easy parsing.
Currently I just include everything in modules which is not ideal...
<fileset id="tuscany.jars" dir="${distro.root}/modules">
<include name="*.jar" />
<include name="*/*.jar" />
</fileset>
<war destfile="${sample.war}" webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml">
<fileset dir="${sample.root}/src/main/webapp"/>
<lib refid="tuscany.jars"/>
<classes dir="${sample.root}/target/classes"/>
</war>
If we want to allow people to build wars from ant scripts then we need to have a way for building a lib path from selected features. An alternative is to say that people can;t do this with ant but need to use maven to build wars and use the maven dependencies. A step back from what we have in 1.x though so I'd rather we continue to support any compiles in this case. We could generate the "fileset" for each feature an maybe this is the easiest way but I was interested to know if you had something in mind without generating more files.
- tuscany-distribution-ejava etc. This is a question about naming really. I'm undecided as to whether we should actually distribute these things but I am very keen that our distribution(s) are structured so that people can depend on sensible chunks of function rather than all of it. Do we anticipate that there will be groups of function here that aren't named distribution, e.g. tuscany-extension-implementation-bpel or tuscany-extension-binding-jms so that people can include manifests for individual extensions rather than larger groups of them?
I think it's about granularity and different combinations of functional modules. Tuscany can only ship a limited number of distros. If we get the technique very simple to declare a "feature", then we can potentially make many configurations available. With what we have, "feature" can extend from one or more features and features can also have overlaps. In fact, we don't have to build a distro for every single feature we define. We can have much less distros than features. For example, one "all" distro can have configurations for "core", "ejava", "webservice" features.
I agree that the idea of having groups of jars represented in the all distribrio and the though that these groups might be separately distributed are different points. I think we need to try different granularity of groups to see what works. The smallest granularity is propably an extension and multiple extensions in a group produce the "features" that are in svn now.
I'll post more as they come to mind.
Simon
[1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html
Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
with the distributions
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jan 26, 2009 at 8:13 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
>
> From: Simon Laws
> Sent: Monday, January 26, 2009 7:00 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
> with the distributions
>
>
> [[snip]]
>
> Hi
>
> I'm adding the three samples I've been playing with to the build and the
> distribution so we can experiment with the process/scripts. I'd like to
> exploit M1 to get the process a slick as we can while we have a small number
> of modules. The binding-ws-calculator and host-webapp-calculator samples
> don't actually work yet as samples. The related function still needs some
> work.
>
> +1 to use samples to validate the distribution structure and grouping.
>
> Looking through the distribuion I have some questions/comments;
>
> - why "ejava"? Any relation to [1]:-)
>
> "ejava" stands for "Enterprise Java". It will potentially include
> Enterprise Java related pieces such as binding.rmi, binding.ejb,
> binding.jms, implementation.ejb, implementation.web etc.
>
> - How to get hold of the list of jars for a given feature so that I can
> build a war including the minimum set of jars. It could be an option if the
> war just referenced an external tuscany distribution but users may not have
> the option to install one so we probably still need to include the runtime
> in the war. Is there a trick to extract this info from a manifest. I'd
> rather not generate another ant script with that info if we can avoid it.
>
> How do you produce the WAR file? If you are using maven, then you can add
> the dependency to the distribution pom project, such as
> tuscany-distribution-core:pom. For ANT, it's typically done via the war ant
> task which has the lib element that defines a fileSet. We can easily
> generate something like modules.lst for each distribution for easy parsing.
>
Currently I just include everything in modules which is not ideal...
<fileset id="tuscany.jars" dir="${distro.root}/modules">
<include name="*.jar" />
<include name="*/*.jar" />
</fileset>
<war destfile="${sample.war}"
webxml="${sample.root}/src/main/webapp/WEB-INF/web.xml">
<fileset dir="${sample.root}/src/main/webapp"/>
<lib refid="tuscany.jars"/>
<classes dir="${sample.root}/target/classes"/>
</war>
If we want to allow people to build wars from ant scripts then we need to
have a way for building a lib path from selected features. An alternative is
to say that people can;t do this with ant but need to use maven to build
wars and use the maven dependencies. A step back from what we have in 1.x
though so I'd rather we continue to support any compiles in this case. We
could generate the "fileset" for each feature an maybe this is the easiest
way but I was interested to know if you had something in mind without
generating more files.
> - tuscany-distribution-ejava etc. This is a question about naming really.
> I'm undecided as to whether we should actually distribute these things but I
> am very keen that our distribution(s) are structured so that people can
> depend on sensible chunks of function rather than all of it. Do we
> anticipate that there will be groups of function here that aren't named
> distribution, e.g. tuscany-extension-implementation-bpel or
> tuscany-extension-binding-jms so that people can include manifests for
> individual extensions rather than larger groups of them?
> I think it's about granularity and different combinations of functional
> modules. Tuscany can only ship a limited number of distros. If we get
> the technique very simple to declare a "feature", then we can potentially
> make many configurations available. With what we have, "feature" can extend
> from one or more features and features can also have overlaps. In fact, we
> don't have to build a distro for every single feature we define. We can have
> much less distros than features. For example, one "all" distro can have
> configurations for "core", "ejava", "webservice" features.
>
I agree that the idea of having groups of jars represented in the all
distribrio and the though that these groups might be separately distributed
are different points. I think we need to try different granularity of groups
to see what works. The smallest granularity is propably an extension and
multiple extensions in a group produce the "features" that are in svn now.
> I'll post more as they come to mind.
>
> Simon
>
> [1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html<http://cs.joensuu.fi/%7Ejeliot/help/EJava/EJava-language.html>
>
Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments inline.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, January 26, 2009 7:00 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions
[[snip]]
Hi
I'm adding the three samples I've been playing with to the build and the distribution so we can experiment with the process/scripts. I'd like to exploit M1 to get the process a slick as we can while we have a small number of modules. The binding-ws-calculator and host-webapp-calculator samples don't actually work yet as samples. The related function still needs some work.
+1 to use samples to validate the distribution structure and grouping.
Looking through the distribuion I have some questions/comments;
- why "ejava"? Any relation to [1]:-)
"ejava" stands for "Enterprise Java". It will potentially include Enterprise Java related pieces such as binding.rmi, binding.ejb, binding.jms, implementation.ejb, implementation.web etc.
- How to get hold of the list of jars for a given feature so that I can build a war including the minimum set of jars. It could be an option if the war just referenced an external tuscany distribution but users may not have the option to install one so we probably still need to include the runtime in the war. Is there a trick to extract this info from a manifest. I'd rather not generate another ant script with that info if we can avoid it.
How do you produce the WAR file? If you are using maven, then you can add the dependency to the distribution pom project, such as tuscany-distribution-core:pom. For ANT, it's typically done via the war ant task which has the lib element that defines a fileSet. We can easily generate something like modules.lst for each distribution for easy parsing.
- tuscany-distribution-ejava etc. This is a question about naming really. I'm undecided as to whether we should actually distribute these things but I am very keen that our distribution(s) are structured so that people can depend on sensible chunks of function rather than all of it. Do we anticipate that there will be groups of function here that aren't named distribution, e.g. tuscany-extension-implementation-bpel or tuscany-extension-binding-jms so that people can include manifests for individual extensions rather than larger groups of them?
I think it's about granularity and different combinations of functional modules. Tuscany can only ship a limited number of distros. If we get the technique very simple to declare a "feature", then we can potentially make many configurations available. With what we have, "feature" can extend from one or more features and features can also have overlaps. In fact, we don't have to build a distro for every single feature we define. We can have much less distros than features. For example, one "all" distro can have configurations for "core", "ejava", "webservice" features.
I'll post more as they come to mind.
Simon
[1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html
Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
with the distributions
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Jan 24, 2009 at 4:35 PM, Raymond Feng <en...@gmail.com> wrote:
> a) I'm really puzzled. Have you ever looked into the "all" distribution
> that the current code produces? I don't see big difference than what you
> have said on the ML.
>
> 1) It's similar with the 1.x all-in-one distribution without the
> tuscany-all jar
> 2) 3rd-party non-OSGi jars are placed under individual folders to form
> OSGi bundles
> 3) Instead of one manifest.jar, it comes with multiple
> tuscany-distribution-* folders that group the manifest.jar and osgi
> configurations for a collection of functions.
>
> We now build the "all" distribution based on "core" and "ejava". And I also
> mentioned in the PDF doc that we will only ship the "all" distro for 2.x M1.
>
> PLEASE elaborate what you are not happy with the "all" distro. I might have
> missed or misunderstood the points.
>
> b) I'm sad too. It seems that my hours of work warrants some critics based
> a misinterpretation on a smiley without good facts. I really meant to
> welcome feedbacks from the community with the smiley.
>
> Thanks,
> Raymond
>
> From: ant elder
> Sent: Saturday, January 24, 2009 1:15 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
> with the distributions
>
>
>
> That seems to ignore what we agreed and has been said on the threads about
> this, and i guess you know that as you said "(IMO :-)". Sad that flouting
> consensus warrants a smiley.
>
> ...ant
>
>
> On Fri, Jan 23, 2009 at 5:25 PM, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> I have made some good progress (IMO :-) to bring up the distribution story
> in 2.x toward M1. The current "all" distribution contains "core" and "ejava"
> (binding.rmi only). You can try to build it with the following command:
>
> cd sca/distribution
> mvn clean install -Pdistribution
>
> Please build the tools and modules first. tuscany-maven-bundle-plugin is
> used to produce some parts of the distribution.
>
> The current story is documented at [1].
>
> Feedbacks are welcome.
>
> [1]
> http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1
>
> Thanks,
> Raymond
>
>
> From: ant elder
> Sent: Friday, January 23, 2009 2:03 AM
> To: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
>
>
>
> On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> 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 <en...@gmail.com> 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: dev@tuscany.apache.org
> Subject: Re: [2.0] Align samples with the distributions
>
>
>
>
>
> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> More comments inline.
>
> Thanks,
> Raymond
>
>
> From: Simon Laws
> Sent: Tuesday, January 20, 2009 8:41 AM
> To: dev@tuscany.apache.org
> 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
>
Hi
I'm adding the three samples I've been playing with to the build and the
distribution so we can experiment with the process/scripts. I'd like to
exploit M1 to get the process a slick as we can while we have a small number
of modules. The binding-ws-calculator and host-webapp-calculator samples
don't actually work yet as samples. The related function still needs some
work.
Looking through the distribuion I have some questions/comments;
- why "ejava"? Any relation to [1]:-)
- How to get hold of the list of jars for a given feature so that I can
build a war including the minimum set of jars. It could be an option if the
war just referenced an external tuscany distribution but users may not have
the option to install one so we probably still need to include the runtime
in the war. Is there a trick to extract this info from a manifest. I'd
rather not generate another ant script with that info if we can avoid it.
- tuscany-distribution-ejava etc. This is a question about naming really.
I'm undecided as to whether we should actually distribute these things but I
am very keen that our distribution(s) are structured so that people can
depend on sensible chunks of function rather than all of it. Do we
anticipate that there will be groups of function here that aren't named
distribution, e.g. tuscany-extension-implementation-bpel or
tuscany-extension-binding-jms so that people can include manifests for
individual extensions rather than larger groups of them?
I'll post more as they come to mind.
Simon
[1] http://cs.joensuu.fi/~jeliot/help/EJava/EJava-language.html
Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples with the distributions
Posted by Raymond Feng <en...@gmail.com>.
a) I'm really puzzled. Have you ever looked into the "all" distribution that
the current code produces? I don't see big difference than what you have
said on the ML.
1) It's similar with the 1.x all-in-one distribution without the
tuscany-all jar
2) 3rd-party non-OSGi jars are placed under individual folders to form
OSGi bundles
3) Instead of one manifest.jar, it comes with multiple
tuscany-distribution-* folders that group the manifest.jar and osgi
configurations for a collection of functions.
We now build the "all" distribution based on "core" and "ejava". And I also
mentioned in the PDF doc that we will only ship the "all" distro for 2.x M1.
PLEASE elaborate what you are not happy with the "all" distro. I might have
missed or misunderstood the points.
b) I'm sad too. It seems that my hours of work warrants some critics based a
misinterpretation on a smiley without good facts. I really meant to welcome
feedbacks from the community with the smiley.
Thanks,
Raymond
From: ant elder
Sent: Saturday, January 24, 2009 1:15 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
with the distributions
That seems to ignore what we agreed and has been said on the threads about
this, and i guess you know that as you said "(IMO :-)". Sad that flouting
consensus warrants a smiley.
...ant
On Fri, Jan 23, 2009 at 5:25 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
I have made some good progress (IMO :-) to bring up the distribution story
in 2.x toward M1. The current "all" distribution contains "core" and "ejava"
(binding.rmi only). You can try to build it with the following command:
cd sca/distribution
mvn clean install -Pdistribution
Please build the tools and modules first. tuscany-maven-bundle-plugin is
used to produce some parts of the distribution.
The current story is documented at [1].
Feedbacks are welcome.
[1]
http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1
Thanks,
Raymond
From: ant elder
Sent: Friday, January 23, 2009 2:03 AM
To: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions
On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com>
wrote:
On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:
On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>
wrote:
On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org> wrote:
On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <si...@googlemail.com>
wrote:
On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com> 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 <en...@gmail.com> 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: dev@tuscany.apache.org
Subject: Re: [2.0] Align samples with the distributions
On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
More comments inline.
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, January 20, 2009 8:41 AM
To: dev@tuscany.apache.org
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
Re: [2.x] 2.x M1 distribution update, was: Re: [2.0] Align samples
with the distributions
Posted by ant elder <an...@gmail.com>.
That seems to ignore what we agreed and has been said on the threads about
this, and i guess you know that as you said "(IMO :-)". Sad that flouting
consensus warrants a smiley.
...ant
On Fri, Jan 23, 2009 at 5:25 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I have made some good progress (IMO :-) to bring up the distribution story
> in 2.x toward M1. The current "all" distribution contains "core" and "ejava"
> (binding.rmi only). You can try to build it with the following command:
>
> cd sca/distribution
> mvn clean install -Pdistribution
>
> Please build the tools and modules first. tuscany-maven-bundle-plugin is
> used to produce some parts of the distribution.
>
> The current story is documented at [1].
>
> Feedbacks are welcome.
>
> [1]
> http://cwiki.apache.org/confluence/download/attachments/108385/Tuscany+Distribution.pdf?version=1
>
> Thanks,
> Raymond
>
> *From:* ant elder <an...@apache.org>
> *Sent:* Friday, January 23, 2009 2:03 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: [2.0] Align samples with the distributions
>
>
>
> On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 11:59 AM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Thu, Jan 22, 2009 at 11:34 AM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 22, 2009 at 11:14 AM, ant elder <an...@apache.org>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 22, 2009 at 10:20 AM, Simon Laws <
>>>>> simonslaws@googlemail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 22, 2009 at 6:44 AM, ant elder <an...@gmail.com>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 <en...@gmail.com>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: dev@tuscany.apache.org
>>>>>>>> Subject: Re: [2.0] Align samples with the distributions
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 20, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> More comments inline.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Raymond
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Simon Laws
>>>>>>>> Sent: Tuesday, January 20, 2009 8:41 AM
>>>>>>>> To: dev@tuscany.apache.org
>>>>>>>> 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
>