On Jan 23, 2008 6:24 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> 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. > > 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 > > - (B from your list) as it's a lighter variation of (A) that'll work > with Web containers that support shared libraries. > > - (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)? > > -- > Jean-Sebastien > The (F), (G) and (H) would use the packaging in your (B). For your (B) how/where were you expecting those sca contribution jars to get used? ...ant
