Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Nash <na...@hursley.ibm.com>]

I'm starting a new thread for this as suggested by Sebastien.

   Simon

Simon Laws wrote:

> On Nov 15, 2007 6:54 PM, Simon Nash <na...@hursley.ibm.com> wrote:
> 
> (cut)
>>
>>I don't think we should put sample dependencies in the bin distro lib
>>folder.  If we need to include them in the bin distro (and I'm not 100%
>>convinced about that), then I think they should go in some other
>>directory.
>>
>>An alternative approach would be to have a samples distro that contains
>>the samples plus dependencies that are only used by the samples and not
>>by the main runtime.  I think this is better as it allows us to add more
>>samples without pushing up the size of the main binary distro.
> 
> 
> Personally I like to see samples with whatever I download and I'd rather
> have a bigger binary distro than a separate download. If there is a real
> need to reduce the distribution size can we do it in a different way, for
> example, have groups of extensions (and their samples) distributed
> separately?
> 
Samples are very important for beginning users.  For users who have
moved beyond that stage and are doing real development using Tuscany,
samples are not very important.  If people in this category do want
samples, they are likely to just want to refer to samples source code
to cut and paste snippets as necessary.  Having pre-built sample binaries
isn't important for these users, and having the main lib directory
polluted/bloated by samples dependencies is a positive nuisance because
there's no easy way for them to find and remove the redundant files.

Having these files in Tuscany's lib directory isn't just wasting a few
bits on the disk.  It can be a problem if their version levels conflict
with other versions of the same code that the user has installed.
For "genuine" Tuscany dependencies, such conflicts are a real issue
that must be handled carefully in order to get Tuscany to co-exist with
their other software.  For sample dependencies, there is no actual
conflict unless the user needs to run the specific sample that pulled
in the dependency, but it might take them some time to figure out why
putting the Tuscany lib directory on the classpath is causing other
code in their application to break.

I'd suggest structuring the binary distribution as follows:

1. Tuscany runtime in "modules" and its dependencies in "lib".
    At the moment we have separate copies of the Tuscany runtime in
    "modules" and "lib" and I'm not quite sure why.
2. Tuscany samples source, READMEs and build files in "samples".
3. Tuscany samples binaries in "modules/samples", with their
    dependencies in "lib/samples".

By doing this we solve the conflict problems and it becomes a distro
size issue to decide whether 3 should be in the main binary distro
or available separately.  Since 3 will be clearly separated from 1
and 2, it will be easy to see how much extra size it is contributing.

The other dimension of splitting the distro by functional contents
is orthogonal to the above and is also worth exploring.  I'd suggest
the following distro packages:

1. Base runtime with functional capabilities that almost everyone
    will want to use, and associated samples.
2. A number of extension bundles (either depending only on the base,
    or possibly depending on other bundles), and associated samples.

If people think this approach makes sense then we could talk about
what the base distro and extension bundles should contain.

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[shaoguang geng <ge...@yahoo.com>]

Hi,
I recently read the article on osoa.org: 《Power_Combination_SCA_Spring_OSGi.pdf》
This article gave great impression to me(and my colleague).

So I think here making Tuscany an osgi based container, will boost Tuscany onto a new era.

I think from the architect view of Tuscany, it is very robust to get leveraged into an osgi runtime.

Jean-Sebastien Delfino <js...@apache.org> wrote: Rajini Sivaram wrote:
> Sebastien,
> 
> 
> We would like to enable a binary Tuscany distribution to run under OSGi. I
> am not sure of the level of granularity at which a bundle-ized Tuscany makes
> sense in terms of providing modularity and versioning using OSGi. But I
> would like to make sure that the bundles from the list below can be run in
> some form under OSGi.
> 
> The big difference between packaging for OSGi and standard jars (apart from
> the additional entries in the manifest) is that OSGi bundle classpath can
> only refer to entries inside the bundle, while standard Jar classpath can
> only refer to jars outside the jar file without a customized classloader.
> 
> I currently have Tuscany loaded into OSGi in two different ways. The first
> is a small list of large bundles (all 3rd party jars are grouped together),
> which are explicitly installed by an application that uses Tuscany. And the
> second is a large list of small bundles (each 3rd party jar is retained as a
> single bundle), loaded using OSGi bundle repository (OBR). Tuscany runtime
> and the required Tuscany extensions are installed by the application, the
> 3rd party jars are automatically installed by OBR.
> 
> I am not sure how big each of the bundles you have listed below will be, and
> also what the relative size of the samples would be compared to the bundle
> itself. But I imagine that the easiest way to bundle these for OSGi would be
> to create each of these as a single OSGi bundle. I would like to add
> META-INF/MANIFEST.MF with OSGi import/export headers and an OSGi
> Bundle-ClassPath to the zip/jar file corresponding to the bundle. This is to
> enable a very coarsely grained set of bundles that can be easily installed
> by an OSGi application. The additional manifest file will not impact
> non-OSGi applications. By default, Tuscany will be run without OSGi, and the
> zip file corresponding to the bundle will need to be unzipped first (no
> change). To run Tuscany under OSGi, the zip file can be installed directly
> into OSGi.
> 
> I would also like to enable finer grained OSGi bundles which can be
> installed using OBR. For the all-in-one bundle, could we have OSGi manifest
> entries inserted into each of the jar files including Tuscany modules and
> 3rd party jars, so that the jars can be installed independently into OSGi?
> But this only makes sense if we can have separate jars for the Tuscany
> extensions, rather than a combined tuscany-all.jar (otherwise OBR will
> install all the 3rd party bundles when tuscany-all is installed). The base
> Tuscany runtime could either be a single jar, or with some more fixes for
> classloading, it could be multiple jars based on the maven modules. Again,
> the OSGi manifest entries will not impact non-OSGi Tuscany. The splitting of
> Tuscany jars also shouldn't have any impact since
> tuscany-sca-manifest.jarcan just point to the longer list of Tuscany
> jars instead of tuscany-all.
> 
> The third alternative is to have a separate set of jars, specifically
> targetted for OSGi-based Tuscany, which would be somewhere in between the
> coarsely grained first option and too finely grained second one. Rather than
> provide this as part of the binary distribution, this could be an optional
> build with the source distribution.
> 
> 
> Suggestions?
> 
> 
> Thank you...
> 
> Regards,
> 
> Rajini
> 

Sorry for the delay I missed this one between ApacheCon and some 
vacation last week.

It looks like you're now thinking about having:
- one bundle per Tuscany JAR
- some way to use 3rd party JARs from the bundles

which I think make sense and will allow us to better leverage OSGi for 
isolation, versioning etc.
-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org



       
---------------------------------
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Jean-Sebastien Delfino <js...@apache.org>]

Rajini Sivaram wrote:
> Sebastien,
> 
> 
> We would like to enable a binary Tuscany distribution to run under OSGi. I
> am not sure of the level of granularity at which a bundle-ized Tuscany makes
> sense in terms of providing modularity and versioning using OSGi. But I
> would like to make sure that the bundles from the list below can be run in
> some form under OSGi.
> 
> The big difference between packaging for OSGi and standard jars (apart from
> the additional entries in the manifest) is that OSGi bundle classpath can
> only refer to entries inside the bundle, while standard Jar classpath can
> only refer to jars outside the jar file without a customized classloader.
> 
> I currently have Tuscany loaded into OSGi in two different ways. The first
> is a small list of large bundles (all 3rd party jars are grouped together),
> which are explicitly installed by an application that uses Tuscany. And the
> second is a large list of small bundles (each 3rd party jar is retained as a
> single bundle), loaded using OSGi bundle repository (OBR). Tuscany runtime
> and the required Tuscany extensions are installed by the application, the
> 3rd party jars are automatically installed by OBR.
> 
> I am not sure how big each of the bundles you have listed below will be, and
> also what the relative size of the samples would be compared to the bundle
> itself. But I imagine that the easiest way to bundle these for OSGi would be
> to create each of these as a single OSGi bundle. I would like to add
> META-INF/MANIFEST.MF with OSGi import/export headers and an OSGi
> Bundle-ClassPath to the zip/jar file corresponding to the bundle. This is to
> enable a very coarsely grained set of bundles that can be easily installed
> by an OSGi application. The additional manifest file will not impact
> non-OSGi applications. By default, Tuscany will be run without OSGi, and the
> zip file corresponding to the bundle will need to be unzipped first (no
> change). To run Tuscany under OSGi, the zip file can be installed directly
> into OSGi.
> 
> I would also like to enable finer grained OSGi bundles which can be
> installed using OBR. For the all-in-one bundle, could we have OSGi manifest
> entries inserted into each of the jar files including Tuscany modules and
> 3rd party jars, so that the jars can be installed independently into OSGi?
> But this only makes sense if we can have separate jars for the Tuscany
> extensions, rather than a combined tuscany-all.jar (otherwise OBR will
> install all the 3rd party bundles when tuscany-all is installed). The base
> Tuscany runtime could either be a single jar, or with some more fixes for
> classloading, it could be multiple jars based on the maven modules. Again,
> the OSGi manifest entries will not impact non-OSGi Tuscany. The splitting of
> Tuscany jars also shouldn't have any impact since
> tuscany-sca-manifest.jarcan just point to the longer list of Tuscany
> jars instead of tuscany-all.
> 
> The third alternative is to have a separate set of jars, specifically
> targetted for OSGi-based Tuscany, which would be somewhere in between the
> coarsely grained first option and too finely grained second one. Rather than
> provide this as part of the binary distribution, this could be an optional
> build with the source distribution.
> 
> 
> Suggestions?
> 
> 
> Thank you...
> 
> Regards,
> 
> Rajini
> 

Sorry for the delay I missed this one between ApacheCon and some 
vacation last week.

It looks like you're now thinking about having:
- one bundle per Tuscany JAR
- some way to use 3rd party JARs from the bundles

which I think make sense and will allow us to better leverage OSGi for 
isolation, versioning etc.
-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Rajini Sivaram <ra...@googlemail.com>]

Sebastien,


We would like to enable a binary Tuscany distribution to run under OSGi. I
am not sure of the level of granularity at which a bundle-ized Tuscany makes
sense in terms of providing modularity and versioning using OSGi. But I
would like to make sure that the bundles from the list below can be run in
some form under OSGi.

The big difference between packaging for OSGi and standard jars (apart from
the additional entries in the manifest) is that OSGi bundle classpath can
only refer to entries inside the bundle, while standard Jar classpath can
only refer to jars outside the jar file without a customized classloader.

I currently have Tuscany loaded into OSGi in two different ways. The first
is a small list of large bundles (all 3rd party jars are grouped together),
which are explicitly installed by an application that uses Tuscany. And the
second is a large list of small bundles (each 3rd party jar is retained as a
single bundle), loaded using OSGi bundle repository (OBR). Tuscany runtime
and the required Tuscany extensions are installed by the application, the
3rd party jars are automatically installed by OBR.

I am not sure how big each of the bundles you have listed below will be, and
also what the relative size of the samples would be compared to the bundle
itself. But I imagine that the easiest way to bundle these for OSGi would be
to create each of these as a single OSGi bundle. I would like to add
META-INF/MANIFEST.MF with OSGi import/export headers and an OSGi
Bundle-ClassPath to the zip/jar file corresponding to the bundle. This is to
enable a very coarsely grained set of bundles that can be easily installed
by an OSGi application. The additional manifest file will not impact
non-OSGi applications. By default, Tuscany will be run without OSGi, and the
zip file corresponding to the bundle will need to be unzipped first (no
change). To run Tuscany under OSGi, the zip file can be installed directly
into OSGi.

I would also like to enable finer grained OSGi bundles which can be
installed using OBR. For the all-in-one bundle, could we have OSGi manifest
entries inserted into each of the jar files including Tuscany modules and
3rd party jars, so that the jars can be installed independently into OSGi?
But this only makes sense if we can have separate jars for the Tuscany
extensions, rather than a combined tuscany-all.jar (otherwise OBR will
install all the 3rd party bundles when tuscany-all is installed). The base
Tuscany runtime could either be a single jar, or with some more fixes for
classloading, it could be multiple jars based on the maven modules. Again,
the OSGi manifest entries will not impact non-OSGi Tuscany. The splitting of
Tuscany jars also shouldn't have any impact since
tuscany-sca-manifest.jarcan just point to the longer list of Tuscany
jars instead of tuscany-all.

