subject:"Distribution zips and what they contain, was\: SCA runtimes"


ant elder wrote:

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

I wonder if some of this debate is due to us not all talking about they same
thing so maybe it would help to go back to this proposal:

Here's what I'd like to see as a user:

- a short list of API JARs that I can add to my dev compile/build path

- a single small launcher or bootstrap JAR that takes care of bootstrapping
the Tuscany runtime

- the launcher should detect the presence of installed extensions in a
particular Tuscany installation

- as a user / app developer I should not have to know the list of JARs from
all these extensions.



This is a fundamentally different approach from what we do today where we
have all the Tuscany jars and dependencies on the application classpath. One
of the main reasons for having jars of aggregated modules is to make it
easier for users but if we change to have a runtime launcher which handles
the all the module jars instead of the user then that reason goes away.

To make this clear, today if a user has an Ant build script for their
application that build script needs to hardcode each Tuscany module jar and
dependency jar name so the build script breaks every time we change things.
The tuscany-all and manifest jars help some but as has been pointed they
have other problems. If we change to use the launcher approach then the Ant
build script just needs to hardcode the Tuscany API and launcher bootstrap
jar names and the location of the Tuscany install, and those few names
should not change much over Tuscany releses so the user application doesn't
get broken when we change Tuscany internal things. It doesn't really matter
to the user if the actual Tuscany install folder has 10 jars or 200 jars all
the they care about is the install location and the launcher handles it all
for them. This is similar to developing webapps for Tomcat, to the user all
they care about is the servlet-api jar and where Tomcat is installed, they
don't care whats in the Tomcat server lib directory.


One place where the number of jars definitely does show through is
when retrieving these artifacts from the maven repos.  Also, as
discussed in your other email on this thread, when embedding and
packaging Tuscany in other environments, it will be necessary to
deal with the physical distributed artifacts.


We did use this launcher approach back in M2 and we changed in 0.90 as a
launcher makes things harder for Tuscany developers, for example when
debugging Tuscany internals, but maybe _now_ it would be better to change
back to a launcher approach as it makes things easier for users.


I can see the advantages, and I'm OK with this as long as we can make
the launcher and registry work conveniently in all the embedded
scenarios where Tuscany might be used.

I'm not quite clear on how 3rd party libraries would be handled using
the registry approach.  Would these continue to be taken from the
classpath, or would they be loaded from the registry?  For ease of
integration with user/application code that uses some of the same
libraries, I think it's best to take these from the classpath, except
when running in an OSGi environment.

  Simon


   ...ant

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes


ant elder wrote:

On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:


Raymond Feng wrote:


Hi,

There are a few patterns we use to determine if a maven module is
required. Let's take the contribution stuff as an example.

1) contribution contains the interfaces for the contribution model and
default implementation classes, SPIs and extension points
2) contribution-xml deals with the reading/writing the xml document for
the sca-contribution.xml
3) contribution-java, contribution-namspace, contribution-resource deal
with a specific perspective of the contribution, for example, namespace,
java, resource
4) contribution-osgi, contribution-groovy support specific packaging
schemes of the SCA contributions.

Please note there is a tree-like dependency graph. I don't think it makes
sense to merge the siblings into one module. Since an ancestor (for example
contribution) are shared by mulitple children (-xml, -osgi, etc), it also
not desirable to merge the common ancestor with other modules.

For databinding related modules, we have a similar strcuture:
1) databinding: The base model, SPIs and transformers for various XML
technologies
2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
individual databinding technologies
3) core-databinding: A set of hook code that leverage the databinding
framework in the invocation chains (data transformation interceptors)

We can use 1 as the data transformation utility in binding/implementation
or even 3rd party code without 3. We can also pick one or more modules from
2.

What I'm trying to point out is that our maven module structure reflects
the nature of the feature units and dependencies fairly well. IMO, each
module maps well into an OSGi bundle. IMHO, both the maven module and OSGi
bundle follow the same principles and the results should be consistent.

Thanks,
Raymond



+1 to all that, makes a lot of sense to me!

 Sorry, but it doesn't make sense to me.  If there is no user scenario

that can pull in contribution-java but not contribution-resource,
or vice versa, I don't see why we would choose to expose these in
our distro as separate bundles.  For the databindings, there are
user scenarios in which a subset would be needed by different users,
so things like databinding-jaxb and databinding-sdo should be in
separate bundles.  However, core-databinding and databinding would
always be used together, so should be in the same bundle.

There might be a reason for keeping these modules separate in the
maven build, to reflect an internal functional split.  This internal
structure is not relevant to Tuscany users and should not be exposed
to them.

I think our distro should have a bundle for a minimal basic core and
bunldes for additional optional components that can be used in
different combinations.  The granularity of these bundles should be
determined by what possible combinations make sense for people using
the binary distro.

 Simon



I do also agree with this despite what i just posted about how if we use the
launcher approach then the actual module jars don't matter to users :)

One group of "users" we want for Tuscany are those embedding Tuscany in
other products, so having some aggregated jars that group modules by
functionality would make it easier for them - eg an aggregated jar that
contains the minimal Tuscany core runtime modules, another jar with all the
web services related modules etc. Its really hard for an outsider (or even
insider for that mater) working out what modules are needed for what, look
at the tuscany-geronimo integration code which has never managed to keep up
with Tuscany changes.

I think we could do both, if we go for a new launcher approach and OSGi'ify
everything then it might even make it easier to get the aggregated jars
working well and its not so much overhead for us to maintain both sets of
jars and use which ever are appropriate depending on the circumstances. The
key thing will be to get _consensus_ on it so we're all working together
instead of what we have now which seems to be we each focus on the bits
we're interested in sometimes to the detriment of what other are trying to
do.


Actually this isn't quite what I was saying.  (Sorry that I wasn't clear.)
I'm talking about the lowest level components that we distribute as
binaries, not about larger groupings that are created from these components
to provide convenient aggregations of functionality.  These groupings
might be useful as well, as you are suggesting here and Graham suggested
in his recent post.

So back to the basic components.  I see no value at this level in breaking
things down any lower than a unit of functionality that might be included
or excluded as a whole from some valid scenario.  To give an example,
I wouldn't put "everything related to Web services" in a single basic
component, because some users might want to create a minimal Web services
configuration without Web services security an

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-12 Thread ant elder

On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <[EMAIL PROTECTED]> wrote:

> Jean-Sebastien Delfino wrote:
>
>> Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> There are a few patterns we use to determine if a maven module is
>>> required. Let's take the contribution stuff as an example.
>>>
>>> 1) contribution contains the interfaces for the contribution model and
>>> default implementation classes, SPIs and extension points
>>> 2) contribution-xml deals with the reading/writing the xml document for
>>> the sca-contribution.xml
>>> 3) contribution-java, contribution-namspace, contribution-resource deal
>>> with a specific perspective of the contribution, for example, namespace,
>>> java, resource
>>> 4) contribution-osgi, contribution-groovy support specific packaging
>>> schemes of the SCA contributions.
>>>
>>> Please note there is a tree-like dependency graph. I don't think it makes
>>> sense to merge the siblings into one module. Since an ancestor (for example
>>> contribution) are shared by mulitple children (-xml, -osgi, etc), it also
>>> not desirable to merge the common ancestor with other modules.
>>>
>>> For databinding related modules, we have a similar strcuture:
>>> 1) databinding: The base model, SPIs and transformers for various XML
>>> technologies
>>> 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
>>> individual databinding technologies
>>> 3) core-databinding: A set of hook code that leverage the databinding
>>> framework in the invocation chains (data transformation interceptors)
>>>
>>> We can use 1 as the data transformation utility in binding/implementation
>>> or even 3rd party code without 3. We can also pick one or more modules from
>>> 2.
>>>
>>> What I'm trying to point out is that our maven module structure reflects
>>> the nature of the feature units and dependencies fairly well. IMO, each
>>> module maps well into an OSGi bundle. IMHO, both the maven module and OSGi
>>> bundle follow the same principles and the results should be consistent.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>> +1 to all that, makes a lot of sense to me!
>>
>>  Sorry, but it doesn't make sense to me.  If there is no user scenario
> that can pull in contribution-java but not contribution-resource,
> or vice versa, I don't see why we would choose to expose these in
> our distro as separate bundles.  For the databindings, there are
> user scenarios in which a subset would be needed by different users,
> so things like databinding-jaxb and databinding-sdo should be in
> separate bundles.  However, core-databinding and databinding would
> always be used together, so should be in the same bundle.
>
> There might be a reason for keeping these modules separate in the
> maven build, to reflect an internal functional split.  This internal
> structure is not relevant to Tuscany users and should not be exposed
> to them.
>
> I think our distro should have a bundle for a minimal basic core and
> bunldes for additional optional components that can be used in
> different combinations.  The granularity of these bundles should be
> determined by what possible combinations make sense for people using
> the binary distro.
>
>  Simon
>
>
I do also agree with this despite what i just posted about how if we use the
launcher approach then the actual module jars don't matter to users :)

One group of "users" we want for Tuscany are those embedding Tuscany in
other products, so having some aggregated jars that group modules by
functionality would make it easier for them - eg an aggregated jar that
contains the minimal Tuscany core runtime modules, another jar with all the
web services related modules etc. Its really hard for an outsider (or even
insider for that mater) working out what modules are needed for what, look
at the tuscany-geronimo integration code which has never managed to keep up
with Tuscany changes.

