[jira] Created: (TUSCANY-2380) Modular distribution structure
Modular distribution structure -- Key: TUSCANY-2380 URL: https://issues.apache.org/jira/browse/TUSCANY-2380 Project: Tuscany Issue Type: Wish Components: Build System Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next I have described the kind of distribution structure that I'd like to have on the dev list there: http://marc.info/?l=tuscany-devm=121306338517687 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Distribution structure
+1. (sorry missed this mail... I see the v1.1 artifacts uploaded in this structure already). Thanks - Venkat On Feb 1, 2008 8:40 PM, Simon Laws [EMAIL PROTECTED] wrote: I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating Let me know. Regards Simon
Re: Distribution structure
Looks fine to me On 1 Feb 2008, at 16:09, Mike Edwards [EMAIL PROTECTED] wrote: +1 Simon Laws wrote: I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating Let me know. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure
Simon Laws wrote: I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating +1 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure
That sounds ok to me. ...ant On Feb 1, 2008 3:10 PM, Simon Laws [EMAIL PROTECTED] wrote: I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating Let me know. Regards Simon
Distribution structure
I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating Let me know. Regards Simon
Re: Distribution structure
+1 Simon Laws wrote: I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating Let me know. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure
Sounds ok. On Feb 1, 2008 8:09 AM, Mike Edwards [EMAIL PROTECTED] wrote: +1 Simon Laws wrote: I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating Let me know. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure
+1 from me. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Friday, February 01, 2008 7:10 AM Subject: Distribution structure I'm looking at copying the 1.1 release artifacts up onto the new distribution infrastructure at www.apache.org/dist/incubator/ We need to make a decision about how this will be structured. As a default I assume we stick pretty much with what we have already (see http://archive.apache.org/dist/incubator/tuscany/) tuscany native (was cpp) java/ das/ sca/ sdo/ If people are happy I'll go in and create the bits necessary for the new java release, i.e. tuscany/java/sca/1.1-incubating Let me know. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 27, 2007 4:11 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Nov 27, 2007 2:29 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 27, 2007 2:25 PM, ant elder [EMAIL PROTECTED] wrote: I've just committed a runtime-war module as a start of whats being talked about here, which could be merged or replace distribution/webapp at some point. I'll post some more details later. One comment inline below: ...ant On Nov 23, 2007 6:00 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I'm with you up to this point. What Tomcat deep integration work is going on (I do know about the Geronimo stuff). - fix Tomcat deep integration and document how to do it (by copying the binary lib directory jars to Tomcat lib etc) I don't think anyone has done much with Tomcat deep integration since M1 days, i tried it a while back but there were varrious class loader issues. With all the fixing up of class loaders done for osgi recently this may work ok now, i just tried moving all the jars from the runtime-war from the war lib folder to the Tomcat lib folder and it all seems to keep working ok now so maybe we just need to test it a bit more and then document it. ...ant So when the contribution is a war in its own right what you say last is the solution? Or is there something else? Right, though for deep integration to work we'd still need some new code that looks in each war as its deployed for .composite files and sca-contibution.xmls, and i guess to do it properly also something like the implementation.web that was mentioned a while ago. I'm interested in getting this to work. Is there a hook point in Tomcat that we could use to look at war code as it's deployed? Simon I think there's a number of things we need to do to get this to work: 1 - start an SCA doman/node when Tomcat starts 1a - local non-http communication between the domain and node. 2 - a way to deploy SCA contributions to the node 3 - look in each webapp as it starts for SCA things to deploy to the node 4 - write an implementation.web to inject properties and references into webapp servlets and JSPs 5 - a new http host to enable registering SCA http service endpoints (similar to host-http-tomcat except not requiring all the servlet stuff in each webapp) For (1) a way to do this is to write and implementation of org.apache.catalina.Host and change the Tomcat server.xml to use that. From there you can start an SCA node and get hooks into webapp start/stop events by registering an impl of org.apache.catalina.LifecycleListener. I've made a start at that though its quite primative so far, i'll commit what i have so anyone else could help. We already have (2) from the runtime-war module and it hopefully shouldn't be to hard to extend that for (3). I'd quite like to try to get something going for this for 1.1 but there's a fair bit of work to get it all that working well, so everyone who'd like to help is welcome :) A lot of the code for doing this could be reused in the Geronimo integration work, Tomcat is a bit easier to work with which is one reason I'm looking at this now. ...ant
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 28, 2007 10:24 AM, ant elder [EMAIL PROTECTED] wrote: On Nov 27, 2007 4:11 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Nov 27, 2007 2:29 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 27, 2007 2:25 PM, ant elder [EMAIL PROTECTED] wrote: I've just committed a runtime-war module as a start of whats being talked about here, which could be merged or replace distribution/webapp at some point. I'll post some more details later. One comment inline below: ...ant On Nov 23, 2007 6:00 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I'm with you up to this point. What Tomcat deep integration work is going on (I do know about the Geronimo stuff). - fix Tomcat deep integration and document how to do it (by copying the binary lib directory jars to Tomcat lib etc) I don't think anyone has done much with Tomcat deep integration since M1 days, i tried it a while back but there were varrious class loader issues. With all the fixing up of class loaders done for osgi recently this may work ok now, i just tried moving all the jars from the runtime-war from the war lib folder to the Tomcat lib folder and it all seems to keep working ok now so maybe we just need to test it a bit more and then document it. ...ant So when the contribution is a war in its own right what you say last is the solution? Or is there something else? Right, though for deep integration to work we'd still need some new code that looks in each war as its deployed for .composite files and sca-contibution.xmls, and i guess to do it properly also something like the implementation.web that was mentioned a while ago. I'm interested in getting this to work. Is there a hook point in Tomcat that we could use to look at war code as it's deployed? Simon I think there's a number of things we need to do to get this to work: 1 - start an SCA doman/node when Tomcat starts 1a - local non-http communication between the domain and node. 2 - a way to deploy SCA contributions to the node 3 - look in each webapp as it starts for SCA things to deploy to the node 4 - write an implementation.web to inject properties and references into webapp servlets and JSPs 5 - a new http host to enable registering SCA http service endpoints (similar to host-http-tomcat except not requiring all the servlet stuff in each webapp) For (1) a way to do this is to write and implementation of org.apache.catalina.Host and change the Tomcat server.xml to use that. From there you can start an SCA node and get hooks into webapp start/stop events by registering an impl of org.apache.catalina.LifecycleListener. I've made a start at that though its quite primative so far, i'll commit what i have so anyone else could help. We already have (2) from the runtime-war module and it hopefully shouldn't be to hard to extend that for (3). I'd quite like to try to get something going for this for 1.1 but there's a fair bit of work to get it all that working well, so everyone who'd like to help is welcome :) A lot of the code for doing this could be reused in the Geronimo integration work, Tomcat is a bit easier to work with which is one reason I'm looking at this now. ...ant Ant I haven't got my head round all the items on this list yet but they look plausible. I do have a question about the way this solution relates to a wider domain. The scenario I believe you are addressing here is one where a user 1. Starts tomcat 2. Adds web apps with the expectation that any SCA artifacts inside these web apps run in a single node as part of a single domain 3. Stops tomcat when they are done This could be a first step and in this case there is no need to worry about node/domain communications. Starting a standalone node means that any contributed components are assumed to be part of the same domain and can find one another. To put it another way a single node only belongs to one domain. The implication here though is that you can't create SCA to/from components in the Tomcat environment and all communication in and out will be via targeted remote bindings. For the more general scenario we can make two assumptions 1. Each web app is associated with a separate node 2. Each web app must be able to belong to a specified domain. In this case the domain, if run in the Tomcat instance where the web apps are running, is just another web app and we have to sort out the non-http comms to avoid the startup deadlock. For that we require some other binding. binding.socket, binding.minapipe for example. The domain can also be run outside of the tomcat instance and I think that is the easier place to start in order to get this scenario running. In neither case is Tomcat starting the domain application automatically. It's the users responsibility to choose where to run it and to actually deploy it.
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 28, 2007 11:41 AM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 28, 2007 10:24 AM, ant elder [EMAIL PROTECTED] wrote: On Nov 27, 2007 4:11 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Nov 27, 2007 2:29 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 27, 2007 2:25 PM, ant elder [EMAIL PROTECTED] wrote: I've just committed a runtime-war module as a start of whats being talked about here, which could be merged or replace distribution/webapp at some point. I'll post some more details later. One comment inline below: ...ant On Nov 23, 2007 6:00 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I'm with you up to this point. What Tomcat deep integration work is going on (I do know about the Geronimo stuff). - fix Tomcat deep integration and document how to do it (by copying the binary lib directory jars to Tomcat lib etc) I don't think anyone has done much with Tomcat deep integration since M1 days, i tried it a while back but there were varrious class loader issues. With all the fixing up of class loaders done for osgi recently this may work ok now, i just tried moving all the jars from the runtime-war from the war lib folder to the Tomcat lib folder and it all seems to keep working ok now so maybe we just need to test it a bit more and then document it. ...ant So when the contribution is a war in its own right what you say last is the solution? Or is there something else? Right, though for deep integration to work we'd still need some new code that looks in each war as its deployed for .composite files and sca-contibution.xmls, and i guess to do it properly also something like the implementation.web that was mentioned a while ago. I'm interested in getting this to work. Is there a hook point in Tomcat that we could use to look at war code as it's deployed? Simon I think there's a number of things we need to do to get this to work: 1 - start an SCA doman/node when Tomcat starts 1a - local non-http communication between the domain and node. 2 - a way to deploy SCA contributions to the node 3 - look in each webapp as it starts for SCA things to deploy to the node 4 - write an implementation.web to inject properties and references into webapp servlets and JSPs 5 - a new http host to enable registering SCA http service endpoints (similar to host-http-tomcat except not requiring all the servlet stuff in each webapp) For (1) a way to do this is to write and implementation of org.apache.catalina.Host and change the Tomcat server.xml to use that. From there you can start an SCA node and get hooks into webapp start/stop events by registering an impl of org.apache.catalina.LifecycleListener. I've made a start at that though its quite primative so far, i'll commit what i have so anyone else could help. We already have (2) from the runtime-war module and it hopefully shouldn't be to hard to extend that for (3). I'd quite like to try to get something going for this for 1.1 but there's a fair bit of work to get it all that working well, so everyone who'd like to help is welcome :) A lot of the code for doing this could be reused in the Geronimo integration work, Tomcat is a bit easier to work with which is one reason I'm looking at this now. ...ant Ant I haven't got my head round all the items on this list yet but they look plausible. I do have a question about the way this solution relates to a wider domain. The scenario I believe you are addressing here is one where a user 1. Starts tomcat 2. Adds web apps with the expectation that any SCA artifacts inside these web apps run in a single node as part of a single domain 3. Stops tomcat when they are done This could be a first step and in this case there is no need to worry about node/domain communications. Starting a standalone node means that any contributed components are assumed to be part of the same domain and can find one another. To put it another way a single node only belongs to one domain. The implication here though is that you can't create SCA to/from components in the Tomcat environment and all communication in and out will be via targeted remote bindings. There are a number of possible runtime scenarios, whats described above are some, I'd like to try to end up supporting as many as possible that we think may be useful and for them all to work in a consistent way. The ones relevant to Tomcat are the deep integration where the Tuscany code is embedded within Tomcat, and the webapp integration where the Tuscany code is included within individual webapps. For both of those I think it should be possible to run as a standalone node or as part of an SCA domain, and I think the domain
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 27, 2007 2:25 PM, ant elder [EMAIL PROTECTED] wrote: I've just committed a runtime-war module as a start of whats being talked about here, which could be merged or replace distribution/webapp at some point. I'll post some more details later. One comment inline below: ...ant On Nov 23, 2007 6:00 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I'm with you up to this point. What Tomcat deep integration work is going on (I do know about the Geronimo stuff). - fix Tomcat deep integration and document how to do it (by copying the binary lib directory jars to Tomcat lib etc) I don't think anyone has done much with Tomcat deep integration since M1 days, i tried it a while back but there were varrious class loader issues. With all the fixing up of class loaders done for osgi recently this may work ok now, i just tried moving all the jars from the runtime-war from the war lib folder to the Tomcat lib folder and it all seems to keep working ok now so maybe we just need to test it a bit more and then document it. ...ant So when the contribution is a war in its own right what you say last is the solution? Or is there something else? Simon
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
I've just committed a runtime-war module as a start of whats being talked about here, which could be merged or replace distribution/webapp at some point. I'll post some more details later. One comment inline below: ...ant On Nov 23, 2007 6:00 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I'm with you up to this point. What Tomcat deep integration work is going on (I do know about the Geronimo stuff). - fix Tomcat deep integration and document how to do it (by copying the binary lib directory jars to Tomcat lib etc) I don't think anyone has done much with Tomcat deep integration since M1 days, i tried it a while back but there were varrious class loader issues. With all the fixing up of class loaders done for osgi recently this may work ok now, i just tried moving all the jars from the runtime-war from the war lib folder to the Tomcat lib folder and it all seems to keep working ok now so maybe we just need to test it a bit more and then document it. ...ant
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
ant elder wrote: On Nov 27, 2007 2:29 PM, Simon Laws [EMAIL PROTECTED] wrote: On Nov 27, 2007 2:25 PM, ant elder [EMAIL PROTECTED] wrote: I've just committed a runtime-war module as a start of whats being talked about here, which could be merged or replace distribution/webapp at some point. I'll post some more details later. One comment inline below: ...ant On Nov 23, 2007 6:00 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I'm with you up to this point. What Tomcat deep integration work is going on (I do know about the Geronimo stuff). - fix Tomcat deep integration and document how to do it (by copying the binary lib directory jars to Tomcat lib etc) I don't think anyone has done much with Tomcat deep integration since M1 days, i tried it a while back but there were varrious class loader issues. With all the fixing up of class loaders done for osgi recently this may work ok now, i just tried moving all the jars from the runtime-war from the war lib folder to the Tomcat lib folder and it all seems to keep working ok now so maybe we just need to test it a bit more and then document it. ...ant So when the contribution is a war in its own right what you say last is the solution? Or is there something else? Right, though for deep integration to work we'd still need some new code that looks in each war as its deployed for .composite files and sca-contibution.xmls, and i guess to do it properly also something like the implementation.web that was mentioned a while ago. I'm interested in getting this to work. Is there a hook point in Tomcat that we could use to look at war code as it's deployed? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
Rajini Sivaram wrote: Sebastien, We would like to enable a binary Tuscany distribution to run under OSGi. I am not sure of the level of granularity at which a bundle-ized Tuscany makes sense in terms of providing modularity and versioning using OSGi. But I would like to make sure that the bundles from the list below can be run in some form under OSGi. The big difference between packaging for OSGi and standard jars (apart from the additional entries in the manifest) is that OSGi bundle classpath can only refer to entries inside the bundle, while standard Jar classpath can only refer to jars outside the jar file without a customized classloader. I currently have Tuscany loaded into OSGi in two different ways. The first is a small list of large bundles (all 3rd party jars are grouped together), which are explicitly installed by an application that uses Tuscany. And the second is a large list of small bundles (each 3rd party jar is retained as a single bundle), loaded using OSGi bundle repository (OBR). Tuscany runtime and the required Tuscany extensions are installed by the application, the 3rd party jars are automatically installed by OBR. I am not sure how big each of the bundles you have listed below will be, and also what the relative size of the samples would be compared to the bundle itself. But I imagine that the easiest way to bundle these for OSGi would be to create each of these as a single OSGi bundle. I would like to add META-INF/MANIFEST.MF with OSGi import/export headers and an OSGi Bundle-ClassPath to the zip/jar file corresponding to the bundle. This is to enable a very coarsely grained set of bundles that can be easily installed by an OSGi application. The additional manifest file will not impact non-OSGi applications. By default, Tuscany will be run without OSGi, and the zip file corresponding to the bundle will need to be unzipped first (no change). To run Tuscany under OSGi, the zip file can be installed directly into OSGi. I would also like to enable finer grained OSGi bundles which can be installed using OBR. For the all-in-one bundle, could we have OSGi manifest entries inserted into each of the jar files including Tuscany modules and 3rd party jars, so that the jars can be installed independently into OSGi? But this only makes sense if we can have separate jars for the Tuscany extensions, rather than a combined tuscany-all.jar (otherwise OBR will install all the 3rd party bundles when tuscany-all is installed). The base Tuscany runtime could either be a single jar, or with some more fixes for classloading, it could be multiple jars based on the maven modules. Again, the OSGi manifest entries will not impact non-OSGi Tuscany. The splitting of Tuscany jars also shouldn't have any impact since tuscany-sca-manifest.jarcan just point to the longer list of Tuscany jars instead of tuscany-all. The third alternative is to have a separate set of jars, specifically targetted for OSGi-based Tuscany, which would be somewhere in between the coarsely grained first option and too finely grained second one. Rather than provide this as part of the binary distribution, this could be an optional build with the source distribution. Suggestions? Thank you... Regards, Rajini Sorry for the delay I missed this one between ApacheCon and some vacation last week. It looks like you're now thinking about having: - one bundle per Tuscany JAR - some way to use 3rd party JARs from the bundles which I think make sense and will allow us to better leverage OSGi for isolation, versioning etc. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: I would like to make a start on improving the modularity of the distro by building a distro containing only a base SCA runtime. Sebastien's description of this was - base SCA runtime (assembly, policy fwk, impl-java) [snip] I haven't yet figured out how to do a sandbox build that pulls in code from the trunk, without copying it. Does anyone else have an example of this that I could look at? Modules assembled by the Maven assembly plugin are taken out of the Maven repository, so you shouldn't need to copy the code to come up with a different assembly. For an example, look at the assemblies under sca/distribution. I'm also going to put together an assembly for the eclipse plugin, I'll give a pointer when it's there. Here it is: - pom.xml [1] runs the Maven assembly plugin as part of the build - runtime.xml [2] configures the assembly plugin to grab all dependency modules from the Maven repos plus a few local files [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tools/eclipse/plugins/runtime/pom.xml [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tools/eclipse/plugins/runtime/src/main/assembly/runtime.xml To build a source distro you may have to directly point to the directories that contain the sources, but ../../../sca/modules/... relative path from the sandbox should work. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
Hi, I recently read the article on osoa.org: ãPower_Combination_SCA_Spring_OSGi.pdfã This article gave great impression to me(and my colleague). So I think here making Tuscany an osgi based container, will boost Tuscany onto a new era. I think from the architect view of Tuscany, it is very robust to get leveraged into an osgi runtime. Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: Sebastien, We would like to enable a binary Tuscany distribution to run under OSGi. I am not sure of the level of granularity at which a bundle-ized Tuscany makes sense in terms of providing modularity and versioning using OSGi. But I would like to make sure that the bundles from the list below can be run in some form under OSGi. The big difference between packaging for OSGi and standard jars (apart from the additional entries in the manifest) is that OSGi bundle classpath can only refer to entries inside the bundle, while standard Jar classpath can only refer to jars outside the jar file without a customized classloader. I currently have Tuscany loaded into OSGi in two different ways. The first is a small list of large bundles (all 3rd party jars are grouped together), which are explicitly installed by an application that uses Tuscany. And the second is a large list of small bundles (each 3rd party jar is retained as a single bundle), loaded using OSGi bundle repository (OBR). Tuscany runtime and the required Tuscany extensions are installed by the application, the 3rd party jars are automatically installed by OBR. I am not sure how big each of the bundles you have listed below will be, and also what the relative size of the samples would be compared to the bundle itself. But I imagine that the easiest way to bundle these for OSGi would be to create each of these as a single OSGi bundle. I would like to add META-INF/MANIFEST.MF with OSGi import/export headers and an OSGi Bundle-ClassPath to the zip/jar file corresponding to the bundle. This is to enable a very coarsely grained set of bundles that can be easily installed by an OSGi application. The additional manifest file will not impact non-OSGi applications. By default, Tuscany will be run without OSGi, and the zip file corresponding to the bundle will need to be unzipped first (no change). To run Tuscany under OSGi, the zip file can be installed directly into OSGi. I would also like to enable finer grained OSGi bundles which can be installed using OBR. For the all-in-one bundle, could we have OSGi manifest entries inserted into each of the jar files including Tuscany modules and 3rd party jars, so that the jars can be installed independently into OSGi? But this only makes sense if we can have separate jars for the Tuscany extensions, rather than a combined tuscany-all.jar (otherwise OBR will install all the 3rd party bundles when tuscany-all is installed). The base Tuscany runtime could either be a single jar, or with some more fixes for classloading, it could be multiple jars based on the maven modules. Again, the OSGi manifest entries will not impact non-OSGi Tuscany. The splitting of Tuscany jars also shouldn't have any impact since tuscany-sca-manifest.jarcan just point to the longer list of Tuscany jars instead of tuscany-all. The third alternative is to have a separate set of jars, specifically targetted for OSGi-based Tuscany, which would be somewhere in between the coarsely grained first option and too finely grained second one. Rather than provide this as part of the binary distribution, this could be an optional build with the source distribution. Suggestions? Thank you... Regards, Rajini Sorry for the delay I missed this one between ApacheCon and some vacation last week. It looks like you're now thinking about having: - one bundle per Tuscany JAR - some way to use 3rd party JARs from the bundles which I think make sense and will allow us to better leverage OSGi for isolation, versioning etc. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
Simon, I did take a look at splitting the Tuscany distribution into bundles with the hope of defining something which makes sense for OSGi as well as non-OSGi. I dont really think that makes much sense anymore. Grouping modules into OSGi bundles using existing maven plugins was far too time consuming (in terms of the amount of time it took to do a build), and quite messy. So I would like to go for a simpler option for OSGi where the the zip/jar files generated for the Tuscany distribution have a manifest file containing OSGi bundle manifest entries, so that they can be directly installed into OSGi (with an easy repackaging option to get rid of samples from the bundle if the bundle size was too big). I would also like to add OSGi manifest entries into all jars distributed by Tuscany including 3rd party jars, so that we can use the OSGi bundle repository API to install Tuscany into an OSGi runtime, instead of relying on Tuscany distribution structure. I have an Eclipse plugin which shows the dependency graphs based on the import/export statements generated by the maven-bundle-plugin. I could compare these with the dependencies you generated (it might help to add appropriate scopes to the dependencies). Thank you... Regards, Rajini On 11/23/07, Simon Laws [EMAIL PROTECTED] wrote: On Nov 22, 2007 2:51 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 22, 2007 1:57 PM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: Samples are very important for beginning users. For users who have moved beyond that stage and are doing real development using Tuscany, samples are not very important. If people in this category do want samples, they are likely to just want to refer to samples source code to cut and paste snippets as necessary. Having pre-built sample binaries isn't important for these users, and having the main lib directory polluted/bloated by samples dependencies is a positive nuisance because there's no easy way for them to find and remove the redundant files. I didn't think we were polluting the lib directory with sample dependencies, do you have a concrete example? I thought this thread was discussing the case of a sample having a dependency that the runtime does not have. If there are no such cases at present, then the issue doesn't arise. However, there could be such cases in the future as we add more application-style samples, and it would be good to have an idea about how such dependencies would be handled. Having these files in Tuscany's lib directory isn't just wasting a few bits on the disk. It can be a problem if their version levels conflict with other versions of the same code that the user has installed. For genuine Tuscany dependencies, such conflicts are a real issue that must be handled carefully in order to get Tuscany to co-exist with their other software. For sample dependencies, there is no actual conflict unless the user needs to run the specific sample that pulled in the dependency, Like I said earlier in the initial thread about sample dependencies, I don't think that samples should bring dependencies that are not genuine Tuscany dependencies. OK, we are agreed about this. But what if an application-style sample does have a non-Tuscany dependency? This is certainly possible. Would the Tuscany distro include the dependency, or leave it up to the user to download it as a prereq to running the sample? but it might take them some time to figure out why putting the Tuscany lib directory on the classpath is causing other code in their application to break. I'd suggest structuring the binary distribution as follows: 1. Tuscany runtime in modules and its dependencies in lib. +1 At the moment we have separate copies of the Tuscany runtime in modules and lib and I'm not quite sure why. Which JARs are you talking about? I'm talking about the tuscany-sca-all.jar in the lib directory, which is a combination of the contents of the jars in the modules directory. The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar as well as referring to all the jars in the modules directory, which seems somewhat redundant. 2. Tuscany samples source, READMEs and build files in samples. +1 3. Tuscany samples binaries in modules/samples, I prefer to have the binaries under samples as well, with their source. Having them there is more convenient but makes it harder to see how much space they are consuming. I did some investigation, and it turns out that these binaries are causing a huge expansion in the size of the samples directory. In the 1.0.1 binary distro, the source under the samples directory
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
I would like to make a start on improving the modularity of the distro by building a distro containing only a base SCA runtime. Sebastien's description of this was - base SCA runtime (assembly, policy fwk, impl-java) If others would like to propose any changes to this list and/or suggest which maven modules should be included, that would be helpful. Otherwise I'll go through the modules myself to make a first cut and iterate from there. I think this will be a useful excercise in seeing how small we can make this basic functionality and its dependencies. It will also allow us to explore some of the dependency issues between modules (official SPIs or implementation code) in a smaller and simpler world than the whole of Tuscany SCA Java. For now I'd like to consider this a personal experiment that may or may not ever get released. For this reason, I'd like to do this work in my sandbox. I haven't yet figured out how to do a sandbox build that pulls in code from the trunk, without copying it. Does anyone else have an example of this that I could look at? Expect a number of these how to questions as I get further into this :-) Simon Rajini Sivaram wrote: Simon, I did take a look at splitting the Tuscany distribution into bundles with the hope of defining something which makes sense for OSGi as well as non-OSGi. I dont really think that makes much sense anymore. Grouping modules into OSGi bundles using existing maven plugins was far too time consuming (in terms of the amount of time it took to do a build), and quite messy. So I would like to go for a simpler option for OSGi where the the zip/jar files generated for the Tuscany distribution have a manifest file containing OSGi bundle manifest entries, so that they can be directly installed into OSGi (with an easy repackaging option to get rid of samples from the bundle if the bundle size was too big). I would also like to add OSGi manifest entries into all jars distributed by Tuscany including 3rd party jars, so that we can use the OSGi bundle repository API to install Tuscany into an OSGi runtime, instead of relying on Tuscany distribution structure. I have an Eclipse plugin which shows the dependency graphs based on the import/export statements generated by the maven-bundle-plugin. I could compare these with the dependencies you generated (it might help to add appropriate scopes to the dependencies). Thank you... Regards, Rajini On 11/23/07, Simon Laws [EMAIL PROTECTED] wrote: On Nov 22, 2007 2:51 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 22, 2007 1:57 PM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: Samples are very important for beginning users. For users who have moved beyond that stage and are doing real development using Tuscany, samples are not very important. If people in this category do want samples, they are likely to just want to refer to samples source code to cut and paste snippets as necessary. Having pre-built sample binaries isn't important for these users, and having the main lib directory polluted/bloated by samples dependencies is a positive nuisance because there's no easy way for them to find and remove the redundant files. I didn't think we were polluting the lib directory with sample dependencies, do you have a concrete example? I thought this thread was discussing the case of a sample having a dependency that the runtime does not have. If there are no such cases at present, then the issue doesn't arise. However, there could be such cases in the future as we add more application-style samples, and it would be good to have an idea about how such dependencies would be handled. Having these files in Tuscany's lib directory isn't just wasting a few bits on the disk. It can be a problem if their version levels conflict with other versions of the same code that the user has installed. For genuine Tuscany dependencies, such conflicts are a real issue that must be handled carefully in order to get Tuscany to co-exist with their other software. For sample dependencies, there is no actual conflict unless the user needs to run the specific sample that pulled in the dependency, Like I said earlier in the initial thread about sample dependencies, I don't think that samples should bring dependencies that are not genuine Tuscany dependencies. OK, we are agreed about this. But what if an application-style sample does have a non-Tuscany dependency? This is certainly possible. Would the Tuscany distro include the dependency, or leave it up to the user to download it as a prereq to running the sample? but it might take them some time to figure out why putting the Tuscany lib directory on the classpath is causing other code in their application to break. I'd suggest structuring the binary distribution as follows: 1. Tuscany runtime in modules and its dependencies in lib. +1
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
Simon Laws wrote: On Nov 22, 2007 2:51 PM, ant elder [EMAIL PROTECTED] wrote: (cut) I can do some more processing on ( http://people.apache.org/~slaws/dependencies.htmhttp://people.apache.org/%7Eslaws/dependencies.htm) to give some help here if required. What do the columns mean? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 26, 2007 5:18 PM, Simon Nash [EMAIL PROTECTED] wrote: Simon Laws wrote: On Nov 22, 2007 2:51 PM, ant elder [EMAIL PROTECTED] wrote: (cut) I can do some more processing on ( http://people.apache.org/~slaws/dependencies.htmhttp://people.apache.org/%7Eslaws/dependencies.htm http://people.apache.org/%7Eslaws/dependencies.htm) to give some help here if required. What do the columns mean? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Column 1 - A jar on which Tuscany depends Column 2 - The type of dependency Column 3 - The Tuscany module that requires the dependency Column 4 to N - The transitive dependency path Simon
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
[snip] Simon Nash wrote: I would like to make a start on improving the modularity of the distro by building a distro containing only a base SCA runtime. Sebastien's description of this was - base SCA runtime (assembly, policy fwk, impl-java) [snip] I haven't yet figured out how to do a sandbox build that pulls in code from the trunk, without copying it. Does anyone else have an example of this that I could look at? Modules assembled by the Maven assembly plugin are taken out of the Maven repository, so you shouldn't need to copy the code to come up with a different assembly. For an example, look at the assemblies under sca/distribution. I'm also going to put together an assembly for the eclipse plugin, I'll give a pointer when it's there. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
Rajini Sivaram wrote: Simon, I did take a look at splitting the Tuscany distribution into bundles with the hope of defining something which makes sense for OSGi as well as non-OSGi. I dont really think that makes much sense anymore. Grouping modules into OSGi bundles using existing maven plugins was far too time consuming (in terms of the amount of time it took to do a build), and quite messy. So I would like to go for a simpler option for OSGi where the the zip/jar files generated for the Tuscany distribution have a manifest file containing OSGi bundle manifest entries, so that they can be directly installed into OSGi +1 from me, I'm glad you reached that conclusion, after thinking about it that was the only option that made sense to me :) (with an easy repackaging option to get rid of samples from the bundle if the bundle size was too big). Didn't quite get that, can you explain? I would also like to add OSGi manifest entries into all jars distributed by Tuscany including 3rd party jars, so that we can use the OSGi bundle repository API to install Tuscany into an OSGi runtime, instead of relying on Tuscany distribution structure. Not sure I'd like to go and change 3rd party dependency jars... but that triggers a very basic question: Independent of Tuscany, isn't this something that every OSGi user is going to bump into with non-OSGified 3rd party jars? What is the best practice in the OSGi community for this issue these days? I have an Eclipse plugin which shows the dependency graphs based on the import/export statements generated by the maven-bundle-plugin. I could compare these with the dependencies you generated (it might help to add appropriate scopes to the dependencies). Great, that'll help. Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
All that sounds sense to me, especially the thought of turning our samples to simple contribution jars. That will align better with what application developers would actually do. - Venkat On Nov 22, 2007 8:21 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 22, 2007 1:57 PM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: Samples are very important for beginning users. For users who have moved beyond that stage and are doing real development using Tuscany, samples are not very important. If people in this category do want samples, they are likely to just want to refer to samples source code to cut and paste snippets as necessary. Having pre-built sample binaries isn't important for these users, and having the main lib directory polluted/bloated by samples dependencies is a positive nuisance because there's no easy way for them to find and remove the redundant files. I didn't think we were polluting the lib directory with sample dependencies, do you have a concrete example? I thought this thread was discussing the case of a sample having a dependency that the runtime does not have. If there are no such cases at present, then the issue doesn't arise. However, there could be such cases in the future as we add more application-style samples, and it would be good to have an idea about how such dependencies would be handled. Having these files in Tuscany's lib directory isn't just wasting a few bits on the disk. It can be a problem if their version levels conflict with other versions of the same code that the user has installed. For genuine Tuscany dependencies, such conflicts are a real issue that must be handled carefully in order to get Tuscany to co-exist with their other software. For sample dependencies, there is no actual conflict unless the user needs to run the specific sample that pulled in the dependency, Like I said earlier in the initial thread about sample dependencies, I don't think that samples should bring dependencies that are not genuine Tuscany dependencies. OK, we are agreed about this. But what if an application-style sample does have a non-Tuscany dependency? This is certainly possible. Would the Tuscany distro include the dependency, or leave it up to the user to download it as a prereq to running the sample? but it might take them some time to figure out why putting the Tuscany lib directory on the classpath is causing other code in their application to break. I'd suggest structuring the binary distribution as follows: 1. Tuscany runtime in modules and its dependencies in lib. +1 At the moment we have separate copies of the Tuscany runtime in modules and lib and I'm not quite sure why. Which JARs are you talking about? I'm talking about the tuscany-sca-all.jar in the lib directory, which is a combination of the contents of the jars in the modules directory. The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar as well as referring to all the jars in the modules directory, which seems somewhat redundant. 2. Tuscany samples source, READMEs and build files in samples. +1 3. Tuscany samples binaries in modules/samples, I prefer to have the binaries under samples as well, with their source. Having them there is more convenient but makes it harder to see how much space they are consuming. I did some investigation, and it turns out that these binaries are causing a huge expansion in the size of the samples directory. In the 1.0.1 binary distro, the source under the samples directory occupies around 2.3 MB. The total size of source plus binaries under this directory is 49.5 MB. This extra 47 MB for samples binaries is almost half the total size of the Tuscany binary distro. I think we need to either remove these binaries or separate them out into a samples download so that we can get the Tuscany binary distro down to a reasonable size. with their dependencies in lib/samples. Again samples should not bring additional dependencies in the first place. I hope this is true. I don't know how to check that nothing in this category has been included in lib. By doing this we solve the conflict problems and it becomes a distro size issue to decide whether 3 should be in the main binary distro or available separately. IMO the samples should be small and not cause a size problem, and therefore should stay in the distro. +1 that this is how it should be, but it is definitely not the case today. The samples make up around 50MB of the 100MB total size of the binary distro. This needs to be fixed. Since 3 will be clearly separated from 1 and 2, it will be easy to see how much extra size it is
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 22, 2007 2:51 PM, ant elder [EMAIL PROTECTED] wrote: On Nov 22, 2007 1:57 PM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: [snip] Simon Nash wrote: Samples are very important for beginning users. For users who have moved beyond that stage and are doing real development using Tuscany, samples are not very important. If people in this category do want samples, they are likely to just want to refer to samples source code to cut and paste snippets as necessary. Having pre-built sample binaries isn't important for these users, and having the main lib directory polluted/bloated by samples dependencies is a positive nuisance because there's no easy way for them to find and remove the redundant files. I didn't think we were polluting the lib directory with sample dependencies, do you have a concrete example? I thought this thread was discussing the case of a sample having a dependency that the runtime does not have. If there are no such cases at present, then the issue doesn't arise. However, there could be such cases in the future as we add more application-style samples, and it would be good to have an idea about how such dependencies would be handled. Having these files in Tuscany's lib directory isn't just wasting a few bits on the disk. It can be a problem if their version levels conflict with other versions of the same code that the user has installed. For genuine Tuscany dependencies, such conflicts are a real issue that must be handled carefully in order to get Tuscany to co-exist with their other software. For sample dependencies, there is no actual conflict unless the user needs to run the specific sample that pulled in the dependency, Like I said earlier in the initial thread about sample dependencies, I don't think that samples should bring dependencies that are not genuine Tuscany dependencies. OK, we are agreed about this. But what if an application-style sample does have a non-Tuscany dependency? This is certainly possible. Would the Tuscany distro include the dependency, or leave it up to the user to download it as a prereq to running the sample? but it might take them some time to figure out why putting the Tuscany lib directory on the classpath is causing other code in their application to break. I'd suggest structuring the binary distribution as follows: 1. Tuscany runtime in modules and its dependencies in lib. +1 At the moment we have separate copies of the Tuscany runtime in modules and lib and I'm not quite sure why. Which JARs are you talking about? I'm talking about the tuscany-sca-all.jar in the lib directory, which is a combination of the contents of the jars in the modules directory. The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar as well as referring to all the jars in the modules directory, which seems somewhat redundant. 2. Tuscany samples source, READMEs and build files in samples. +1 3. Tuscany samples binaries in modules/samples, I prefer to have the binaries under samples as well, with their source. Having them there is more convenient but makes it harder to see how much space they are consuming. I did some investigation, and it turns out that these binaries are causing a huge expansion in the size of the samples directory. In the 1.0.1 binary distro, the source under the samples directory occupies around 2.3 MB. The total size of source plus binaries under this directory is 49.5 MB. This extra 47 MB for samples binaries is almost half the total size of the Tuscany binary distro. I think we need to either remove these binaries or separate them out into a samples download so that we can get the Tuscany binary distro down to a reasonable size. with their dependencies in lib/samples. Again samples should not bring additional dependencies in the first place. I hope this is true. I don't know how to check that nothing in this category has been included in lib. By doing this we solve the conflict problems and it becomes a distro size issue to decide whether 3 should be in the main binary distro or available separately. IMO the samples should be small and not cause a size problem, and therefore should stay in the distro. +1 that this is how it should be, but it is definitely not the case today. The samples make up around 50MB of the 100MB total size of the binary distro. This needs to be fixed. Since 3 will be clearly separated from 1 and 2, it will be easy to see how much extra size it is contributing. The other dimension of splitting the distro by functional contents is orthogonal to the above and is also worth exploring. I'd suggest the following distro packages:
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
Sebastien, We would like to enable a binary Tuscany distribution to run under OSGi. I am not sure of the level of granularity at which a bundle-ized Tuscany makes sense in terms of providing modularity and versioning using OSGi. But I would like to make sure that the bundles from the list below can be run in some form under OSGi. The big difference between packaging for OSGi and standard jars (apart from the additional entries in the manifest) is that OSGi bundle classpath can only refer to entries inside the bundle, while standard Jar classpath can only refer to jars outside the jar file without a customized classloader. I currently have Tuscany loaded into OSGi in two different ways. The first is a small list of large bundles (all 3rd party jars are grouped together), which are explicitly installed by an application that uses Tuscany. And the second is a large list of small bundles (each 3rd party jar is retained as a single bundle), loaded using OSGi bundle repository (OBR). Tuscany runtime and the required Tuscany extensions are installed by the application, the 3rd party jars are automatically installed by OBR. I am not sure how big each of the bundles you have listed below will be, and also what the relative size of the samples would be compared to the bundle itself. But I imagine that the easiest way to bundle these for OSGi would be to create each of these as a single OSGi bundle. I would like to add META-INF/MANIFEST.MF with OSGi import/export headers and an OSGi Bundle-ClassPath to the zip/jar file corresponding to the bundle. This is to enable a very coarsely grained set of bundles that can be easily installed by an OSGi application. The additional manifest file will not impact non-OSGi applications. By default, Tuscany will be run without OSGi, and the zip file corresponding to the bundle will need to be unzipped first (no change). To run Tuscany under OSGi, the zip file can be installed directly into OSGi. I would also like to enable finer grained OSGi bundles which can be installed using OBR. For the all-in-one bundle, could we have OSGi manifest entries inserted into each of the jar files including Tuscany modules and 3rd party jars, so that the jars can be installed independently into OSGi? But this only makes sense if we can have separate jars for the Tuscany extensions, rather than a combined tuscany-all.jar (otherwise OBR will install all the 3rd party bundles when tuscany-all is installed). The base Tuscany runtime could either be a single jar, or with some more fixes for classloading, it could be multiple jars based on the maven modules. Again, the OSGi manifest entries will not impact non-OSGi Tuscany. The splitting of Tuscany jars also shouldn't have any impact since tuscany-sca-manifest.jarcan just point to the longer list of Tuscany jars instead of tuscany-all. The third alternative is to have a separate set of jars, specifically targetted for OSGi-based Tuscany, which would be somewhere in between the coarsely grained first option and too finely grained second one. Rather than provide this as part of the binary distribution, this could be an optional build with the source distribution. Suggestions? Thank you... Regards, Rajini On 11/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Makes sense to me, I'd suggest the following packages: - base SCA runtime (assembly, policy fwk, impl-java) - web services package (ws binding + related databindings) - web 2.0 package (json, dwr, widget, atom, scripting) - data integration (impl-data, openjpa) - business process integration (bpel, xquery) - jee integration (ejb, jms, rmi) - spring + osgi integration (spring, osgi) - all-in-one, for people who don't have time to solve puzzles. Perhaps group web services and web 2.0 together, I'm not sure. Also I'm not sure about where to put policies like security, reliability, transactions. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
On Nov 18, 2007 9:31 PM, Simon Nash [EMAIL PROTECTED] wrote: I'm starting a new thread for this as suggested by Sebastien. Simon Simon Laws wrote: On Nov 15, 2007 6:54 PM, Simon Nash [EMAIL PROTECTED] wrote: (cut) I don't think we should put sample dependencies in the bin distro lib folder. If we need to include them in the bin distro (and I'm not 100% convinced about that), then I think they should go in some other directory. An alternative approach would be to have a samples distro that contains the samples plus dependencies that are only used by the samples and not by the main runtime. I think this is better as it allows us to add more samples without pushing up the size of the main binary distro. Personally I like to see samples with whatever I download and I'd rather have a bigger binary distro than a separate download. If there is a real need to reduce the distribution size can we do it in a different way, for example, have groups of extensions (and their samples) distributed separately? Samples are very important for beginning users. For users who have moved beyond that stage and are doing real development using Tuscany, samples are not very important. If people in this category do want samples, they are likely to just want to refer to samples source code to cut and paste snippets as necessary. Having pre-built sample binaries isn't important for these users, and having the main lib directory polluted/bloated by samples dependencies is a positive nuisance because there's no easy way for them to find and remove the redundant files. Having these files in Tuscany's lib directory isn't just wasting a few bits on the disk. It can be a problem if their version levels conflict with other versions of the same code that the user has installed. For genuine Tuscany dependencies, such conflicts are a real issue that must be handled carefully in order to get Tuscany to co-exist with their other software. For sample dependencies, there is no actual conflict unless the user needs to run the specific sample that pulled in the dependency, but it might take them some time to figure out why putting the Tuscany lib directory on the classpath is causing other code in their application to break. I'd suggest structuring the binary distribution as follows: 1. Tuscany runtime in modules and its dependencies in lib. At the moment we have separate copies of the Tuscany runtime in modules and lib and I'm not quite sure why. 2. Tuscany samples source, READMEs and build files in samples. 3. Tuscany samples binaries in modules/samples, with their dependencies in lib/samples. By doing this we solve the conflict problems and it becomes a distro size issue to decide whether 3 should be in the main binary distro or available separately. Since 3 will be clearly separated from 1 and 2, it will be easy to see how much extra size it is contributing. The other dimension of splitting the distro by functional contents is orthogonal to the above and is also worth exploring. I'd suggest the following distro packages: 1. Base runtime with functional capabilities that almost everyone will want to use, and associated samples. 2. A number of extension bundles (either depending only on the base, or possibly depending on other bundles), and associated samples. If people think this approach makes sense then we could talk about what the base distro and extension bundles should contain. Simon I think we should try to get to where the samples are just simple sca contribution jars - just the .composite files and whatever resources, Java classes or BPEL or Javascript files etc that the sample uses. All the dependency jars Tuscany uses to support running that - Ode, Axis2, Rhino and BSF etc and all the various Tuscany module jars - are a Tuscany implementation detail and the samples should be free from any reference to those. If we can do this then the sample build scripts become simple and the samples are tiny so there's no size problem at all with including them in a distribution. ...ant
Distribution structure for SCA Java 1.1 release (was Re: Sample dependencies not pulled in distribution)
I'm starting a new thread for this as suggested by Sebastien. Simon Simon Laws wrote: On Nov 15, 2007 6:54 PM, Simon Nash [EMAIL PROTECTED] wrote: (cut) I don't think we should put sample dependencies in the bin distro lib folder. If we need to include them in the bin distro (and I'm not 100% convinced about that), then I think they should go in some other directory. An alternative approach would be to have a samples distro that contains the samples plus dependencies that are only used by the samples and not by the main runtime. I think this is better as it allows us to add more samples without pushing up the size of the main binary distro. Personally I like to see samples with whatever I download and I'd rather have a bigger binary distro than a separate download. If there is a real need to reduce the distribution size can we do it in a different way, for example, have groups of extensions (and their samples) distributed separately? Samples are very important for beginning users. For users who have moved beyond that stage and are doing real development using Tuscany, samples are not very important. If people in this category do want samples, they are likely to just want to refer to samples source code to cut and paste snippets as necessary. Having pre-built sample binaries isn't important for these users, and having the main lib directory polluted/bloated by samples dependencies is a positive nuisance because there's no easy way for them to find and remove the redundant files. Having these files in Tuscany's lib directory isn't just wasting a few bits on the disk. It can be a problem if their version levels conflict with other versions of the same code that the user has installed. For genuine Tuscany dependencies, such conflicts are a real issue that must be handled carefully in order to get Tuscany to co-exist with their other software. For sample dependencies, there is no actual conflict unless the user needs to run the specific sample that pulled in the dependency, but it might take them some time to figure out why putting the Tuscany lib directory on the classpath is causing other code in their application to break. I'd suggest structuring the binary distribution as follows: 1. Tuscany runtime in modules and its dependencies in lib. At the moment we have separate copies of the Tuscany runtime in modules and lib and I'm not quite sure why. 2. Tuscany samples source, READMEs and build files in samples. 3. Tuscany samples binaries in modules/samples, with their dependencies in lib/samples. By doing this we solve the conflict problems and it becomes a distro size issue to decide whether 3 should be in the main binary distro or available separately. Since 3 will be clearly separated from 1 and 2, it will be easy to see how much extra size it is contributing. The other dimension of splitting the distro by functional contents is orthogonal to the above and is also worth exploring. I'd suggest the following distro packages: 1. Base runtime with functional capabilities that almost everyone will want to use, and associated samples. 2. A number of extension bundles (either depending only on the base, or possibly depending on other bundles), and associated samples. If people think this approach makes sense then we could talk about what the base distro and extension bundles should contain. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