The third alternative is to have a separate set of jars, specifically
targetted for OSGi-based Tuscany, which would be somewhere in between the
coarsely grained first option and too finely grained second one. Rather than
provide this as part of the binary distribution, this could be an optional
build with the source distribution.


Suggestions?


Thank you...

Regards,

Rajini


On 11/19/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Makes sense to me, I'd suggest the following packages:
> - base SCA runtime (assembly, policy fwk, impl-java)
> - web services package (ws binding + related databindings)
> - web 2.0 package (json, dwr, widget, atom, scripting)
> - data integration (impl-data, openjpa)
> - business process integration (bpel, xquery)
> - jee integration (ejb, jms, rmi)
> - spring + osgi integration (spring, osgi)
> - all-in-one, for people who don't have time to solve puzzles.
>
> Perhaps group web services and web 2.0 together, I'm not sure.
>
> Also I'm not sure about where to put policies like security,
> reliability, transactions.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[ant elder <an...@apache.org>]

On Nov 28, 2007 11:41 AM, Simon Laws <si...@googlemail.com> wrote:

> On Nov 28, 2007 10:24 AM, ant elder <an...@gmail.com> wrote:
>
> > On Nov 27, 2007 4:11 PM, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > >
> > > ant elder wrote:
> > >
> > > > On Nov 27, 2007 2:29 PM, Simon Laws <si...@googlemail.com>
> wrote:
> > > >
> > > >
> > > >>
> > > >>On Nov 27, 2007 2:25 PM, ant elder <an...@apache.org> wrote:
> > > >>
> > > >>
> > > >>>I've just committed a runtime-war module as a start of whats being
> > > >>>talked
> > > >>>about here, which could be merged or replace distribution/webapp at
> > > some
> > > >>>point. I'll post some more details later. One comment inline below:
> > > >>>
> > > >>>  ...ant
> > > >>>
> > > >>>On Nov 23, 2007 6:00 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> > > >>>
> > > >>><snip>
> > > >>>
> > > >>>
> > > >>>>I'm with you up to this point. What Tomcat deep integration work
> is
> > > >>>
> > > >>>going
> > > >>>
> > > >>>>on
> > > >>>>(I do know about the Geronimo stuff).
> > > >>>>
> > > >>>>
> > > >>>>>- fix Tomcat deep integration and document how to do it (by
> copying
> > > >>>
> > > >>>the
> > > >>>
> > > >>>>>binary lib directory jars to Tomcat lib etc)
> > > >>>>
> > > >>>I don't think anyone has done much with Tomcat deep integration
> since
> > > M1
> > > >>>days, i tried it a while back but there were varrious class loader
> > > >>>issues.
> > > >>>With all the fixing up of class loaders done for osgi recently this
> > may
> > > >>>work
> > > >>>ok now, i just tried moving all the jars from the runtime-war from
> > the
> > > >>>war
> > > >>>lib folder to the Tomcat lib folder and it all seems to keep
> working
> > ok
> > > >>>now
> > > >>>so maybe we just need to test it a bit more and then document it.
> > > >>>
> > > >>>  ...ant
> > > >>>
> > > >>
> > > >>So when the contribution is a war in its own right what you say last
> > is
> > > >>the solution? Or is there something else?
> > > >>
> > > >>
> > > >
> > > > Right, though for deep integration to work we'd still need some new
> > code
> > > > that looks in each war as its deployed for .composite files and
> > > > sca-contibution.xmls, and i guess to do it properly also something
> > like
> > > the
> > > > implementation.web that was mentioned a while ago.
> > > >
> > > I'm interested in getting this to work.  Is there a hook point in
> Tomcat
> > > that we could use to look at war code as it's deployed?
> > >
> > >   Simon
> > >
> >
> > I think there's a number of things we need to do to get this to work:
> > 1 - start an SCA doman/node when Tomcat starts
> > 1a - local non-http communication between the domain and node.
> > 2 - a way to deploy SCA contributions to the node
> > 3 - look in each webapp as it starts for SCA things to deploy to the
> node
> > 4 - write an implementation.web to inject properties and references into
> > webapp servlets and JSPs
> > 5 - a new http host to enable registering SCA http service endpoints
> > (similar to host-http-tomcat except not requiring all the servlet stuff
> in
> > each webapp)
> >
> > For (1) a way to do this is to write and implementation of
> > org.apache.catalina.Host and change the Tomcat server.xml to use that.
> > From
> > there you can start an SCA node and get hooks into webapp start/stop
> > events
> > by registering an impl of org.apache.catalina.LifecycleListener. I've
> made
> > a
> > start at that though its quite primative so far, i'll commit what i have
> > so
> > anyone else could help. We already have (2) from the runtime-war module
> > and
> > it hopefully shouldn't be to hard to extend that for (3).
> >
> > I'd quite like to try to get something going for this for 1.1 but
> there's
> > a
> > fair bit of work to get it all that working well, so everyone who'd like
> > to
> > help is welcome :) A lot of the code for doing this could be reused in
> the
> > Geronimo integration work, Tomcat is a bit easier to work with which is
> > one
> > reason I'm looking at this now.
> >
> >   ...ant
> >
> Ant
>
> I haven't got my head round all the items on this list yet but they look
> plausible. I do have a question about the way this solution relates to a
> wider domain. The scenario I believe you are addressing here is one where
> a
> user
>
> 1. Starts tomcat
> 2. Adds web apps with the expectation that any SCA artifacts inside these
> web apps run in a single node as part of a single domain
> 3. Stops tomcat when they are done
>
> This could be a first step and in this case there is no need to worry
> about
> node/domain communications. Starting a standalone node means that any
> contributed components are assumed to be part of the same domain and can
> find one another. To put it another way a single node only belongs to one
> domain. The implication here though is that you can't create SCA to/from
> components in the Tomcat environment and all communication in and out will
> be via targeted remote bindings.
>

There are a number of possible runtime scenarios, whats described above are
some, I'd like to try to end up supporting as many as possible that we think
may be useful and for them all to work in a consistent way.  The ones
relevant to Tomcat are the deep integration where the Tuscany code is
embedded within Tomcat, and the webapp integration where the Tuscany code is
included within individual webapps.

For both of those I think it should be possible to run as a standalone node
or as part of an SCA domain, and I think the domain should be able to be run
within Tomcat.

I'm less clear about the SCA nodes, there needs to be at least one, maybe
there's more - one fore each composite or each contribution or each webapp,
or each Tomcat instance. Once we have things working with one it shouldn't
be too hard to as more as we see fit.

I think this should work with simple sca contribution jars - ie just a jar
which includes .composite files and sca-contribution.xml etc. Thats what the
runtime-war webapp support and the deep integration with runtime-tomcat has
right now by putting the contribution jars in specific folder.

And then I think we should try have something like implementation-web so
servlets and JSPs etc in a webapp can use SCA.


>
> For the more general scenario we can make two assumptions
>
> 1. Each web app is associated with a separate node
> 2. Each web app must be able to belong to a specified domain.
>
> In this case the domain, if run in the Tomcat instance where the web apps
> are running, is just another web app and we have to sort out the non-http
> comms to avoid the startup deadlock. For that we require some other
> binding.
> binding.socket, binding.minapipe for example.
>

Yes, I think we really need that if this is going to work very well.

>
> The domain can also be run outside of the tomcat instance and I think that
> is the easier place to start in order to get this scenario running.
>

Yes, right now things only work with standalone nodes. It may well also work
with nodes using a standalone domain running outside of Tomcat, there's code
to support that which worked at one point but i've not tried it recently, it
will depend on if the domain works talking to nodes which include a path in
their URL - i'm not sure if that is working just now.


>
> In neither case is Tomcat starting the domain application automatically.
> It's the users responsibility to choose where to run it and to actually
> deploy it.  There is a requirement to be able to specify the domain URL
> for
> each web app. Can we do this through a parameter in web.xml? I need to go
> read the OSOA docs to see if they say anything about this.
>
>
OK, and with the deep integration we'd probably want a way to optionally
start up with a domain automatically, and also to configure the domain that
the nodes should use. Right now the code supports a properties file next to
the contribution jars where you can define this but that was just for
expediency I'm not sure if its the best approach long term.

   ...ant

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Laws <si...@googlemail.com>]

On Nov 28, 2007 10:24 AM, ant elder <an...@gmail.com> wrote:

> On Nov 27, 2007 4:11 PM, Simon Nash <na...@hursley.ibm.com> wrote:
>
> >
> > ant elder wrote:
> >
> > > On Nov 27, 2007 2:29 PM, Simon Laws <si...@googlemail.com> wrote:
> > >
> > >
> > >>
> > >>On Nov 27, 2007 2:25 PM, ant elder <an...@apache.org> wrote:
> > >>
> > >>
> > >>>I've just committed a runtime-war module as a start of whats being
> > >>>talked
> > >>>about here, which could be merged or replace distribution/webapp at
> > some
> > >>>point. I'll post some more details later. One comment inline below:
> > >>>
> > >>>  ...ant
> > >>>
> > >>>On Nov 23, 2007 6:00 PM, Simon Laws <si...@googlemail.com>
> wrote:
> > >>>
> > >>><snip>
> > >>>
> > >>>
> > >>>>I'm with you up to this point. What Tomcat deep integration work is
> > >>>
> > >>>going
> > >>>
> > >>>>on
> > >>>>(I do know about the Geronimo stuff).
> > >>>>
> > >>>>
> > >>>>>- fix Tomcat deep integration and document how to do it (by copying
> > >>>
> > >>>the
> > >>>
> > >>>>>binary lib directory jars to Tomcat lib etc)
> > >>>>
> > >>>I don't think anyone has done much with Tomcat deep integration since
> > M1
> > >>>days, i tried it a while back but there were varrious class loader
> > >>>issues.
> > >>>With all the fixing up of class loaders done for osgi recently this
> may
> > >>>work
> > >>>ok now, i just tried moving all the jars from the runtime-war from
> the
> > >>>war
> > >>>lib folder to the Tomcat lib folder and it all seems to keep working
> ok
> > >>>now
> > >>>so maybe we just need to test it a bit more and then document it.
> > >>>
> > >>>  ...ant
> > >>>
> > >>
> > >>So when the contribution is a war in its own right what you say last
> is
> > >>the solution? Or is there something else?
> > >>
> > >>
> > >
> > > Right, though for deep integration to work we'd still need some new
> code
> > > that looks in each war as its deployed for .composite files and
> > > sca-contibution.xmls, and i guess to do it properly also something
> like
> > the
> > > implementation.web that was mentioned a while ago.
> > >
> > I'm interested in getting this to work.  Is there a hook point in Tomcat
> > that we could use to look at war code as it's deployed?
> >
> >   Simon
> >
>
> I think there's a number of things we need to do to get this to work:
> 1 - start an SCA doman/node when Tomcat starts
> 1a - local non-http communication between the domain and node.
> 2 - a way to deploy SCA contributions to the node
> 3 - look in each webapp as it starts for SCA things to deploy to the node
> 4 - write an implementation.web to inject properties and references into
> webapp servlets and JSPs
> 5 - a new http host to enable registering SCA http service endpoints
> (similar to host-http-tomcat except not requiring all the servlet stuff in
> each webapp)
>
> For (1) a way to do this is to write and implementation of
> org.apache.catalina.Host and change the Tomcat server.xml to use that.
> From
> there you can start an SCA node and get hooks into webapp start/stop
> events
> by registering an impl of org.apache.catalina.LifecycleListener. I've made
> a
> start at that though its quite primative so far, i'll commit what i have
> so
> anyone else could help. We already have (2) from the runtime-war module
> and
> it hopefully shouldn't be to hard to extend that for (3).
>
> I'd quite like to try to get something going for this for 1.1 but there's
> a
> fair bit of work to get it all that working well, so everyone who'd like
> to
> help is welcome :) A lot of the code for doing this could be reused in the
> Geronimo integration work, Tomcat is a bit easier to work with which is
> one
> reason I'm looking at this now.
>
>   ...ant
>
Ant