I think we could do both, if we go for a new launcher approach and OSGi'ify
everything then it might even make it easier to get the aggregated jars
working well and its not so much overhead for us to maintain both sets of
jars and use which ever are appropriate depending on the circumstances. The
key thing will be to get _consensus_ on it so we're all working together
instead of what we have now which seems to be we each focus on the bits
we're interested in sometimes to the detriment of what other are trying to
do.

   ...ant

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-12 Thread ant elder

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

I wonder if some of this debate is due to us not all talking about they same
thing so maybe it would help to go back to this proposal:

Here's what I'd like to see as a user:
>
> - a short list of API JARs that I can add to my dev compile/build path
>
> - a single small launcher or bootstrap JAR that takes care of bootstrapping
> the Tuscany runtime
>
> - the launcher should detect the presence of installed extensions in a
> particular Tuscany installation
>
> - as a user / app developer I should not have to know the list of JARs from
> all these extensions.
>
>
This is a fundamentally different approach from what we do today where we
have all the Tuscany jars and dependencies on the application classpath. One
of the main reasons for having jars of aggregated modules is to make it
easier for users but if we change to have a runtime launcher which handles
the all the module jars instead of the user then that reason goes away.

To make this clear, today if a user has an Ant build script for their
application that build script needs to hardcode each Tuscany module jar and
dependency jar name so the build script breaks every time we change things.
The tuscany-all and manifest jars help some but as has been pointed they
have other problems. If we change to use the launcher approach then the Ant
build script just needs to hardcode the Tuscany API and launcher bootstrap
jar names and the location of the Tuscany install, and those few names
should not change much over Tuscany releses so the user application doesn't
get broken when we change Tuscany internal things. It doesn't really matter
to the user if the actual Tuscany install folder has 10 jars or 200 jars all
the they care about is the install location and the launcher handles it all
for them. This is similar to developing webapps for Tomcat, to the user all
they care about is the servlet-api jar and where Tomcat is installed, they
don't care whats in the Tomcat server lib directory.

We did use this launcher approach back in M2 and we changed in 0.90 as a
launcher makes things harder for Tuscany developers, for example when
debugging Tuscany internals, but maybe _now_ it would be better to change
back to a launcher approach as it makes things easier for users.

   ...ant

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes


Graham Charters wrote:

+1 from me also.  We shouldn't confuse modularity purely with
versioning or whether something can be used on its own.  It's also
about being able to make different combinations of modules to fit
different deployment profiles.


I agree with that, and this should be considered as part of the
use cases that would determine the granularity of the bundles.
If there is no possible deployment profile that can include A and
not B, or vice versa, then I don't see a case for having A and B
as separate bundles.


I think it was Ant who first brought up the distinction between what
make sense in terms of modularity and what makes sense from a user's
perspective.  I think having 1 bundle per Tuscany module and
third-party jar is fine so long as we provide some way of aggregating
those in ways that make sense for how users will consume them.  For
example, I as a user might want to think in terms of a core runtime +
implementation type X and binding Y.  That's three concepts to me, not
123 bundles.


This might be valuable as well as a higher-level grouping of bundles
into different functional profiles.  But it doesn't change the
fundamental question of what is the minimum independently aggregatable
unit of functionality that is encapsulated in a single bundle.

  Simon


Hope this make sense.

Regards, Graham.

2008/6/12 Jean-Sebastien Delfino <[EMAIL PROTECTED]>:

Raymond Feng wrote:

Hi,

There are a few patterns we use to determine if a maven module is
required. Let's take the contribution stuff as an example.

1) contribution contains the interfaces for the contribution model and
default implementation classes, SPIs and extension points
2) contribution-xml deals with the reading/writing the xml document for
the sca-contribution.xml
3) contribution-java, contribution-namspace, contribution-resource deal
with a specific perspective of the contribution, for example, namespace,
java, resource
4) contribution-osgi, contribution-groovy support specific packaging
schemes of the SCA contributions.

Please note there is a tree-like dependency graph. I don't think it makes
sense to merge the siblings into one module. Since an ancestor (for example
contribution) are shared by mulitple children (-xml, -osgi, etc), it also
not desirable to merge the common ancestor with other modules.

For databinding related modules, we have a similar strcuture:
1) databinding: The base model, SPIs and transformers for various XML
technologies
2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
individual databinding technologies
3) core-databinding: A set of hook code that leverage the databinding
framework in the invocation chains (data transformation interceptors)

We can use 1 as the data transformation utility in binding/implementation
or even 3rd party code without 3. We can also pick one or more modules from
2.

What I'm trying to point out is that our maven module structure reflects
the nature of the feature units and dependencies fairly well. IMO, each
module maps well into an OSGi bundle. IMHO, both the maven module and OSGi
bundle follow the same principles and the results should be consistent.

Thanks,
Raymond


+1 to all that, makes a lot of sense to me!

--
Jean-Sebastien

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes


Jean-Sebastien Delfino wrote:

Raymond Feng wrote:

Hi,

There are a few patterns we use to determine if a maven module is 
required. Let's take the contribution stuff as an example.


1) contribution contains the interfaces for the contribution model and 
default implementation classes, SPIs and extension points
2) contribution-xml deals with the reading/writing the xml document 
for the sca-contribution.xml
3) contribution-java, contribution-namspace, contribution-resource 
deal with a specific perspective of the contribution, for example, 
namespace, java, resource
4) contribution-osgi, contribution-groovy support specific packaging 
schemes of the SCA contributions.


Please note there is a tree-like dependency graph. I don't think it 
makes sense to merge the siblings into one module. Since an ancestor 
(for example contribution) are shared by mulitple children (-xml, 
-osgi, etc), it also not desirable to merge the common ancestor with 
other modules.


For databinding related modules, we have a similar strcuture:
1) databinding: The base model, SPIs and transformers for various XML 
technologies
2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The 
individual databinding technologies
3) core-databinding: A set of hook code that leverage the databinding 
framework in the invocation chains (data transformation interceptors)


We can use 1 as the data transformation utility in 
binding/implementation or even 3rd party code without 3. We can also 
pick one or more modules from 2.


What I'm trying to point out is that our maven module structure 
reflects the nature of the feature units and dependencies fairly well. 
IMO, each module maps well into an OSGi bundle. IMHO, both the maven 
module and OSGi bundle follow the same principles and the results 
should be consistent.


Thanks,
Raymond



+1 to all that, makes a lot of sense to me!


Sorry, but it doesn't make sense to me.  If there is no user scenario
that can pull in contribution-java but not contribution-resource,
or vice versa, I don't see why we would choose to expose these in
our distro as separate bundles.  For the databindings, there are
user scenarios in which a subset would be needed by different users,
so things like databinding-jaxb and databinding-sdo should be in
separate bundles.  However, core-databinding and databinding would
always be used together, so should be in the same bundle.

There might be a reason for keeping these modules separate in the
maven build, to reflect an internal functional split.  This internal
structure is not relevant to Tuscany users and should not be exposed
to them.

I think our distro should have a bundle for a minimal basic core and
bunldes for additional optional components that can be used in
different combinations.  The granularity of these bundles should be
determined by what possible combinations make sense for people using
the binary distro.

  Simon

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-12 Thread Graham Charters

+1 from me also.  We shouldn't confuse modularity purely with
versioning or whether something can be used on its own.  It's also
about being able to make different combinations of modules to fit
different deployment profiles.

I think it was Ant who first brought up the distinction between what
make sense in terms of modularity and what makes sense from a user's
perspective.  I think having 1 bundle per Tuscany module and
third-party jar is fine so long as we provide some way of aggregating
those in ways that make sense for how users will consume them.  For
example, I as a user might want to think in terms of a core runtime +
implementation type X and binding Y.  That's three concepts to me, not
123 bundles.

Hope this make sense.

Regards, Graham.

2008/6/12 Jean-Sebastien Delfino <[EMAIL PROTECTED]>:
> Raymond Feng wrote:
>>
>> Hi,
>>
>> There are a few patterns we use to determine if a maven module is
>> required. Let's take the contribution stuff as an example.
>>
>> 1) contribution contains the interfaces for the contribution model and
>> default implementation classes, SPIs and extension points
>> 2) contribution-xml deals with the reading/writing the xml document for
>> the sca-contribution.xml
>> 3) contribution-java, contribution-namspace, contribution-resource deal
>> with a specific perspective of the contribution, for example, namespace,
>> java, resource
>> 4) contribution-osgi, contribution-groovy support specific packaging
>> schemes of the SCA contributions.
>>
>> Please note there is a tree-like dependency graph. I don't think it makes
>> sense to merge the siblings into one module. Since an ancestor (for example
>> contribution) are shared by mulitple children (-xml, -osgi, etc), it also
>> not desirable to merge the common ancestor with other modules.
>>
>> For databinding related modules, we have a similar strcuture:
>> 1) databinding: The base model, SPIs and transformers for various XML
>> technologies
>> 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The
>> individual databinding technologies
>> 3) core-databinding: A set of hook code that leverage the databinding
>> framework in the invocation chains (data transformation interceptors)
>>
>> We can use 1 as the data transformation utility in binding/implementation
>> or even 3rd party code without 3. We can also pick one or more modules from
>> 2.
>>
>> What I'm trying to point out is that our maven module structure reflects
>> the nature of the feature units and dependencies fairly well. IMO, each
>> module maps well into an OSGi bundle. IMHO, both the maven module and OSGi
>> bundle follow the same principles and the results should be consistent.
>>
>> Thanks,
>> Raymond
>>
>
> +1 to all that, makes a lot of sense to me!
>
> --
> Jean-Sebastien
>

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Jean-Sebastien Delfino


