You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/06/10 18:37:21 UTC
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 <
>> jsdelfino@apache.org> 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 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.
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).
[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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Simon Nash wrote:
>>
>>> ant elder wrote:
>>>
>>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>>> jsdelfino@apache.org> 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 granularity
> but what are the specific problems for those things you mention? Eg what
> doesn't it do well in IDEs? I've made a few changes to things over the last
> months and last time i tried the all jar DOES work fine in webapps, and if
> we're using osgi exports its no problem to mix APIs and internals in one jar
> is it?
>
> ...ant
>
tuscany-all.jar puts everything on my buildpath, everything including
internals, not really what I want to see in an IDE.
tuscany-manifest doesn't seem to be recognized by my IDE (I get compile
errors on APIs that it should bring on board)
I'm using Eclipse 3.2.
--
Jean-Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Simon Nash wrote:
>
>> ant elder wrote:
>>
>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>> jsdelfino@apache.org> 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 granularity
but what are the specific problems for those things you mention? Eg what
doesn't it do well in IDEs? I've made a few changes to things over the last
months and last time i tried the all jar DOES work fine in webapps, and if
we're using osgi exports its no problem to mix APIs and internals in one jar
is it?
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> 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
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> 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
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 10, 2008 at 7:03 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> ant elder wrote:
>
>> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> wrote:
>>
>> Simon Nash wrote:
>>>
>>> ant elder wrote:
>>>>
>>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>>>> jsdelfino@apache.org> 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 some of these internal details.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by haleh mahbod <hm...@gmail.com>.
Thanks Mike for putting things in perspective. It always helps to think of
these topics in terms of problem that we are trying to solve and who the
audience is before we get into the details of how to solve it. Your idea of
creating wiki pages for each of these topics will help clarify things
further and keep the discussion focused.
I created wiki pages based on my understanding of this thread for items a
and c. It is a starting point and needs to be reviewed and fixed.
a) Basic modules, as we have today. ß created under [1]
b) A variety of functional components, that represent sets of coherent
functions. ß created under [2]
c) A small number of large packages aimed at supporting end users in a
series of environments and with a specific set of functionality ß created
under [3]
d) Simple ways of starting Tuscany functionality - based on using the
packages in c) [4]
I also created wiki pages for items b and d, however I cannot articulate
what problem we are trying to solve with b and d. Can you please expand on
these two? What is the problem? Who is the audience?
This email thread is 32 emails deep on gmail. It is extremely difficult to
read and follow. Once there is agreement on the categories, can we start a
separate thread per category and continue updating the wiki pages as the
discussions solidify? This is like using the wiki pages as a white board for
keeping discussions focused. I have created these pages under [5]
and I hope that others find this approach useful.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Basic+Modules+Runtime+Bundles
[2]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
[3] http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=88325
[4
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Simple+ways+of+starting+Tuscany
[5]:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Java+White+Board+Index
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
>
>
> On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
> <mike.edwards.inglenook@gmail.com
> <ma...@gmail.com>> wrote:
>
> <snip>
>
>
> b) A variety of functional components, that represent sets of
> coherent functions.
>
> Each consists of a series of the basic modules, aggregated
> together.
> Their function in life is to assist developers of applications
> that embed some level of
> Tuscany capability (including tools, Tuscany itself and so on)
>
> These are probably not agreed by folk today - we have work to
> do here to define these.
> You demonstrate the problem in your example above - you want
> "Basic Web Services" separate from
> "Web Services Security" - but for an end user, the step from
> using the first to using the
> second is a trivial addition of @required="integrity" to the SCDL.
>
> Anyone care to have a go at defining these compoennts?
>
>
> Thats taking a different tack to the launcher appraoch but maybe we
> need both and this approach would be easier for embedders so ok to
> move things long I'll try an initial stab at it:
>
> 1) tuscany-scdl4j
>
> An aggregated jar containing _all_ the model and stax processor
> classes which can be used by tools etc for for reading/writing scdl
> without booting a runtime. It includes all the extension classes as
> they generally don't drag in any other dependencies so its not
> really any problem to incude them. The only required dependency
> would be on stax, maybe some optional dependencies like wsdl4j as
> the wsdl extension may need that. Not sure if any of the
> contribution modules should be included, would have to investigate
> that a bit.
>
> 2) tuscany-runtime
> An aggregated jar containing the minimum modules to start a runtime
> able to run something like the simple calculator sample. Has
> dependencies on tuscany-scdl4j and minimal other jars -
> geronimo-commonj_1.1_spec, cglib, jaxb etc.
>
> 3) tuscany-api
> An aggregated jar containing everything tuscany/sca applications
> might need to compile - sca-api, SCADomain class from host-embedded,
> node2-api, jsp taglib etc. Has no external dependencies.
>
> 4) Single jars for all the binding and implementation type
> extensions which add the capability to the minimal tuscany-runtime.
> We're already starting to get these with the way extensions are
> being structured nowadays - binding-jsonrpc-runtime,
> binding-ejb-runtime, implementation-widget-runtime etc.
>
> The above would make life for embedders much easier like the
> Tuscany-Geronimo integration code (or JBoss when they come along)
> less likely to break over releases as we add remove modules.
>
> ...ant
>
>
> No comments on this after a couple of weeks so I'll go start trying it.
>
> ...ant
>
Actually I did comment on this, and I updated the two Wiki pages that
Haleh created. See the post on this thread that I sent on 24 June at
10:43 am my time. It appears that this post does not appear in
markmail for some reason.
Simon
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Thu, Jul 10, 2008 at 5:43 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Let me take the two prototypes to build the "Collection" and compare them
> aspect by aspect.
>
> 1) Aggregated jar:
> http://svn.apache.org/repos/asf/tuscany/java/sca/modules/scdl4j/pom.xml
> 2) Feature/Distro:
> http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml
>
> a. How is it declared as a maven module?
> 1. Create a jar module, add the contained modules as dependencies, and use
> the share plugin to aggregate/merge artifacts from the modules into the
> target jar. Fairly-complicated exclusion filters and transformers have to be
> defined.
> 2. Create a pom module, add the contained modules as dependencies, add the
> descriptor for the assembly and use the assembly plugin to assemble the
> modules in a fairly-straightforward way. The distro can also contain related
> samples.
>
> b. What will be produced?
> 1: An aggregated jar that physically contains all the classes from the
> modules and merged resource files.
> 2: A zip or tar.gz that contains the modules as original jars in the
> zip/tar.gz.
>
> c. How to declare dependency to reference them in maven?
> 1: Declare a dependency to the new jar (Will the contained modules be
> pulled in as transitive dependencies in addition to the aggregated jar?)
> 2. Declare a dependency to the new pom (The contained modules will be
> pulled in as transitive dependencies)
>
> d. How to use them in non-maven?
> 1. Add the new jar to the classpath
> 2. Unzip the zip/tar.gz so that all the contained modules will be on the
> classpath (or use our ant generator, or mvn dependency:copy-dependencies to
> copy the jars over)
>
> e. How to use them in OSGi?
> 1. The new jar becomes a new bundle and it needs to merge the MANIFEST.MF
> from the contained modules. (How do we deal with the import/export,
> versioning?)
> 2. The contained modules are the bundles, no new bundles are introduced.
>
> f. Can two collections contain the overlapping modules?
> 1. No (AFAIK from Ant's response)
> 2. Yes
>
> g. How to overlay the collections into an existing installation?
> 1. Add the new jar assuming there are no duplicate
> 2. Unzip the distro and either overwrite or ignore the duplicate modules
> during the unzip
>
> h. Footprint
> 1. It might pull in extra stuff not required, for example, to support WS,
> we need to pull in scdl4j.jar which contains models for EJBs or BEPL.
> 2. Can be potentially the bare minimum if we declare the feature/distro in
> a fine-grained fashion.
>
> Please help to complete the list and correctly judged.
>
>
I'm not ignoring this, just waiting to see what the request for user
feedback on the user lists shows up.
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Let me take the two prototypes to build the "Collection" and compare them
aspect by aspect.
1) Aggregated jar:
http://svn.apache.org/repos/asf/tuscany/java/sca/modules/scdl4j/pom.xml
2) Feature/Distro:
http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml
a. How is it declared as a maven module?
1. Create a jar module, add the contained modules as dependencies, and use
the share plugin to aggregate/merge artifacts from the modules into the
target jar. Fairly-complicated exclusion filters and transformers have to be
defined.
2. Create a pom module, add the contained modules as dependencies, add the
descriptor for the assembly and use the assembly plugin to assemble the
modules in a fairly-straightforward way. The distro can also contain related
samples.
b. What will be produced?
1: An aggregated jar that physically contains all the classes from the
modules and merged resource files.
2: A zip or tar.gz that contains the modules as original jars in the
zip/tar.gz.
c. How to declare dependency to reference them in maven?
1: Declare a dependency to the new jar (Will the contained modules be pulled
in as transitive dependencies in addition to the aggregated jar?)
2. Declare a dependency to the new pom (The contained modules will be pulled
in as transitive dependencies)
d. How to use them in non-maven?
1. Add the new jar to the classpath
2. Unzip the zip/tar.gz so that all the contained modules will be on the
classpath (or use our ant generator, or mvn dependency:copy-dependencies to
copy the jars over)
e. How to use them in OSGi?
1. The new jar becomes a new bundle and it needs to merge the MANIFEST.MF
from the contained modules. (How do we deal with the import/export,
versioning?)
2. The contained modules are the bundles, no new bundles are introduced.
f. Can two collections contain the overlapping modules?
1. No (AFAIK from Ant's response)
2. Yes
g. How to overlay the collections into an existing installation?
1. Add the new jar assuming there are no duplicate
2. Unzip the distro and either overwrite or ignore the duplicate modules
during the unzip
h. Footprint
1. It might pull in extra stuff not required, for example, to support WS, we
need to pull in scdl4j.jar which contains models for EJBs or BEPL.
2. Can be potentially the bare minimum if we declare the feature/distro in a
fine-grained fashion.
Please help to complete the list and correctly judged.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Nash" <na...@apache.org>
Sent: Thursday, July 10, 2008 12:57 AM
To: <de...@tuscany.apache.org>
Cc: <us...@tuscany.apache.org>
Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
> haleh mahbod wrote:
>> Hi Ant,
>> when you refer to a user, do you mean an embedder or an application
>> developer?
>> I am looking at [1] link where the first draft of functional components
>> were defined. I am assuming it is the embedders.
>>
>> Let's say I am an embedder wanting to use ejb. What are the steps that I
>> take with the component proposal vs the feature proposal to use ejb
>> feature? What are the pros and cons?
>> I am wondering if Tuscany embedders could share their experience here?
>> How are they solving this problem today that seems to be satisfactory for
>> them? Are we solving a problem that is not a real issue for Tuscany
>> embedders?
>>
> This would not affect someone who is developing a business application
> within a predefined environment. It would affect the packaging and
> distribution of that application with its dependency on Tuscany or
> some elements of Tuscany. In this sense I think it affects all
> Tuscany users, as any real application developed using Tuscany will
> need to be packaged and distributed before it can be used by others.
> It also affects embedders who want to incorporate all or part of
> Tuscany into platform or middleware offerings.
>
> I believe our packaging and distribution story needs to be as simple
> and consumable as possible, while providing flexibility for different
> selections of Tuscany functionality. Having this story depend on
> maven, an extension registry, or a launcher would fail to achieve the
> necessary level of simplicity. Packaging Tuscany as a manageable
> and fairly stable set of jar files/OSGi bundles whose purpose and
> dependencies are easy to understand does achieve the simplicity goal.
>
> Simon
>
>> [1]:
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
>> Haleh
>> On 7/8/08, *ant elder* <antelder@apache.org
>> <ma...@apache.org>> wrote:
>>
>>
>>
>> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <enjoyjava@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> What are the benefits do we intend to provide for users with the
>> "components"-based aggregation? Simplicity and ease of use.
>>
>> Take the scdl jar aggregate as an example, a user wants to process
>> some scdl - things like reading and writing composites, perhaps
>> validating or manipulating the model programatically - they don't
>> know what binding or component types may be used they just want it
>> to work with what ever is in the scdl. Right now to do that they
>> need to explicitly use a vast list of tuscany modules and that list
>> of modules is continually changing over time so every time they pick
>> up a new build their code breaks. With the tuscany-scdl aggregate
>> they can just use that single jar and that will continue to work
>> over new builds and releases.
>>
>> IMHO, we can use the "feature" idea to address the requirements
>> of b) in Mike's original e-mail without the restriction of
>> non-overlapping and side-effort of producing new jars.
>> Meanwhile, the alignment of feature/distribution gives us the
>> flexibility to balance the granularities. A distribution is also
>> a feature and we can also easily group features into a
>> distribution.
>> The "feature" idea of having a Maven pom module instead of an
>> aggregate jar helps users when building with Maven but it doesn't
>> help non Maven users and it doesn't help with aspects out side of
>> the Maven build process such as packaging and distribution, users
>> are still going to have to deal with the vast and changing list of
>> individual Tuscany module jars.
>>
>> ...ant
>>
>>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
haleh mahbod wrote:
> Hi Ant,
>
> when you refer to a user, do you mean an embedder or an application
> developer?
> I am looking at [1] link where the first draft of functional components
> were defined. I am assuming it is the embedders.
>
> Let's say I am an embedder wanting to use ejb. What are the steps that I
> take with the component proposal vs the feature proposal to use ejb
> feature? What are the pros and cons?
>
> I am wondering if Tuscany embedders could share their experience here?
> How are they solving this problem today that seems to be satisfactory
> for them? Are we solving a problem that is not a real issue for Tuscany
> embedders?
>
This would not affect someone who is developing a business application
within a predefined environment. It would affect the packaging and
distribution of that application with its dependency on Tuscany or
some elements of Tuscany. In this sense I think it affects all
Tuscany users, as any real application developed using Tuscany will
need to be packaged and distributed before it can be used by others.
It also affects embedders who want to incorporate all or part of
Tuscany into platform or middleware offerings.
I believe our packaging and distribution story needs to be as simple
and consumable as possible, while providing flexibility for different
selections of Tuscany functionality. Having this story depend on
maven, an extension registry, or a launcher would fail to achieve the
necessary level of simplicity. Packaging Tuscany as a manageable
and fairly stable set of jar files/OSGi bundles whose purpose and
dependencies are easy to understand does achieve the simplicity goal.
Simon
>
> [1]:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
>
>
> Haleh
>
> On 7/8/08, *ant elder* <antelder@apache.org
> <ma...@apache.org>> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> What are the benefits do we intend to provide for users with the
> "components"-based aggregation?
>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process
> some scdl - things like reading and writing composites, perhaps
> validating or manipulating the model programatically - they don't
> know what binding or component types may be used they just want it
> to work with what ever is in the scdl. Right now to do that they
> need to explicitly use a vast list of tuscany modules and that list
> of modules is continually changing over time so every time they pick
> up a new build their code breaks. With the tuscany-scdl aggregate
> they can just use that single jar and that will continue to work
> over new builds and releases.
>
>
>
>
> IMHO, we can use the "feature" idea to address the requirements
> of b) in Mike's original e-mail without the restriction of
> non-overlapping and side-effort of producing new jars.
> Meanwhile, the alignment of feature/distribution gives us the
> flexibility to balance the granularities. A distribution is also
> a feature and we can also easily group features into a
> distribution.
>
>
>
> The "feature" idea of having a Maven pom module instead of an
> aggregate jar helps users when building with Maven but it doesn't
> help non Maven users and it doesn't help with aspects out side of
> the Maven build process such as packaging and distribution, users
> are still going to have to deal with the vast and changing list of
> individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
haleh mahbod wrote:
> Hi Ant,
>
> when you refer to a user, do you mean an embedder or an application
> developer?
> I am looking at [1] link where the first draft of functional components
> were defined. I am assuming it is the embedders.
>
> Let's say I am an embedder wanting to use ejb. What are the steps that I
> take with the component proposal vs the feature proposal to use ejb
> feature? What are the pros and cons?
>
> I am wondering if Tuscany embedders could share their experience here?
> How are they solving this problem today that seems to be satisfactory
> for them? Are we solving a problem that is not a real issue for Tuscany
> embedders?
>
This would not affect someone who is developing a business application
within a predefined environment. It would affect the packaging and
distribution of that application with its dependency on Tuscany or
some elements of Tuscany. In this sense I think it affects all
Tuscany users, as any real application developed using Tuscany will
need to be packaged and distributed before it can be used by others.
It also affects embedders who want to incorporate all or part of
Tuscany into platform or middleware offerings.
I believe our packaging and distribution story needs to be as simple
and consumable as possible, while providing flexibility for different
selections of Tuscany functionality. Having this story depend on
maven, an extension registry, or a launcher would fail to achieve the
necessary level of simplicity. Packaging Tuscany as a manageable
and fairly stable set of jar files/OSGi bundles whose purpose and
dependencies are easy to understand does achieve the simplicity goal.
Simon
>
> [1]:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
>
>
> Haleh
>
> On 7/8/08, *ant elder* <antelder@apache.org
> <ma...@apache.org>> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> What are the benefits do we intend to provide for users with the
> "components"-based aggregation?
>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process
> some scdl - things like reading and writing composites, perhaps
> validating or manipulating the model programatically - they don't
> know what binding or component types may be used they just want it
> to work with what ever is in the scdl. Right now to do that they
> need to explicitly use a vast list of tuscany modules and that list
> of modules is continually changing over time so every time they pick
> up a new build their code breaks. With the tuscany-scdl aggregate
> they can just use that single jar and that will continue to work
> over new builds and releases.
>
>
>
>
> IMHO, we can use the "feature" idea to address the requirements
> of b) in Mike's original e-mail without the restriction of
> non-overlapping and side-effort of producing new jars.
> Meanwhile, the alignment of feature/distribution gives us the
> flexibility to balance the granularities. A distribution is also
> a feature and we can also easily group features into a
> distribution.
>
>
>
> The "feature" idea of having a Maven pom module instead of an
> aggregate jar helps users when building with Maven but it doesn't
> help non Maven users and it doesn't help with aspects out side of
> the Maven build process such as packaging and distribution, users
> are still going to have to deal with the vast and changing list of
> individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by haleh mahbod <hm...@gmail.com>.
Hi Ant,
when you refer to a user, do you mean an embedder or an application
developer?
I am looking at [1] link where the first draft of functional components were
defined. I am assuming it is the embedders.
Let's say I am an embedder wanting to use ejb. What are the steps that I
take with the component proposal vs the feature proposal to use ejb feature?
What are the pros and cons?
I am wondering if Tuscany embedders could share their experience here? How
are they solving this problem today that seems to be satisfactory for them?
Are we solving a problem that is not a real issue for Tuscany embedders?
[1]:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
Haleh
On 7/8/08, ant elder <an...@apache.org> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> What are the benefits do we intend to provide for users with the
>> "components"-based aggregation?
>>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process some
> scdl - things like reading and writing composites, perhaps validating or
> manipulating the model programatically - they don't know what binding or
> component types may be used they just want it to work with what ever is in
> the scdl. Right now to do that they need to explicitly use a vast list of
> tuscany modules and that list of modules is continually changing over time
> so every time they pick up a new build their code breaks. With the
> tuscany-scdl aggregate they can just use that single jar and that will
> continue to work over new builds and releases.
>
>
>
>>
>> IMHO, we can use the "feature" idea to address the requirements of b) in
>> Mike's original e-mail without the restriction of non-overlapping
>> and side-effort of producing new jars. Meanwhile, the alignment of
>> feature/distribution gives us the flexibility to balance the granularities.
>> A distribution is also a feature and we can also easily group features into
>> a distribution.
>>
>>
>
> The "feature" idea of having a Maven pom module instead of an aggregate jar
> helps users when building with Maven but it doesn't help non Maven users and
> it doesn't help with aspects out side of the Maven build process such as
> packaging and distribution, users are still going to have to deal with the
> vast and changing list of individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by haleh mahbod <hm...@gmail.com>.
Hi Ant,
when you refer to a user, do you mean an embedder or an application
developer?
I am looking at [1] link where the first draft of functional components were
defined. I am assuming it is the embedders.
Let's say I am an embedder wanting to use ejb. What are the steps that I
take with the component proposal vs the feature proposal to use ejb feature?
What are the pros and cons?
I am wondering if Tuscany embedders could share their experience here? How
are they solving this problem today that seems to be satisfactory for them?
Are we solving a problem that is not a real issue for Tuscany embedders?
[1]:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/functional+components+at+runtime
Haleh
On 7/8/08, ant elder <an...@apache.org> wrote:
>
>
>
> On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> What are the benefits do we intend to provide for users with the
>> "components"-based aggregation?
>>
>
> Simplicity and ease of use.
>
> Take the scdl jar aggregate as an example, a user wants to process some
> scdl - things like reading and writing composites, perhaps validating or
> manipulating the model programatically - they don't know what binding or
> component types may be used they just want it to work with what ever is in
> the scdl. Right now to do that they need to explicitly use a vast list of
> tuscany modules and that list of modules is continually changing over time
> so every time they pick up a new build their code breaks. With the
> tuscany-scdl aggregate they can just use that single jar and that will
> continue to work over new builds and releases.
>
>
>
>>
>> IMHO, we can use the "feature" idea to address the requirements of b) in
>> Mike's original e-mail without the restriction of non-overlapping
>> and side-effort of producing new jars. Meanwhile, the alignment of
>> feature/distribution gives us the flexibility to balance the granularities.
>> A distribution is also a feature and we can also easily group features into
>> a distribution.
>>
>>
>
> The "feature" idea of having a Maven pom module instead of an aggregate jar
> helps users when building with Maven but it doesn't help non Maven users and
> it doesn't help with aspects out side of the Maven build process such as
> packaging and distribution, users are still going to have to deal with the
> vast and changing list of individual Tuscany module jars.
>
> ...ant
>
>
>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@apache.org>.
On Mon, Jul 7, 2008 at 6:58 PM, Raymond Feng <en...@gmail.com> wrote:
> What are the benefits do we intend to provide for users with the
> "components"-based aggregation?
>
Simplicity and ease of use.
Take the scdl jar aggregate as an example, a user wants to process some scdl
- things like reading and writing composites, perhaps validating or
manipulating the model programatically - they don't know what binding or
component types may be used they just want it to work with what ever is in
the scdl. Right now to do that they need to explicitly use a vast list of
tuscany modules and that list of modules is continually changing over time
so every time they pick up a new build their code breaks. With the
tuscany-scdl aggregate they can just use that single jar and that will
continue to work over new builds and releases.
> IMHO, we can use the "feature" idea to address the requirements of b) in
> Mike's original e-mail without the restriction of non-overlapping
> and side-effort of producing new jars. Meanwhile, the alignment of
> feature/distribution gives us the flexibility to balance the granularities.
> A distribution is also a feature and we can also easily group features into
> a distribution.
>
>
The "feature" idea of having a Maven pom module instead of an aggregate jar
helps users when building with Maven but it doesn't help non Maven users and
it doesn't help with aspects out side of the Maven build process such as
packaging and distribution, users are still going to have to deal with the
vast and changing list of individual Tuscany module jars.
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
What are the benefits do we intend to provide for users with the "components"-based aggregation?
IMHO, we can use the "feature" idea to address the requirements of b) in Mike's original e-mail without the restriction of non-overlapping and side-effort of producing new jars. Meanwhile, the alignment of feature/distribution gives us the flexibility to balance the granularities. A distribution is also a feature and we can also easily group features into a distribution.
Thanks,
Raymond
From: ant elder
Sent: Monday, July 07, 2008 4:10 AM
To: dev@tuscany.apache.org
Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
That all sounds reasonable to me.
To help anyone else hunting around for "Mike's original note on this" the link is: http://apache.markmail.org/message/nplwkkncelkwwrrk
...ant
On Mon, Jul 7, 2008 at 11:59 AM, Simon Nash <na...@apache.org> wrote:
Raymond Feng wrote:
Hi,
It seems that the fundamental difference we're having is whether two tuscany features can contain the same module. For example, if I build the web service feature and jsonrpc feature, both of them would contain core-spi and databinding modules.
The other thing is that I see a feature can contain other features too.
I don't think the "components" that Ant has described and started
to produce are at the same level as the "features" that Raymond has
proposed and the "distributions" that Sebastien has produced.
Going back to Mike's original note on this, I see the components
playing the role described for level b) and the features/distributions
playing the role described for level c).
If the component split is correct, it would have the following
properties:
1. Each maven module would belong to exactly one component.
2. Features/distributions would be assembled from components and
not from maven modules directly.
3. The assembly of a feature/distribution from components would
not drag in "too much" that is not needed by the feature or
distribution.
How much in point 3 above is "too much" is a subjective judgment
and some might have different views on this. I'd suggest the
following criteria as a starting point for discussion:
a. No unnecessary third party dependencies.
b. No additional system resources (e.g., ports, threads) consumed.
c. No slowdown on any code paths.
If we can achieve the above, then I don't see any problem with
physically aggregating modules together into component jars/bundles
and using these component jars/bundles to build features or
distributions.
If the component approach works out, I'd like to add support
for it in the build, so that a specified selection of components
could be built without building other components. Also, when
building a component, it should not be necessary to build the
other components on which the component depends, if these are
available in binary form.
Simon
Thanks,
Raymond
*From:* ant elder <ma...@apache.org>
*Sent:* Wednesday, July 02, 2008 9:05 AM
*To:* tuscany-dev <ma...@ws.apache.org>
*Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
This went to me not the dev list, comments in line
...ant
On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <enjoyjava@gmail.com <ma...@gmail.com>> wrote:
Hi,
Can you provide us some use cases for the aggregated jars?
I think it's very important that we don't physically merge module
jars into a feature jar.
Let's assume we have two features: f1 and f2. f1 contains modules m1
and m2, f2 contains m1 and m3.
If that happens then likely we don't have the aggregation granularity correct. Could you provide an example of that using actual Tuscany modules and the aggregations suggested so far?
If we produce f1.jar and f2.jar, what's going to happen if my
application uses both f1 and f2? If we declare maven dependencies to
f1 and f2, we end up with a classpath containing f1.jar and f2.jar.
All the classes/resources from module m1 will be duplicate in these
two jars. The jar aggregation also prevents a feature to be depended
by another feature for the same reason. Even when we put maven on
the side, do you expect the user to download both f1.jar and f2.jar
to support both features? If so, we still have the duplicating
artifacts issue.
Also thinking about OSGi, adding feature jars will be problematic
too. If it's just a descriptor, then adding a feature just pulls
into the contained module bundles.
I'm not seeing the problems you're hinting at, could you be more specific or give concrete examples?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
That all sounds reasonable to me.
To help anyone else hunting around for "Mike's original note on this" the
link is: http://apache.markmail.org/message/nplwkkncelkwwrrk
...ant
On Mon, Jul 7, 2008 at 11:59 AM, Simon Nash <na...@apache.org> wrote:
> Raymond Feng wrote:
>
>> Hi,
>> It seems that the fundamental difference we're having is whether two
>> tuscany features can contain the same module. For example, if I build the
>> web service feature and jsonrpc feature, both of them would contain core-spi
>> and databinding modules.
>> The other thing is that I see a feature can contain other features too.
>>
>>
> I don't think the "components" that Ant has described and started
> to produce are at the same level as the "features" that Raymond has
> proposed and the "distributions" that Sebastien has produced.
>
> Going back to Mike's original note on this, I see the components
> playing the role described for level b) and the features/distributions
> playing the role described for level c).
>
> If the component split is correct, it would have the following
> properties:
> 1. Each maven module would belong to exactly one component.
> 2. Features/distributions would be assembled from components and
> not from maven modules directly.
> 3. The assembly of a feature/distribution from components would
> not drag in "too much" that is not needed by the feature or
> distribution.
>
> How much in point 3 above is "too much" is a subjective judgment
> and some might have different views on this. I'd suggest the
> following criteria as a starting point for discussion:
> a. No unnecessary third party dependencies.
> b. No additional system resources (e.g., ports, threads) consumed.
> c. No slowdown on any code paths.
>
> If we can achieve the above, then I don't see any problem with
> physically aggregating modules together into component jars/bundles
> and using these component jars/bundles to build features or
> distributions.
>
> If the component approach works out, I'd like to add support
> for it in the build, so that a specified selection of components
> could be built without building other components. Also, when
> building a component, it should not be necessary to build the
> other components on which the component depends, if these are
> available in binary form.
>
> Simon
>
> Thanks,
>> Raymond
>>
>> *From:* ant elder <ma...@apache.org>
>> *Sent:* Wednesday, July 02, 2008 9:05 AM
>> *To:* tuscany-dev <ma...@ws.apache.org>
>> *Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking
>> Tuscany extensions, was: Distribution zips and what they contain, was: SCA
>> runtimes
>>
>> This went to me not the dev list, comments in line
>>
>> ...ant
>>
>> On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>> enjoyjava@gmail.com>> wrote:
>>
>> Hi,
>> Can you provide us some use cases for the aggregated jars?
>> I think it's very important that we don't physically merge module
>> jars into a feature jar.
>> Let's assume we have two features: f1 and f2. f1 contains modules
>> m1
>> and m2, f2 contains m1 and m3.
>>
>> If that happens then likely we don't have the aggregation granularity
>> correct. Could you provide an example of that using actual Tuscany modules
>> and the aggregations suggested so far?
>>
>> If we produce f1.jar and f2.jar, what's going to happen if my
>> application uses both f1 and f2? If we declare maven dependencies to
>> f1 and f2, we end up with a classpath containing f1.jar and f2.jar.
>> All the classes/resources from module m1 will be duplicate in these
>> two jars. The jar aggregation also prevents a feature to be depended
>> by another feature for the same reason. Even when we put maven on
>> the side, do you expect the user to download both f1.jar and f2.jar
>> to support both features? If so, we still have the duplicating
>> artifacts issue.
>> Also thinking about OSGi, adding feature jars will be problematic
>> too. If it's just a descriptor, then adding a feature just pulls
>> into the contained module bundles.
>>
>>
>> I'm not seeing the problems you're hinting at, could you be more specific
>> or give concrete examples?
>>
>> ...ant
>>
>>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Wed, Jul 2, 2008 at 5:38 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Wed, Jul 2, 2008 at 5:34 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> Hi,
>>
>> It seems that the fundamental difference we're having is whether two
>> tuscany features can contain the same module. For example, if I build the
>> web service feature and jsonrpc feature, both of them would contain core-spi
>> and databinding modules.
>>
>
> Thats not how i was thinking it would look like, i didn't expect the
> jsonrpc or ws ones would include those core-spi or databinding classes. To
> use a ws feature you'd also need to use the tuscany-runtime and tuscany-scdl
> jars.
>
> ...ant
>
>
I stopped with these aggregation examples while this discussion was going
on, maybe i should go continue so there's things like ws support and a
calculator-ws sample to make it clearer?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Wed, Jul 2, 2008 at 5:34 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> It seems that the fundamental difference we're having is whether two
> tuscany features can contain the same module. For example, if I build the
> web service feature and jsonrpc feature, both of them would contain core-spi
> and databinding modules.
>
Thats not how i was thinking it would look like, i didn't expect the jsonrpc
or ws ones would include those core-spi or databinding classes. To use a ws
feature you'd also need to use the tuscany-runtime and tuscany-scdl jars.
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany
extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> It seems that the fundamental difference we're having is whether two
> tuscany features can contain the same module. For example, if I build
> the web service feature and jsonrpc feature, both of them would contain
> core-spi and databinding modules.
>
> The other thing is that I see a feature can contain other features too.
>
I don't think the "components" that Ant has described and started
to produce are at the same level as the "features" that Raymond has
proposed and the "distributions" that Sebastien has produced.
Going back to Mike's original note on this, I see the components
playing the role described for level b) and the features/distributions
playing the role described for level c).
If the component split is correct, it would have the following
properties:
1. Each maven module would belong to exactly one component.
2. Features/distributions would be assembled from components and
not from maven modules directly.
3. The assembly of a feature/distribution from components would
not drag in "too much" that is not needed by the feature or
distribution.
How much in point 3 above is "too much" is a subjective judgment
and some might have different views on this. I'd suggest the
following criteria as a starting point for discussion:
a. No unnecessary third party dependencies.
b. No additional system resources (e.g., ports, threads) consumed.
c. No slowdown on any code paths.
If we can achieve the above, then I don't see any problem with
physically aggregating modules together into component jars/bundles
and using these component jars/bundles to build features or
distributions.
If the component approach works out, I'd like to add support
for it in the build, so that a specified selection of components
could be built without building other components. Also, when
building a component, it should not be necessary to build the
other components on which the component depends, if these are
available in binary form.
Simon
> Thanks,
> Raymond
>
> *From:* ant elder <ma...@apache.org>
> *Sent:* Wednesday, July 02, 2008 9:05 AM
> *To:* tuscany-dev <ma...@ws.apache.org>
> *Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking
> Tuscany extensions, was: Distribution zips and what they contain, was:
> SCA runtimes
>
> This went to me not the dev list, comments in line
>
> ...ant
>
> On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi,
>
> Can you provide us some use cases for the aggregated jars?
>
> I think it's very important that we don't physically merge module
> jars into a feature jar.
>
> Let's assume we have two features: f1 and f2. f1 contains modules m1
> and m2, f2 contains m1 and m3.
>
>
> If that happens then likely we don't have the aggregation granularity
> correct. Could you provide an example of that using actual Tuscany
> modules and the aggregations suggested so far?
>
>
> If we produce f1.jar and f2.jar, what's going to happen if my
> application uses both f1 and f2? If we declare maven dependencies to
> f1 and f2, we end up with a classpath containing f1.jar and f2.jar.
> All the classes/resources from module m1 will be duplicate in these
> two jars. The jar aggregation also prevents a feature to be depended
> by another feature for the same reason. Even when we put maven on
> the side, do you expect the user to download both f1.jar and f2.jar
> to support both features? If so, we still have the duplicating
> artifacts issue.
>
> Also thinking about OSGi, adding feature jars will be problematic
> too. If it's just a descriptor, then adding a feature just pulls
> into the contained module bundles.
>
>
>
> I'm not seeing the problems you're hinting at, could you be more
> specific or give concrete examples?
>
> ...ant
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It seems that the fundamental difference we're having is whether two tuscany features can contain the same module. For example, if I build the web service feature and jsonrpc feature, both of them would contain core-spi and databinding modules.
The other thing is that I see a feature can contain other features too.
Thanks,
Raymond
From: ant elder
Sent: Wednesday, July 02, 2008 9:05 AM
To: tuscany-dev
Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
This went to me not the dev list, comments in line
...ant
On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <en...@gmail.com> wrote:
Hi,
Can you provide us some use cases for the aggregated jars?
I think it's very important that we don't physically merge module jars into a feature jar.
Let's assume we have two features: f1 and f2. f1 contains modules m1 and m2, f2 contains m1 and m3.
If that happens then likely we don't have the aggregation granularity correct. Could you provide an example of that using actual Tuscany modules and the aggregations suggested so far?
If we produce f1.jar and f2.jar, what's going to happen if my application uses both f1 and f2? If we declare maven dependencies to f1 and f2, we end up with a classpath containing f1.jar and f2.jar. All the classes/resources from module m1 will be duplicate in these two jars. The jar aggregation also prevents a feature to be depended by another feature for the same reason. Even when we put maven on the side, do you expect the user to download both f1.jar and f2.jar to support both features? If so, we still have the duplicating artifacts issue.
Also thinking about OSGi, adding feature jars will be problematic too. If it's just a descriptor, then adding a feature just pulls into the contained module bundles.
I'm not seeing the problems you're hinting at, could you be more specific or give concrete examples?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@apache.org>.
This went to me not the dev list, comments in line
...ant
On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Can you provide us some use cases for the aggregated jars?
>
> I think it's very important that we don't physically merge module jars into
> a feature jar.
>
> Let's assume we have two features: f1 and f2. f1 contains modules m1 and
> m2, f2 contains m1 and m3.
>
If that happens then likely we don't have the aggregation granularity
correct. Could you provide an example of that using actual Tuscany modules
and the aggregations suggested so far?
> If we produce f1.jar and f2.jar, what's going to happen if my application
> uses both f1 and f2? If we declare maven dependencies to f1 and f2, we end
> up with a classpath containing f1.jar and f2.jar. All the classes/resources
> from module m1 will be duplicate in these two jars. The jar aggregation also
> prevents a feature to be depended by another feature for the same reason.
> Even when we put maven on the side, do you expect the user to download both
> f1.jar and f2.jar to support both features? If so, we still have the
> duplicating artifacts issue.
>
> Also thinking about OSGi, adding feature jars will be problematic too. If
> it's just a descriptor, then adding a feature just pulls into the contained
> module bundles.
>
>
I'm not seeing the problems you're hinting at, could you be more specific or
give concrete examples?
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
Thanks for participating, most of these sound like good ideas but I'm not
convinced about (3) as the aggregate jars are about more than just managing
Maven dependencies. How about for now we keep them as aggregate jars and
re-review this once they're more complete?
...ant
On Wed, Jul 2, 2008 at 3:04 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I have looked into what you have checked in. I think we need to make the
> following refinements:
>
> 1) IMO, this kind of collection of tuscany modules is very similar to
> Eclipse features which is the deployment descriptor of a set of Eclipse
> plugins. For the sake of discussion, let me call them tuscany features. Two
> features should be able to contain the same module.
>
> 2) The maven module for a tuscany feature should be just a pom project
> which declares the contained tuscany modules as dependencies.
>
> <project> * * <modelVersion>*4.0.0*</modelVersion>
> <artifactId>tuscany-scdl4j</artifactId> * * <packaging>*pom*</packaging>
> *-*<http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml#>
> <dependencies>
> <!-- All the contained modules should be declared her as
> dependency -->
> <dependencies>
> </project>
>
> The applications or other features can just declare the tuscany feature pom
> project as a dependency to reference that feature.
>
> It seems that the distro prototype added by Sebastien has already taken the
> pom project approach. See
> http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml
> .
>
> 3) The feature module
> should not try to aggregate the modules into a new jar. As the new jar
> will consume more storage, add duplicate classes and does not support
> overlay.
>
> 4) We should add a new folder such as "features" to host all defined
> feature modules. IMO, the "scdl4j" should be checked in under this
> "features" folder instead of "modules" which hosts all the physical/atomic
> modules. The other option is to check them in under "distribution". The
> distro should be just an aggregation of one or more features.
>
> Thanks,
> Raymond
>
> *From:* ant elder <an...@apache.org>
> *Sent:* Tuesday, July 01, 2008 4:51 PM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: Grouping/Aggregating tuscany modules, was: Re: Tracking
> Tuscany extensions, was: Distribution zips and what they contain, was: SCA
> runtimes
>
>
>
> On Tue, Jul 1, 2008 at 6:11 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> I renamed the thread to better reflect the nature of this discussion.
>>
>
> Maybe we need a discussion thread on all the subject line fiddling that
> goes on these days ;-)
>
>
>>
>> I have a few questions here:
>>
>> 1) If an application uses binding.ejb, what would the dependency look
>> like?
>>
>>
>
> I've not added ejb support yet but ideally it would be something like just
> adding the binding-ejb-runtime jar, along with the standard tuscany-api,
> tuscany-scdl4j, and tuscany-runtime jars.
>
>
> 2) Where are the databinding modules being aggregated?
>>
>>
>
> The runtime jar currenlty contains the modules: tuscany-core-databinding,
> tuscany-databinding, tuscany-databinding-jaxb
>
> I guess the other ones like databinding-axiom, databinding-fastinfoset etc
> would be optional ones that you'd add as single jars if required. Actually
> no, databinding-axiom and databinding-jaxb-axiom could be included in a
> tuscany-runtime-ws-axis2 agregate jar that includes everything you need to
> use web services. So something like a calculator-ws sample would use the
> jars: tuscany-api, tuscany-scdl4j, tuscany-runtime, and
> tuscany-runtime-ws-axis2
>
> 3) Is the java component support in tuscany-runtime?
>>
>
> Currently yes, it seemed to make sense to include that one implementation
> type.
>
> WDYT? All this is quite embryonic so feel free to point out flaws or dive
> in with alternatives.
>
>
>
>> Thanks,
>> Raymond
>>
>> *From:* ant elder <an...@gmail.com>
>> *Sent:* Tuesday, July 01, 2008 8:04 AM
>> *To:* dev@tuscany.apache.org
>> *Subject:* Re: Tracking Tuscany extensions, was: Distribution zips and
>> what they contain, was: SCA runtimes
>>
>>
>>
>> On Tue, Jul 1, 2008 at 12:09 PM, Simon Nash <na...@apache.org> wrote:
>>
>>> ant elder wrote:
>>>
>>>>
>>>>
>>>> On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com<mailto:
>>>> ant.elder@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
>>>> <mike.edwards.inglenook@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>> b) A variety of functional components, that represent sets of
>>>> coherent functions.
>>>>
>>>> Each consists of a series of the basic modules, aggregated
>>>> together.
>>>> Their function in life is to assist developers of applications
>>>> that embed some level of
>>>> Tuscany capability (including tools, Tuscany itself and so on)
>>>>
>>>> These are probably not agreed by folk today - we have work to
>>>> do here to define these.
>>>> You demonstrate the problem in your example above - you want
>>>> "Basic Web Services" separate from
>>>> "Web Services Security" - but for an end user, the step from
>>>> using the first to using the
>>>> second is a trivial addition of @required="integrity" to the
>>>> SCDL.
>>>>
>>>> Anyone care to have a go at defining these compoennts?
>>>>
>>>>
>>>> Thats taking a different tack to the launcher appraoch but maybe we
>>>> need both and this approach would be easier for embedders so ok to
>>>> move things long I'll try an initial stab at it:
>>>>
>>>> 1) tuscany-scdl4j
>>>>
>>>> An aggregated jar containing _all_ the model and stax processor
>>>> classes which can be used by tools etc for for reading/writing scdl
>>>> without booting a runtime. It includes all the extension classes as
>>>> they generally don't drag in any other dependencies so its not
>>>> really any problem to incude them. The only required dependency
>>>> would be on stax, maybe some optional dependencies like wsdl4j as
>>>> the wsdl extension may need that. Not sure if any of the
>>>> contribution modules should be included, would have to investigate
>>>> that a bit.
>>>>
>>>> 2) tuscany-runtime
>>>> An aggregated jar containing the minimum modules to start a runtime
>>>> able to run something like the simple calculator sample. Has
>>>> dependencies on tuscany-scdl4j and minimal other jars -
>>>> geronimo-commonj_1.1_spec, cglib, jaxb etc.
>>>>
>>>> 3) tuscany-api
>>>> An aggregated jar containing everything tuscany/sca applications
>>>> might need to compile - sca-api, SCADomain class from host-embedded,
>>>> node2-api, jsp taglib etc. Has no external dependencies.
>>>>
>>>> 4) Single jars for all the binding and implementation type
>>>> extensions which add the capability to the minimal tuscany-runtime.
>>>> We're already starting to get these with the way extensions are
>>>> being structured nowadays - binding-jsonrpc-runtime,
>>>> binding-ejb-runtime, implementation-widget-runtime etc.
>>>>
>>>> The above would make life for embedders much easier like the
>>>> Tuscany-Geronimo integration code (or JBoss when they come along)
>>>> less likely to break over releases as we add remove modules.
>>>>
>>>> ...ant
>>>>
>>>>
>>>> No comments on this after a couple of weeks so I'll go start trying it.
>>>>
>>>> ...ant
>>>>
>>> >
>>> I'd like to help with this. Please post an update here when you
>>> have something that others can look at and get involved with.
>>>
>>> Simon
>>>
>>>
>> Ok, in r673092 there's some minimal aggregate jars which get the
>> calculator sample running.
>>
>> - tuscany-api which has the application compile dependencies - the
>> sca-api and Tuscany SCADomain api classes
>> - tuscany-scdl4j which has the model and stax processor classes
>> - tuscany-runtime2 which has the runtime classes to needed to run Tuscany
>> and just Java implementation types
>>
>> And there's a sample/calculator2 which is the calculator sample using
>> these new modules. The output of "mvn dependency:tree" in calculator2 shows
>> all the jars needed to run the sample:
>>
>> [INFO] org.apache.tuscany.sca:sample-calculator2:jar:1.4-SNAPSHOT
>> [INFO] +- org.apache.tuscany.sca:tuscany-api:jar:1.4-SNAPSHOT:compile
>> [INFO] +- org.apache.tuscany.sca:tuscany-scdl4j:jar:1.4-SNAPSHOT:runtime
>> [INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:runtime
>> [INFO] | \- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime
>> [INFO] +- org.apache.tuscany.sca:tuscany-runtime2:jar:1.4-SNAPSHOT:runtime
>> [INFO] | +- xml-apis:xml-apis:jar:1.3.03:runtime
>> [INFO] | +- asm:asm-all:jar:3.1:runtime
>> [INFO] | +- javax.jws:jsr181-api:jar:1.0-MR1:runtime
>> [INFO] | +- javax.xml.bind:jaxb-api:jar:2.1:runtime
>> [INFO] | +- org.jvnet.jaxb.reflection:jaxb2-reflection:jar:2.1.4:runtime
>> [INFO] | +- javax.annotation:jsr250-api:jar:1.0:runtime
>> [INFO] | +-
>> org.apache.geronimo.specs:geronimo-commonj_1.1_spec:jar:1.0:runtime
>> [INFO] | +- javax.activation:activation:jar:1.1:runtime
>> [INFO] | +- org.apache.ws.commons.schema:XmlSchema:jar:1.3.2:runtime
>> [INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:runtime
>> [INFO] | +- cglib:cglib-nodep:jar:2.1_3:runtime
>> [INFO] | \- javax.xml.ws:jaxws-api:jar:2.1:runtime
>> [INFO] \- junit:junit:jar:4.2:test
>>
>> From that output it looks like there are still dependencies being pulled
>> in that could be removed or made optional.
>>
>> ...ant
>>
>>
>
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have looked into what you have checked in. I think we need to make the following refinements:
1) IMO, this kind of collection of tuscany modules is very similar to Eclipse features which is the deployment descriptor of a set of Eclipse plugins. For the sake of discussion, let me call them tuscany features. Two features should be able to contain the same module.
2) The maven module for a tuscany feature should be just a pom project which declares the contained tuscany modules as dependencies.
<project>
<modelVersion>4.0.0</modelVersion>
<artifactId>tuscany-scdl4j</artifactId>
<packaging>pom</packaging>
- <dependencies>
<!-- All the contained modules should be declared her as dependency -->
<dependencies>
</project>
The applications or other features can just declare the tuscany feature pom project as a dependency to reference that feature.
It seems that the distro prototype added by Sebastien has already taken the pom project approach. See http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/distribution/base/pom.xml.
3) The feature module should not try to aggregate the modules into a new jar. As the new jar will consume more storage, add duplicate classes and does not support overlay.
4) We should add a new folder such as "features" to host all defined feature modules. IMO, the "scdl4j" should be checked in under this "features" folder instead of "modules" which hosts all the physical/atomic modules. The other option is to check them in under "distribution". The distro should be just an aggregation of one or more features.
Thanks,
Raymond
From: ant elder
Sent: Tuesday, July 01, 2008 4:51 PM
To: dev@tuscany.apache.org
Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jul 1, 2008 at 6:11 PM, Raymond Feng <en...@gmail.com> wrote:
I renamed the thread to better reflect the nature of this discussion.
Maybe we need a discussion thread on all the subject line fiddling that goes on these days ;-)
I have a few questions here:
1) If an application uses binding.ejb, what would the dependency look like?
I've not added ejb support yet but ideally it would be something like just adding the binding-ejb-runtime jar, along with the standard tuscany-api, tuscany-scdl4j, and tuscany-runtime jars.
2) Where are the databinding modules being aggregated?
The runtime jar currenlty contains the modules: tuscany-core-databinding, tuscany-databinding, tuscany-databinding-jaxb
I guess the other ones like databinding-axiom, databinding-fastinfoset etc would be optional ones that you'd add as single jars if required. Actually no, databinding-axiom and databinding-jaxb-axiom could be included in a tuscany-runtime-ws-axis2 agregate jar that includes everything you need to use web services. So something like a calculator-ws sample would use the jars: tuscany-api, tuscany-scdl4j, tuscany-runtime, and tuscany-runtime-ws-axis2
3) Is the java component support in tuscany-runtime?
Currently yes, it seemed to make sense to include that one implementation type.
WDYT? All this is quite embryonic so feel free to point out flaws or dive in with alternatives.
Thanks,
Raymond
From: ant elder
Sent: Tuesday, July 01, 2008 8:04 AM
To: dev@tuscany.apache.org
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jul 1, 2008 at 12:09 PM, Simon Nash <na...@apache.org> wrote:
ant elder wrote:
On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com <ma...@gmail.com>> wrote:
On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
<mike.edwards.inglenook@gmail.com
<ma...@gmail.com>> wrote:
<snip>
b) A variety of functional components, that represent sets of
coherent functions.
Each consists of a series of the basic modules, aggregated
together.
Their function in life is to assist developers of applications
that embed some level of
Tuscany capability (including tools, Tuscany itself and so on)
These are probably not agreed by folk today - we have work to
do here to define these.
You demonstrate the problem in your example above - you want
"Basic Web Services" separate from
"Web Services Security" - but for an end user, the step from
using the first to using the
second is a trivial addition of @required="integrity" to the SCDL.
Anyone care to have a go at defining these compoennts?
Thats taking a different tack to the launcher appraoch but maybe we
need both and this approach would be easier for embedders so ok to
move things long I'll try an initial stab at it:
1) tuscany-scdl4j
An aggregated jar containing _all_ the model and stax processor
classes which can be used by tools etc for for reading/writing scdl
without booting a runtime. It includes all the extension classes as
they generally don't drag in any other dependencies so its not
really any problem to incude them. The only required dependency
would be on stax, maybe some optional dependencies like wsdl4j as
the wsdl extension may need that. Not sure if any of the
contribution modules should be included, would have to investigate
that a bit.
2) tuscany-runtime
An aggregated jar containing the minimum modules to start a runtime
able to run something like the simple calculator sample. Has
dependencies on tuscany-scdl4j and minimal other jars -
geronimo-commonj_1.1_spec, cglib, jaxb etc.
3) tuscany-api
An aggregated jar containing everything tuscany/sca applications
might need to compile - sca-api, SCADomain class from host-embedded,
node2-api, jsp taglib etc. Has no external dependencies.
4) Single jars for all the binding and implementation type
extensions which add the capability to the minimal tuscany-runtime.
We're already starting to get these with the way extensions are
being structured nowadays - binding-jsonrpc-runtime,
binding-ejb-runtime, implementation-widget-runtime etc.
The above would make life for embedders much easier like the
Tuscany-Geronimo integration code (or JBoss when they come along)
less likely to break over releases as we add remove modules.
...ant
No comments on this after a couple of weeks so I'll go start trying it.
...ant
>
I'd like to help with this. Please post an update here when you
have something that others can look at and get involved with.
Simon
Ok, in r673092 there's some minimal aggregate jars which get the calculator sample running.
- tuscany-api which has the application compile dependencies - the sca-api and Tuscany SCADomain api classes
- tuscany-scdl4j which has the model and stax processor classes
- tuscany-runtime2 which has the runtime classes to needed to run Tuscany and just Java implementation types
And there's a sample/calculator2 which is the calculator sample using these new modules. The output of "mvn dependency:tree" in calculator2 shows all the jars needed to run the sample:
[INFO] org.apache.tuscany.sca:sample-calculator2:jar:1.4-SNAPSHOT
[INFO] +- org.apache.tuscany.sca:tuscany-api:jar:1.4-SNAPSHOT:compile
[INFO] +- org.apache.tuscany.sca:tuscany-scdl4j:jar:1.4-SNAPSHOT:runtime
[INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:runtime
[INFO] | \- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime
[INFO] +- org.apache.tuscany.sca:tuscany-runtime2:jar:1.4-SNAPSHOT:runtime
[INFO] | +- xml-apis:xml-apis:jar:1.3.03:runtime
[INFO] | +- asm:asm-all:jar:3.1:runtime
[INFO] | +- javax.jws:jsr181-api:jar:1.0-MR1:runtime
[INFO] | +- javax.xml.bind:jaxb-api:jar:2.1:runtime
[INFO] | +- org.jvnet.jaxb.reflection:jaxb2-reflection:jar:2.1.4:runtime
[INFO] | +- javax.annotation:jsr250-api:jar:1.0:runtime
[INFO] | +- org.apache.geronimo.specs:geronimo-commonj_1.1_spec:jar:1.0:runtime
[INFO] | +- javax.activation:activation:jar:1.1:runtime
[INFO] | +- org.apache.ws.commons.schema:XmlSchema:jar:1.3.2:runtime
[INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:runtime
[INFO] | +- cglib:cglib-nodep:jar:2.1_3:runtime
[INFO] | \- javax.xml.ws:jaxws-api:jar:2.1:runtime
[INFO] \- junit:junit:jar:4.2:test
From that output it looks like there are still dependencies being pulled in that could be removed or made optional.
...ant
Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@apache.org>.
On Tue, Jul 1, 2008 at 6:11 PM, Raymond Feng <en...@gmail.com> wrote:
> I renamed the thread to better reflect the nature of this discussion.
>
Maybe we need a discussion thread on all the subject line fiddling that goes
on these days ;-)
>
> I have a few questions here:
>
> 1) If an application uses binding.ejb, what would the dependency look like?
>
>
I've not added ejb support yet but ideally it would be something like just
adding the binding-ejb-runtime jar, along with the standard tuscany-api,
tuscany-scdl4j, and tuscany-runtime jars.
2) Where are the databinding modules being aggregated?
>
>
The runtime jar currenlty contains the modules: tuscany-core-databinding,
tuscany-databinding, tuscany-databinding-jaxb
I guess the other ones like databinding-axiom, databinding-fastinfoset etc
would be optional ones that you'd add as single jars if required. Actually
no, databinding-axiom and databinding-jaxb-axiom could be included in a
tuscany-runtime-ws-axis2 agregate jar that includes everything you need to
use web services. So something like a calculator-ws sample would use the
jars: tuscany-api, tuscany-scdl4j, tuscany-runtime, and
tuscany-runtime-ws-axis2
3) Is the java component support in tuscany-runtime?
>
Currently yes, it seemed to make sense to include that one implementation
type.
WDYT? All this is quite embryonic so feel free to point out flaws or dive in
with alternatives.
> Thanks,
> Raymond
>
> *From:* ant elder <an...@gmail.com>
> *Sent:* Tuesday, July 01, 2008 8:04 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: Tracking Tuscany extensions, was: Distribution zips and
> what they contain, was: SCA runtimes
>
>
>
> On Tue, Jul 1, 2008 at 12:09 PM, Simon Nash <na...@apache.org> wrote:
>
>> ant elder wrote:
>>
>>>
>>>
>>> On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com <mailto:
>>> ant.elder@gmail.com>> wrote:
>>>
>>>
>>>
>>> On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
>>> <mike.edwards.inglenook@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> <snip>
>>>
>>>
>>> b) A variety of functional components, that represent sets of
>>> coherent functions.
>>>
>>> Each consists of a series of the basic modules, aggregated
>>> together.
>>> Their function in life is to assist developers of applications
>>> that embed some level of
>>> Tuscany capability (including tools, Tuscany itself and so on)
>>>
>>> These are probably not agreed by folk today - we have work to
>>> do here to define these.
>>> You demonstrate the problem in your example above - you want
>>> "Basic Web Services" separate from
>>> "Web Services Security" - but for an end user, the step from
>>> using the first to using the
>>> second is a trivial addition of @required="integrity" to the
>>> SCDL.
>>>
>>> Anyone care to have a go at defining these compoennts?
>>>
>>>
>>> Thats taking a different tack to the launcher appraoch but maybe we
>>> need both and this approach would be easier for embedders so ok to
>>> move things long I'll try an initial stab at it:
>>>
>>> 1) tuscany-scdl4j
>>>
>>> An aggregated jar containing _all_ the model and stax processor
>>> classes which can be used by tools etc for for reading/writing scdl
>>> without booting a runtime. It includes all the extension classes as
>>> they generally don't drag in any other dependencies so its not
>>> really any problem to incude them. The only required dependency
>>> would be on stax, maybe some optional dependencies like wsdl4j as
>>> the wsdl extension may need that. Not sure if any of the
>>> contribution modules should be included, would have to investigate
>>> that a bit.
>>>
>>> 2) tuscany-runtime
>>> An aggregated jar containing the minimum modules to start a runtime
>>> able to run something like the simple calculator sample. Has
>>> dependencies on tuscany-scdl4j and minimal other jars -
>>> geronimo-commonj_1.1_spec, cglib, jaxb etc.
>>>
>>> 3) tuscany-api
>>> An aggregated jar containing everything tuscany/sca applications
>>> might need to compile - sca-api, SCADomain class from host-embedded,
>>> node2-api, jsp taglib etc. Has no external dependencies.
>>>
>>> 4) Single jars for all the binding and implementation type
>>> extensions which add the capability to the minimal tuscany-runtime.
>>> We're already starting to get these with the way extensions are
>>> being structured nowadays - binding-jsonrpc-runtime,
>>> binding-ejb-runtime, implementation-widget-runtime etc.
>>>
>>> The above would make life for embedders much easier like the
>>> Tuscany-Geronimo integration code (or JBoss when they come along)
>>> less likely to break over releases as we add remove modules.
>>>
>>> ...ant
>>>
>>>
>>> No comments on this after a couple of weeks so I'll go start trying it.
>>>
>>> ...ant
>>>
>> >
>> I'd like to help with this. Please post an update here when you
>> have something that others can look at and get involved with.
>>
>> Simon
>>
>>
> Ok, in r673092 there's some minimal aggregate jars which get the calculator
> sample running.
>
> - tuscany-api which has the application compile dependencies - the sca-api
> and Tuscany SCADomain api classes
> - tuscany-scdl4j which has the model and stax processor classes
> - tuscany-runtime2 which has the runtime classes to needed to run Tuscany
> and just Java implementation types
>
> And there's a sample/calculator2 which is the calculator sample using these
> new modules. The output of "mvn dependency:tree" in calculator2 shows all
> the jars needed to run the sample:
>
> [INFO] org.apache.tuscany.sca:sample-calculator2:jar:1.4-SNAPSHOT
> [INFO] +- org.apache.tuscany.sca:tuscany-api:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.apache.tuscany.sca:tuscany-scdl4j:jar:1.4-SNAPSHOT:runtime
> [INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:runtime
> [INFO] | \- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime
> [INFO] +- org.apache.tuscany.sca:tuscany-runtime2:jar:1.4-SNAPSHOT:runtime
> [INFO] | +- xml-apis:xml-apis:jar:1.3.03:runtime
> [INFO] | +- asm:asm-all:jar:3.1:runtime
> [INFO] | +- javax.jws:jsr181-api:jar:1.0-MR1:runtime
> [INFO] | +- javax.xml.bind:jaxb-api:jar:2.1:runtime
> [INFO] | +- org.jvnet.jaxb.reflection:jaxb2-reflection:jar:2.1.4:runtime
> [INFO] | +- javax.annotation:jsr250-api:jar:1.0:runtime
> [INFO] | +-
> org.apache.geronimo.specs:geronimo-commonj_1.1_spec:jar:1.0:runtime
> [INFO] | +- javax.activation:activation:jar:1.1:runtime
> [INFO] | +- org.apache.ws.commons.schema:XmlSchema:jar:1.3.2:runtime
> [INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:runtime
> [INFO] | +- cglib:cglib-nodep:jar:2.1_3:runtime
> [INFO] | \- javax.xml.ws:jaxws-api:jar:2.1:runtime
> [INFO] \- junit:junit:jar:4.2:test
>
> From that output it looks like there are still dependencies being pulled in
> that could be removed or made optional.
>
> ...ant
>
>
Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
I renamed the thread to better reflect the nature of this discussion.
I have a few questions here:
1) If an application uses binding.ejb, what would the dependency look like?
2) Where are the databinding modules being aggregated?
3) Is the java component support in tuscany-runtime?
Thanks,
Raymond
From: ant elder
Sent: Tuesday, July 01, 2008 8:04 AM
To: dev@tuscany.apache.org
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jul 1, 2008 at 12:09 PM, Simon Nash <na...@apache.org> wrote:
ant elder wrote:
On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com <ma...@gmail.com>> wrote:
On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
<mike.edwards.inglenook@gmail.com
<ma...@gmail.com>> wrote:
<snip>
b) A variety of functional components, that represent sets of
coherent functions.
Each consists of a series of the basic modules, aggregated
together.
Their function in life is to assist developers of applications
that embed some level of
Tuscany capability (including tools, Tuscany itself and so on)
These are probably not agreed by folk today - we have work to
do here to define these.
You demonstrate the problem in your example above - you want
"Basic Web Services" separate from
"Web Services Security" - but for an end user, the step from
using the first to using the
second is a trivial addition of @required="integrity" to the SCDL.
Anyone care to have a go at defining these compoennts?
Thats taking a different tack to the launcher appraoch but maybe we
need both and this approach would be easier for embedders so ok to
move things long I'll try an initial stab at it:
1) tuscany-scdl4j
An aggregated jar containing _all_ the model and stax processor
classes which can be used by tools etc for for reading/writing scdl
without booting a runtime. It includes all the extension classes as
they generally don't drag in any other dependencies so its not
really any problem to incude them. The only required dependency
would be on stax, maybe some optional dependencies like wsdl4j as
the wsdl extension may need that. Not sure if any of the
contribution modules should be included, would have to investigate
that a bit.
2) tuscany-runtime
An aggregated jar containing the minimum modules to start a runtime
able to run something like the simple calculator sample. Has
dependencies on tuscany-scdl4j and minimal other jars -
geronimo-commonj_1.1_spec, cglib, jaxb etc.
3) tuscany-api
An aggregated jar containing everything tuscany/sca applications
might need to compile - sca-api, SCADomain class from host-embedded,
node2-api, jsp taglib etc. Has no external dependencies.
4) Single jars for all the binding and implementation type
extensions which add the capability to the minimal tuscany-runtime.
We're already starting to get these with the way extensions are
being structured nowadays - binding-jsonrpc-runtime,
binding-ejb-runtime, implementation-widget-runtime etc.
The above would make life for embedders much easier like the
Tuscany-Geronimo integration code (or JBoss when they come along)
less likely to break over releases as we add remove modules.
...ant
No comments on this after a couple of weeks so I'll go start trying it.
...ant
>
I'd like to help with this. Please post an update here when you
have something that others can look at and get involved with.
Simon
Ok, in r673092 there's some minimal aggregate jars which get the calculator sample running.
- tuscany-api which has the application compile dependencies - the sca-api and Tuscany SCADomain api classes
- tuscany-scdl4j which has the model and stax processor classes
- tuscany-runtime2 which has the runtime classes to needed to run Tuscany and just Java implementation types
And there's a sample/calculator2 which is the calculator sample using these new modules. The output of "mvn dependency:tree" in calculator2 shows all the jars needed to run the sample:
[INFO] org.apache.tuscany.sca:sample-calculator2:jar:1.4-SNAPSHOT
[INFO] +- org.apache.tuscany.sca:tuscany-api:jar:1.4-SNAPSHOT:compile
[INFO] +- org.apache.tuscany.sca:tuscany-scdl4j:jar:1.4-SNAPSHOT:runtime
[INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:runtime
[INFO] | \- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime
[INFO] +- org.apache.tuscany.sca:tuscany-runtime2:jar:1.4-SNAPSHOT:runtime
[INFO] | +- xml-apis:xml-apis:jar:1.3.03:runtime
[INFO] | +- asm:asm-all:jar:3.1:runtime
[INFO] | +- javax.jws:jsr181-api:jar:1.0-MR1:runtime
[INFO] | +- javax.xml.bind:jaxb-api:jar:2.1:runtime
[INFO] | +- org.jvnet.jaxb.reflection:jaxb2-reflection:jar:2.1.4:runtime
[INFO] | +- javax.annotation:jsr250-api:jar:1.0:runtime
[INFO] | +- org.apache.geronimo.specs:geronimo-commonj_1.1_spec:jar:1.0:runtime
[INFO] | +- javax.activation:activation:jar:1.1:runtime
[INFO] | +- org.apache.ws.commons.schema:XmlSchema:jar:1.3.2:runtime
[INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:runtime
[INFO] | +- cglib:cglib-nodep:jar:2.1_3:runtime
[INFO] | \- javax.xml.ws:jaxws-api:jar:2.1:runtime
[INFO] \- junit:junit:jar:4.2:test
>From that output it looks like there are still dependencies being pulled in that could be removed or made optional.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Tue, Jul 1, 2008 at 12:09 PM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>
>>
>>
>> On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com <mailto:
>> ant.elder@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
>> <mike.edwards.inglenook@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> <snip>
>>
>>
>> b) A variety of functional components, that represent sets of
>> coherent functions.
>>
>> Each consists of a series of the basic modules, aggregated
>> together.
>> Their function in life is to assist developers of applications
>> that embed some level of
>> Tuscany capability (including tools, Tuscany itself and so on)
>>
>> These are probably not agreed by folk today - we have work to
>> do here to define these.
>> You demonstrate the problem in your example above - you want
>> "Basic Web Services" separate from
>> "Web Services Security" - but for an end user, the step from
>> using the first to using the
>> second is a trivial addition of @required="integrity" to the
>> SCDL.
>>
>> Anyone care to have a go at defining these compoennts?
>>
>>
>> Thats taking a different tack to the launcher appraoch but maybe we
>> need both and this approach would be easier for embedders so ok to
>> move things long I'll try an initial stab at it:
>>
>> 1) tuscany-scdl4j
>>
>> An aggregated jar containing _all_ the model and stax processor
>> classes which can be used by tools etc for for reading/writing scdl
>> without booting a runtime. It includes all the extension classes as
>> they generally don't drag in any other dependencies so its not
>> really any problem to incude them. The only required dependency
>> would be on stax, maybe some optional dependencies like wsdl4j as
>> the wsdl extension may need that. Not sure if any of the
>> contribution modules should be included, would have to investigate
>> that a bit.
>>
>> 2) tuscany-runtime
>> An aggregated jar containing the minimum modules to start a runtime
>> able to run something like the simple calculator sample. Has
>> dependencies on tuscany-scdl4j and minimal other jars -
>> geronimo-commonj_1.1_spec, cglib, jaxb etc.
>>
>> 3) tuscany-api
>> An aggregated jar containing everything tuscany/sca applications
>> might need to compile - sca-api, SCADomain class from host-embedded,
>> node2-api, jsp taglib etc. Has no external dependencies.
>>
>> 4) Single jars for all the binding and implementation type
>> extensions which add the capability to the minimal tuscany-runtime.
>> We're already starting to get these with the way extensions are
>> being structured nowadays - binding-jsonrpc-runtime,
>> binding-ejb-runtime, implementation-widget-runtime etc.
>>
>> The above would make life for embedders much easier like the
>> Tuscany-Geronimo integration code (or JBoss when they come along)
>> less likely to break over releases as we add remove modules.
>>
>> ...ant
>>
>>
>> No comments on this after a couple of weeks so I'll go start trying it.
>>
>> ...ant
>>
> >
> I'd like to help with this. Please post an update here when you
> have something that others can look at and get involved with.
>
> Simon
>
>
Ok, in r673092 there's some minimal aggregate jars which get the calculator
sample running.
- tuscany-api which has the application compile dependencies - the sca-api
and Tuscany SCADomain api classes
- tuscany-scdl4j which has the model and stax processor classes
- tuscany-runtime2 which has the runtime classes to needed to run Tuscany
and just Java implementation types
And there's a sample/calculator2 which is the calculator sample using these
new modules. The output of "mvn dependency:tree" in calculator2 shows all
the jars needed to run the sample:
[INFO] org.apache.tuscany.sca:sample-calculator2:jar:1.4-SNAPSHOT
[INFO] +- org.apache.tuscany.sca:tuscany-api:jar:1.4-SNAPSHOT:compile
[INFO] +- org.apache.tuscany.sca:tuscany-scdl4j:jar:1.4-SNAPSHOT:runtime
[INFO] | +- javax.xml.stream:stax-api:jar:1.0-2:runtime
[INFO] | \- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime
[INFO] +- org.apache.tuscany.sca:tuscany-runtime2:jar:1.4-SNAPSHOT:runtime
[INFO] | +- xml-apis:xml-apis:jar:1.3.03:runtime
[INFO] | +- asm:asm-all:jar:3.1:runtime
[INFO] | +- javax.jws:jsr181-api:jar:1.0-MR1:runtime
[INFO] | +- javax.xml.bind:jaxb-api:jar:2.1:runtime
[INFO] | +- org.jvnet.jaxb.reflection:jaxb2-reflection:jar:2.1.4:runtime
[INFO] | +- javax.annotation:jsr250-api:jar:1.0:runtime
[INFO] | +-
org.apache.geronimo.specs:geronimo-commonj_1.1_spec:jar:1.0:runtime
[INFO] | +- javax.activation:activation:jar:1.1:runtime
[INFO] | +- org.apache.ws.commons.schema:XmlSchema:jar:1.3.2:runtime
[INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:runtime
[INFO] | +- cglib:cglib-nodep:jar:2.1_3:runtime
[INFO] | \- javax.xml.ws:jaxws-api:jar:2.1:runtime
[INFO] \- junit:junit:jar:4.2:test
>From that output it looks like there are still dependencies being pulled in
that could be removed or made optional.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
>
>
> On Sun, Jun 15, 2008 at 8:52 AM, ant elder <ant.elder@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards
> <mike.edwards.inglenook@gmail.com
> <ma...@gmail.com>> wrote:
>
> <snip>
>
>
> b) A variety of functional components, that represent sets of
> coherent functions.
>
> Each consists of a series of the basic modules, aggregated
> together.
> Their function in life is to assist developers of applications
> that embed some level of
> Tuscany capability (including tools, Tuscany itself and so on)
>
> These are probably not agreed by folk today - we have work to
> do here to define these.
> You demonstrate the problem in your example above - you want
> "Basic Web Services" separate from
> "Web Services Security" - but for an end user, the step from
> using the first to using the
> second is a trivial addition of @required="integrity" to the SCDL.
>
> Anyone care to have a go at defining these compoennts?
>
>
> Thats taking a different tack to the launcher appraoch but maybe we
> need both and this approach would be easier for embedders so ok to
> move things long I'll try an initial stab at it:
>
> 1) tuscany-scdl4j
>
> An aggregated jar containing _all_ the model and stax processor
> classes which can be used by tools etc for for reading/writing scdl
> without booting a runtime. It includes all the extension classes as
> they generally don't drag in any other dependencies so its not
> really any problem to incude them. The only required dependency
> would be on stax, maybe some optional dependencies like wsdl4j as
> the wsdl extension may need that. Not sure if any of the
> contribution modules should be included, would have to investigate
> that a bit.
>
> 2) tuscany-runtime
> An aggregated jar containing the minimum modules to start a runtime
> able to run something like the simple calculator sample. Has
> dependencies on tuscany-scdl4j and minimal other jars -
> geronimo-commonj_1.1_spec, cglib, jaxb etc.
>
> 3) tuscany-api
> An aggregated jar containing everything tuscany/sca applications
> might need to compile - sca-api, SCADomain class from host-embedded,
> node2-api, jsp taglib etc. Has no external dependencies.
>
> 4) Single jars for all the binding and implementation type
> extensions which add the capability to the minimal tuscany-runtime.
> We're already starting to get these with the way extensions are
> being structured nowadays - binding-jsonrpc-runtime,
> binding-ejb-runtime, implementation-widget-runtime etc.
>
> The above would make life for embedders much easier like the
> Tuscany-Geronimo integration code (or JBoss when they come along)
> less likely to break over releases as we add remove modules.
>
> ...ant
>
>
> No comments on this after a couple of weeks so I'll go start trying it.
>
> ...ant
>
I'd like to help with this. Please post an update here when you
have something that others can look at and get involved with.
Simon
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Sun, Jun 15, 2008 at 8:52 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards <
> mike.edwards.inglenook@gmail.com> wrote:
>
> <snip>
>
> b) A variety of functional components, that represent sets of coherent
>> functions.
>>
>> Each consists of a series of the basic modules, aggregated together.
>> Their function in life is to assist developers of applications that
>> embed some level of
>> Tuscany capability (including tools, Tuscany itself and so on)
>>
>> These are probably not agreed by folk today - we have work to do here to
>> define these.
>> You demonstrate the problem in your example above - you want "Basic Web
>> Services" separate from
>> "Web Services Security" - but for an end user, the step from using the
>> first to using the
>> second is a trivial addition of @required="integrity" to the SCDL.
>>
>> Anyone care to have a go at defining these compoennts?
>>
>>
> Thats taking a different tack to the launcher appraoch but maybe we need
> both and this approach would be easier for embedders so ok to move things
> long I'll try an initial stab at it:
>
> 1) tuscany-scdl4j
>
> An aggregated jar containing _all_ the model and stax processor classes
> which can be used by tools etc for for reading/writing scdl without booting
> a runtime. It includes all the extension classes as they generally don't
> drag in any other dependencies so its not really any problem to incude them.
> The only required dependency would be on stax, maybe some optional
> dependencies like wsdl4j as the wsdl extension may need that. Not sure if
> any of the contribution modules should be included, would have to
> investigate that a bit.
>
> 2) tuscany-runtime
> An aggregated jar containing the minimum modules to start a runtime able to
> run something like the simple calculator sample. Has dependencies on
> tuscany-scdl4j and minimal other jars - geronimo-commonj_1.1_spec, cglib,
> jaxb etc.
>
> 3) tuscany-api
> An aggregated jar containing everything tuscany/sca applications might need
> to compile - sca-api, SCADomain class from host-embedded, node2-api, jsp
> taglib etc. Has no external dependencies.
>
> 4) Single jars for all the binding and implementation type extensions which
> add the capability to the minimal tuscany-runtime. We're already starting to
> get these with the way extensions are being structured nowadays -
> binding-jsonrpc-runtime, binding-ejb-runtime, implementation-widget-runtime
> etc.
>
> The above would make life for embedders much easier like the
> Tuscany-Geronimo integration code (or JBoss when they come along) less
> likely to break over releases as we add remove modules.
>
> ...ant
>
>
No comments on this after a couple of weeks so I'll go start trying it.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
<snip>
b) A variety of functional components, that represent sets of coherent
> functions.
>
> Each consists of a series of the basic modules, aggregated together.
> Their function in life is to assist developers of applications that embed
> some level of
> Tuscany capability (including tools, Tuscany itself and so on)
>
> These are probably not agreed by folk today - we have work to do here to
> define these.
> You demonstrate the problem in your example above - you want "Basic Web
> Services" separate from
> "Web Services Security" - but for an end user, the step from using the
> first to using the
> second is a trivial addition of @required="integrity" to the SCDL.
>
> Anyone care to have a go at defining these compoennts?
>
>
Thats taking a different tack to the launcher appraoch but maybe we need
both and this approach would be easier for embedders so ok to move things
long I'll try an initial stab at it:
1) tuscany-scdl4j
An aggregated jar containing _all_ the model and stax processor classes
which can be used by tools etc for for reading/writing scdl without booting
a runtime. It includes all the extension classes as they generally don't
drag in any other dependencies so its not really any problem to incude them.
The only required dependency would be on stax, maybe some optional
dependencies like wsdl4j as the wsdl extension may need that. Not sure if
any of the contribution modules should be included, would have to
investigate that a bit.
2) tuscany-runtime
An aggregated jar containing the minimum modules to start a runtime able to
run something like the simple calculator sample. Has dependencies on
tuscany-scdl4j and minimal other jars - geronimo-commonj_1.1_spec, cglib,
jaxb etc.
3) tuscany-api
An aggregated jar containing everything tuscany/sca applications might need
to compile - sca-api, SCADomain class from host-embedded, node2-api, jsp
taglib etc. Has no external dependencies.
4) Single jars for all the binding and implementation type extensions which
add the capability to the minimal tuscany-runtime. We're already starting to
get these with the way extensions are being structured nowadays -
binding-jsonrpc-runtime, binding-ejb-runtime, implementation-widget-runtime
etc.
The above would make life for embedders much easier like the
Tuscany-Geronimo integration code (or JBoss when they come along) less
likely to break over releases as we add remove modules.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> Hi, Mike.
>
> It's a very good summary. The different perspectives are now well
> separated and they should be discussed on different threads to avoid
> further confusions :-).
>
> Please see some more comments inline.
>
I added a couple of responses on specific points below.
Simon
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Mike Edwards" <mi...@gmail.com>
> Sent: Friday, June 13, 2008 2:08 PM
> To: <tu...@ws.apache.org>
> Subject: Re: Tracking Tuscany extensions, was: Distribution zips and
> what they contain, was: SCA runtimes
>
>> Simon Nash wrote:
>>> 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 and/or Web services policy.
>>> I also wouldn't put assembly and core in the same basic component,
>>> because some users might just want the Tuscany model without the
>>> Tuscany runtime. But I would put interface and assembly together in the
>>> same basic component, because there are no cases where one would be used
>>> without the other, and I would put core, core-databinding and
>>> databinding
>>> together in the same basic component for the same reason.
>>>
>>> Simon
>>>
>> Simon,
>>
>> I'm not clear what components you are talking about here.
>>
>> It seems to me that we have things are different granularities, for
>> different purposes and for different users, something like this
>> (starting at the smallest):
>>
>> a) Basic modules, as we have today.
>> These are largely for Tuscany developers, but they should represent
>> a level of development
>> independence.
>>
>> Some folk (including me) believe that it is these modules that
>> should be OSGi bundles.
>> If there really is NO reason to separate functionality, then we
>> should merge modules at this
>> level. I don't think that is necessary at present.
>
> +1. The OSGi bundles are the basic units to constitute the tuscany
> runtime and they formally defines the SPI contracts across the modules.
> Maven modules are the static/structural reflection of the same idea.
>
There could reasons why a developer would want to separate functionality
into multiple modules even though these modules are never separated when
assembling the larger aggregrations at the b) and c) level. I see a few
ways to handle this situation:
1) Optimize the module split around developer convenience and let the
basic module structure reflect this. This could create finer-grained
modules than are needed by the b) and c) levels.
2) Optimize the module split around the granularity that is needed by
the b) and c) levels. This could create coarser-grained modules than
are ideal from a developer perspective.
3) Create an additional level in the hierarchy between the a) and b)
levels as defined here. This creates confusion and complexity.
I have been arguing for some combination of 2) and 3). As a result of
this discussion, I'd like to explore the alternative of using 1) in
combination with a strengthened role for the b) level. This might
provide the advantages of 2) and 3) without their disadvantages.
So I'd like to suggest that we try to make progress at the b) level
first and come back to the a) level when we know what the b) level
looks like.
>>
>> b) A variety of functional components, that represent sets of coherent
>> functions.
>>
>> Each consists of a series of the basic modules, aggregated together.
>> Their function in life is to assist developers of applications that
>> embed some level of
>> Tuscany capability (including tools, Tuscany itself and so on)
>>
>> These are probably not agreed by folk today - we have work to do
>> here to define these.
>> You demonstrate the problem in your example above - you want "Basic
>> Web Services" separate from
>> "Web Services Security" - but for an end user, the step from using
>> the first to using the
>> second is a trivial addition of @required="integrity" to the SCDL.
>>
>> Anyone care to have a go at defining these compoennts?
>>
>
> What physical representations of this layer? A library/collection of
> bundles like Eclispe feature?
>
>> c) A small number of large packages aimed at supporting end users in a
>> series of environments and
>> with a specific set of functionality
>>
>> Frankly, the average end user would prefer as few of these as
>> possible. 1 is ideal.
>> However, I recognise that we are likely to have different groups of
>> users with different needs,
>> so that multiple packages are pragmatic - avoiding providing huge
>> hunks of unneeded code to users
>> who will never need them (eg no BPEL needed? - let's not have
>> implementation.bpel and its
>> humongous ODE 3rd party dependencies)
>>
>> Jean-Sebastien has made a stab at these packages, and I think they
>> are a good starting point.
>>
>
> +1. This is about physical distributions which pick modules from a) and
> package them into archives to be downloaded/shipped. We probably just
> have to agree on this idea in principle. And we can tune the various
> combinations over time based on user feedbacks.
>
I would expect these to be based on a combination of components from b),
with duplicate modules eliminated, not on custom combinations of modules
from a). If we can't build these packages by aggregating b) components,
this would indicate that we don't have the right groupings at the b) level.
Simon
>> d) Simple ways of starting Tuscany fucntionality - based on using the
>> packages in c)
>>
>> This includes a launcher (or launchers) and various forms of
>> embedding of Tuscany into other
>> runtime environments such as Tomcat, Geronimo (...pick your
>> favourite runtime...)
>>
>>
>
> +1 this is about platform or hosting environment specific deployment and
> launching.
>
>> I'd like to ask folks generally whether they agree with this
>> division. If we can agree on the division, I'd like to see us write
>> down the contents of each of a) b) c) and d) - ideally on some nice
>> Wiki page that we can maintain.
>>
>>
>
> +1 to have a wiki page.
>
>>
>> Yours, Mike.
>
>
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi, Mike.
It's a very good summary. The different perspectives are now well separated
and they should be discussed on different threads to avoid further
confusions :-).
Please see some more comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mi...@gmail.com>
Sent: Friday, June 13, 2008 2:08 PM
To: <tu...@ws.apache.org>
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
> Simon Nash wrote:
>> 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 and/or Web services policy.
>> I also wouldn't put assembly and core in the same basic component,
>> because some users might just want the Tuscany model without the
>> Tuscany runtime. But I would put interface and assembly together in the
>> same basic component, because there are no cases where one would be used
>> without the other, and I would put core, core-databinding and databinding
>> together in the same basic component for the same reason.
>>
>> Simon
>>
> Simon,
>
> I'm not clear what components you are talking about here.
>
> It seems to me that we have things are different granularities, for
> different purposes and for different users, something like this (starting
> at the smallest):
>
> a) Basic modules, as we have today.
> These are largely for Tuscany developers, but they should represent a
> level of development
> independence.
>
> Some folk (including me) believe that it is these modules that should
> be OSGi bundles.
> If there really is NO reason to separate functionality, then we should
> merge modules at this
> level. I don't think that is necessary at present.
+1. The OSGi bundles are the basic units to constitute the tuscany runtime
and they formally defines the SPI contracts across the modules. Maven
modules are the static/structural reflection of the same idea.
>
> b) A variety of functional components, that represent sets of coherent
> functions.
>
> Each consists of a series of the basic modules, aggregated together.
> Their function in life is to assist developers of applications that
> embed some level of
> Tuscany capability (including tools, Tuscany itself and so on)
>
> These are probably not agreed by folk today - we have work to do here
> to define these.
> You demonstrate the problem in your example above - you want "Basic Web
> Services" separate from
> "Web Services Security" - but for an end user, the step from using the
> first to using the
> second is a trivial addition of @required="integrity" to the SCDL.
>
> Anyone care to have a go at defining these compoennts?
>
What physical representations of this layer? A library/collection of bundles
like Eclispe feature?
> c) A small number of large packages aimed at supporting end users in a
> series of environments and
> with a specific set of functionality
>
> Frankly, the average end user would prefer as few of these as possible.
> 1 is ideal.
> However, I recognise that we are likely to have different groups of
> users with different needs,
> so that multiple packages are pragmatic - avoiding providing huge hunks
> of unneeded code to users
> who will never need them (eg no BPEL needed? - let's not have
> implementation.bpel and its
> humongous ODE 3rd party dependencies)
>
> Jean-Sebastien has made a stab at these packages, and I think they are
> a good starting point.
>
+1. This is about physical distributions which pick modules from a) and
package them into archives to be downloaded/shipped. We probably just have
to agree on this idea in principle. And we can tune the various combinations
over time based on user feedbacks.
> d) Simple ways of starting Tuscany fucntionality - based on using the
> packages in c)
>
> This includes a launcher (or launchers) and various forms of embedding
> of Tuscany into other
> runtime environments such as Tomcat, Geronimo (...pick your favourite
> runtime...)
>
>
+1 this is about platform or hosting environment specific deployment and
launching.
> I'd like to ask folks generally whether they agree with this division. If
> we can agree on the division, I'd like to see us write down the contents
> of each of a) b) c) and d) - ideally on some nice Wiki page that we can
> maintain.
>
>
+1 to have a wiki page.
>
> Yours, Mike.
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Mike Edwards <mi...@gmail.com>.
Simon Nash wrote:
> 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 and/or Web services policy.
> I also wouldn't put assembly and core in the same basic component,
> because some users might just want the Tuscany model without the
> Tuscany runtime. But I would put interface and assembly together in the
> same basic component, because there are no cases where one would be used
> without the other, and I would put core, core-databinding and databinding
> together in the same basic component for the same reason.
>
> Simon
>
Simon,
I'm not clear what components you are talking about here.
It seems to me that we have things are different granularities, for different purposes and for
different users, something like this (starting at the smallest):
a) Basic modules, as we have today.
These are largely for Tuscany developers, but they should represent a level of development
independence.
Some folk (including me) believe that it is these modules that should be OSGi bundles.
If there really is NO reason to separate functionality, then we should merge modules at this
level. I don't think that is necessary at present.
b) A variety of functional components, that represent sets of coherent functions.
Each consists of a series of the basic modules, aggregated together.
Their function in life is to assist developers of applications that embed some level of
Tuscany capability (including tools, Tuscany itself and so on)
These are probably not agreed by folk today - we have work to do here to define these.
You demonstrate the problem in your example above - you want "Basic Web Services" separate from
"Web Services Security" - but for an end user, the step from using the first to using the
second is a trivial addition of @required="integrity" to the SCDL.
Anyone care to have a go at defining these compoennts?
c) A small number of large packages aimed at supporting end users in a series of environments and
with a specific set of functionality
Frankly, the average end user would prefer as few of these as possible. 1 is ideal.
However, I recognise that we are likely to have different groups of users with different needs,
so that multiple packages are pragmatic - avoiding providing huge hunks of unneeded code to users
who will never need them (eg no BPEL needed? - let's not have implementation.bpel and its
humongous ODE 3rd party dependencies)
Jean-Sebastien has made a stab at these packages, and I think they are a good starting point.
d) Simple ways of starting Tuscany fucntionality - based on using the packages in c)
This includes a launcher (or launchers) and various forms of embedding of Tuscany into other
runtime environments such as Tomcat, Geronimo (...pick your favourite runtime...)
I'd like to ask folks generally whether they agree with this division. If we can agree on the
division, I'd like to see us write down the contents of each of a) b) c) and d) - ideally on some
nice Wiki page that we can maintain.
Yours, Mike.
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Thu, Jun 12, 2008 at 4:31 PM, Simon Nash <na...@apache.org> wrote:
> ant elder wrote:
>
>> On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <na...@apache.org> 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 and/or Web services policy.
> I also wouldn't put assembly and core in the same basic component,
> because some users might just want the Tuscany model without the
> Tuscany runtime. But I would put interface and assembly together in the
> same basic component, because there are no cases where one would be used
> without the other, and I would put core, core-databinding and databinding
> together in the same basic component for the same reason.
>
> Simon
>
> ...ant
>>
>>
>
Sure ok i think we're agreeing, those were just initial stabs at some
aggregation suggestions, someone embedding Tuscany could well want something
more fine grained along the lines of what you have above.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <na...@apache.org> 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 and/or Web services policy.
I also wouldn't put assembly and core in the same basic component,
because some users might just want the Tuscany model without the
Tuscany runtime. But I would put interface and assembly together in the
same basic component, because there are no cases where one would be used
without the other, and I would put core, core-databinding and databinding
together in the same basic component for the same reason.
Simon
> ...ant
>
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash <na...@apache.org> 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
Posted by Simon Nash <na...@apache.org>.
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 <js...@apache.org>:
>> 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
Posted by Graham Charters <gc...@googlemail.com>.
+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 <js...@apache.org>:
> 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
Posted by Graham Charters <gc...@googlemail.com>.
2008/6/11 ant elder <an...@gmail.com>:
> On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram <
> rajinisivaram@googlemail.com> 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
Posted by Graham Charters <gc...@googlemail.com>.
Hi Rajini, couple of comments below
2008/6/11 Rajini Sivaram <ra...@googlemail.com>:
> On 6/11/08, Graham Charters <gc...@googlemail.com> 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 <an...@gmail.com>:
>> > On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
>> > rajinisivaram@googlemail.com> wrote:
>> >
>> > <snip>
>> >
>> > 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
Posted by ant elder <an...@gmail.com>.
On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram <
rajinisivaram@googlemail.com> 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
Posted by Rajini Sivaram <ra...@googlemail.com>.
On 6/11/08, Graham Charters <gc...@googlemail.com> 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 <an...@gmail.com>:
> > On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
> > rajinisivaram@googlemail.com> wrote:
> >
> > <snip>
> >
> > 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
Posted by Graham Charters <gc...@googlemail.com>.
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 <an...@gmail.com>:
> On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
> rajinisivaram@googlemail.com> wrote:
>
> <snip>
>
> 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
Posted by ant elder <an...@gmail.com>.
On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram <
rajinisivaram@googlemail.com> wrote:
<snip>
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
Posted by Simon Nash <na...@apache.org>.
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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
Posted by Raymond Feng <en...@gmail.com>.
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" <na...@apache.org>
Sent: Wednesday, June 11, 2008 12:33 PM
To: <tu...@ws.apache.org>
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 <js...@apache.org> wrote:
>>> ant elder wrote:
>>>
>>>> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>>>> jsdelfino@apache.org> wrote:
>>>>
>>>> Simon Nash wrote:
>>>>> ant elder wrote:
>>>>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>>>>>> jsdelfino@apache.org> 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-runtime of a different
>> version?
>> The answer is probably "no". But that does not necessarily mean that
>> these
>> should be combined into a single maven module. In some cases the
>> splitting
>> of modules does have a point beyond versioning - eg. separating models
>> and
>> runtimes like you have been doing. Now that is good reason to define
>> different bundles for these two - enabling bundles to be used
>> independently
>> of each other. But I dont believe that we have 100 different entities in
>> Tuscany that can be separately versioned or used independently.
>>
> I agree and I think this is the key factor that needs to be considered.
> In some cases existing Tuscany maven modules would make excellent OSGi
> bundles, for example binding-ws-axis2, host-tomcat, implementation-osgi
> and interface-wsdl.
>
> But what about the 10 contribution-xxx maven modules? Can they be
> separately versioned or used independently? Can databinding be used
> independently from core-databinding, or vice versa? Can core do
> anything useful without core-databinding? Can anyone use interface
> without assembly? When maven modules don't pass the test of being
> separately versionable or usable independently, they either need to be
> aggregated into a single bundle or merged into a single maven module.
>
>> If we look at the total Tuscany distribution including Tuscany modules
>> and
>> 3rd party libraries, aggregating Tuscany modules doesn't add much value
>> unless 3rd party libs that go with these modules are also combined
>> together
>> with the Tuscany modules in a "bundle". And that to me is completely
>> impractical. 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 don't think this follows at all. The Tuscany bundles should reflect
> the independently usable and/or versionable elements of Tuscany, and
> the current maven module split doesn't achieve this. It isn't necessary
> or even desirable IMO to combine Tuscany bundles with their third-party
> dependencies in order to achieve the benefits of a better structure for
> Tuscany itself.
>
> Simon
>
>>
>>> --
>>> Jean-Sebastien
>>>
>>
>>
>>
>
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
Comments inline.
Simon
Rajini Sivaram wrote:
> On 6/10/08, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> ant elder wrote:
>>
>>> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>>> jsdelfino@apache.org> wrote:
>>>
>>> Simon Nash wrote:
>>>> ant elder wrote:
>>>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>>>>> jsdelfino@apache.org> 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-runtime of a different version?
> The answer is probably "no". But that does not necessarily mean that these
> should be combined into a single maven module. In some cases the splitting
> of modules does have a point beyond versioning - eg. separating models and
> runtimes like you have been doing. Now that is good reason to define
> different bundles for these two - enabling bundles to be used independently
> of each other. But I dont believe that we have 100 different entities in
> Tuscany that can be separately versioned or used independently.
>
I agree and I think this is the key factor that needs to be considered.
In some cases existing Tuscany maven modules would make excellent OSGi
bundles, for example binding-ws-axis2, host-tomcat, implementation-osgi
and interface-wsdl.
But what about the 10 contribution-xxx maven modules? Can they be
separately versioned or used independently? Can databinding be used
independently from core-databinding, or vice versa? Can core do
anything useful without core-databinding? Can anyone use interface
without assembly? When maven modules don't pass the test of being
separately versionable or usable independently, they either need to be
aggregated into a single bundle or merged into a single maven module.
> If we look at the total Tuscany distribution including Tuscany modules and
> 3rd party libraries, aggregating Tuscany modules doesn't add much value
> unless 3rd party libs that go with these modules are also combined together
> with the Tuscany modules in a "bundle". And that to me is completely
> impractical. 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 don't think this follows at all. The Tuscany bundles should reflect
the independently usable and/or versionable elements of Tuscany, and
the current maven module split doesn't achieve this. It isn't necessary
or even desirable IMO to combine Tuscany bundles with their third-party
dependencies in order to achieve the benefits of a better structure for
Tuscany itself.
Simon
>
>> --
>> Jean-Sebastien
>>
>
>
>
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Rajini Sivaram <ra...@googlemail.com>.
On 6/10/08, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
>
>> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> wrote:
>>
>> Simon Nash wrote:
>>>
>>> ant elder wrote:
>>>>
>>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>>>> jsdelfino@apache.org> 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 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-runtime of a different version?
The answer is probably "no". But that does not necessarily mean that these
should be combined into a single maven module. In some cases the splitting
of modules does have a point beyond versioning - eg. separating models and
runtimes like you have been doing. Now that is good reason to define
different bundles for these two - enabling bundles to be used independently
of each other. But I dont believe that we have 100 different entities in
Tuscany that can be separately versioned or used independently.
If we look at the total Tuscany distribution including Tuscany modules and
3rd party libraries, aggregating Tuscany modules doesn't add much value
unless 3rd party libs that go with these modules are also combined together
with the Tuscany modules in a "bundle". And that to me is completely
impractical. 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?
> --
> Jean-Sebastien
>
--
Thank you...
Regards,
Rajini
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Simon Nash wrote:
>>
>>> ant elder wrote:
>>>
>>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>>> jsdelfino@apache.org> 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
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Simon Nash wrote:
>
>> ant elder wrote:
>>
>>> On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino <
>>> jsdelfino@apache.org> 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
Posted by ant elder <an...@gmail.com>.
There was a strawman type example in
http://apache.markmail.org/message/te5ork3yppzf3a6i
...ant
On Tue, Jul 1, 2008 at 5:53 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> Can one of you show me a sample of the definitions.xml to configure the SCA
> extensions? I would like to better understand how Tuscany would works with
> it to provide the extensibility.
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Simon Nash" <na...@apache.org>
> Sent: Tuesday, July 01, 2008 3:59 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what
> they contain, was: SCA runtimes
>
>
> ant elder wrote:
>>
>>>
>>>
>>> On Tue, Jul 1, 2008 at 12:26 AM, Raymond Feng <enjoyjava@gmail.com<mailto:
>>> enjoyjava@gmail.com>> wrote:
>>>
>>> Hi,
>>>
>>> I would like to reactivate the discussion on how we can improve the
>>> extensibility story based on the following use cases.
>>>
>>> 1) Be able to discover extensions declared using the
>>> META-INF/services pattern in a non-OSGi environment
>>> 2) Be able to discover extensions declared using the
>>> META-INF/services pattern in an OSGi environment
>>> 3) Be able to discover extensions declared using the
>>> META-INF/plugin.xml with the Eclipse Equinox Extension Registry
>>> 4) Be able to discover extensions declared using the
>>> META-INF/plugin.xml with other OSGi implementation such as Apache
>>> Felix
>>>
>>> 1 & 2 is the poor-man's ExtensionRegistry and 3 & 4 is based on the
>>> Eclipse extension registry syntax with nice tooling support.
>>>
>>> At this moment, the ServiceDiscovery SPI is a class which depends on
>>> the registered classloaders. To support the different extension
>>> mechanisms, the ServiceDiscovery.getInstance() should be able to
>>> return an instance of the ServiceDiscovery which fits the hosting
>>> environment.
>>>
>>> For 1), we can use ClassLoader.getResources() to find the service
>>> provider files
>>> For 2), we can use the BundleContext.getBundles() from the OSGi
>>> runtime and Bundle.findEntries() to find the service provider entries
>>> For 3), we can use the Eclipse Equinox IExtensionRegistry API
>>> For 4), we can simulates 3) as the ExtensionRegistry is implemented
>>> using standard OSGi APIs without Equinox backdoors.
>>>
>>> If we agree on the objectives, I can start to prototype some of the
>>> approaches and share with you over time.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>>> If we're going to start redoing the extensibility story I think we should
>>> be using the definitions.xml file for defining the SCA extensions as
>>> discussed in http://apache.markmail.org/message/unubgkqdcwwch66m
>>>
>>> It sounds like we've two different types of extensions:
>>>
>>> (1) SCA extensions for binding, implantation and interface types
>>> (2) Tuscany runtime extensions for creating the actual runtime code,
>>> things like our host-http-jetty etc
>>>
>>> These have different characteristics and requirements so don't need to
>>> use the same extension mechanism.
>>>
>>> ...ant
>>>
>>>
>>> I agree. I think there are two levels of this:
>> 1. A Tuscany extension model that is used for all Tuscany extensions.
>> This includes mechanisms for packaging, installing, loading and
>> configuring Tuscany extensions.
>> 2. An SCA extension mechanism based on the definitions.xml file. This
>> includes mechanisms for specifying and configuring SCA extensions.
>> These would sit on top of the underlying Tuscany mechanisms as
>> described in point 1.
>>
>> Simon
>>
>
>
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Fri, Jun 13, 2008 at 3:50 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> ant elder wrote:
>
>>
>> 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
>>
>>
> No, the M2 launcher mixed too many different aspects:
> a) load the Tuscany JARs
> b) download then from the network as necessary
> b) launch your application code
> c) turn a client into a a 'client component'
>
> I am talking about what's currently demonstrated in:
> samples/calculator-distributed, in LaunchCalculatorNodeA
> or
> tutorial/store-client, in LaunchStoreClient
>
> for example, which only address (a).
> --
> Jean-Sebastien
>
Fair enough, i think we'd all be a bit nervous about trying "b) download
them from the network as necessary" again :)
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
>
> 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
>
No, the M2 launcher mixed too many different aspects:
a) load the Tuscany JARs
b) download then from the network as necessary
b) launch your application code
c) turn a client into a a 'client component'
I am talking about what's currently demonstrated in:
samples/calculator-distributed, in LaunchCalculatorNodeA
or
tutorial/store-client, in LaunchStoreClient
for example, which only address (a).
--
Jean-Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 10, 2008 at 6:52 PM, Raymond Feng <en...@gmail.com> 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: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Can one of you show me a sample of the definitions.xml to configure the SCA
extensions? I would like to better understand how Tuscany would works with
it to provide the extensibility.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Nash" <na...@apache.org>
Sent: Tuesday, July 01, 2008 3:59 AM
To: <de...@tuscany.apache.org>
Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
> ant elder wrote:
>>
>>
>> On Tue, Jul 1, 2008 at 12:26 AM, Raymond Feng <enjoyjava@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Hi,
>>
>> I would like to reactivate the discussion on how we can improve the
>> extensibility story based on the following use cases.
>>
>> 1) Be able to discover extensions declared using the
>> META-INF/services pattern in a non-OSGi environment
>> 2) Be able to discover extensions declared using the
>> META-INF/services pattern in an OSGi environment
>> 3) Be able to discover extensions declared using the
>> META-INF/plugin.xml with the Eclipse Equinox Extension Registry
>> 4) Be able to discover extensions declared using the
>> META-INF/plugin.xml with other OSGi implementation such as Apache
>> Felix
>>
>> 1 & 2 is the poor-man's ExtensionRegistry and 3 & 4 is based on the
>> Eclipse extension registry syntax with nice tooling support.
>>
>> At this moment, the ServiceDiscovery SPI is a class which depends on
>> the registered classloaders. To support the different extension
>> mechanisms, the ServiceDiscovery.getInstance() should be able to
>> return an instance of the ServiceDiscovery which fits the hosting
>> environment.
>>
>> For 1), we can use ClassLoader.getResources() to find the service
>> provider files
>> For 2), we can use the BundleContext.getBundles() from the OSGi
>> runtime and Bundle.findEntries() to find the service provider entries
>> For 3), we can use the Eclipse Equinox IExtensionRegistry API
>> For 4), we can simulates 3) as the ExtensionRegistry is implemented
>> using standard OSGi APIs without Equinox backdoors.
>>
>> If we agree on the objectives, I can start to prototype some of the
>> approaches and share with you over time.
>>
>> Thanks,
>> Raymond
>>
>>
>> If we're going to start redoing the extensibility story I think we should
>> be using the definitions.xml file for defining the SCA extensions as
>> discussed in http://apache.markmail.org/message/unubgkqdcwwch66m
>>
>> It sounds like we've two different types of extensions:
>>
>> (1) SCA extensions for binding, implantation and interface types
>> (2) Tuscany runtime extensions for creating the actual runtime code,
>> things like our host-http-jetty etc
>>
>> These have different characteristics and requirements so don't need to
>> use the same extension mechanism.
>>
>> ...ant
>>
>>
> I agree. I think there are two levels of this:
> 1. A Tuscany extension model that is used for all Tuscany extensions.
> This includes mechanisms for packaging, installing, loading and
> configuring Tuscany extensions.
> 2. An SCA extension mechanism based on the definitions.xml file. This
> includes mechanisms for specifying and configuring SCA extensions.
> These would sit on top of the underlying Tuscany mechanisms as
> described in point 1.
>
> Simon
Re: Tracking Tuscany extensions, was: Distribution zips and what
they contain, was: SCA runtimes
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
>
>
> On Tue, Jul 1, 2008 at 12:26 AM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi,
>
> I would like to reactivate the discussion on how we can improve the
> extensibility story based on the following use cases.
>
> 1) Be able to discover extensions declared using the
> META-INF/services pattern in a non-OSGi environment
> 2) Be able to discover extensions declared using the
> META-INF/services pattern in an OSGi environment
> 3) Be able to discover extensions declared using the
> META-INF/plugin.xml with the Eclipse Equinox Extension Registry
> 4) Be able to discover extensions declared using the
> META-INF/plugin.xml with other OSGi implementation such as Apache Felix
>
> 1 & 2 is the poor-man's ExtensionRegistry and 3 & 4 is based on the
> Eclipse extension registry syntax with nice tooling support.
>
> At this moment, the ServiceDiscovery SPI is a class which depends on
> the registered classloaders. To support the different extension
> mechanisms, the ServiceDiscovery.getInstance() should be able to
> return an instance of the ServiceDiscovery which fits the hosting
> environment.
>
> For 1), we can use ClassLoader.getResources() to find the service
> provider files
> For 2), we can use the BundleContext.getBundles() from the OSGi
> runtime and Bundle.findEntries() to find the service provider entries
> For 3), we can use the Eclipse Equinox IExtensionRegistry API
> For 4), we can simulates 3) as the ExtensionRegistry is implemented
> using standard OSGi APIs without Equinox backdoors.
>
> If we agree on the objectives, I can start to prototype some of the
> approaches and share with you over time.
>
> Thanks,
> Raymond
>
>
> If we're going to start redoing the extensibility story I think we
> should be using the definitions.xml file for defining the SCA extensions
> as discussed in http://apache.markmail.org/message/unubgkqdcwwch66m
>
> It sounds like we've two different types of extensions:
>
> (1) SCA extensions for binding, implantation and interface types
> (2) Tuscany runtime extensions for creating the actual runtime code,
> things like our host-http-jetty etc
>
> These have different characteristics and requirements so don't need to
> use the same extension mechanism.
>
> ...ant
>
>
I agree. I think there are two levels of this:
1. A Tuscany extension model that is used for all Tuscany extensions.
This includes mechanisms for packaging, installing, loading and
configuring Tuscany extensions.
2. An SCA extension mechanism based on the definitions.xml file. This
includes mechanisms for specifying and configuring SCA extensions.
These would sit on top of the underlying Tuscany mechanisms as
described in point 1.
Simon
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by ant elder <an...@gmail.com>.
On Tue, Jul 1, 2008 at 12:26 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I would like to reactivate the discussion on how we can improve the
> extensibility story based on the following use cases.
>
> 1) Be able to discover extensions declared using the META-INF/services
> pattern in a non-OSGi environment
> 2) Be able to discover extensions declared using the META-INF/services
> pattern in an OSGi environment
> 3) Be able to discover extensions declared using the META-INF/plugin.xml
> with the Eclipse Equinox Extension Registry
> 4) Be able to discover extensions declared using the META-INF/plugin.xml
> with other OSGi implementation such as Apache Felix
>
> 1 & 2 is the poor-man's ExtensionRegistry and 3 & 4 is based on the Eclipse
> extension registry syntax with nice tooling support.
>
> At this moment, the ServiceDiscovery SPI is a class which depends on the
> registered classloaders. To support the different extension mechanisms, the
> ServiceDiscovery.getInstance() should be able to return an instance of the
> ServiceDiscovery which fits the hosting environment.
>
> For 1), we can use ClassLoader.getResources() to find the service provider
> files
> For 2), we can use the BundleContext.getBundles() from the OSGi runtime and
> Bundle.findEntries() to find the service provider entries
> For 3), we can use the Eclipse Equinox IExtensionRegistry API
> For 4), we can simulates 3) as the ExtensionRegistry is implemented using
> standard OSGi APIs without Equinox backdoors.
>
> If we agree on the objectives, I can start to prototype some of the
> approaches and share with you over time.
>
> Thanks,
> Raymond
>
If we're going to start redoing the extensibility story I think we should be
using the definitions.xml file for defining the SCA extensions as discussed
in http://apache.markmail.org/message/unubgkqdcwwch66m
It sounds like we've two different types of extensions:
(1) SCA extensions for binding, implantation and interface types
(2) Tuscany runtime extensions for creating the actual runtime code, things
like our host-http-jetty etc
These have different characteristics and requirements so don't need to use
the same extension mechanism.
...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I would like to reactivate the discussion on how we can improve the
extensibility story based on the following use cases.
1) Be able to discover extensions declared using the META-INF/services
pattern in a non-OSGi environment
2) Be able to discover extensions declared using the META-INF/services
pattern in an OSGi environment
3) Be able to discover extensions declared using the META-INF/plugin.xml
with the Eclipse Equinox Extension Registry
4) Be able to discover extensions declared using the META-INF/plugin.xml
with other OSGi implementation such as Apache Felix
1 & 2 is the poor-man's ExtensionRegistry and 3 & 4 is based on the Eclipse
extension registry syntax with nice tooling support.
At this moment, the ServiceDiscovery SPI is a class which depends on the
registered classloaders. To support the different extension mechanisms, the
ServiceDiscovery.getInstance() should be able to return an instance of the
ServiceDiscovery which fits the hosting environment.
For 1), we can use ClassLoader.getResources() to find the service provider
files
For 2), we can use the BundleContext.getBundles() from the OSGi runtime and
Bundle.findEntries() to find the service provider entries
For 3), we can use the Eclipse Equinox IExtensionRegistry API
For 4), we can simulates 3) as the ExtensionRegistry is implemented using
standard OSGi APIs without Equinox backdoors.
If we agree on the objectives, I can start to prototype some of the
approaches and share with you over time.
Thanks,
Raymond
--------------------------------------------------
From: "Jean-Sebastien Delfino" <js...@apache.org>
Sent: Tuesday, June 10, 2008 9:37 AM
To: <tu...@ws.apache.org>
Subject: 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 <
>>> jsdelfino@apache.org> 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 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.
>
> 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).
>
> [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
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I would like to reactivate the discussion on how we can improve the
extensibility story based on the following use cases.
1) Be able to discover extensions declared using the META-INF/services
pattern in a non-OSGi environment
2) Be able to discover extensions declared using the META-INF/services
pattern in an OSGi environment
3) Be able to discover extensions declared using the META-INF/plugin.xml
with the Eclipse Equinox Extension Registry
4) Be able to discover extensions declared using the META-INF/plugin.xml
with other OSGi implementation such as Apache Felix
1 & 2 is the poor-man's ExtensionRegistry and 3 & 4 is based on the Eclipse
extension registry syntax with nice tooling support.
At this moment, the ServiceDiscovery SPI is a class which depends on the
registered classloaders. To support the different extension mechanisms, the
ServiceDiscovery.getInstance() should be able to return an instance of the
ServiceDiscovery which fits the hosting environment.
For 1), we can use ClassLoader.getResources() to find the service provider
files
For 2), we can use the BundleContext.getBundles() from the OSGi runtime and
Bundle.findEntries() to find the service provider entries
For 3), we can use the Eclipse Equinox IExtensionRegistry API
For 4), we can simulates 3) as the ExtensionRegistry is implemented using
standard OSGi APIs without Equinox backdoors.
If we agree on the objectives, I can start to prototype some of the
approaches and share with you over time.
Thanks,
Raymond
--------------------------------------------------
From: "Jean-Sebastien Delfino" <js...@apache.org>
Sent: Tuesday, June 10, 2008 9:37 AM
To: <tu...@ws.apache.org>
Subject: 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 <
>>> jsdelfino@apache.org> 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 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.
>
> 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).
>
> [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
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
Posted by Raymond Feng <en...@gmail.com>.
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