I haven't got my head round all the items on this list yet but they look
plausible. I do have a question about the way this solution relates to a
wider domain. The scenario I believe you are addressing here is one where a
user

1. Starts tomcat
2. Adds web apps with the expectation that any SCA artifacts inside these
web apps run in a single node as part of a single domain
3. Stops tomcat when they are done

This could be a first step and in this case there is no need to worry about
node/domain communications. Starting a standalone node means that any
contributed components are assumed to be part of the same domain and can
find one another. To put it another way a single node only belongs to one
domain. The implication here though is that you can't create SCA to/from
components in the Tomcat environment and all communication in and out will
be via targeted remote bindings.

For the more general scenario we can make two assumptions

1. Each web app is associated with a separate node
2. Each web app must be able to belong to a specified domain.

In this case the domain, if run in the Tomcat instance where the web apps
are running, is just another web app and we have to sort out the non-http
comms to avoid the startup deadlock. For that we require some other binding.
binding.socket, binding.minapipe for example.

The domain can also be run outside of the tomcat instance and I think that
is the easier place to start in order to get this scenario running.

In neither case is Tomcat starting the domain application automatically.
It's the users responsibility to choose where to run it and to actually
deploy it.  There is a requirement to be able to specify the domain URL for
each web app. Can we do this through a parameter in web.xml? I need to go
read the OSOA docs to see if they say anything about this.

Regards

Simon

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[ant elder <an...@gmail.com>]

On Nov 27, 2007 4:11 PM, Simon Nash <na...@hursley.ibm.com> wrote:

>
> ant elder wrote:
>
> > On Nov 27, 2007 2:29 PM, Simon Laws <si...@googlemail.com> wrote:
> >
> >
> >>
> >>On Nov 27, 2007 2:25 PM, ant elder <an...@apache.org> wrote:
> >>
> >>
> >>>I've just committed a runtime-war module as a start of whats being
> >>>talked
> >>>about here, which could be merged or replace distribution/webapp at
> some
> >>>point. I'll post some more details later. One comment inline below:
> >>>
> >>>  ...ant
> >>>
> >>>On Nov 23, 2007 6:00 PM, Simon Laws <si...@googlemail.com> wrote:
> >>>
> >>><snip>
> >>>
> >>>
> >>>>I'm with you up to this point. What Tomcat deep integration work is
> >>>
> >>>going
> >>>
> >>>>on
> >>>>(I do know about the Geronimo stuff).
> >>>>
> >>>>
> >>>>>- fix Tomcat deep integration and document how to do it (by copying
> >>>
> >>>the
> >>>
> >>>>>binary lib directory jars to Tomcat lib etc)
> >>>>
> >>>I don't think anyone has done much with Tomcat deep integration since
> M1
> >>>days, i tried it a while back but there were varrious class loader
> >>>issues.
> >>>With all the fixing up of class loaders done for osgi recently this may
> >>>work
> >>>ok now, i just tried moving all the jars from the runtime-war from the
> >>>war
> >>>lib folder to the Tomcat lib folder and it all seems to keep working ok
> >>>now
> >>>so maybe we just need to test it a bit more and then document it.
> >>>
> >>>  ...ant
> >>>
> >>
> >>So when the contribution is a war in its own right what you say last is
> >>the solution? Or is there something else?
> >>
> >>
> >
> > Right, though for deep integration to work we'd still need some new code
> > that looks in each war as its deployed for .composite files and
> > sca-contibution.xmls, and i guess to do it properly also something like
> the
> > implementation.web that was mentioned a while ago.
> >
> I'm interested in getting this to work.  Is there a hook point in Tomcat
> that we could use to look at war code as it's deployed?
>
>   Simon
>

I think there's a number of things we need to do to get this to work:
1 - start an SCA doman/node when Tomcat starts
1a - local non-http communication between the domain and node.
2 - a way to deploy SCA contributions to the node
3 - look in each webapp as it starts for SCA things to deploy to the node
4 - write an implementation.web to inject properties and references into
webapp servlets and JSPs
5 - a new http host to enable registering SCA http service endpoints
(similar to host-http-tomcat except not requiring all the servlet stuff in
each webapp)

For (1) a way to do this is to write and implementation of
org.apache.catalina.Host and change the Tomcat server.xml to use that. From
there you can start an SCA node and get hooks into webapp start/stop events
by registering an impl of org.apache.catalina.LifecycleListener. I've made a
start at that though its quite primative so far, i'll commit what i have so
anyone else could help. We already have (2) from the runtime-war module and
it hopefully shouldn't be to hard to extend that for (3).

I'd quite like to try to get something going for this for 1.1 but there's a
fair bit of work to get it all that working well, so everyone who'd like to
help is welcome :) A lot of the code for doing this could be reused in the
Geronimo integration work, Tomcat is a bit easier to work with which is one
reason I'm looking at this now.

   ...ant

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Venkata Krishnan <fo...@gmail.com>]

All that sounds sense to me, especially the thought of turning our samples
to simple contribution jars.   That will align better with what application
developers would actually do.

- Venkat

On Nov 22, 2007 8:21 PM, ant elder <an...@gmail.com> wrote:

> On Nov 22, 2007 1:57 PM, Simon Nash <na...@hursley.ibm.com> wrote:
>
> >
> > Jean-Sebastien Delfino wrote:
> >
> > > [snip]
> > > Simon Nash wrote:
> > >
> > >> Samples are very important for beginning users.  For users who have
> > >> moved beyond that stage and are doing real development using Tuscany,
> > >> samples are not very important.  If people in this category do want
> > >> samples, they are likely to just want to refer to samples source code
> > >> to cut and paste snippets as necessary.  Having pre-built sample
> > binaries
> > >> isn't important for these users, and having the main lib directory
> > >> polluted/bloated by samples dependencies is a positive nuisance
> because
> > >> there's no easy way for them to find and remove the redundant files.
> > >
> > >
> > > I didn't think we were polluting the lib directory with sample
> > > dependencies, do you have a concrete example?
> > >
> > I thought this thread was discussing the case of a sample having a
> > dependency that the runtime does not have.  If there are no such cases
> > at present, then the issue doesn't arise.  However, there could be
> > such cases in the future as we add more "application-style" samples,
> > and it would be good to have an idea about how such dependencies would
> > be handled.
> >
> > >>
> > >> Having these files in Tuscany's lib directory isn't just wasting a
> few
> > >> bits on the disk.  It can be a problem if their version levels
> conflict
> > >> with other versions of the same code that the user has installed.
> > >> For "genuine" Tuscany dependencies, such conflicts are a real issue
> > >> that must be handled carefully in order to get Tuscany to co-exist
> with
> > >> their other software.  For sample dependencies, there is no actual
> > >> conflict unless the user needs to run the specific sample that pulled
> > >> in the dependency,
> > >
> > >
> > > Like I said earlier in the initial thread about sample dependencies, I
> > > don't think that samples should bring dependencies that are not
> genuine
> > > Tuscany dependencies.
> > >
> > OK, we are agreed about this.  But what if an application-style sample
> > does have a non-Tuscany dependency?  This is certainly possible.  Would
> > the Tuscany distro include the dependency, or leave it up to the user
> > to download it as a prereq to running the sample?
> >
> > > but it might take them some time to figure out why
> > >
> > >> putting the Tuscany lib directory on the classpath is causing other
> > >> code in their application to break.
> > >>
> > >> I'd suggest structuring the binary distribution as follows:
> > >>
> > >> 1. Tuscany runtime in "modules" and its dependencies in "lib".
> > >
> > >
> > > +1
> > >
> > >>    At the moment we have separate copies of the Tuscany runtime in
> > >>    "modules" and "lib" and I'm not quite sure why.
> > >
> > >
> > > Which JARs are you talking about?
> > >
> > I'm talking about the tuscany-sca-all.jar in the lib directory, which
> > is a combination of the contents of the jars in the modules directory.
> > The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar
> > as well as referring to all the jars in the modules directory, which
> > seems somewhat redundant.
> >
> > >
> > >> 2. Tuscany samples source, READMEs and build files in "samples".
> > >
> > >
> > > +1
> > >
> > >> 3. Tuscany samples binaries in "modules/samples",
> > >
> > >
> > > I prefer to have the binaries under samples as well, with their
> source.
> > >
> > Having them there is more convenient but makes it harder to see how
> > much space they are consuming.  I did some investigation, and it
> > turns out that these binaries are causing a huge expansion in the
> > size of the "samples" directory.
> >
> > In the 1.0.1 binary distro, the source under the "samples" directory
> > occupies around 2.3 MB.  The total size of source plus binaries under
> > this directory is 49.5 MB.  This extra 47 MB for samples binaries is
> > almost half the total size of the Tuscany binary distro.  I think we
> > need to either remove these binaries or separate them out into a
> > samples download so that we can get the Tuscany binary distro down
> > to a reasonable size.
> >
> > > with their
> > >
> > >>    dependencies in "lib/samples".
> > >
> > >
> > > Again samples should not bring additional dependencies in the first
> > place.
> > >
> > I hope this is true.  I don't know how to check that nothing in
> > this category has been included in lib.
> >
> > >>
> > >> By doing this we solve the conflict problems and it becomes a distro
> > >> size issue to decide whether 3 should be in the main binary distro
> > >> or available separately.
> > >
> > >
> > > IMO the samples should be small and not cause a size problem, and
> > > therefore should stay in the distro.
> > >
> > +1 that this is how it should be, but it is definitely not the case
> > today.  The samples make up around 50MB of the 100MB total size of
> > the binary distro.  This needs to be fixed.
> >
> > >  Since 3 will be clearly separated from 1
> > >
> > >> and 2, it will be easy to see how much extra size it is contributing.
> > >>
> > >> The other dimension of splitting the distro by functional contents
> > >> is orthogonal to the above and is also worth exploring.  I'd suggest
> > >> the following distro packages:
> > >>
> > >> 1. Base runtime with functional capabilities that almost everyone
> > >>    will want to use, and associated samples.
> > >> 2. A number of extension bundles (either depending only on the base,
> > >>    or possibly depending on other bundles), and associated samples.
> > >>
> > >> If people think this approach makes sense then we could talk about
> > >> what the base distro and extension bundles should contain.
> > >
> > >
> > > Makes sense to me, I'd suggest the following packages:
> > > - base SCA runtime (assembly, policy fwk, impl-java)
> > > - web services package (ws binding + related databindings)
> > > - web 2.0 package (json, dwr, widget, atom, scripting)
> > > - data integration (impl-data, openjpa)
> > > - business process integration (bpel, xquery)
> > > - jee integration (ejb, jms, rmi)
> > > - spring + osgi integration (spring, osgi)
> > > - all-in-one, for people who don't have time to solve puzzles.
> > >
> > This looks pretty good as a starting point.  If we find that
> > people are normally downloading the same combinations, we could
> > look at merging these combinations.
> >
> > > Perhaps group web services and web 2.0 together, I'm not sure.
> > >
> > I think these shouldn't be combined.  Web 2.0 applications don't
> > always use Web services.
> >
> > > Also I'm not sure about where to put policies like security,
> > > reliability, transactions.
> > >
> > Wouldn't these normally be applied to a binding?  If so, they should
> > go with that binding IMO.
> >
> >
> Right now the distribution is nice and simple which makes it easy for
> users
> to figure out what they want and it makes the download page very clear.
> Having multiple downloads reduces the download size but i think it needs
> to
> be weighed against the extra complexity doing that might bring, so I'd
> like
> to see more detail about how things would look before this happens.
>
> The main reason the binary distribution is large is because the webapp
> samples are each including copies of the the Tuscany runtime dependencies.
> We've talked several times about this and i thought there was (at least
> some) agreement that the webapp samples shouldn't be like this but instead
> all the samples should be simple sca contribution jars. If we fix that
> then
> the size problem goes away (and it simplifies the sample build scripts).
>
> So an alternative to splitting up the binary distribution could be:
>
> - keep the current standalone runtime using all the jars in the
> distribution
> lib directory
> - make all samples simple sca contribution jars
> - have a separate Tuscany WAR that you can use to run any/all the samples
> in
> a webapp
> - fix Tomcat deep integration and document how to do it (by copying the
> binary lib directory jars to Tomcat lib etc)
> (and slightly related - finish the Geronimo integration and get that
> released somewhere and document how to use the sample contribution jars
> with
> it)
>
> All those would by default include all the Tuscany extensions and
> dependencies, we document which jars are for what so advanced users can
> remove what they don't need.
>
>   ...ant
>

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Nash <na...@hursley.ibm.com>]