Raymond Feng wrote:

Hi,

There are a few patterns we use to determine if a maven module is 
required. Let's take the contribution stuff as an example.


1) contribution contains the interfaces for the contribution model and 
default implementation classes, SPIs and extension points
2) contribution-xml deals with the reading/writing the xml document for 
the sca-contribution.xml
3) contribution-java, contribution-namspace, contribution-resource deal 
with a specific perspective of the contribution, for example, namespace, 
java, resource
4) contribution-osgi, contribution-groovy support specific packaging 
schemes of the SCA contributions.


Please note there is a tree-like dependency graph. I don't think it 
makes sense to merge the siblings into one module. Since an ancestor 
(for example contribution) are shared by mulitple children (-xml, -osgi, 
etc), it also not desirable to merge the common ancestor with other 
modules.


For databinding related modules, we have a similar strcuture:
1) databinding: The base model, SPIs and transformers for various XML 
technologies
2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The 
individual databinding technologies
3) core-databinding: A set of hook code that leverage the databinding 
framework in the invocation chains (data transformation interceptors)


We can use 1 as the data transformation utility in 
binding/implementation or even 3rd party code without 3. We can also 
pick one or more modules from 2.


What I'm trying to point out is that our maven module structure reflects 
the nature of the feature units and dependencies fairly well. IMO, each 
module maps well into an OSGi bundle. IMHO, both the maven module and 
OSGi bundle follow the same principles and the results should be 
consistent.


Thanks,
Raymond



+1 to all that, makes a lot of sense to me!

--
Jean-Sebastien

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Raymond Feng


Hi,

There are a few patterns we use to determine if a maven module is required. 
Let's take the contribution stuff as an example.


1) contribution contains the interfaces for the contribution model and 
default implementation classes, SPIs and extension points
2) contribution-xml deals with the reading/writing the xml document for the 
sca-contribution.xml
3) contribution-java, contribution-namspace, contribution-resource deal with 
a specific perspective of the contribution, for example, namespace, java, 
resource
4) contribution-osgi, contribution-groovy support specific packaging schemes 
of the SCA contributions.


Please note there is a tree-like dependency graph. I don't think it makes 
sense to merge the siblings into one module. Since an ancestor (for example 
contribution) are shared by mulitple children (-xml, -osgi, etc), it also 
not desirable to merge the common ancestor with other modules.


For databinding related modules, we have a similar strcuture:
1) databinding: The base model, SPIs and transformers for various XML 
technologies
2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual 
databinding technologies
3) core-databinding: A set of hook code that leverage the databinding 
framework in the invocation chains (data transformation interceptors)


We can use 1 as the data transformation utility in binding/implementation or 
even 3rd party code without 3. We can also pick one or more modules from 2.


What I'm trying to point out is that our maven module structure reflects the 
nature of the feature units and dependencies fairly well. IMO, each module 
maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle 
follow the same principles and the results should be consistent.


Thanks,
Raymond

--
From: "Simon Nash" <[EMAIL PROTECTED]>
Sent: Wednesday, June 11, 2008 12:33 PM
To: 
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what 
they contain, was: SCA runtimes



Comments inline.

  Simon

Rajini Sivaram wrote:

On 6/10/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

ant elder wrote:


On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

Simon Nash wrote:

ant elder wrote:

On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <

[EMAIL PROTECTED]> wrote:

Jean-Sebastien Delfino wrote:
I'd like to discuss the following: "What distro Zips are we 
building

and
what do they contain?"

I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need

I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
 core assembly model and runtime
 Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
 WS binding, Web 2.0 bindings, Scripting components, Widget
components

- tuscany-jee.zip - For JEE app integration
 EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
 BPEL and XQuery components

- tuscany-all.zip - all of the above

Note that I'm not trying to tackle release cycles and the 
potential

for
releasing the above zips independently in this discussion and I'm

assuming

that we release all of the above together.

I'm also assuming that the relevant samples are included in each 
zip.


 This email was from 1/22/08, generated a lot of discussion for 
about

3


weeks, lots of opinions, no conclusion, no commits :)


No commits as we haven't found much consensus yet.

 I still think the same as what I had posted then, plus additional
ideas:

- Use OSGi exports/imports to export clean SPIs, hide internals, 
and


refine

the contents of the distros and their dependencies.
Disclaimer - Please don't get me wrong I'm not saying that one 
distro

==

one

OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think 
that

declaring and enforcing clean dependencies using OSGi will help us
refine
the contents of each distro.

 The term "enforcing" seems to suggest that there might be an OSGi


dependency for the Tuscany runtime.  I don't know if this was

intended.  I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.

Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi

environment...


What would be the granularity of these OSGi bundles?  If the bundles

are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
 a) Ex

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Simon Nash


Comments inline.

  Simon

Rajini Sivaram wrote:

On 6/10/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

ant elder wrote:


On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

Simon Nash wrote:

ant elder wrote:

On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <

[EMAIL PROTECTED]> wrote:

Jean-Sebastien Delfino wrote:

I'd like to discuss the following: "What distro Zips are we building

and
what do they contain?"

I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need

I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
 core assembly model and runtime
 Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
 WS binding, Web 2.0 bindings, Scripting components, Widget
components

- tuscany-jee.zip - For JEE app integration
 EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
 BPEL and XQuery components

- tuscany-all.zip - all of the above

Note that I'm not trying to tackle release cycles and the potential
for
releasing the above zips independently in this discussion and I'm

assuming

that we release all of the above together.


I'm also assuming that the relevant samples are included in each zip.

 This email was from 1/22/08, generated a lot of discussion for about
3


weeks, lots of opinions, no conclusion, no commits :)


No commits as we haven't found much consensus yet.

 I still think the same as what I had posted then, plus additional
ideas:


- Use OSGi exports/imports to export clean SPIs, hide internals, and

refine

the contents of the distros and their dependencies.

Disclaimer - Please don't get me wrong I'm not saying that one distro
==

one

OSGi bundle, as I've already said several times on the list that the

big-OSGi-bundle approach didn't make sense to me :) I just think that
declaring and enforcing clean dependencies using OSGi will help us
refine
the contents of each distro.

 The term "enforcing" seems to suggest that there might be an OSGi


dependency for the Tuscany runtime.  I don't know if this was

intended.  I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.

Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi

environment...


What would be the granularity of these OSGi bundles?  If the bundles

are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
 a) Export more than we really believe is correct.  This
  leaves us in the current unsatisfactory position of exposing
  unwanted implementation internals.
 b) Combine multiple maven modules with a close implementation
  affinity into a single OSGi bundle, and only expose true
  APIs or SPIs from these bundles.
 c) Refactor the code to remove dependencies on internals of other
  modules, and create new SPIs or APIs when this isn't possible.

I believe a combination of b) and c) is the best approach.

We've already rehashed this (and disagreed on this) in several other

threads, where I've already given my opinion:
- 1 bundle per module
- clean API/SPI imports/exports



By "1 bundle per module" do you mean any sort bundled jar combining
multiple
of our tuscany/java/sca/module jars is not worth pursuing?

  ...ant



I think that the right design is one bundle per maven module.





From an OSGi point of view I would like to ensure that we will continue to

have one bundle per 3rd party jar and that these will not be aggregated
regardless of how the distribution is zipped up.

As for one bundle per maven module, I think there are pros and cons for
finely grained and coarsely grained bundles, and it is really just a matter
of preference. Since we anyway have nearly 150 3rd party bundles/jars
anyway, I personally dont see any problem with one bundle per module.


I have a different view on this.  See below.


I don't think that aggregating multiple modules into a single bundle makes

much sense, or they should be aggregated in a single Maven module in the
first place.



IMHO modularizing Tuscany is about code quality and maintenance - something
internal benefitting Tuscany developers. So we have 100 "modules" based on
the developer's view of Tuscany internals. That does not necessarily mean
that end users have to deal with 100 bundles. If 20 core modules are very
tightly coupled together and will only operate with each other, as far as an
end user is concerned, this could as well be one bundle. Can a Tuscany user
combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even
implementation-java with implementation-java-r

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Graham Charters

Hi Rajini, couple of comments below

2008/6/11 Rajini Sivaram <[EMAIL PROTECTED]>:
> On 6/11/08, Graham Charters <[EMAIL PROTECTED]> wrote:
>>
>> If we assume one bundle per Tuscany module for developers, perhaps
>> there's a need for a separate concept that provides a simplified view
>> for users?  The SpringSource Application Platform has the concept of a
>> library, which has caused much debate in the OSGi world (it has its
>> own manifest header).  A library is a collection of bundles which
>> gives the developer a single 'thing' on which to depend.  At runtime
>> the concept goes away and just results in Import/Export-Package
>> statements created through manifest re-writing (the library does not
>> affect package visibility).  I'm not suggesting we use the same
>> approach, but it just highlights that others a felt the need for an
>> 'aggregation' concept.
>>
>> I wonder if a bundle repository might also provide such a capability,
>> but I'm not too familiar with things like OBR at the moment.
>
>
> OBR does provide similar capability, but IMO the problem with all these
> approaches (OBR, SpringSource library) is that none of them is a standard. I
> just hope we dont invent yet another one.
>

