----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, January 23, 2008 10:24 AM
Subject: Re: SCA contribution packaging schemes: was: SCA runtimes
ant elder wrote:
On Jan 21, 2008 9:31 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
Simon Nash wrote:
>> Jean-Sebastien Delfino wrote:
- Under which circumstances does the app packager want to package the
Tuscany and dependency JARs with the application artifacts.
[snip]
With a big topic like this, dividing it into separate threads makes it
easier for people to follow and participate in the discussions. The
split you are suggesting looks good to me.
[snip]
Trying to address "Under which circumstances does the app packager want
to package the Tuscany and dependency JARs with the application
artifacts?"
My (maybe simplistic) view is:
A) We can package in a WAR:
- several SCA contributions JARs
- any SCA deployment composites
- the required API JARs
- the required Tuscany JARs and runtime dependency JARs
This allows deployment of an SCA/Tuscany based solution to JEE Web
containers without requiring any system configuration or software
installation besides the Webapp.
There are some basic architectural limitations to that scheme:
- no good support for other bindings than HTTP based bindings
- footprint issue with every Webapp packaging the whole runtime
Also we're not quite there yet as I don't think we support:
- several SCA contributions in the packaged solution
- SCA deployment composites
B) Package SCA contributions as simple JARs, containing only the
application artifacts (no API JARs, no runtime dependency JARs).
Packaging SCA contributions as OSGi bundles is a variation of the same
scheme.
Any thoughts?
What other packaging schemes do people want to support and when?
--
Jean-Sebastien
Here's all the options I can think of:
A) - app dependencies and tuscany and its dependencies in web-inf/lib
B) - app dependencies in web-inf/lib, tuscany and its dependencies in
container shared library (geronimo/websphere/..)
C) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany
and
its dependencies in web-inf/tuscany (to issolate tuscany from app CL)
D) - app dependencies and tuscany bootstrap jar in web-inf/lib, tuscany
and
its dependencies in folder outside of webapp ie c:/Tuscany/lib
E) - app dependencies in web-inf/lib, tuscany using deep integration in
container (tomcat/geronimo/...)
F) - all tuscany and its dependencies in web-inf/lib, app (sca
contributions) in web-inf/sca-contributions
G) - all tuscany and its dependencies in web-inf/lib, app (sca
contributions) outside of webapp ie c:/MySCAContributions
H) - tuscany using deep integration in container (tomcat/geronimo/...),
app's (sca contributions) in folder in container, ie
c:/apache-tomcat-6.0.10
/SCAContributions
Are there any other configurations anyone can think of?
Most of our webapp samples today use (A) but we've code scattered about
SVN
and SVN history that do most of the others.
(C) and (D) is what i think was being suggested by Simon Nash in [1].
The app can see the Tuscany classes and dependencies with (A) and (B)
which
we were trying to avoid at one point.
(B) (D) (E) and (H) reduce the size of the application as Tuscany is
outside
of the webapp but that requires an extra install step
(G) (and F) is what I think users were interested in doing in
TUSCANY-1884
and [2]
So its just a matter of deciding which we want to support and distribute
:)
As everyone seems to have different ideas about whats important I'm
tempted
to say lets try to support all of these for now so we play around and see
which we think are really useful. How to distribute each option could be
left to another thread.
...ant
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200801.mbox/[EMAIL
PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200710.mbox/[EMAIL
PROTECTED]
I don't think that "support all of these" is such a good idea as it will
create complexity, but people are welcome to work on them if they want to
spend the time.
+1 to start with only a few options. I have to admit that I will be
overhelmed by so many choices.
I'm interested in working on providing simple and usable support for:
- (A) as it's a simple scheme that'll work with all Web containers
+1.
- (B from your list) as it's a lighter variation of (A) that'll work with
Web containers that support shared libraries.
+1. I already experimented it with Geronimo and it works fine.
- (B from my list) as it's in line with the SCA spec and keeps runtime
specifics out of the application package.
I'm not quite sure how to map my option (B) to your options (F), (G), (H).
What will the packaging of an SCA contribution look like in your options
(F), (G), (H)?
My understanding is that F/G/H have the same packaging scheme as Sebstien's
B, i.e., a place to get a list of installed contributions. What's left is
how the hosting environment manage the contributions and composites to form
a SCA domain (list/install/uninstall contributions, list/start/stop
deployable composites).
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