ant elder wrote:

> On Nov 27, 2007 2:29 PM, Simon Laws <si...@googlemail.com> wrote:
> 
> 
>>
>>On Nov 27, 2007 2:25 PM, ant elder <an...@apache.org> wrote:
>>
>>
>>>I've just committed a runtime-war module as a start of whats being
>>>talked
>>>about here, which could be merged or replace distribution/webapp at some
>>>point. I'll post some more details later. One comment inline below:
>>>
>>>  ...ant
>>>
>>>On Nov 23, 2007 6:00 PM, Simon Laws <si...@googlemail.com> wrote:
>>>
>>><snip>
>>>
>>>
>>>>I'm with you up to this point. What Tomcat deep integration work is
>>>
>>>going
>>>
>>>>on
>>>>(I do know about the Geronimo stuff).
>>>>
>>>>
>>>>>- fix Tomcat deep integration and document how to do it (by copying
>>>
>>>the
>>>
>>>>>binary lib directory jars to Tomcat lib etc)
>>>>
>>>I don't think anyone has done much with Tomcat deep integration since M1
>>>days, i tried it a while back but there were varrious class loader
>>>issues.
>>>With all the fixing up of class loaders done for osgi recently this may
>>>work
>>>ok now, i just tried moving all the jars from the runtime-war from the
>>>war
>>>lib folder to the Tomcat lib folder and it all seems to keep working ok
>>>now
>>>so maybe we just need to test it a bit more and then document it.
>>>
>>>  ...ant
>>>
>>
>>So when the contribution is a war in its own right what you say last is
>>the solution? Or is there something else?
>>
>>
> 
> Right, though for deep integration to work we'd still need some new code
> that looks in each war as its deployed for .composite files and
> sca-contibution.xmls, and i guess to do it properly also something like the
> implementation.web that was mentioned a while ago.
> 
I'm interested in getting this to work.  Is there a hook point in Tomcat
that we could use to look at war code as it's deployed?

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[ant elder <an...@gmail.com>]

On Nov 27, 2007 2:29 PM, Simon Laws <si...@googlemail.com> wrote:

>
>
> On Nov 27, 2007 2:25 PM, ant elder <an...@apache.org> wrote:
>
> > I've just committed a runtime-war module as a start of whats being
> > talked
> > about here, which could be merged or replace distribution/webapp at some
> > point. I'll post some more details later. One comment inline below:
> >
> >   ...ant
> >
> > On Nov 23, 2007 6:00 PM, Simon Laws <si...@googlemail.com> wrote:
> >
> > <snip>
> >
> >
> > > I'm with you up to this point. What Tomcat deep integration work is
> > going
> > > on
> > > (I do know about the Geronimo stuff).
> > >
> > > >
> > > > - fix Tomcat deep integration and document how to do it (by copying
> > the
> > > > binary lib directory jars to Tomcat lib etc)
> > >
> >
> > I don't think anyone has done much with Tomcat deep integration since M1
> > days, i tried it a while back but there were varrious class loader
> > issues.
> > With all the fixing up of class loaders done for osgi recently this may
> > work
> > ok now, i just tried moving all the jars from the runtime-war from the
> > war
> > lib folder to the Tomcat lib folder and it all seems to keep working ok
> > now
> > so maybe we just need to test it a bit more and then document it.
> >
> >   ...ant
> >
> So when the contribution is a war in its own right what you say last is
> the solution? Or is there something else?
>
>
Right, though for deep integration to work we'd still need some new code
that looks in each war as its deployed for .composite files and
sca-contibution.xmls, and i guess to do it properly also something like the
implementation.web that was mentioned a while ago.

   ...ant

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Laws <si...@googlemail.com>]

On Nov 26, 2007 5:18 PM, Simon Nash <na...@hursley.ibm.com> wrote:

>
> Simon Laws wrote:
>
> > On Nov 22, 2007 2:51 PM, ant elder <an...@gmail.com> wrote:
> >
> > (cut)
> >
> > I can do some more processing on (
> > http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>
> <http://people.apache.org/%7Eslaws/dependencies.htm>)
> > to give some help here if required.
> >
> >
> What do the columns mean?
>
>   Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Column 1 - A jar on which Tuscany depends
Column 2 - The type of dependency
Column 3 - The Tuscany module that requires the dependency
Column 4 to N - The transitive dependency path

Simon

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Laws <si...@googlemail.com>]

On Nov 27, 2007 2:25 PM, ant elder <an...@apache.org> wrote:

> I've just committed a runtime-war module as a start of whats being talked
> about here, which could be merged or replace distribution/webapp at some
> point. I'll post some more details later. One comment inline below:
>
>   ...ant
>
> On Nov 23, 2007 6:00 PM, Simon Laws <si...@googlemail.com> wrote:
>
> <snip>
>
>
> > I'm with you up to this point. What Tomcat deep integration work is
> going
> > on
> > (I do know about the Geronimo stuff).
> >
> > >
> > > - fix Tomcat deep integration and document how to do it (by copying
> the
> > > binary lib directory jars to Tomcat lib etc)
> >
>
> I don't think anyone has done much with Tomcat deep integration since M1
> days, i tried it a while back but there were varrious class loader issues.
> With all the fixing up of class loaders done for osgi recently this may
> work
> ok now, i just tried moving all the jars from the runtime-war from the war
> lib folder to the Tomcat lib folder and it all seems to keep working ok
> now
> so maybe we just need to test it a bit more and then document it.
>
>   ...ant
>
So when the contribution is a war in its own right what you say last is the
solution? Or is there something else?

Simon

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[ant elder <an...@apache.org>]

I've just committed a runtime-war module as a start of whats being talked
about here, which could be merged or replace distribution/webapp at some
point. I'll post some more details later. One comment inline below:

   ...ant

On Nov 23, 2007 6:00 PM, Simon Laws <si...@googlemail.com> wrote:

<snip>


> I'm with you up to this point. What Tomcat deep integration work is going
> on
> (I do know about the Geronimo stuff).
>
> >
> > - fix Tomcat deep integration and document how to do it (by copying the
> > binary lib directory jars to Tomcat lib etc)
>

I don't think anyone has done much with Tomcat deep integration since M1
days, i tried it a while back but there were varrious class loader issues.
With all the fixing up of class loaders done for osgi recently this may work
ok now, i just tried moving all the jars from the runtime-war from the war
lib folder to the Tomcat lib folder and it all seems to keep working ok now
so maybe we just need to test it a bit more and then document it.

   ...ant

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Jean-Sebastien Delfino <js...@apache.org>]

Rajini Sivaram wrote:
> Simon,
> 
> I did take a look at splitting the Tuscany distribution into bundles with
> the hope of defining something which makes sense for OSGi as well as
> non-OSGi. I dont really think that makes much sense anymore. Grouping
> modules into OSGi bundles using existing maven plugins was far too time
> consuming (in terms of the amount of time it took to do a build), and quite
> messy.
> 
> So I would like to go for a simpler option for OSGi where the the zip/jar
> files generated for the Tuscany distribution have a manifest file containing
> OSGi bundle manifest entries, so that they can be directly installed into
> OSGi

+1 from me, I'm glad you reached that conclusion, after thinking about 
it that was the only option that made sense to me :)

(with an easy repackaging option to get rid of samples from the bundle
> if the bundle size was too big).

Didn't quite get that, can you explain?

I would also like to add OSGi manifest
> entries into all jars distributed by Tuscany including 3rd party jars, so
> that we can use the OSGi bundle repository API to install Tuscany into an
> OSGi runtime, instead of relying on Tuscany distribution structure.


Not sure I'd like to go and change 3rd party dependency jars... but that 
triggers a very basic question:

Independent of Tuscany, isn't this something that every OSGi user is 
going to bump into with non-OSGified 3rd party jars? What is the best 
practice in the OSGi community for this issue these days?

> 
> I have an Eclipse plugin which shows the dependency graphs based on the
> import/export statements generated by the maven-bundle-plugin. I could
> compare these with the dependencies you generated (it might help to add
> appropriate scopes to the dependencies).
> 

Great, that'll help. Thanks.

-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> [snip]
> Simon Nash wrote:
>> I would like to make a start on improving the modularity of the
>> distro by building a distro containing only a base SCA runtime.
>> Sebastien's description of this was
>>  - base SCA runtime (assembly, policy fwk, impl-java)
> 
> [snip]
> 
> I haven't yet figured out how to do a sandbox
>> build that pulls in code from the trunk, without copying it.  Does
>> anyone else have an example of this that I could look at?
> 
> Modules assembled by the Maven assembly plugin are taken out of the 
> Maven repository, so you shouldn't need to copy the code to come up with 
> a different assembly.
> 
> For an example, look at the assemblies under sca/distribution.
> 
> I'm also going to put together an assembly for the eclipse plugin, I'll 
> give a pointer when it's there.

Here it is:
- pom.xml [1] runs the Maven assembly plugin as part of the build
- runtime.xml [2] configures the assembly plugin to grab all dependency 
modules from the Maven repos plus a few local files

[1] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tools/eclipse/plugins/runtime/pom.xml
[2] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tools/eclipse/plugins/runtime/src/main/assembly/runtime.xml

To build a source distro you may have to directly point to the 
directories that contain the sources, but ../../../sca/modules/... 
relative path from the sandbox should work.

> 
> Hope this helps.

-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Jean-Sebastien Delfino <js...@apache.org>]

[snip]
Simon Nash wrote:
> I would like to make a start on improving the modularity of the
> distro by building a distro containing only a base SCA runtime.
> Sebastien's description of this was
>  - base SCA runtime (assembly, policy fwk, impl-java)

[snip]

I haven't yet figured out how to do a sandbox
> build that pulls in code from the trunk, without copying it.  Does
> anyone else have an example of this that I could look at?

Modules assembled by the Maven assembly plugin are taken out of the 
Maven repository, so you shouldn't need to copy the code to come up with 
a different assembly.

For an example, look at the assemblies under sca/distribution.

I'm also going to put together an assembly for the eclipse plugin, I'll 
give a pointer when it's there.

Hope this helps.
-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Nash <na...@hursley.ibm.com>]

I would like to make a start on improving the modularity of the
distro by building a distro containing only a base SCA runtime.
Sebastien's description of this was
  - base SCA runtime (assembly, policy fwk, impl-java)
If others would like to propose any changes to this list and/or
suggest which maven modules should be included, that would be
helpful.  Otherwise I'll go through the modules myself to make
a first cut and iterate from there.

I think this will be a useful excercise in seeing how small we
can make this basic functionality and its dependencies.  It will
also allow us to explore some of the dependency issues between
modules (official SPIs or implementation code) in a smaller and
simpler world than the whole of Tuscany SCA Java.

For now I'd like to consider this a personal experiment that may
or may not ever get released.  For this reason, I'd like to do this
work in my sandbox.  I haven't yet figured out how to do a sandbox
build that pulls in code from the trunk, without copying it.  Does
anyone else have an example of this that I could look at?

Expect a number of these "how to" questions as I get further into
this :-)

   Simon