RFC 112 covers the design for a Bundle Repository (inspired by OBR) so
is some way along the path to being a standard.  This might make the
OBR approach a safer bet.

> On the subject of the ExtensionRegistry.  This is not a standard OSGi
>> feature, but I've been told the Equinox implementation should run on
>> any standard OSGi implementation (e.g. Felix).  Is there any reason
>> why we wouldn't just use the standard service registry?  It has all
>> the features required to manage the lifecycle of new extensions being
>> installed/uninstalled, etc.
>
>
> You have probably read this already, but others may find Neil Bartlett's
> discussion useful:
> http://www.eclipsezone.com/articles/extensions-vs-services/
> I dont actually have an opinion, just pointing to the docs.
>

Yes, but thanks for the pointer.  It's an excellent article.  My
comment was less about the technical pros/cons of each approach and
more about the standards aspect, although the technical aspects need
to be considered.

> Regards, Graham.
>>
>> 2008/6/11 ant elder <[EMAIL PROTECTED]>:
>> > On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
>> > [EMAIL PROTECTED]> wrote:
>> >
>> > 
>> >
>> > If we are anyway going to require a "launcher" of some form,
>> >> wouldn't it be just as easy to maintain one-bundle-per-module?
>> >>
>> >
>> > I agree, if we go back to requiring a launcher that changes a lot how
>> we'd
>> > could put this together. I'm not at all against requiring a launcher as
>> that
>> > does make things easier in some respects, but lets remember why we did
>> used
>> > to do this and then chucked it out in the 0.90 rewrite ;)
>> >
>> >   ...ant
>> >
>>
>
>
>
> --
> Thank you...
>
> Regards,
>
> Rajini
>

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Graham Charters

2008/6/11 ant elder <[EMAIL PROTECTED]>:
> On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram <
> [EMAIL PROTECTED]> wrote:
>
> ,snip>
>
>
>>
>> You have probably read this already, but others may find Neil Bartlett's
>> discussion useful:
>> http://www.eclipsezone.com/articles/extensions-vs-services/
>>
>
> Great article, thanks for the link. Thats over a year old now so has much
> changed eg in relation to comments like "The "delayed" services feature
> requires some small tweaks to the basic Equinox runtime, and these tweaks
> have not been implemented yet in the released version 3.2. They do not
> appear at all yet (at the time of writing) in the other open source OSGi
> runtimes, Apache Felix and Knopflerfish."?
>
>   ...ant
>

The delayed services feature is supported in Equinox.  The equinox
implementation was improved by a contribution from Prosyst.

Felix has DS support and documentation mentions the "immediate"
attribute used to control delayed services, so I'm guessing it is also
supported in that project.

I've not looked at Knopflerfish.

Regards, Graham

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread ant elder

On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:

,snip>

>
> You have probably read this already, but others may find Neil Bartlett's
> discussion useful:
> http://www.eclipsezone.com/articles/extensions-vs-services/
>

Great article, thanks for the link. Thats over a year old now so has much
changed eg in relation to comments like "The "delayed" services feature
requires some small tweaks to the basic Equinox runtime, and these tweaks
have not been implemented yet in the released version 3.2. They do not
appear at all yet (at the time of writing) in the other open source OSGi
runtimes, Apache Felix and Knopflerfish."?

   ...ant

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Rajini Sivaram

On 6/11/08, Graham Charters <[EMAIL PROTECTED]> wrote:
>
> If we assume one bundle per Tuscany module for developers, perhaps
> there's a need for a separate concept that provides a simplified view
> for users?  The SpringSource Application Platform has the concept of a
> library, which has caused much debate in the OSGi world (it has its
> own manifest header).  A library is a collection of bundles which
> gives the developer a single 'thing' on which to depend.  At runtime
> the concept goes away and just results in Import/Export-Package
> statements created through manifest re-writing (the library does not
> affect package visibility).  I'm not suggesting we use the same
> approach, but it just highlights that others a felt the need for an
> 'aggregation' concept.
>
> I wonder if a bundle repository might also provide such a capability,
> but I'm not too familiar with things like OBR at the moment.


OBR does provide similar capability, but IMO the problem with all these
approaches (OBR, SpringSource library) is that none of them is a standard. I
just hope we dont invent yet another one.

On the subject of the ExtensionRegistry.  This is not a standard OSGi
> feature, but I've been told the Equinox implementation should run on
> any standard OSGi implementation (e.g. Felix).  Is there any reason
> why we wouldn't just use the standard service registry?  It has all
> the features required to manage the lifecycle of new extensions being
> installed/uninstalled, etc.


You have probably read this already, but others may find Neil Bartlett's
discussion useful:
http://www.eclipsezone.com/articles/extensions-vs-services/
I dont actually have an opinion, just pointing to the docs.

Regards, Graham.
>
> 2008/6/11 ant elder <[EMAIL PROTECTED]>:
> > On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
> > [EMAIL PROTECTED]> wrote:
> >
> > 
> >
> > If we are anyway going to require a "launcher" of some form,
> >> wouldn't it be just as easy to maintain one-bundle-per-module?
> >>
> >
> > I agree, if we go back to requiring a launcher that changes a lot how
> we'd
> > could put this together. I'm not at all against requiring a launcher as
> that
> > does make things easier in some respects, but lets remember why we did
> used
> > to do this and then chucked it out in the 0.90 rewrite ;)
> >
> >   ...ant
> >
>



-- 
Thank you...

Regards,

Rajini

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Graham Charters

If we assume one bundle per Tuscany module for developers, perhaps
there's a need for a separate concept that provides a simplified view
for users?  The SpringSource Application Platform has the concept of a
library, which has caused much debate in the OSGi world (it has its
own manifest header).  A library is a collection of bundles which
gives the developer a single 'thing' on which to depend.  At runtime
the concept goes away and just results in Import/Export-Package
statements created through manifest re-writing (the library does not
affect package visibility).  I'm not suggesting we use the same
approach, but it just highlights that others a felt the need for an
'aggregation' concept.

I wonder if a bundle repository might also provide such a capability,
but I'm not too familiar with things like OBR at the moment.

On the subject of the ExtensionRegistry.  This is not a standard OSGi
feature, but I've been told the Equinox implementation should run on
any standard OSGi implementation (e.g. Felix).  Is there any reason
why we wouldn't just use the standard service registry?  It has all
the features required to manage the lifecycle of new extensions being
installed/uninstalled, etc.

Regards, Graham.

2008/6/11 ant elder <[EMAIL PROTECTED]>:
> On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
> [EMAIL PROTECTED]> wrote:
>
> 
>
> If we are anyway going to require a "launcher" of some form,
>> wouldn't it be just as easy to maintain one-bundle-per-module?
>>
>
> I agree, if we go back to requiring a launcher that changes a lot how we'd
> could put this together. I'm not at all against requiring a launcher as that
> does make things easier in some respects, but lets remember why we did used
> to do this and then chucked it out in the 0.90 rewrite ;)
>
>   ...ant
>

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread ant elder

On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:

If we are anyway going to require a "launcher" of some form,
> wouldn't it be just as easy to maintain one-bundle-per-module?
>

I agree, if we go back to requiring a launcher that changes a lot how we'd
could put this together. I'm not at all against requiring a launcher as that
does make things easier in some respects, but lets remember why we did used
to do this and then chucked it out in the 0.90 rewrite ;)

   ...ant

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-11 Thread Rajini Sivaram

On 6/10/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
>
>> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>> [EMAIL PROTECTED]> wrote:
>>
>> Simon Nash wrote:
>>>
>>> ant elder wrote:

 On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]> wrote:
>
> Jean-Sebastien Delfino wrote:
>>
>> I'd like to discuss the following: "What distro Zips are we building
>>> and
>>> what do they contain?"
>>>
>>> I think we could improve our distro scheme to provide:
>>> - smaller packages
>>> - easier for people to find what they need
>>>
>>> I was thinking about the following binary distro zips:
>>>
>>> - tuscany-core.zip - The base that everybody needs.
>>>  core assembly model and runtime
>>>  Java APIs, Java components
>>>
>>> - tuscany-web.zip - For WS and Web developers
>>>  WS binding, Web 2.0 bindings, Scripting components, Widget
>>> components
>>>
>>> - tuscany-jee.zip - For JEE app integration
>>>  EJB, RMI and JMS bindings, Spring components
>>>
>>> - tuscany-process.zip - For process development
>>>  BPEL and XQuery components
>>>
>>> - tuscany-all.zip - all of the above
>>>
>>> Note that I'm not trying to tackle release cycles and the potential
>>> for
>>> releasing the above zips independently in this discussion and I'm
>>>
>>> assuming
>> that we release all of the above together.
>>
>>> I'm also assuming that the relevant samples are included in each zip.
>>>
>>>  This email was from 1/22/08, generated a lot of discussion for about
>>> 3
>>>
>> weeks, lots of opinions, no conclusion, no commits :)
>>
>>
>> No commits as we haven't found much consensus yet.
>
>  I still think the same as what I had posted then, plus additional
> ideas:
>
>> - Use OSGi exports/imports to export clean SPIs, hide internals, and
>>
>> refine
>
> the contents of the distros and their dependencies.
>>
>> Disclaimer - Please don't get me wrong I'm not saying that one distro
>> ==
>>
>> one
>
> OSGi bundle, as I've already said several times on the list that the
>> big-OSGi-bundle approach didn't make sense to me :) I just think that
>> declaring and enforcing clean dependencies using OSGi will help us
>> refine
>> the contents of each distro.
>>
>>  The term "enforcing" seems to suggest that there might be an OSGi
>>
> dependency for the Tuscany runtime.  I don't know if this was
 intended.  I think the right approach is to have a Tuscany+OSGi
 runtime (as we are building in itest\osgi-tuscany) which would
 actually do enforcement, and a non-OSGi Tuscany runtime in which
 the exports/imports are present in the jars but not enforced.

 Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
