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: [email protected]
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 <[email protected]> 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: [email protected]
Subject: Re: [2.0] Align samples with the distributions
On Fri, Jan 23, 2009 at 9:58 AM, Simon Laws <[email protected]>
wrote:
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
Ok if i don't hear any objections I'll start doing this first thing next
week.
...ant