Rajini Sivaram wrote:

> Simon,
> 
> I did take a look at splitting the Tuscany distribution into bundles with
> the hope of defining something which makes sense for OSGi as well as
> non-OSGi. I dont really think that makes much sense anymore. Grouping
> modules into OSGi bundles using existing maven plugins was far too time
> consuming (in terms of the amount of time it took to do a build), and quite
> messy.
> 
> So I would like to go for a simpler option for OSGi where the the zip/jar
> files generated for the Tuscany distribution have a manifest file containing
> OSGi bundle manifest entries, so that they can be directly installed into
> OSGi (with an easy repackaging option to get rid of samples from the bundle
> if the bundle size was too big). I would also like to add OSGi manifest
> entries into all jars distributed by Tuscany including 3rd party jars, so
> that we can use the OSGi bundle repository API to install Tuscany into an
> OSGi runtime, instead of relying on Tuscany distribution structure.
> 
> I have an Eclipse plugin which shows the dependency graphs based on the
> import/export statements generated by the maven-bundle-plugin. I could
> compare these with the dependencies you generated (it might help to add
> appropriate scopes to the dependencies).
> 
> 
> 
> Thank you...
> 
> Regards,
> 
> Rajini
> 
> 
> On 11/23/07, Simon Laws <si...@googlemail.com> wrote:
> 
>>On Nov 22, 2007 2:51 PM, ant elder <an...@gmail.com> wrote:
>>
>>
>>>On Nov 22, 2007 1:57 PM, Simon Nash <na...@hursley.ibm.com> wrote:
>>>
>>>
>>>>Jean-Sebastien Delfino wrote:
>>>>
>>>>
>>>>>[snip]
>>>>>Simon Nash wrote:
>>>>>
>>>>>
>>>>>>Samples are very important for beginning users.  For users who have
>>>>>>moved beyond that stage and are doing real development using
>>
>>Tuscany,
>>
>>>>>>samples are not very important.  If people in this category do want
>>>>>>samples, they are likely to just want to refer to samples source
>>
>>code
>>
>>>>>>to cut and paste snippets as necessary.  Having pre-built sample
>>>>
>>>>binaries
>>>>
>>>>>>isn't important for these users, and having the main lib directory
>>>>>>polluted/bloated by samples dependencies is a positive nuisance
>>>
>>>because
>>>
>>>>>>there's no easy way for them to find and remove the redundant
>>
>>files.
>>
>>>>>
>>>>>I didn't think we were polluting the lib directory with sample
>>>>>dependencies, do you have a concrete example?
>>>>>
>>>>
>>>>I thought this thread was discussing the case of a sample having a
>>>>dependency that the runtime does not have.  If there are no such cases
>>>>at present, then the issue doesn't arise.  However, there could be
>>>>such cases in the future as we add more "application-style" samples,
>>>>and it would be good to have an idea about how such dependencies would
>>>>be handled.
>>>>
>>>>
>>>>>>Having these files in Tuscany's lib directory isn't just wasting a
>>>
>>>few
>>>
>>>>>>bits on the disk.  It can be a problem if their version levels
>>>
>>>conflict
>>>
>>>>>>with other versions of the same code that the user has installed.
>>>>>>For "genuine" Tuscany dependencies, such conflicts are a real issue
>>>>>>that must be handled carefully in order to get Tuscany to co-exist
>>>
>>>with
>>>
>>>>>>their other software.  For sample dependencies, there is no actual
>>>>>>conflict unless the user needs to run the specific sample that
>>
>>pulled
>>
>>>>>>in the dependency,
>>>>>
>>>>>
>>>>>Like I said earlier in the initial thread about sample dependencies,
>>
>>I
>>
>>>>>don't think that samples should bring dependencies that are not
>>>
>>>genuine
>>>
>>>>>Tuscany dependencies.
>>>>>
>>>>
>>>>OK, we are agreed about this.  But what if an application-style sample
>>>>does have a non-Tuscany dependency?  This is certainly
>>
>>possible.  Would
>>
>>>>the Tuscany distro include the dependency, or leave it up to the user
>>>>to download it as a prereq to running the sample?
>>>>
>>>>
>>>>>but it might take them some time to figure out why
>>>>>
>>>>>
>>>>>>putting the Tuscany lib directory on the classpath is causing other
>>>>>>code in their application to break.
>>>>>>
>>>>>>I'd suggest structuring the binary distribution as follows:
>>>>>>
>>>>>>1. Tuscany runtime in "modules" and its dependencies in "lib".
>>>>>
>>>>>
>>>>>+1
>>>>>
>>>>>
>>>>>>   At the moment we have separate copies of the Tuscany runtime in
>>>>>>   "modules" and "lib" and I'm not quite sure why.
>>>>>
>>>>>
>>>>>Which JARs are you talking about?
>>>>>
>>>>
>>>>I'm talking about the tuscany-sca-all.jar in the lib directory, which
>>>>is a combination of the contents of the jars in the modules directory.
>>>>The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar
>>>>as well as referring to all the jars in the modules directory, which
>>>>seems somewhat redundant.
>>>>
>>>>
>>>>>>2. Tuscany samples source, READMEs and build files in "samples".
>>>>>
>>>>>
>>>>>+1
>>>>>
>>>>>
>>>>>>3. Tuscany samples binaries in "modules/samples",
>>>>>
>>>>>
>>>>>I prefer to have the binaries under samples as well, with their
>>>
>>>source.
>>>
>>>>Having them there is more convenient but makes it harder to see how
>>>>much space they are consuming.  I did some investigation, and it
>>>>turns out that these binaries are causing a huge expansion in the
>>>>size of the "samples" directory.
>>>>
>>>>In the 1.0.1 binary distro, the source under the "samples" directory
>>>>occupies around 2.3 MB.  The total size of source plus binaries under
>>>>this directory is 49.5 MB.  This extra 47 MB for samples binaries is
>>>>almost half the total size of the Tuscany binary distro.  I think we
>>>>need to either remove these binaries or separate them out into a
>>>>samples download so that we can get the Tuscany binary distro down
>>>>to a reasonable size.
>>>>
>>>>
>>>>>with their
>>>>>
>>>>>
>>>>>>   dependencies in "lib/samples".
>>>>>
>>>>>
>>>>>Again samples should not bring additional dependencies in the first
>>>>
>>>>place.
>>>>
>>>>I hope this is true.  I don't know how to check that nothing in
>>>>this category has been included in lib.
>>>>
>>>>
>>>>>>By doing this we solve the conflict problems and it becomes a
>>
>>distro
>>
>>>>>>size issue to decide whether 3 should be in the main binary distro
>>>>>>or available separately.
>>>>>
>>>>>
>>>>>IMO the samples should be small and not cause a size problem, and
>>>>>therefore should stay in the distro.
>>>>>
>>>>
>>>>+1 that this is how it should be, but it is definitely not the case
>>>>today.  The samples make up around 50MB of the 100MB total size of
>>>>the binary distro.  This needs to be fixed.
>>>>
>>>>
>>>>> Since 3 will be clearly separated from 1
>>>>>
>>>>>
>>>>>>and 2, it will be easy to see how much extra size it is
>>
>>contributing.
>>
>>>>>>The other dimension of splitting the distro by functional contents
>>>>>>is orthogonal to the above and is also worth exploring.  I'd
>>
>>suggest
>>
>>>>>>the following distro packages:
>>>>>>
>>>>>>1. Base runtime with functional capabilities that almost everyone
>>>>>>   will want to use, and associated samples.
>>>>>>2. A number of extension bundles (either depending only on the
>>
>>base,
>>
>>>>>>   or possibly depending on other bundles), and associated samples.
>>>>>>
>>>>>>If people think this approach makes sense then we could talk about
>>>>>>what the base distro and extension bundles should contain.
>>>>>
>>>>>
>>>>>Makes sense to me, I'd suggest the following packages:
>>>>>- base SCA runtime (assembly, policy fwk, impl-java)
>>>>>- web services package (ws binding + related databindings)
>>>>>- web 2.0 package (json, dwr, widget, atom, scripting)
>>>>>- data integration (impl-data, openjpa)
>>>>>- business process integration (bpel, xquery)
>>>>>- jee integration (ejb, jms, rmi)
>>>>>- spring + osgi integration (spring, osgi)
>>>>>- all-in-one, for people who don't have time to solve puzzles.
>>>>>
>>>>
>>>>This looks pretty good as a starting point.  If we find that
>>>>people are normally downloading the same combinations, we could
>>>>look at merging these combinations.
>>>>
>>>>
>>>>>Perhaps group web services and web 2.0 together, I'm not sure.
>>>>>
>>>>
>>>>I think these shouldn't be combined.  Web 2.0 applications don't
>>>>always use Web services.
>>>>
>>>>
>>>>>Also I'm not sure about where to put policies like security,
>>>>>reliability, transactions.
>>>>>
>>>>
>>>>Wouldn't these normally be applied to a binding?  If so, they should
>>>>go with that binding IMO.
>>>>
>>>>
>>>
>>>Right now the distribution is nice and simple which makes it easy for
>>>users
>>>to figure out what they want and it makes the download page very clear.
>>>Having multiple downloads reduces the download size but i think it needs
>>>to
>>>be weighed against the extra complexity doing that might bring, so I'd
>>>like
>>>to see more detail about how things would look before this happens.
>>>
>>>The main reason the binary distribution is large is because the webapp
>>>samples are each including copies of the the Tuscany runtime
>>
>>dependencies.
>>
>>>We've talked several times about this and i thought there was (at least
>>>some) agreement that the webapp samples shouldn't be like this but
>>
>>instead
>>
>>>all the samples should be simple sca contribution jars. If we fix that
>>>then
>>>the size problem goes away (and it simplifies the sample build scripts).
>>
>>I was under the impression that there is already work ongoing to try this
>>out.
>>
>>
>>>
>>>So an alternative to splitting up the binary distribution could be:
>>>
>>>- keep the current standalone runtime using all the jars in the
>>>distribution
>>>lib directory
>>>- make all samples simple sca contribution jars
>>>- have a separate Tuscany WAR that you can use to run any/all the
>>
>>samples
>>
>>>in
>>>a webapp
>>
>>I'm with you up to this point. What Tomcat deep integration work is going
>>on
>>(I do know about the Geronimo stuff).
>>
>>
>>>- fix Tomcat deep integration and document how to do it (by copying the
>>>binary lib directory jars to Tomcat lib etc)
>>>(and slightly related - finish the Geronimo integration and get that
>>>released somewhere and document how to use the sample contribution jars
>>>with
>>>it)
>>>
>>>All those would by default include all the Tuscany extensions and
>>>dependencies, we document which jars are for what so advanced users can
>>>remove what they don't need.
>>
>>I can do some more processing on (
>>http://people.apache.org/~slaws/dependencies.htm<
>>http://people.apache.org/%7Eslaws/dependencies.htm>)
>>to give some help here if required.
>>
>>
>>>
>>>  ...ant
>>>
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Rajini Sivaram <ra...@googlemail.com>]

Simon,

I did take a look at splitting the Tuscany distribution into bundles with
the hope of defining something which makes sense for OSGi as well as
non-OSGi. I dont really think that makes much sense anymore. Grouping
modules into OSGi bundles using existing maven plugins was far too time
consuming (in terms of the amount of time it took to do a build), and quite
messy.

So I would like to go for a simpler option for OSGi where the the zip/jar
files generated for the Tuscany distribution have a manifest file containing
OSGi bundle manifest entries, so that they can be directly installed into
OSGi (with an easy repackaging option to get rid of samples from the bundle
if the bundle size was too big). I would also like to add OSGi manifest
entries into all jars distributed by Tuscany including 3rd party jars, so
that we can use the OSGi bundle repository API to install Tuscany into an
OSGi runtime, instead of relying on Tuscany distribution structure.

I have an Eclipse plugin which shows the dependency graphs based on the
import/export statements generated by the maven-bundle-plugin. I could
compare these with the dependencies you generated (it might help to add
appropriate scopes to the dependencies).