>>> environment...
>>>
>>>
>>> What would be the granularity of these OSGi bundles?  If the bundles
 are the current maven modules, I think we will find a number of
 classes that need to be exported even though these classes are not
 considered part of the SPI or API that the module provides.
 To resolve this I see the following options:
  a) Export more than we really believe is correct.  This
   leaves us in the current unsatisfactory position of exposing
   unwanted implementation internals.
  b) Combine multiple maven modules with a close implementation
   affinity into a single OSGi bundle, and only expose true
   APIs or SPIs from these bundles.
  c) Refactor the code to remove dependencies on internals of other
   modules, and create new SPIs or APIs when this isn't possible.

 I believe a combination of b) and c) is the best approach.

 We've already rehashed this (and disagreed on this) in several other
>>> threads, where I've already given my opinion:
>>> - 1 bundle per module
>>> - clean API/SPI imports/exports
>>>
>>
>>
>> By "1 bundle per module" do you mean any sort bundled jar combining
>> multiple
>> of our tuscany/java/sca/module jars is not worth pursuing?
>>
>>   ...ant
>>
>>
> I think that the right design is one bundle per maven module.



>From an OSGi point of view I would like to ensure that we will continue to
have one bundle per 3rd party jar and that these will not be aggregated
regardless of how the distribution is zipped up.

As for one bundle per maven module, I think there are pros and cons for
finely grained and coarsely grained bundles, and it is really just a matter
of preference. Since we anyway have nearly 150 3rd party bundles/jars
anyway, I personally dont see any problem with one bundle per module.

I don't think that aggregating multiple modules into a single bundle makes
> much sense, or they should be aggregated in a single Maven module in the
> first place.


IMHO

Re: Distribution zips and what they contain, was: SCA runtimes

On Tue, Jun 10, 2008 at 10:59 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Good debate here, but let's be clear about the big picture before the
> details swamp the debate.
>

Big +1 to that, i really hope we can some consensus on what the
distributions and runtimes should look like before we decide what registries
etc we need to use to implement them.

   ...ant

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

On Tue, Jun 10, 2008 at 7:03 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>> [EMAIL PROTECTED]> wrote:
>>
>>  Simon Nash wrote:
>>>
>>>  ant elder wrote:

  On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]> wrote:
>
>  Jean-Sebastien Delfino wrote:
>>
>>  I'd like to discuss the following: "What distro Zips are we building
>>> and
>>> what do they contain?"
>>>
>>> I think we could improve our distro scheme to provide:
>>> - smaller packages
>>> - easier for people to find what they need
>>>
>>> I was thinking about the following binary distro zips:
>>>
>>> - tuscany-core.zip - The base that everybody needs.
>>>  core assembly model and runtime
>>>  Java APIs, Java components
>>>
>>> - tuscany-web.zip - For WS and Web developers
>>>  WS binding, Web 2.0 bindings, Scripting components, Widget
>>> components
>>>
>>> - tuscany-jee.zip - For JEE app integration
>>>  EJB, RMI and JMS bindings, Spring components
>>>
>>> - tuscany-process.zip - For process development
>>>  BPEL and XQuery components
>>>
>>> - tuscany-all.zip - all of the above
>>>
>>> Note that I'm not trying to tackle release cycles and the potential
>>> for
>>> releasing the above zips independently in this discussion and I'm
>>>
>>>  assuming
>> that we release all of the above together.
>>
>>> I'm also assuming that the relevant samples are included in each zip.
>>>
>>>  This email was from 1/22/08, generated a lot of discussion for about
>>> 3
>>>
>> weeks, lots of opinions, no conclusion, no commits :)
>>
>>
>>  No commits as we haven't found much consensus yet.
>
>  I still think the same as what I had posted then, plus additional
> ideas:
>
>> - Use OSGi exports/imports to export clean SPIs, hide internals, and
>>
>>  refine
>
>  the contents of the distros and their dependencies.
>>
>> Disclaimer - Please don't get me wrong I'm not saying that one distro
>> ==
>>
>>  one
>
>  OSGi bundle, as I've already said several times on the list that the
>> big-OSGi-bundle approach didn't make sense to me :) I just think that
>> declaring and enforcing clean dependencies using OSGi will help us
>> refine
>> the contents of each distro.
>>
>>  The term "enforcing" seems to suggest that there might be an OSGi
>>
> dependency for the Tuscany runtime.  I don't know if this was
 intended.  I think the right approach is to have a Tuscany+OSGi
 runtime (as we are building in itest\osgi-tuscany) which would
 actually do enforcement, and a non-OSGi Tuscany runtime in which
 the exports/imports are present in the jars but not enforced.

  Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
>>> environment...
>>>
>>>
>>>  What would be the granularity of these OSGi bundles?  If the bundles
 are the current maven modules, I think we will find a number of
 classes that need to be exported even though these classes are not
 considered part of the SPI or API that the module provides.
 To resolve this I see the following options:
  a) Export more than we really believe is correct.  This
   leaves us in the current unsatisfactory position of exposing
   unwanted implementation internals.
  b) Combine multiple maven modules with a close implementation
   affinity into a single OSGi bundle, and only expose true
   APIs or SPIs from these bundles.
  c) Refactor the code to remove dependencies on internals of other
   modules, and create new SPIs or APIs when this isn't possible.

 I believe a combination of b) and c) is the best approach.

  We've already rehashed this (and disagreed on this) in several other
>>> threads, where I've already given my opinion:
>>> - 1 bundle per module
>>> - clean API/SPI imports/exports
>>>
>>
>>
>> By "1 bundle per module" do you mean any sort bundled jar combining
>> multiple
>> of our tuscany/java/sca/module jars is not worth pursuing?
>>
>>   ...ant
>>
>>
> I think that the right design is one bundle per maven module. I don't think
> that aggregating multiple modules into a single bundle makes much sense, or
> they should be aggregated in a single Maven module in the first place.
>
>
I'm not sure i agree with that, individual small maven modules are for
making things easier for developers, aggregated jars are for making things
easier for users. There is lots of prior discussion about the pros and cons
of this eg just search for all the projects using the shade plugin and then
their mailing lists when they did that. Though if we do go back to a runtime
launcher approach then users don't need to care so much as the launcher will
hide

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

On Tue, Jun 10, 2008 at 6:52 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> [snip]
>
>> Good requirement, but I don't think that the current manifest +
>> tuscany-all JAR solution is a good one (for example it mixes APIs and
>> internals in the same JAR, doesn't work well with IDEs, works only for one
>> big distro, requires different settings in J2SE and webapps)
>>
>>
> IMHO, the all-in-one package pretty much defeats our modularity. For
> example, all module activators will be called even the extension won't be
> used at all.

Calling a module activator is pretty minimal initialization overhead
especially if it just fails right away with something like a
ClassNotFoundException and the runtime carries on, and this is what happens
with the our bundle jar - you can just use it without the extension
dependencies you don't need and it works fine.  Note I'm not necessarily
saying we should be keeping the single one big bundle jar, i'm just trying
to avoid the impression that the _only_ option we have is everything in
individual separate jars.

> Two extension cannot have different versions of a 3rd party jar.
>
>  Here's what I'd like to see as a user:
>>
>> - a short list of API JARs that I can add to my dev compile/build path
>>
>> - a single small launcher or bootstrap JAR that takes care of
>> bootstrapping the Tuscany runtime
>>
>>
> This is similar to JEE launchClient. If I can invoke the Launcher directly
> in java, I would be happy.
>

So just to be clear on what is being suggested this would be like the
launcher we used to have back in M2 days right?

   ...ant

Re: Distribution zips and what they contain, was: SCA runtimes


Mike Edwards wrote:
...

Are people interested in exploring these ideas?

Jean-Sebastien,

I'll start with the last question first: YES.

But I'd next like to step back from what I can see is developing into a 
somewhat "active" debate (to use a neutral euphemism)


:)

and investigate

the big picture here.


Let me try to understand the motivations (yes, plural, I think) for 
multiple binary distro zips of Tuscany.  My initial reaction to seeing a 
list like the one above is "hmm - complexity - for the end user"  - they 
now have to understand which of those packages they need and install 
each of them separately.  The more packages, the more complexity.


Now, this is only looking at one side of things - why is splitting 
things into packages like that a good idea?  Well, I suppose there is 
the question of download size and size on disk.  More packages = each 
package can be smaller.  You get what you ask for.  The other side is 
smaller runtime size - no unnecessary things get loaded.


For the download size, I see the merits of bacon slicing into sets of 
independent packages.  For the runtime size, other methods (eg lazy 
loading) might be an alternative.


I can see the argument to use an install system like Eclipse, but on the 
other hand, as a user of Eclipse, I have to say that this aspect is one 
of the less satisfactory parts of Eclipse, and it can be frustratingly 
hard to know that you've got the right set of stuff installed.  Part of 
this is about the number of packages and the set of valid combinations.  
If it's a small number then OK, perhaps not a problem.  Once the number 
grows, I think it does become a problem for the end user.


