Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
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 [EMAIL PROTECTED] Sent: Friday, June 13, 2008 2:08 PM To: tuscany-dev@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
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Fri, Jun 13, 2008 at 10:08 PM, Mike Edwards [EMAIL PROTECTED] 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
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
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
On Fri, Jun 13, 2008 at 3:50 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] Sent: Friday, June 13, 2008 2:08 PM To: tuscany-dev@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,
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
+1 from me also. We shouldn't confuse modularity purely with versioning or whether something can be used on its own. It's also about being able to make different combinations of modules to fit different deployment profiles. I think it was Ant who first brought up the distinction between what make sense in terms of modularity and what makes sense from a user's perspective. I think having 1 bundle per Tuscany module and third-party jar is fine so long as we provide some way of aggregating those in ways that make sense for how users will consume them. For example, I as a user might want to think in terms of a core runtime + implementation type X and binding Y. That's three concepts to me, not 123 bundles. Hope this make sense. Regards, Graham. 2008/6/12 Jean-Sebastien Delfino [EMAIL PROTECTED]: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! -- Jean-Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
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
Graham Charters wrote: +1 from me also. We shouldn't confuse modularity purely with versioning or whether something can be used on its own. It's also about being able to make different combinations of modules to fit different deployment profiles. I agree with that, and this should be considered as part of the use cases that would determine the granularity of the bundles. If there is no possible deployment profile that can include A and not B, or vice versa, then I don't see a case for having A and B as separate bundles. I think it was Ant who first brought up the distinction between what make sense in terms of modularity and what makes sense from a user's perspective. I think having 1 bundle per Tuscany module and third-party jar is fine so long as we provide some way of aggregating those in ways that make sense for how users will consume them. For example, I as a user might want to think in terms of a core runtime + implementation type X and binding Y. That's three concepts to me, not 123 bundles. This might be valuable as well as a higher-level grouping of bundles into different functional profiles. But it doesn't change the fundamental question of what is the minimum independently aggregatable unit of functionality that is encapsulated in a single bundle. Simon Hope this make sense. Regards, Graham. 2008/6/12 Jean-Sebastien Delfino [EMAIL PROTECTED]: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! -- Jean-Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I wonder if some of this debate is due to us not all talking about they same thing so maybe it would help to go back to this proposal: Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care of bootstrapping the Tuscany runtime - the launcher should detect the presence of installed extensions in a particular Tuscany installation - as a user / app developer I should not have to know the list of JARs from all these extensions. This is a fundamentally different approach from what we do today where we have all the Tuscany jars and dependencies on the application classpath. One of the main reasons for having jars of aggregated modules is to make it easier for users but if we change to have a runtime launcher which handles the all the module jars instead of the user then that reason goes away. To make this clear, today if a user has an Ant build script for their application that build script needs to hardcode each Tuscany module jar and dependency jar name so the build script breaks every time we change things. The tuscany-all and manifest jars help some but as has been pointed they have other problems. If we change to use the launcher approach then the Ant build script just needs to hardcode the Tuscany API and launcher bootstrap jar names and the location of the Tuscany install, and those few names should not change much over Tuscany releses so the user application doesn't get broken when we change Tuscany internal things. It doesn't really matter to the user if the actual Tuscany install folder has 10 jars or 200 jars all the they care about is the install location and the launcher handles it all for them. This is similar to developing webapps for Tomcat, to the user all they care about is the servlet-api jar and where Tomcat is installed, they don't care whats in the Tomcat server lib directory. We did use this launcher approach back in M2 and we changed in 0.90 as a launcher makes things harder for Tuscany developers, for example when debugging Tuscany internals, but maybe _now_ it would be better to change back to a launcher approach as it makes things easier for users. ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! Sorry, but it doesn't make sense to me. If there is no user scenario that can pull in contribution-java but not contribution-resource, or vice versa, I don't see why we would choose to expose these in our distro as separate bundles. For the databindings, there are user scenarios in which a subset would be needed by different users, so things like databinding-jaxb and databinding-sdo should be in separate bundles. However, core-databinding and databinding would always be used together, so should be in the same bundle. There might be a reason for keeping these modules separate in the maven build, to reflect an internal functional split. This internal structure is not relevant to Tuscany users and should not be exposed to them. I think our distro should have a bundle for a minimal basic core and bunldes for additional optional components that can be used in different combinations. The granularity of these bundles should be determined by what possible combinations make sense for people using the binary distro. Simon I do also agree with this despite what i just posted about how if we use the launcher approach then the actual module jars don't matter to users :) One group of users we want for Tuscany are those embedding Tuscany in other products, so having some aggregated jars that group modules by functionality would make it easier for them - eg an aggregated jar that contains the minimal Tuscany core runtime modules, another jar with all the web services related modules etc. Its really hard for an outsider (or even insider for that mater) working out what modules are needed for what, look at the tuscany-geronimo integration code which has never managed to keep up with Tuscany changes. I think we could do both, if we go for a new launcher approach and OSGi'ify everything then it might even make it easier to get the aggregated jars working well and its not so much overhead for us to maintain both sets of jars and use which ever are appropriate depending on the circumstances. The key thing will be to get _consensus_ on it so we're all working together instead of what we have now which seems to be we each focus on the bits we're interested in sometimes to the detriment of what other are trying to do. ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! Sorry, but it doesn't make sense to me. If there is no user scenario that can pull in contribution-java but not contribution-resource, or vice versa, I don't see why we would choose to expose these in our distro as separate bundles. For the databindings, there are user scenarios in which a subset would be needed by different users, so things like databinding-jaxb and databinding-sdo should be in separate bundles. However, core-databinding and databinding would always be used together, so should be in the same bundle. There might be a reason for keeping these modules separate in the maven build, to reflect an internal functional split. This internal structure is not relevant to Tuscany users and should not be exposed to them. I think our distro should have a bundle for a minimal basic core and bunldes for additional optional components that can be used in different combinations. The granularity of these bundles should be determined by what possible combinations make sense for people using the binary distro. Simon I do also agree with this despite what i just posted about how if we use the launcher approach then the actual module jars don't matter to users :) One group of users we want for Tuscany are those embedding Tuscany in other products, so having some aggregated jars that group modules by functionality would make it easier for them - eg an aggregated jar that contains the minimal Tuscany core runtime modules, another jar with all the web services related modules etc. Its really hard for an outsider (or even insider for that mater) working out what modules are needed for what, look at the tuscany-geronimo integration code which has never managed to keep up with Tuscany changes. I think we could do both, if we go for a new launcher approach and OSGi'ify everything then it might even make it easier to get the aggregated jars working well and its not so much overhead for us to maintain both sets of jars and use which ever are appropriate depending on the circumstances. The key thing will be to get _consensus_ on it so we're all working together instead of what we have now which seems to be we each focus on the bits we're interested in sometimes to the detriment of what other are trying to do. Actually this isn't quite what I was saying. (Sorry that I wasn't clear.) I'm talking about the lowest level components that we distribute as binaries, not about larger groupings that are created from these components to provide convenient aggregations of functionality. These groupings might be useful as well, as you are suggesting here and Graham suggested in his recent post. So back to the basic components. I see no value at this level in breaking things down any lower than a unit of functionality that might be included or excluded as a whole from some valid scenario. To give an example, I wouldn't put everything related to Web services in a single basic component, because some users might want to create a minimal Web services configuration without Web services security and/or
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: 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
On Thu, Jun 12, 2008 at 4:31 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! Sorry, but it doesn't make sense to me. If there is no user scenario that can pull in contribution-java but not contribution-resource, or vice versa, I don't see why we would choose to expose these in our distro as separate bundles. For the databindings, there are user scenarios in which a subset would be needed by different users, so things like databinding-jaxb and databinding-sdo should be in separate bundles. However, core-databinding and databinding would always be used together, so should be in the same bundle. There might be a reason for keeping these modules separate in the maven build, to reflect an internal functional split. This internal structure is not relevant to Tuscany users and should not be exposed to them. I think our distro should have a bundle for a minimal basic core and bunldes for additional optional components that can be used in different combinations. The granularity of these bundles should be determined by what possible combinations make sense for people using the binary distro. Simon I do also agree with this despite what i just posted about how if we use the launcher approach then the actual module jars don't matter to users :) One group of users we want for Tuscany are those embedding Tuscany in other products, so having some aggregated jars that group modules by functionality would make it easier for them - eg an aggregated jar that contains the minimal Tuscany core runtime modules, another jar with all the web services related modules etc. Its really hard for an outsider (or even insider for that mater) working out what modules are needed for what, look at the tuscany-geronimo integration code which has never managed to keep up with Tuscany changes. I think we could do both, if we go for a new launcher approach and OSGi'ify everything then it might even make it easier to get the aggregated jars working well and its not so much overhead for us to maintain both sets of jars and use which ever are appropriate depending on the circumstances. The key thing will be to get _consensus_ on it so we're all working together instead of what we have now which seems to be we each focus on the bits we're interested in sometimes to the detriment of what other are trying to do. Actually this isn't quite what I was saying. (Sorry that I wasn't clear.) I'm talking about the lowest level components that we distribute as binaries, not about larger groupings that are created from these components to provide convenient aggregations of functionality. These groupings might be useful as well, as you are suggesting here and Graham suggested in his recent post. So back to the basic components. I see no value at this level in breaking things down any lower than a unit of functionality that might be included or excluded as a whole from some valid scenario. To give an example, I wouldn't put everything
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On 6/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. From an OSGi point of view I would like to ensure that we will continue to have one bundle per 3rd party jar and that these will not be aggregated regardless of how the distribution is zipped up. As for one bundle per maven module, I think there are pros and cons for finely grained and coarsely grained bundles, and it is really just a matter of preference. Since we anyway have nearly 150 3rd party bundles/jars anyway, I personally dont see any problem with one bundle per module. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. IMHO 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
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] 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
If we assume one bundle per Tuscany module for developers, perhaps there's a need for a separate concept that provides a simplified view for users? The SpringSource Application Platform has the concept of a library, which has caused much debate in the OSGi world (it has its own manifest header). A library is a collection of bundles which gives the developer a single 'thing' on which to depend. At runtime the concept goes away and just results in Import/Export-Package statements created through manifest re-writing (the library does not affect package visibility). I'm not suggesting we use the same approach, but it just highlights that others a felt the need for an 'aggregation' concept. I wonder if a bundle repository might also provide such a capability, but I'm not too familiar with things like OBR at the moment. On the subject of the ExtensionRegistry. This is not a standard OSGi feature, but I've been told the Equinox implementation should run on any standard OSGi implementation (e.g. Felix). Is there any reason why we wouldn't just use the standard service registry? It has all the features required to manage the lifecycle of new extensions being installed/uninstalled, etc. Regards, Graham. 2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: 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
On 6/11/08, Graham Charters [EMAIL PROTECTED] wrote: If we assume one bundle per Tuscany module for developers, perhaps there's a need for a separate concept that provides a simplified view for users? The SpringSource Application Platform has the concept of a library, which has caused much debate in the OSGi world (it has its own manifest header). A library is a collection of bundles which gives the developer a single 'thing' on which to depend. At runtime the concept goes away and just results in Import/Export-Package statements created through manifest re-writing (the library does not affect package visibility). I'm not suggesting we use the same approach, but it just highlights that others a felt the need for an 'aggregation' concept. I wonder if a bundle repository might also provide such a capability, but I'm not too familiar with things like OBR at the moment. OBR does provide similar capability, but IMO the problem with all these approaches (OBR, SpringSource library) is that none of them is a standard. I just hope we dont invent yet another one. On the subject of the ExtensionRegistry. This is not a standard OSGi feature, but I've been told the Equinox implementation should run on any standard OSGi implementation (e.g. Felix). Is there any reason why we wouldn't just use the standard service registry? It has all the features required to manage the lifecycle of new extensions being installed/uninstalled, etc. You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ I dont actually have an opinion, just pointing to the docs. Regards, Graham. 2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: 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
On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram [EMAIL PROTECTED] wrote: ,snip You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ Great article, thanks for the link. Thats over a year old now so has much changed eg in relation to comments like The delayed services feature requires some small tweaks to the basic Equinox runtime, and these tweaks have not been implemented yet in the released version 3.2. They do not appear at all yet (at the time of writing) in the other open source OSGi runtimes, Apache Felix and Knopflerfish.? ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram [EMAIL PROTECTED] wrote: ,snip You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ Great article, thanks for the link. Thats over a year old now so has much changed eg in relation to comments like The delayed services feature requires some small tweaks to the basic Equinox runtime, and these tweaks have not been implemented yet in the released version 3.2. They do not appear at all yet (at the time of writing) in the other open source OSGi runtimes, Apache Felix and Knopflerfish.? ...ant The delayed services feature is supported in Equinox. The equinox implementation was improved by a contribution from Prosyst. Felix has DS support and documentation mentions the immediate attribute used to control delayed services, so I'm guessing it is also supported in that project. I've not looked at Knopflerfish. Regards, Graham
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Hi Rajini, couple of comments below 2008/6/11 Rajini Sivaram [EMAIL PROTECTED]: On 6/11/08, Graham Charters [EMAIL PROTECTED] wrote: If we assume one bundle per Tuscany module for developers, perhaps there's a need for a separate concept that provides a simplified view for users? The SpringSource Application Platform has the concept of a library, which has caused much debate in the OSGi world (it has its own manifest header). A library is a collection of bundles which gives the developer a single 'thing' on which to depend. At runtime the concept goes away and just results in Import/Export-Package statements created through manifest re-writing (the library does not affect package visibility). I'm not suggesting we use the same approach, but it just highlights that others a felt the need for an 'aggregation' concept. I wonder if a bundle repository might also provide such a capability, but I'm not too familiar with things like OBR at the moment. OBR does provide similar capability, but IMO the problem with all these approaches (OBR, SpringSource library) is that none of them is a standard. I just hope we dont invent yet another one. RFC 112 covers the design for a Bundle Repository (inspired by OBR) so is some way along the path to being a standard. This might make the OBR approach a safer bet. On the subject of the ExtensionRegistry. This is not a standard OSGi feature, but I've been told the Equinox implementation should run on any standard OSGi implementation (e.g. Felix). Is there any reason why we wouldn't just use the standard service registry? It has all the features required to manage the lifecycle of new extensions being installed/uninstalled, etc. You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ I dont actually have an opinion, just pointing to the docs. Yes, but thanks for the pointer. It's an excellent article. My comment was less about the technical pros/cons of each approach and more about the standards aspect, although the technical aspects need to be considered. Regards, Graham. 2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: 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
Comments inline. Simon Rajini Sivaram wrote: On 6/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. From an OSGi point of view I would like to ensure that we will continue to have one bundle per 3rd party jar and that these will not be aggregated regardless of how the distribution is zipped up. As for one bundle per maven module, I think there are pros and cons for finely grained and coarsely grained bundles, and it is really just a matter of preference. Since we anyway have nearly 150 3rd party bundles/jars anyway, I personally dont see any problem with one bundle per module. I have a different view on this. See below. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. IMHO modularizing Tuscany is about code quality and maintenance - something internal benefitting Tuscany developers. So we have 100 modules based on the developer's view of Tuscany internals. That does not necessarily mean that end users have to deal with 100 bundles. If 20 core modules are very tightly coupled together and will only operate with each other, as far as an end user is concerned, this could as well be one bundle. Can a Tuscany user combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even implementation-java with implementation-java-runtime of a
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 12:33 PM To: tuscany-dev@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 [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
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
Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Can you say a bit more about what an extension registry mechanism would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? Yes, I think this is important. Ideally the Tuscany core runtime would figure out which pieces are needed for the domain configuration and load these pieces automatically. Good requirement, but I don't think that the current manifest + tuscany-all JAR solution is a good one (for example it mixes APIs and internals in the same JAR, doesn't work well with IDEs, works only for one big distro, requires different settings in J2SE and webapps) Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Can you say a bit more about what an extension registry mechanism would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? Yes, I think this is important. Ideally the 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
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Hi, Please see my comments inline. Thanks, Raymond [snip] Good requirement, but I don't think that the current manifest + tuscany-all JAR solution is a good one (for example it mixes APIs and internals in the same JAR, doesn't work well with IDEs, works only for one big distro, requires different settings in J2SE and webapps) IMHO, the all-in-one package pretty much defeats our modularity. For example, all module activators will be called even the extension won't be used at all. Two extension cannot have different versions of a 3rd party jar. Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care of bootstrapping the Tuscany runtime This is similar to JEE launchClient. If I can invoke the Launcher directly in java, I would be happy. - the launcher should detect the presence of installed extensions in a particular Tuscany installation +1. - as a user / app developer I should not have to know the list of JARs from all these extensions. Do we expect the launcher to be smart enough to pick the right set of extensions based on the SCA assembly? That's what I've been trying to do with the Node launcher and the library provided by the Tuscany Eclipse plugin. More work is required to get that vision in place (as the current launcher is still pretty rudimentary and only scans an installation directory for JARs). There's a good extension registry mechanism in Eclipse Equinox [1]. It would allow us to rely on a robust mechanism for detecting installed extensions, tracking what they provide in an extension registry [2], and use a more user friendly syntax for registering extensions using plugin.xml files. If we start to integrate more with OSGi I think we should just use it (maybe in combination with what we currently have with META-INF/services for the cases where we don't use OSGi). We can have a SPI so that different mechanism of extension discovery can be plugged in. I would prefer to see both OSGi and META-INF/services based approaches available. [1] http://www.eclipse.org/equinox/ [2] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/ -- Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. -- Jean-Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Raymond Feng wrote: Hi, Please see my comments inline. Thanks, Raymond [snip] Good requirement, but I don't think that the current manifest + tuscany-all JAR solution is a good one (for example it mixes APIs and internals in the same JAR, doesn't work well with IDEs, works only for one big distro, requires different settings in J2SE and webapps) IMHO, the all-in-one package pretty much defeats our modularity. For example, all module activators will be called even the extension won't be used at all. Two extension cannot have different versions of a 3rd party jar. That's what I was trying to convey too. Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care of bootstrapping the Tuscany runtime This is similar to JEE launchClient. If I can invoke the Launcher directly in java, I would be happy. - the launcher should detect the presence of installed extensions in a particular Tuscany installation +1. - as a user / app developer I should not have to know the list of JARs from all these extensions. Do we expect the launcher to be smart enough to pick the right set of extensions based on the SCA assembly? Not so fast. I'm trying not to mix these different aspects. That would be a separate step. That's what I've been trying to do with the Node launcher and the library provided by the Tuscany Eclipse plugin. More work is required to get that vision in place (as the current launcher is still pretty rudimentary and only scans an installation directory for JARs). There's a good extension registry mechanism in Eclipse Equinox [1]. It would allow us to rely on a robust mechanism for detecting installed extensions, tracking what they provide in an extension registry [2], and use a more user friendly syntax for registering extensions using plugin.xml files. If we start to integrate more with OSGi I think we should just use it (maybe in combination with what we currently have with META-INF/services for the cases where we don't use OSGi). We can have a SPI so that different mechanism of extension discovery can be plugged in. ExtensionRegistry is designed for that, it was modeled after the Eclipse IExtensionRegistry. I had been careful at the time to not put anything in it that wouldn't map easily to IExtensionRegistry. prefer to see both OSGi and META-INF/services based approaches available. Me too. [1] http://www.eclipse.org/equinox/ [2] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox.registry/ -- Sebastien -- Jean-Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports - 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
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 6:52 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Please see my comments inline. Thanks, Raymond [snip] Good requirement, but I don't think that the current manifest + tuscany-all JAR solution is a good one (for example it mixes APIs and internals in the same JAR, doesn't work well with IDEs, works only for one big distro, requires different settings in J2SE and webapps) IMHO, the all-in-one package pretty much defeats our modularity. For example, all module activators will be called even the extension won't be used at all. Calling a module activator is pretty minimal initialization overhead especially if it just fails right away with something like a ClassNotFoundException and the runtime carries on, and this is what happens with the our bundle jar - you can just use it without the extension dependencies you don't need and it works fine. Note I'm not necessarily saying we should be keeping the single one big bundle jar, i'm just trying to avoid the impression that the _only_ option we have is everything in individual separate jars. Two extension cannot have different versions of a 3rd party jar. Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care of bootstrapping the Tuscany runtime This is similar to JEE launchClient. If I can invoke the Launcher directly in java, I would be happy. So just to be clear on what is being suggested this would be like the launcher we used to have back in M2 days right? ...ant
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 7:03 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. I'm not sure i agree with that, individual small maven modules are for making things easier for developers, aggregated jars are for making things easier for users. There is lots of prior discussion about the pros and cons of this eg just search for all the projects using the shade plugin and then their mailing lists when they did that. Though if we do go back to a runtime launcher approach then users don't need to care so much as the launcher will hide some of these internal details. ...ant