Thank you...

Regards,

Rajini


On 11/23/07, Simon Laws <si...@googlemail.com> wrote:
>
> On Nov 22, 2007 2:51 PM, ant elder <an...@gmail.com> wrote:
>
> > On Nov 22, 2007 1:57 PM, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > >
> > > Jean-Sebastien Delfino wrote:
> > >
> > > > [snip]
> > > > Simon Nash wrote:
> > > >
> > > >> Samples are very important for beginning users.  For users who have
> > > >> moved beyond that stage and are doing real development using
> Tuscany,
> > > >> samples are not very important.  If people in this category do want
> > > >> samples, they are likely to just want to refer to samples source
> code
> > > >> to cut and paste snippets as necessary.  Having pre-built sample
> > > binaries
> > > >> isn't important for these users, and having the main lib directory
> > > >> polluted/bloated by samples dependencies is a positive nuisance
> > because
> > > >> there's no easy way for them to find and remove the redundant
> files.
> > > >
> > > >
> > > > I didn't think we were polluting the lib directory with sample
> > > > dependencies, do you have a concrete example?
> > > >
> > > I thought this thread was discussing the case of a sample having a
> > > dependency that the runtime does not have.  If there are no such cases
> > > at present, then the issue doesn't arise.  However, there could be
> > > such cases in the future as we add more "application-style" samples,
> > > and it would be good to have an idea about how such dependencies would
> > > be handled.
> > >
> > > >>
> > > >> Having these files in Tuscany's lib directory isn't just wasting a
> > few
> > > >> bits on the disk.  It can be a problem if their version levels
> > conflict
> > > >> with other versions of the same code that the user has installed.
> > > >> For "genuine" Tuscany dependencies, such conflicts are a real issue
> > > >> that must be handled carefully in order to get Tuscany to co-exist
> > with
> > > >> their other software.  For sample dependencies, there is no actual
> > > >> conflict unless the user needs to run the specific sample that
> pulled
> > > >> in the dependency,
> > > >
> > > >
> > > > Like I said earlier in the initial thread about sample dependencies,
> I
> > > > don't think that samples should bring dependencies that are not
> > genuine
> > > > Tuscany dependencies.
> > > >
> > > OK, we are agreed about this.  But what if an application-style sample
> > > does have a non-Tuscany dependency?  This is certainly
> possible.  Would
> > > the Tuscany distro include the dependency, or leave it up to the user
> > > to download it as a prereq to running the sample?
> > >
> > > > but it might take them some time to figure out why
> > > >
> > > >> putting the Tuscany lib directory on the classpath is causing other
> > > >> code in their application to break.
> > > >>
> > > >> I'd suggest structuring the binary distribution as follows:
> > > >>
> > > >> 1. Tuscany runtime in "modules" and its dependencies in "lib".
> > > >
> > > >
> > > > +1
> > > >
> > > >>    At the moment we have separate copies of the Tuscany runtime in
> > > >>    "modules" and "lib" and I'm not quite sure why.
> > > >
> > > >
> > > > Which JARs are you talking about?
> > > >
> > > I'm talking about the tuscany-sca-all.jar in the lib directory, which
> > > is a combination of the contents of the jars in the modules directory.
> > > The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar
> > > as well as referring to all the jars in the modules directory, which
> > > seems somewhat redundant.
> > >
> > > >
> > > >> 2. Tuscany samples source, READMEs and build files in "samples".
> > > >
> > > >
> > > > +1
> > > >
> > > >> 3. Tuscany samples binaries in "modules/samples",
> > > >
> > > >
> > > > I prefer to have the binaries under samples as well, with their
> > source.
> > > >
> > > Having them there is more convenient but makes it harder to see how
> > > much space they are consuming.  I did some investigation, and it
> > > turns out that these binaries are causing a huge expansion in the
> > > size of the "samples" directory.
> > >
> > > In the 1.0.1 binary distro, the source under the "samples" directory
> > > occupies around 2.3 MB.  The total size of source plus binaries under
> > > this directory is 49.5 MB.  This extra 47 MB for samples binaries is
> > > almost half the total size of the Tuscany binary distro.  I think we
> > > need to either remove these binaries or separate them out into a
> > > samples download so that we can get the Tuscany binary distro down
> > > to a reasonable size.
> > >
> > > > with their
> > > >
> > > >>    dependencies in "lib/samples".
> > > >
> > > >
> > > > Again samples should not bring additional dependencies in the first
> > > place.
> > > >
> > > I hope this is true.  I don't know how to check that nothing in
> > > this category has been included in lib.
> > >
> > > >>
> > > >> By doing this we solve the conflict problems and it becomes a
> distro
> > > >> size issue to decide whether 3 should be in the main binary distro
> > > >> or available separately.
> > > >
> > > >
> > > > IMO the samples should be small and not cause a size problem, and
> > > > therefore should stay in the distro.
> > > >
> > > +1 that this is how it should be, but it is definitely not the case
> > > today.  The samples make up around 50MB of the 100MB total size of
> > > the binary distro.  This needs to be fixed.
> > >
> > > >  Since 3 will be clearly separated from 1
> > > >
> > > >> and 2, it will be easy to see how much extra size it is
> contributing.
> >
> > > >>
> > > >> The other dimension of splitting the distro by functional contents
> > > >> is orthogonal to the above and is also worth exploring.  I'd
> suggest
> > > >> the following distro packages:
> > > >>
> > > >> 1. Base runtime with functional capabilities that almost everyone
> > > >>    will want to use, and associated samples.
> > > >> 2. A number of extension bundles (either depending only on the
> base,
> > > >>    or possibly depending on other bundles), and associated samples.
> > > >>
> > > >> If people think this approach makes sense then we could talk about
> > > >> what the base distro and extension bundles should contain.
> > > >
> > > >
> > > > Makes sense to me, I'd suggest the following packages:
> > > > - base SCA runtime (assembly, policy fwk, impl-java)
> > > > - web services package (ws binding + related databindings)
> > > > - web 2.0 package (json, dwr, widget, atom, scripting)
> > > > - data integration (impl-data, openjpa)
> > > > - business process integration (bpel, xquery)
> > > > - jee integration (ejb, jms, rmi)
> > > > - spring + osgi integration (spring, osgi)
> > > > - all-in-one, for people who don't have time to solve puzzles.
> > > >
> > > This looks pretty good as a starting point.  If we find that
> > > people are normally downloading the same combinations, we could
> > > look at merging these combinations.
> > >
> > > > Perhaps group web services and web 2.0 together, I'm not sure.
> > > >
> > > I think these shouldn't be combined.  Web 2.0 applications don't
> > > always use Web services.
> > >
> > > > Also I'm not sure about where to put policies like security,
> > > > reliability, transactions.
> > > >
> > > Wouldn't these normally be applied to a binding?  If so, they should
> > > go with that binding IMO.
> > >
> > >
> > Right now the distribution is nice and simple which makes it easy for
> > users
> > to figure out what they want and it makes the download page very clear.
> > Having multiple downloads reduces the download size but i think it needs
> > to
> > be weighed against the extra complexity doing that might bring, so I'd
> > like
> > to see more detail about how things would look before this happens.
> >
> > The main reason the binary distribution is large is because the webapp
> > samples are each including copies of the the Tuscany runtime
> dependencies.
> > We've talked several times about this and i thought there was (at least
> > some) agreement that the webapp samples shouldn't be like this but
> instead
> >
> > all the samples should be simple sca contribution jars. If we fix that
> > then
> > the size problem goes away (and it simplifies the sample build scripts).
>
> I was under the impression that there is already work ongoing to try this
> out.
>
> >
> >
> > So an alternative to splitting up the binary distribution could be:
> >
> > - keep the current standalone runtime using all the jars in the
> > distribution
> > lib directory
> > - make all samples simple sca contribution jars
> > - have a separate Tuscany WAR that you can use to run any/all the
> samples
> > in
> > a webapp
>
> I'm with you up to this point. What Tomcat deep integration work is going
> on
> (I do know about the Geronimo stuff).
>
> >
> > - fix Tomcat deep integration and document how to do it (by copying the
> > binary lib directory jars to Tomcat lib etc)
> > (and slightly related - finish the Geronimo integration and get that
> > released somewhere and document how to use the sample contribution jars
> > with
> > it)
> >
> > All those would by default include all the Tuscany extensions and
> > dependencies, we document which jars are for what so advanced users can
> > remove what they don't need.
>
> I can do some more processing on (
> http://people.apache.org/~slaws/dependencies.htm<
> http://people.apache.org/%7Eslaws/dependencies.htm>)
> to give some help here if required.
>
> >
> >
> >   ...ant
> >
>

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Nash <na...@hursley.ibm.com>]

Simon Laws wrote:

> On Nov 22, 2007 2:51 PM, ant elder <an...@gmail.com> wrote:
> 
> (cut)
> 
> I can do some more processing on (
> http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>)
> to give some help here if required.
> 
> 
What do the columns mean?

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Laws <si...@googlemail.com>]

On Nov 22, 2007 2:51 PM, ant elder <an...@gmail.com> wrote:

> On Nov 22, 2007 1:57 PM, Simon Nash <na...@hursley.ibm.com> wrote:
>
> >
> > Jean-Sebastien Delfino wrote:
> >
> > > [snip]
> > > Simon Nash wrote:
> > >
> > >> Samples are very important for beginning users.  For users who have
> > >> moved beyond that stage and are doing real development using Tuscany,
> > >> samples are not very important.  If people in this category do want
> > >> samples, they are likely to just want to refer to samples source code
> > >> to cut and paste snippets as necessary.  Having pre-built sample
> > binaries
> > >> isn't important for these users, and having the main lib directory
> > >> polluted/bloated by samples dependencies is a positive nuisance
> because
> > >> there's no easy way for them to find and remove the redundant files.
> > >
> > >
> > > I didn't think we were polluting the lib directory with sample
> > > dependencies, do you have a concrete example?
> > >
> > I thought this thread was discussing the case of a sample having a
> > dependency that the runtime does not have.  If there are no such cases
> > at present, then the issue doesn't arise.  However, there could be
> > such cases in the future as we add more "application-style" samples,
> > and it would be good to have an idea about how such dependencies would
> > be handled.
> >
> > >>
> > >> Having these files in Tuscany's lib directory isn't just wasting a
> few
> > >> bits on the disk.  It can be a problem if their version levels
> conflict
> > >> with other versions of the same code that the user has installed.
> > >> For "genuine" Tuscany dependencies, such conflicts are a real issue
> > >> that must be handled carefully in order to get Tuscany to co-exist
> with
> > >> their other software.  For sample dependencies, there is no actual
> > >> conflict unless the user needs to run the specific sample that pulled
> > >> in the dependency,
> > >
> > >
> > > Like I said earlier in the initial thread about sample dependencies, I
> > > don't think that samples should bring dependencies that are not
> genuine
> > > Tuscany dependencies.
> > >
> > OK, we are agreed about this.  But what if an application-style sample
> > does have a non-Tuscany dependency?  This is certainly possible.  Would
> > the Tuscany distro include the dependency, or leave it up to the user
> > to download it as a prereq to running the sample?
> >
> > > but it might take them some time to figure out why
> > >
> > >> putting the Tuscany lib directory on the classpath is causing other
> > >> code in their application to break.
> > >>
> > >> I'd suggest structuring the binary distribution as follows:
> > >>
> > >> 1. Tuscany runtime in "modules" and its dependencies in "lib".
> > >
> > >
> > > +1
> > >
> > >>    At the moment we have separate copies of the Tuscany runtime in
> > >>    "modules" and "lib" and I'm not quite sure why.
> > >
> > >
> > > Which JARs are you talking about?
> > >
> > I'm talking about the tuscany-sca-all.jar in the lib directory, which
> > is a combination of the contents of the jars in the modules directory.
> > The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar
> > as well as referring to all the jars in the modules directory, which
> > seems somewhat redundant.
> >
> > >
> > >> 2. Tuscany samples source, READMEs and build files in "samples".
> > >
> > >
> > > +1
> > >
> > >> 3. Tuscany samples binaries in "modules/samples",
> > >
> > >
> > > I prefer to have the binaries under samples as well, with their
> source.
> > >
> > Having them there is more convenient but makes it harder to see how
> > much space they are consuming.  I did some investigation, and it
> > turns out that these binaries are causing a huge expansion in the
> > size of the "samples" directory.
> >
> > In the 1.0.1 binary distro, the source under the "samples" directory
> > occupies around 2.3 MB.  The total size of source plus binaries under
> > this directory is 49.5 MB.  This extra 47 MB for samples binaries is
> > almost half the total size of the Tuscany binary distro.  I think we
> > need to either remove these binaries or separate them out into a
> > samples download so that we can get the Tuscany binary distro down
> > to a reasonable size.
> >
> > > with their
> > >
> > >>    dependencies in "lib/samples".
> > >
> > >
> > > Again samples should not bring additional dependencies in the first
> > place.
> > >
> > I hope this is true.  I don't know how to check that nothing in
> > this category has been included in lib.
> >
> > >>
> > >> By doing this we solve the conflict problems and it becomes a distro
> > >> size issue to decide whether 3 should be in the main binary distro
> > >> or available separately.
> > >
> > >
> > > IMO the samples should be small and not cause a size problem, and
> > > therefore should stay in the distro.
> > >
> > +1 that this is how it should be, but it is definitely not the case
> > today.  The samples make up around 50MB of the 100MB total size of
> > the binary distro.  This needs to be fixed.
> >
> > >  Since 3 will be clearly separated from 1
> > >
> > >> and 2, it will be easy to see how much extra size it is contributing.
>
> > >>
> > >> The other dimension of splitting the distro by functional contents
> > >> is orthogonal to the above and is also worth exploring.  I'd suggest
> > >> the following distro packages:
> > >>
> > >> 1. Base runtime with functional capabilities that almost everyone
> > >>    will want to use, and associated samples.
> > >> 2. A number of extension bundles (either depending only on the base,
> > >>    or possibly depending on other bundles), and associated samples.
> > >>
> > >> If people think this approach makes sense then we could talk about
> > >> what the base distro and extension bundles should contain.
> > >
> > >
> > > Makes sense to me, I'd suggest the following packages:
> > > - base SCA runtime (assembly, policy fwk, impl-java)
> > > - web services package (ws binding + related databindings)
> > > - web 2.0 package (json, dwr, widget, atom, scripting)
> > > - data integration (impl-data, openjpa)
> > > - business process integration (bpel, xquery)
> > > - jee integration (ejb, jms, rmi)
> > > - spring + osgi integration (spring, osgi)
> > > - all-in-one, for people who don't have time to solve puzzles.
> > >
> > This looks pretty good as a starting point.  If we find that
> > people are normally downloading the same combinations, we could
> > look at merging these combinations.
> >
> > > Perhaps group web services and web 2.0 together, I'm not sure.
> > >
> > I think these shouldn't be combined.  Web 2.0 applications don't
> > always use Web services.
> >
> > > Also I'm not sure about where to put policies like security,
> > > reliability, transactions.
> > >
> > Wouldn't these normally be applied to a binding?  If so, they should
> > go with that binding IMO.
> >
> >
> Right now the distribution is nice and simple which makes it easy for
> users
> to figure out what they want and it makes the download page very clear.
> Having multiple downloads reduces the download size but i think it needs
> to
> be weighed against the extra complexity doing that might bring, so I'd
> like
> to see more detail about how things would look before this happens.
>
> The main reason the binary distribution is large is because the webapp
> samples are each including copies of the the Tuscany runtime dependencies.
> We've talked several times about this and i thought there was (at least
> some) agreement that the webapp samples shouldn't be like this but instead
>
> all the samples should be simple sca contribution jars. If we fix that
> then
> the size problem goes away (and it simplifies the sample build scripts).

I was under the impression that there is already work ongoing to try this
out.

>
>
> So an alternative to splitting up the binary distribution could be:
>
> - keep the current standalone runtime using all the jars in the
> distribution
> lib directory
> - make all samples simple sca contribution jars
> - have a separate Tuscany WAR that you can use to run any/all the samples
> in
> a webapp

I'm with you up to this point. What Tomcat deep integration work is going on
(I do know about the Geronimo stuff).

>
> - fix Tomcat deep integration and document how to do it (by copying the
> binary lib directory jars to Tomcat lib etc)
> (and slightly related - finish the Geronimo integration and get that
> released somewhere and document how to use the sample contribution jars
> with
> it)
>
> All those would by default include all the Tuscany extensions and
> dependencies, we document which jars are for what so advanced users can
> remove what they don't need.

I can do some more processing on (
http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>)
to give some help here if required.

>
>
>   ...ant
>

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[ant elder <an...@gmail.com>]

On Nov 22, 2007 1:57 PM, Simon Nash <na...@hursley.ibm.com> wrote:

>
> Jean-Sebastien Delfino wrote:
>
> > [snip]
> > Simon Nash wrote:
> >
> >> Samples are very important for beginning users.  For users who have
> >> moved beyond that stage and are doing real development using Tuscany,
> >> samples are not very important.  If people in this category do want
> >> samples, they are likely to just want to refer to samples source code
> >> to cut and paste snippets as necessary.  Having pre-built sample
> binaries
> >> isn't important for these users, and having the main lib directory
> >> polluted/bloated by samples dependencies is a positive nuisance because
> >> there's no easy way for them to find and remove the redundant files.
> >
> >
> > I didn't think we were polluting the lib directory with sample
> > dependencies, do you have a concrete example?
> >
> I thought this thread was discussing the case of a sample having a
> dependency that the runtime does not have.  If there are no such cases
> at present, then the issue doesn't arise.  However, there could be
> such cases in the future as we add more "application-style" samples,
> and it would be good to have an idea about how such dependencies would
> be handled.
>
> >>
> >> Having these files in Tuscany's lib directory isn't just wasting a few
> >> bits on the disk.  It can be a problem if their version levels conflict
> >> with other versions of the same code that the user has installed.
> >> For "genuine" Tuscany dependencies, such conflicts are a real issue
> >> that must be handled carefully in order to get Tuscany to co-exist with
> >> their other software.  For sample dependencies, there is no actual
> >> conflict unless the user needs to run the specific sample that pulled
> >> in the dependency,
> >
> >
> > Like I said earlier in the initial thread about sample dependencies, I
> > don't think that samples should bring dependencies that are not genuine
> > Tuscany dependencies.
> >
> OK, we are agreed about this.  But what if an application-style sample
> does have a non-Tuscany dependency?  This is certainly possible.  Would
> the Tuscany distro include the dependency, or leave it up to the user
> to download it as a prereq to running the sample?
>
> > but it might take them some time to figure out why
> >
> >> putting the Tuscany lib directory on the classpath is causing other
> >> code in their application to break.
> >>
> >> I'd suggest structuring the binary distribution as follows:
> >>
> >> 1. Tuscany runtime in "modules" and its dependencies in "lib".
> >
> >
> > +1
> >
> >>    At the moment we have separate copies of the Tuscany runtime in
> >>    "modules" and "lib" and I'm not quite sure why.
> >
> >
> > Which JARs are you talking about?
> >
> I'm talking about the tuscany-sca-all.jar in the lib directory, which
> is a combination of the contents of the jars in the modules directory.
> The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar
> as well as referring to all the jars in the modules directory, which
> seems somewhat redundant.
>
> >
> >> 2. Tuscany samples source, READMEs and build files in "samples".
> >
> >
> > +1
> >
> >> 3. Tuscany samples binaries in "modules/samples",
> >
> >
> > I prefer to have the binaries under samples as well, with their source.
> >
> Having them there is more convenient but makes it harder to see how
> much space they are consuming.  I did some investigation, and it
> turns out that these binaries are causing a huge expansion in the
> size of the "samples" directory.
>
> In the 1.0.1 binary distro, the source under the "samples" directory
> occupies around 2.3 MB.  The total size of source plus binaries under
> this directory is 49.5 MB.  This extra 47 MB for samples binaries is
> almost half the total size of the Tuscany binary distro.  I think we
> need to either remove these binaries or separate them out into a
> samples download so that we can get the Tuscany binary distro down
> to a reasonable size.
>
> > with their
> >
> >>    dependencies in "lib/samples".
> >
> >
> > Again samples should not bring additional dependencies in the first
> place.
> >
> I hope this is true.  I don't know how to check that nothing in
> this category has been included in lib.
>
> >>
> >> By doing this we solve the conflict problems and it becomes a distro
> >> size issue to decide whether 3 should be in the main binary distro
> >> or available separately.
> >
> >
> > IMO the samples should be small and not cause a size problem, and
> > therefore should stay in the distro.
> >
> +1 that this is how it should be, but it is definitely not the case
> today.  The samples make up around 50MB of the 100MB total size of
> the binary distro.  This needs to be fixed.
>
> >  Since 3 will be clearly separated from 1
> >
> >> and 2, it will be easy to see how much extra size it is contributing.
> >>
> >> The other dimension of splitting the distro by functional contents
> >> is orthogonal to the above and is also worth exploring.  I'd suggest
> >> the following distro packages:
> >>
> >> 1. Base runtime with functional capabilities that almost everyone
> >>    will want to use, and associated samples.
> >> 2. A number of extension bundles (either depending only on the base,
> >>    or possibly depending on other bundles), and associated samples.
> >>
> >> If people think this approach makes sense then we could talk about
> >> what the base distro and extension bundles should contain.
> >
> >
> > Makes sense to me, I'd suggest the following packages:
> > - base SCA runtime (assembly, policy fwk, impl-java)
> > - web services package (ws binding + related databindings)
> > - web 2.0 package (json, dwr, widget, atom, scripting)
> > - data integration (impl-data, openjpa)
> > - business process integration (bpel, xquery)
> > - jee integration (ejb, jms, rmi)
> > - spring + osgi integration (spring, osgi)
> > - all-in-one, for people who don't have time to solve puzzles.
> >
> This looks pretty good as a starting point.  If we find that
> people are normally downloading the same combinations, we could
> look at merging these combinations.
>
> > Perhaps group web services and web 2.0 together, I'm not sure.
> >
> I think these shouldn't be combined.  Web 2.0 applications don't
> always use Web services.
>
> > Also I'm not sure about where to put policies like security,
> > reliability, transactions.
> >
> Wouldn't these normally be applied to a binding?  If so, they should
> go with that binding IMO.
>
>
Right now the distribution is nice and simple which makes it easy for users
to figure out what they want and it makes the download page very clear.
Having multiple downloads reduces the download size but i think it needs to
be weighed against the extra complexity doing that might bring, so I'd like
to see more detail about how things would look before this happens.

The main reason the binary distribution is large is because the webapp
samples are each including copies of the the Tuscany runtime dependencies.
We've talked several times about this and i thought there was (at least
some) agreement that the webapp samples shouldn't be like this but instead
all the samples should be simple sca contribution jars. If we fix that then
the size problem goes away (and it simplifies the sample build scripts).

So an alternative to splitting up the binary distribution could be:

- keep the current standalone runtime using all the jars in the distribution
lib directory
- make all samples simple sca contribution jars
- have a separate Tuscany WAR that you can use to run any/all the samples in
a webapp
- fix Tomcat deep integration and document how to do it (by copying the
binary lib directory jars to Tomcat lib etc)
(and slightly related - finish the Geronimo integration and get that
released somewhere and document how to use the sample contribution jars with
it)

All those would by default include all the Tuscany extensions and
dependencies, we document which jars are for what so advanced users can
remove what they don't need.

   ...ant

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Simon Nash <na...@hursley.ibm.com>]

Jean-Sebastien Delfino wrote:

> [snip]
> Simon Nash wrote:
> 
>> Samples are very important for beginning users.  For users who have
>> moved beyond that stage and are doing real development using Tuscany,
>> samples are not very important.  If people in this category do want
>> samples, they are likely to just want to refer to samples source code
>> to cut and paste snippets as necessary.  Having pre-built sample binaries
>> isn't important for these users, and having the main lib directory
>> polluted/bloated by samples dependencies is a positive nuisance because
>> there's no easy way for them to find and remove the redundant files.
> 
> 
> I didn't think we were polluting the lib directory with sample 
> dependencies, do you have a concrete example?
> 
I thought this thread was discussing the case of a sample having a
dependency that the runtime does not have.  If there are no such cases
at present, then the issue doesn't arise.  However, there could be
such cases in the future as we add more "application-style" samples,
and it would be good to have an idea about how such dependencies would
be handled.

>>
>> Having these files in Tuscany's lib directory isn't just wasting a few
>> bits on the disk.  It can be a problem if their version levels conflict
>> with other versions of the same code that the user has installed.
>> For "genuine" Tuscany dependencies, such conflicts are a real issue
>> that must be handled carefully in order to get Tuscany to co-exist with
>> their other software.  For sample dependencies, there is no actual
>> conflict unless the user needs to run the specific sample that pulled
>> in the dependency,
> 
> 
> Like I said earlier in the initial thread about sample dependencies, I 
> don't think that samples should bring dependencies that are not genuine 
> Tuscany dependencies.
> 
OK, we are agreed about this.  But what if an application-style sample
does have a non-Tuscany dependency?  This is certainly possible.  Would
the Tuscany distro include the dependency, or leave it up to the user
to download it as a prereq to running the sample?

> but it might take them some time to figure out why
> 
>> putting the Tuscany lib directory on the classpath is causing other
>> code in their application to break.
>>
>> I'd suggest structuring the binary distribution as follows:
>>
>> 1. Tuscany runtime in "modules" and its dependencies in "lib".
> 
> 
> +1
> 
>>    At the moment we have separate copies of the Tuscany runtime in
>>    "modules" and "lib" and I'm not quite sure why.
> 
> 
> Which JARs are you talking about?
> 
I'm talking about the tuscany-sca-all.jar in the lib directory, which
is a combination of the contents of the jars in the modules directory.
The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar
as well as referring to all the jars in the modules directory, which
seems somewhat redundant.

> 
>> 2. Tuscany samples source, READMEs and build files in "samples".
> 
> 
> +1
> 
>> 3. Tuscany samples binaries in "modules/samples",
> 
> 
> I prefer to have the binaries under samples as well, with their source.
> 
Having them there is more convenient but makes it harder to see how
much space they are consuming.  I did some investigation, and it
turns out that these binaries are causing a huge expansion in the
size of the "samples" directory.

In the 1.0.1 binary distro, the source under the "samples" directory
occupies around 2.3 MB.  The total size of source plus binaries under
this directory is 49.5 MB.  This extra 47 MB for samples binaries is
almost half the total size of the Tuscany binary distro.  I think we
need to either remove these binaries or separate them out into a
samples download so that we can get the Tuscany binary distro down
to a reasonable size.

> with their
> 
>>    dependencies in "lib/samples".
> 
> 
> Again samples should not bring additional dependencies in the first place.
> 
I hope this is true.  I don't know how to check that nothing in
this category has been included in lib.

>>
>> By doing this we solve the conflict problems and it becomes a distro
>> size issue to decide whether 3 should be in the main binary distro
>> or available separately.
> 
> 
> IMO the samples should be small and not cause a size problem, and 
> therefore should stay in the distro.
> 
+1 that this is how it should be, but it is definitely not the case
today.  The samples make up around 50MB of the 100MB total size of
the binary distro.  This needs to be fixed.

>  Since 3 will be clearly separated from 1
> 
>> and 2, it will be easy to see how much extra size it is contributing.
>>
>> The other dimension of splitting the distro by functional contents
>> is orthogonal to the above and is also worth exploring.  I'd suggest
>> the following distro packages:
>>
>> 1. Base runtime with functional capabilities that almost everyone
>>    will want to use, and associated samples.
>> 2. A number of extension bundles (either depending only on the base,
>>    or possibly depending on other bundles), and associated samples.
>>
>> If people think this approach makes sense then we could talk about
>> what the base distro and extension bundles should contain.
> 
> 
> Makes sense to me, I'd suggest the following packages:
> - base SCA runtime (assembly, policy fwk, impl-java)
> - web services package (ws binding + related databindings)
> - web 2.0 package (json, dwr, widget, atom, scripting)
> - data integration (impl-data, openjpa)
> - business process integration (bpel, xquery)
> - jee integration (ejb, jms, rmi)
> - spring + osgi integration (spring, osgi)
> - all-in-one, for people who don't have time to solve puzzles.
> 
This looks pretty good as a starting point.  If we find that
people are normally downloading the same combinations, we could
look at merging these combinations.

> Perhaps group web services and web 2.0 together, I'm not sure.
> 
I think these shouldn't be combined.  Web 2.0 applications don't
always use Web services.

> Also I'm not sure about where to put policies like security, 
> reliability, transactions.
> 
Wouldn't these normally be applied to a binding?  If so, they should
go with that binding IMO.

   Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[Jean-Sebastien Delfino <js...@apache.org>]

[snip]
Simon Nash wrote:
> Samples are very important for beginning users.  For users who have
> moved beyond that stage and are doing real development using Tuscany,
> samples are not very important.  If people in this category do want
> samples, they are likely to just want to refer to samples source code
> to cut and paste snippets as necessary.  Having pre-built sample binaries
> isn't important for these users, and having the main lib directory
> polluted/bloated by samples dependencies is a positive nuisance because
> there's no easy way for them to find and remove the redundant files.

I didn't think we were polluting the lib directory with sample 
dependencies, do you have a concrete example?


> 
> Having these files in Tuscany's lib directory isn't just wasting a few
> bits on the disk.  It can be a problem if their version levels conflict
> with other versions of the same code that the user has installed.
> For "genuine" Tuscany dependencies, such conflicts are a real issue
> that must be handled carefully in order to get Tuscany to co-exist with
> their other software.  For sample dependencies, there is no actual
> conflict unless the user needs to run the specific sample that pulled
> in the dependency,

Like I said earlier in the initial thread about sample dependencies, I 
don't think that samples should bring dependencies that are not genuine 
Tuscany dependencies.

but it might take them some time to figure out why
> putting the Tuscany lib directory on the classpath is causing other
> code in their application to break.
> 
> I'd suggest structuring the binary distribution as follows:
> 
> 1. Tuscany runtime in "modules" and its dependencies in "lib".

+1

>    At the moment we have separate copies of the Tuscany runtime in
>    "modules" and "lib" and I'm not quite sure why.

Which JARs are you talking about?


> 2. Tuscany samples source, READMEs and build files in "samples".

+1

> 3. Tuscany samples binaries in "modules/samples",

I prefer to have the binaries under samples as well, with their source.

with their
>    dependencies in "lib/samples".

Again samples should not bring additional dependencies in the first place.

> 
> By doing this we solve the conflict problems and it becomes a distro
> size issue to decide whether 3 should be in the main binary distro
> or available separately.

IMO the samples should be small and not cause a size problem, and 
therefore should stay in the distro.


  Since 3 will be clearly separated from 1
> and 2, it will be easy to see how much extra size it is contributing.
> 
> The other dimension of splitting the distro by functional contents
> is orthogonal to the above and is also worth exploring.  I'd suggest
> the following distro packages:
> 
> 1. Base runtime with functional capabilities that almost everyone
>    will want to use, and associated samples.
> 2. A number of extension bundles (either depending only on the base,
>    or possibly depending on other bundles), and associated samples.
> 
> If people think this approach makes sense then we could talk about
> what the base distro and extension bundles should contain.

Makes sense to me, I'd suggest the following packages:
- base SCA runtime (assembly, policy fwk, impl-java)
- web services package (ws binding + related databindings)
- web 2.0 package (json, dwr, widget, atom, scripting)
- data integration (impl-data, openjpa)
- business process integration (bpel, xquery)
- jee integration (ejb, jms, rmi)
- spring + osgi integration (spring, osgi)
- all-in-one, for people who don't have time to solve puzzles.

Perhaps group web services and web 2.0 together, I'm not sure.

Also I'm not sure about where to put policies like security, 
reliability, transactions.

Thoughts?

-- 
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)

[ant elder <an...@gmail.com>]

On Nov 18, 2007 9:31 PM, Simon Nash <na...@hursley.ibm.com> wrote:

> I'm starting a new thread for this as suggested by Sebastien.
>
>   Simon
>
> Simon Laws wrote:
>
> > On Nov 15, 2007 6:54 PM, Simon Nash <nash@hursley.ibm.com > wrote:
> >
> > (cut)
> >>
> >>I don't think we should put sample dependencies in the bin distro lib
> >>folder.  If we need to include them in the bin distro (and I'm not 100%
> >>convinced about that), then I think they should go in some other
> >>directory.
> >>
> >>An alternative approach would be to have a samples distro that contains
> >>the samples plus dependencies that are only used by the samples and not
> >>by the main runtime.  I think this is better as it allows us to add more
> >>samples without pushing up the size of the main binary distro.
> >
> >
> > Personally I like to see samples with whatever I download and I'd rather
>
> > have a bigger binary distro than a separate download. If there is a real
> > need to reduce the distribution size can we do it in a different way,
> for
> > example, have groups of extensions (and their samples) distributed
> > separately?
> >
> Samples are very important for beginning users.  For users who have
> moved beyond that stage and are doing real development using Tuscany,
> samples are not very important.  If people in this category do want
> samples, they are likely to just want to refer to samples source code
> to cut and paste snippets as necessary.  Having pre-built sample binaries
> isn't important for these users, and having the main lib directory
> polluted/bloated by samples dependencies is a positive nuisance because
> there's no easy way for them to find and remove the redundant files.
>
> Having these files in Tuscany's lib directory isn't just wasting a few
> bits on the disk.  It can be a problem if their version levels conflict
> with other versions of the same code that the user has installed.
> For "genuine" Tuscany dependencies, such conflicts are a real issue
> that must be handled carefully in order to get Tuscany to co-exist with
> their other software.  For sample dependencies, there is no actual
> conflict unless the user needs to run the specific sample that pulled
> in the dependency, but it might take them some time to figure out why
> putting the Tuscany lib directory on the classpath is causing other
> code in their application to break.
>
> I'd suggest structuring the binary distribution as follows:
>
> 1. Tuscany runtime in "modules" and its dependencies in "lib".
>    At the moment we have separate copies of the Tuscany runtime in
>    "modules" and "lib" and I'm not quite sure why.
> 2. Tuscany samples source, READMEs and build files in "samples".
> 3. Tuscany samples binaries in "modules/samples", with their
>    dependencies in "lib/samples".
>
> By doing this we solve the conflict problems and it becomes a distro
> size issue to decide whether 3 should be in the main binary distro
> or available separately.  Since 3 will be clearly separated from 1
> and 2, it will be easy to see how much extra size it is contributing.
>
> The other dimension of splitting the distro by functional contents
> is orthogonal to the above and is also worth exploring.  I'd suggest
> the following distro packages:
>
> 1. Base runtime with functional capabilities that almost everyone
>    will want to use, and associated samples.
> 2. A number of extension bundles (either depending only on the base,
>    or possibly depending on other bundles), and associated samples.
>
> If people think this approach makes sense then we could talk about
> what the base distro and extension bundles should contain.
>
>   Simon
>
>
I think we should try to get to where the samples are just simple sca
contribution jars - just the .composite files and whatever resources, Java
classes or BPEL or Javascript files etc that the sample uses. All the
dependency jars Tuscany uses to support running that - Ode, Axis2, Rhino and
BSF etc and all the various Tuscany module jars - are a Tuscany
implementation detail and the samples should be free from any reference to
those. If we can do this then the sample build scripts become simple and the
samples are tiny so there's no size problem at all with including them in a
distribution.

   ...ant