I'm aiming for a small number of packages, similar to the Eclipse 
distributions that people build (a Java developer distro, a Web 
developer distro, an Enterprise distro, a Mobile device distro etc) to 
not have to worry about the bits and pieces. We already had that 
discussion in January and IIRC I had also brought up the similarity 
with Eclipse distros then :)




The question of the approach to OSGi is perhaps different.  I think it 
does make sense to create a bundle-per-module.  It does make sense to 
have clean interfaces for each module with crisp lists of imports and 
exports. (and yes, I know that we are a long way from that today!)


Yes, but I'm not sure we're a long way from that today, except for the 
few cases where people have gone around SPIs. OSGi imports/exports will 
help prevent that, as going around exported SPIs will break the build.




But I don't expect that OSGi bundles should be directly reflected into 
the bigger scale packaging. In other words, the bigger scale packaging 
is aimed at satisfying the user's needs and a big package could have 10 
or 100 module-sized bundles in it, as necessary.  That depends on 
overall function, not on details of the modules used to provide that 
function.


Exactly!
- 1 bundle per module
- n bundles per 'bigger packaging' distro



Good debate here, but let's be clear about the big picture before the 
details swamp the debate.




:)

--
Jean-Sebastien

Re: Distribution zips and what they contain, was: SCA runtimes

2008-06-10 Thread Mike Edwards

Jean-Sebastien Delfino wrote:

I'd like to discuss the following: "What distro Zips are we building
and what do they contain?"

I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need

I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
core assembly model and runtime
Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
WS binding, Web 2.0 bindings, Scripting components, Widget components

- tuscany-jee.zip - For JEE app integration
EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
BPEL and XQuery components

- tuscany-all.zip - all of the above

Note that I'm not trying to tackle release cycles and the potential
for releasing the above zips independently in this discussion and I'm
assuming that we release all of the above together.

I'm also assuming that the relevant samples are included in each zip.

This email was from 1/22/08, generated a lot of discussion for about 3
weeks, lots of opinions, no conclusion, no commits :)

I still think the same as what I had posted then, plus additional ideas:

- Use OSGi exports/imports to export clean SPIs, hide internals, and
refine the contents of the distros and their dependencies.

Disclaimer - Please don't get me wrong I'm not saying that one distro ==
one OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think that
declaring and enforcing clean dependencies using OSGi will help us
refine the contents of each distro.

- Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension
registry mechanism (what we have now in Tuscany or better a combination
of what we have now and the Eclipse Equinox registry for example) to
detect which pieces are installed and activate their capabilities.

Are people interested in exploring these ideas?

Jean-Sebastien,

I'll start with the last question first: YES.

But I'd next like to step back from what I can see is developing into a somewhat "active" debate (to
use a neutral euphemism) and investigate the big picture here.

Let me try to understand the motivations (yes, plural, I think) for multiple binary distro zips of
Tuscany. My initial reaction to seeing a list like the one above is "hmm - complexity - for the end
user" - they now have to understand which of those packages they need and install each of them
separately. The more packages, the more complexity.

Now, this is only looking at one side of things - why is splitting things into packages like that a
good idea? Well, I suppose there is the question of download size and size on disk. More packages
= each package can be smaller. You get what you ask for. The other side is smaller runtime size -
no unnecessary things get loaded.

For the download size, I see the merits of bacon slicing into sets of independent packages. For the
runtime size, other methods (eg lazy loading) might be an alternative.

I can see the argument to use an install system like Eclipse, but on the other hand, as a user of
Eclipse, I have to say that this aspect is one of the less satisfactory parts of Eclipse, and it can
be frustratingly hard to know that you've got the right set of stuff installed. Part of this is
about the number of packages and the set of valid combinations. If it's a small number then OK,
perhaps not a problem. Once the number grows, I think it does become a problem for the end user.

The question of the approach to OSGi is perhaps different. I think it does make sense to create a
bundle-per-module. It does make sense to have clean interfaces for each module with crisp lists of
imports and exports. (and yes, I know that we are a long way from that today!)

But I don't expect that OSGi bundles should be directly reflected into the bigger scale packaging.
In other words, the bigger scale packaging is aimed at satisfying the user's needs and a big package
could have 10 or 100 module-sized bundles in it, as necessary. That depends on overall function,
not on details of the modules used to provide that function.

Good debate here, but let's be clear about the big picture before the details
swamp the debate.

Yours, Mike.

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes


ant elder wrote:

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:


Simon Nash wrote:


ant elder wrote:


On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:


I'd like to discuss the following: "What distro Zips are we building
and
what do they contain?"

I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need

I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
 core assembly model and runtime
 Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
 WS binding, Web 2.0 bindings, Scripting components, Widget components

- tuscany-jee.zip - For JEE app integration
 EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
 BPEL and XQuery components

- tuscany-all.zip - all of the above

Note that I'm not trying to tackle release cycles and the potential for
releasing the above zips independently in this discussion and I'm


assuming
that we release all of the above together.

I'm also assuming that the relevant samples are included in each zip.

 This email was from 1/22/08, generated a lot of discussion for about 3

weeks, lots of opinions, no conclusion, no commits :)



No commits as we haven't found much consensus yet.

 I still think the same as what I had posted then, plus additional ideas:

- Use OSGi exports/imports to export clean SPIs, hide internals, and


refine


the contents of the distros and their dependencies.

Disclaimer - Please don't get me wrong I'm not saying that one distro ==


one


OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think that
declaring and enforcing clean dependencies using OSGi will help us
refine
the contents of each distro.

 The term "enforcing" seems to suggest that there might be an OSGi

dependency for the Tuscany runtime.  I don't know if this was
intended.  I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.


Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
environment...



What would be the granularity of these OSGi bundles?  If the bundles
are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
 a) Export more than we really believe is correct.  This
   leaves us in the current unsatisfactory position of exposing
   unwanted implementation internals.
 b) Combine multiple maven modules with a close implementation
   affinity into a single OSGi bundle, and only expose true
   APIs or SPIs from these bundles.
 c) Refactor the code to remove dependencies on internals of other
   modules, and create new SPIs or APIs when this isn't possible.

I believe a combination of b) and c) is the best approach.


We've already rehashed this (and disagreed on this) in several other
threads, where I've already given my opinion:
- 1 bundle per module
- clean API/SPI imports/exports



 - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension

registry mechanism (what we have now in Tuscany or better a combination
of
what we have now and the Eclipse Equinox registry for example) to detect
which pieces are installed and activate their capabilities.



Can you say a bit more about what an "extension registry mechanism" would
look like?

What the tuscany-all/manifest jar are trying to do is to have users not
need
to know about the internal makeup of Tuscany. So they can simply use
tuscany-all and avoid needing to know about all the dozens of different
Tuscany modules and their dependencies, and that should keep working over
many Tuscany releases whereas as we keep adding/deleting/changing the
modules we keep breaking user builds for each Tuscany release if they
refer
to the individual modules. Maybe the granularity isn't quite right yet
and
we need something in between the all jar and all the individual modules.

Is there much agreement that avoiding users needing to know about the
internal Tuscany modules is a Good Thing?

 Yes, I think this is important.  Ideally the Tuscany core runtime

would figure out which pieces are needed for the domain configuration
and load these pieces automatically.



Good requirement, but I don't think that the current manifest + tuscany-all
JAR solution is a good one (for example it mixes APIs and internals in the
same JAR, doesn't work well with IDEs, works only for one big distro,
requires different settings in J2SE and webapps)



I'm not saying I disagree that the all jar isn't quite the right granu

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes


Raymond Feng wrote:

Hi,

Please see my comments inline.

Thanks,
Raymond

[snip]
Good requirement, but I don't think that the current manifest + 
tuscany-all JAR solution is a good one (for example it mixes APIs and 
internals in the same JAR, doesn't work well with IDEs, works only for 
one big distro, requires different settings in J2SE and webapps)




IMHO, the all-in-one package pretty much defeats our modularity. For 
example, all module activators will be called even the extension won't 
be used at all. Two extension cannot have different versions of a 3rd 
party jar.


That's what I was trying to convey too.


Here's what I'd like to see as a user:

- a short list of API JARs that I can add to my dev compile/build path

- a single small launcher or bootstrap JAR that takes care of 
bootstrapping the Tuscany runtime




This is similar to JEE launchClient. If I can invoke the Launcher 
directly in java, I would be happy.


- the launcher should detect the presence of installed extensions in a 
particular Tuscany installation


+1.


- as a user / app developer I should not have to know the list of JARs 
from all these extensions.


Do we expect the launcher to be smart enough to pick the right set of 
extensions based on the SCA assembly?




Not so fast. I'm trying not to mix these different aspects. That would 
be a separate step.


That's what I've been trying to do with the Node launcher and the 
library provided by the Tuscany Eclipse plugin. More work is required 
to get that vision in place (as the current launcher is still pretty 
rudimentary and only scans an installation directory for JARs).


There's a good extension registry mechanism in Eclipse Equinox [1]. It 
would allow us to rely on a robust mechanism for detecting installed 
extensions, tracking what they provide in an extension registry [2], 
and use a more user friendly syntax for registering extensions using 
plugin.xml files. If we start to integrate more with OSGi I think we 
should just use it (maybe in combination with what we currently have 
with META-INF/services for the cases where we don't use OSGi).




We can have a SPI so that different mechanism of extension discovery can 
be plugged in.


ExtensionRegistry is designed for that, it was modeled after the Eclipse 
IExtensionRegistry. I had been careful at the time to not put anything 
in it that wouldn't map easily to IExtensionRegistry.


 prefer to see both OSGi and META-INF/services

based approaches available.


Me too.




[1] http://www.eclipse.org/equinox/
[2] 
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/


-- Sebastien 




--
Jean-Sebastien

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes


ant elder wrote:

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:


Simon Nash wrote:


ant elder wrote:


On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:


Jean-Sebastien Delfino wrote:


I'd like to discuss the following: "What distro Zips are we building
and
what do they contain?"

I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need

I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
 core assembly model and runtime
 Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
 WS binding, Web 2.0 bindings, Scripting components, Widget components

- tuscany-jee.zip - For JEE app integration
 EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
 BPEL and XQuery components

- tuscany-all.zip - all of the above

Note that I'm not trying to tackle release cycles and the potential for
releasing the above zips independently in this discussion and I'm


assuming
that we release all of the above together.

I'm also assuming that the relevant samples are included in each zip.

 This email was from 1/22/08, generated a lot of discussion for about 3

weeks, lots of opinions, no conclusion, no commits :)



No commits as we haven't found much consensus yet.

 I still think the same as what I had posted then, plus additional ideas:

- Use OSGi exports/imports to export clean SPIs, hide internals, and


refine


the contents of the distros and their dependencies.

Disclaimer - Please don't get me wrong I'm not saying that one distro ==


one


OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think that
declaring and enforcing clean dependencies using OSGi will help us
refine
the contents of each distro.

 The term "enforcing" seems to suggest that there might be an OSGi

dependency for the Tuscany runtime.  I don't know if this was
intended.  I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.


Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
environment...



What would be the granularity of these OSGi bundles?  If the bundles
are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
 a) Export more than we really believe is correct.  This
   leaves us in the current unsatisfactory position of exposing
   unwanted implementation internals.
 b) Combine multiple maven modules with a close implementation
   affinity into a single OSGi bundle, and only expose true
   APIs or SPIs from these bundles.
 c) Refactor the code to remove dependencies on internals of other
   modules, and create new SPIs or APIs when this isn't possible.

I believe a combination of b) and c) is the best approach.


We've already rehashed this (and disagreed on this) in several other
threads, where I've already given my opinion:
- 1 bundle per module
- clean API/SPI imports/exports



By "1 bundle per module" do you mean any sort bundled jar combining multiple
of our tuscany/java/sca/module jars is not worth pursuing?

   ...ant



I think that the right design is one bundle per maven module. I don't 
think that aggregating multiple modules into a single bundle makes much 
sense, or they should be aggregated in a single Maven module in the 
first place.


--
Jean-Sebastien

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

2008-06-10 Thread Raymond Feng


Hi,

Please see my comments inline.

Thanks,
Raymond

[snip]
Good requirement, but I don't think that the current manifest + 
tuscany-all JAR solution is a good one (for example it mixes APIs and 
internals in the same JAR, doesn't work well with IDEs, works only for one 
big distro, requires different settings in J2SE and webapps)




IMHO, the all-in-one package pretty much defeats our modularity. For 
example, all module activators will be called even the extension won't be 
used at all. Two extension cannot have different versions of a 3rd party 
jar.



Here's what I'd like to see as a user:

- a short list of API JARs that I can add to my dev compile/build path

- a single small launcher or bootstrap JAR that takes care of 
bootstrapping the Tuscany runtime




This is similar to JEE launchClient. If I can invoke the Launcher directly 
in java, I would be happy.


- the launcher should detect the presence of installed extensions in a 
particular Tuscany installation


+1.


- as a user / app developer I should not have to know the list of JARs 
from all these extensions.


Do we expect the launcher to be smart enough to pick the right set of 
extensions based on the SCA assembly?




That's what I've been trying to do with the Node launcher and the library 
provided by the Tuscany Eclipse plugin. More work is required to get that 
vision in place (as the current launcher is still pretty rudimentary and 
only scans an installation directory for JARs).


There's a good extension registry mechanism in Eclipse Equinox [1]. It 
would allow us to rely on a robust mechanism for detecting installed 
extensions, tracking what they provide in an extension registry [2], and 
use a more user friendly syntax for registering extensions using 
plugin.xml files. If we start to integrate more with OSGi I think we 
should just use it (maybe in combination with what we currently have with 
META-INF/services for the cases where we don't use OSGi).




We can have a SPI so that different mechanism of extension discovery can be 
plugged in. I would prefer to see both OSGi and META-INF/services based 
approaches available.



[1] http://www.eclipse.org/equinox/
[2] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/

-- Sebastien

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Simon Nash wrote:
>
>> ant elder wrote:
>>
>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>> [EMAIL PROTECTED]> wrote:
>>>
 Jean-Sebastien Delfino wrote:

> I'd like to discuss the following: "What distro Zips are we building
> and
> what do they contain?"
>
> I think we could improve our distro scheme to provide:
> - smaller packages
> - easier for people to find what they need
>
> I was thinking about the following binary distro zips:
>
> - tuscany-core.zip - The base that everybody needs.
>  core assembly model and runtime
>  Java APIs, Java components
>
> - tuscany-web.zip - For WS and Web developers
>  WS binding, Web 2.0 bindings, Scripting components, Widget components
>
> - tuscany-jee.zip - For JEE app integration
>  EJB, RMI and JMS bindings, Spring components
>
> - tuscany-process.zip - For process development
>  BPEL and XQuery components
>
> - tuscany-all.zip - all of the above
>
> Note that I'm not trying to tackle release cycles and the potential for
> releasing the above zips independently in this discussion and I'm
>
 assuming
>>>
 that we release all of the above together.
>
> I'm also assuming that the relevant samples are included in each zip.
>
>  This email was from 1/22/08, generated a lot of discussion for about 3
 weeks, lots of opinions, no conclusion, no commits :)


>>> No commits as we haven't found much consensus yet.
>>>
>>>  I still think the same as what I had posted then, plus additional ideas:

 - Use OSGi exports/imports to export clean SPIs, hide internals, and

>>> refine
>>>
 the contents of the distros and their dependencies.

 Disclaimer - Please don't get me wrong I'm not saying that one distro ==

>>> one
>>>
 OSGi bundle, as I've already said several times on the list that the
 big-OSGi-bundle approach didn't make sense to me :) I just think that
 declaring and enforcing clean dependencies using OSGi will help us
 refine
 the contents of each distro.

  The term "enforcing" seems to suggest that there might be an OSGi
>> dependency for the Tuscany runtime.  I don't know if this was
>> intended.  I think the right approach is to have a Tuscany+OSGi
>> runtime (as we are building in itest\osgi-tuscany) which would
>> actually do enforcement, and a non-OSGi Tuscany runtime in which
>> the exports/imports are present in the jars but not enforced.
>>
>
> Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
> environment...
>
>
>> What would be the granularity of these OSGi bundles?  If the bundles
>> are the current maven modules, I think we will find a number of
>> classes that need to be exported even though these classes are not
>> considered part of the SPI or API that the module provides.
>> To resolve this I see the following options:
>>  a) Export more than we really believe is correct.  This
>>leaves us in the current unsatisfactory position of exposing
>>unwanted implementation internals.
>>  b) Combine multiple maven modules with a close implementation
>>affinity into a single OSGi bundle, and only expose true
>>APIs or SPIs from these bundles.
>>  c) Refactor the code to remove dependencies on internals of other
>>modules, and create new SPIs or APIs when this isn't possible.
>>
>> I believe a combination of b) and c) is the best approach.
>>
>
> We've already rehashed this (and disagreed on this) in several other
> threads, where I've already given my opinion:
> - 1 bundle per module
> - clean API/SPI imports/exports


By "1 bundle per module" do you mean any sort bundled jar combining multiple
of our tuscany/java/sca/module jars is not worth pursuing?

   ...ant

Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes

On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Simon Nash wrote:
>
>> ant elder wrote:
>>
>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>> [EMAIL PROTECTED]> wrote:
>>>
 Jean-Sebastien Delfino wrote:

> I'd like to discuss the following: "What distro Zips are we building
> and
> what do they contain?"
>
> I think we could improve our distro scheme to provide:
> - smaller packages
> - easier for people to find what they need
>
> I was thinking about the following binary distro zips:
>
> - tuscany-core.zip - The base that everybody needs.
>  core assembly model and runtime
>  Java APIs, Java components
>
> - tuscany-web.zip - For WS and Web developers
>  WS binding, Web 2.0 bindings, Scripting components, Widget components
>
> - tuscany-jee.zip - For JEE app integration
>  EJB, RMI and JMS bindings, Spring components
>
> - tuscany-process.zip - For process development
>  BPEL and XQuery components
>
> - tuscany-all.zip - all of the above
>
> Note that I'm not trying to tackle release cycles and the potential for
> releasing the above zips independently in this discussion and I'm
>
 assuming
>>>
 that we release all of the above together.
>
> I'm also assuming that the relevant samples are included in each zip.
>
>  This email was from 1/22/08, generated a lot of discussion for about 3
 weeks, lots of opinions, no conclusion, no commits :)


>>> No commits as we haven't found much consensus yet.
>>>
>>>  I still think the same as what I had posted then, plus additional ideas:

 - Use OSGi exports/imports to export clean SPIs, hide internals, and

>>> refine
>>>
 the contents of the distros and their dependencies.

 Disclaimer - Please don't get me wrong I'm not saying that one distro ==

>>> one
>>>
 OSGi bundle, as I've already said several times on the list that the
 big-OSGi-bundle approach didn't make sense to me :) I just think that
 declaring and enforcing clean dependencies using OSGi will help us
 refine
 the contents of each distro.

  The term "enforcing" seems to suggest that there might be an OSGi
>> dependency for the Tuscany runtime.  I don't know if this was
>> intended.  I think the right approach is to have a Tuscany+OSGi
>> runtime (as we are building in itest\osgi-tuscany) which would
>> actually do enforcement, and a non-OSGi Tuscany runtime in which
>> the exports/imports are present in the jars but not enforced.
>>
>
> Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi
> environment...
>
>
>> What would be the granularity of these OSGi bundles?  If the bundles
>> are the current maven modules, I think we will find a number of
>> classes that need to be exported even though these classes are not
>> considered part of the SPI or API that the module provides.
>> To resolve this I see the following options:
>>  a) Export more than we really believe is correct.  This
>>leaves us in the current unsatisfactory position of exposing
>>unwanted implementation internals.
>>  b) Combine multiple maven modules with a close implementation
>>affinity into a single OSGi bundle, and only expose true
>>APIs or SPIs from these bundles.
>>  c) Refactor the code to remove dependencies on internals of other
>>modules, and create new SPIs or APIs when this isn't possible.
>>
>> I believe a combination of b) and c) is the best approach.
>>
>
> We've already rehashed this (and disagreed on this) in several other
> threads, where I've already given my opinion:
> - 1 bundle per module
> - clean API/SPI imports/exports
>
>
>>  - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension
 registry mechanism (what we have now in Tuscany or better a combination
 of
 what we have now and the Eclipse Equinox registry for example) to detect
 which pieces are installed and activate their capabilities.


>>> Can you say a bit more about what an "extension registry mechanism" would
>>> look like?
>>>
>>> What the tuscany-all/manifest jar are trying to do is to have users not
>>> need
>>> to know about the internal makeup of Tuscany. So they can simply use
>>> tuscany-all and avoid needing to know about all the dozens of different
>>> Tuscany modules and their dependencies, and that should keep working over
>>> many Tuscany releases whereas as we keep adding/deleting/changing the
>>> modules we keep breaking user builds for each Tuscany release if they
>>> refer
>>> to the individual modules. Maybe the granularity isn't quite right yet
>>> and
>>> we need something in between the all jar and all the individual modules.
>>>
>>> Is there much agreement that avoiding users needing to know about the
>>> internal Tuscany modules is a Good Thing?
>>>
>>>  Yes, I think this is important.  Ideally the

Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes


Simon Nash wrote:

ant elder wrote:

On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

Jean-Sebastien Delfino wrote:
I'd like to discuss the following: "What distro Zips are we building 
and

what do they contain?"

I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need

I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
 core assembly model and runtime
 Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
 WS binding, Web 2.0 bindings, Scripting components, Widget components

- tuscany-jee.zip - For JEE app integration
 EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
 BPEL and XQuery components

- tuscany-all.zip - all of the above

Note that I'm not trying to tackle release cycles and the potential for
releasing the above zips independently in this discussion and I'm

assuming

that we release all of the above together.

I'm also assuming that the relevant samples are included in each zip.


This email was from 1/22/08, generated a lot of discussion for about 3
weeks, lots of opinions, no conclusion, no commits :)



No commits as we haven't found much consensus yet.


I still think the same as what I had posted then, plus additional ideas:

- Use OSGi exports/imports to export clean SPIs, hide internals, and

refine

the contents of the distros and their dependencies.

Disclaimer - Please don't get me wrong I'm not saying that one distro ==

one

OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think that
declaring and enforcing clean dependencies using OSGi will help us 
refine

the contents of each distro.


The term "enforcing" seems to suggest that there might be an OSGi
dependency for the Tuscany runtime.  I don't know if this was
intended.  I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.


Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi 
environment...




What would be the granularity of these OSGi bundles?  If the bundles
are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
 a) Export more than we really believe is correct.  This
leaves us in the current unsatisfactory position of exposing
unwanted implementation internals.
 b) Combine multiple maven modules with a close implementation
affinity into a single OSGi bundle, and only expose true
APIs or SPIs from these bundles.
 c) Refactor the code to remove dependencies on internals of other
modules, and create new SPIs or APIs when this isn't possible.

I believe a combination of b) and c) is the best approach.


We've already rehashed this (and disagreed on this) in several other 
threads, where I've already given my opinion:

- 1 bundle per module
- clean API/SPI imports/exports




- Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension
registry mechanism (what we have now in Tuscany or better a 
combination of

what we have now and the Eclipse Equinox registry for example) to detect
which pieces are installed and activate their capabilities.



Can you say a bit more about what an "extension registry mechanism" would
look like?

What the tuscany-all/manifest jar are trying to do is to have users 
not need

to know about the internal makeup of Tuscany. So they can simply use
tuscany-all and avoid needing to know about all the dozens of different
Tuscany modules and their dependencies, and that should keep working over
many Tuscany releases whereas as we keep adding/deleting/changing the
modules we keep breaking user builds for each Tuscany release if they 
refer
to the individual modules. Maybe the granularity isn't quite right yet 
and

we need something in between the all jar and all the individual modules.

Is there much agreement that avoiding users needing to know about the
internal Tuscany modules is a Good Thing?


Yes, I think this is important.  Ideally the Tuscany core runtime
would figure out which pieces are needed for the domain configuration
and load these pieces automatically.



Good requirement, but I don't think that the current manifest + 
tuscany-all JAR solution is a good one (for example it mixes APIs and 
internals in the same JAR, doesn't work well with IDEs, works only for 
one big distro, requires different settings in J2SE and webapps)


Here's what I'd like to see as a user:

- a short list of API JARs that I can add to my dev compile/build path

- a single small launcher or bootstrap JAR that takes

Re: Distribution zips and what they contain, was: SCA runtimes

2008-06-10 Thread Simon Nash


ant elder wrote:

On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

Jean-Sebastien Delfino wrote:

I'd like to discuss the following: "What distro Zips are we building and
what do they contain?"

I think we could improve our distro scheme to provide:
- smaller packages
- easier for people to find what they need

I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
 core assembly model and runtime
 Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
 WS binding, Web 2.0 bindings, Scripting components, Widget components

- tuscany-jee.zip - For JEE app integration
 EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
 BPEL and XQuery components

- tuscany-all.zip - all of the above

Note that I'm not trying to tackle release cycles and the potential for
releasing the above zips independently in this discussion and I'm

assuming

that we release all of the above together.

I'm also assuming that the relevant samples are included in each zip.


This email was from 1/22/08, generated a lot of discussion for about 3
weeks, lots of opinions, no conclusion, no commits :)



No commits as we haven't found much consensus yet.


I still think the same as what I had posted then, plus additional ideas:

- Use OSGi exports/imports to export clean SPIs, hide internals, and

refine

the contents of the distros and their dependencies.

Disclaimer - Please don't get me wrong I'm not saying that one distro ==

one

OSGi bundle, as I've already said several times on the list that the
big-OSGi-bundle approach didn't make sense to me :) I just think that
declaring and enforcing clean dependencies using OSGi will help us refine
the contents of each distro.


The term "enforcing" seems to suggest that there might be an OSGi
dependency for the Tuscany runtime.  I don't know if this was
intended.  I think the right approach is to have a Tuscany+OSGi
runtime (as we are building in itest\osgi-tuscany) which would
actually do enforcement, and a non-OSGi Tuscany runtime in which
the exports/imports are present in the jars but not enforced.

What would be the granularity of these OSGi bundles?  If the bundles
are the current maven modules, I think we will find a number of
classes that need to be exported even though these classes are not
considered part of the SPI or API that the module provides.
To resolve this I see the following options:
 a) Export more than we really believe is correct.  This
leaves us in the current unsatisfactory position of exposing
unwanted implementation internals.
 b) Combine multiple maven modules with a close implementation
affinity into a single OSGi bundle, and only expose true
APIs or SPIs from these bundles.
 c) Refactor the code to remove dependencies on internals of other
modules, and create new SPIs or APIs when this isn't possible.

I believe a combination of b) and c) is the best approach.


- Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension
registry mechanism (what we have now in Tuscany or better a combination of
what we have now and the Eclipse Equinox registry for example) to detect
which pieces are installed and activate their capabilities.



Can you say a bit more about what an "extension registry mechanism" would
look like?

What the tuscany-all/manifest jar are trying to do is to have users not need
to know about the internal makeup of Tuscany. So they can simply use
tuscany-all and avoid needing to know about all the dozens of different
Tuscany modules and their dependencies, and that should keep working over
many Tuscany releases whereas as we keep adding/deleting/changing the
modules we keep breaking user builds for each Tuscany release if they refer
to the individual modules. Maybe the granularity isn't quite right yet and
we need something in between the all jar and all the individual modules.

Is there much agreement that avoiding users needing to know about the
internal Tuscany modules is a Good Thing?


Yes, I think this is important.  Ideally the Tuscany core runtime
would figure out which pieces are needed for the domain configuration
and load these pieces automatically.

  Simon


  ...ant

Re: Distribution zips and what they contain, was: SCA runtimes