Re: Process and content for next release?
I'm happy to pitch in and handle the SDO Java aspects of this release. A pre-ApacheCon release fits pretty well with the state of play in SDO Java. Can anyone point to or create a quick checklist of the processes/tasks involved in creating a release, and perhaps some estimates of what would need to be in place by when in order to achieve a release before ApacheCon? Regards, Kelvin. On 30/08/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson
Re: Process and content for next release?
I can handle the DAS Java aspects of this release. I'm going to be updating the list of features that are planned and it's status on the wiki : http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview If there is anything else in terms of process/tasks that needs to be done, please let me know. - Luciano On 9/8/06, kelvin goodson [EMAIL PROTECTED] wrote: I'm happy to pitch in and handle the SDO Java aspects of this release. A pre-ApacheCon release fits pretty well with the state of play in SDO Java. Can anyone point to or create a quick checklist of the processes/tasks involved in creating a release, and perhaps some estimates of what would need to be in place by when in order to achieve a release before ApacheCon? Regards, Kelvin. On 30/08/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards Kelvin Goodson -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: Process and content for next release?
We have had a rush of build problems recently which have stopped people from being able to contribute effectively. Some of those have come from the size of the build leading to Jim's proposal to go ahead with the build refactors we have been talking about. For those to work we need some way to publish unstable artifacts and that meshes nicely with this release thread. There have been no comments on this thread since the original burst so I plan to start pulling together a release based on the approach described here (factoring in those comments). -- Jeremy On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote: Our discussions on modularity have gone quiet and Kelvin and Luciano have started to build distributions for SDO and DAS. I'd like to open the discussion up about what should be in our next release, how we should approach it and when we think it might be ready. As the person opening this thread, I guess I'm also volunteering to be Release Manager unless someone else would prefer to do it :-) One of the things we're achieved with the modularization is the ability to decompose what we have into separately releasable modules - we don't have to pull everything together at the same time. We also have the ability to release artifacts individually through various maven repositories, publishing specific jars rather than than entire distribution. This allows us to structure a release differently from what we did in M1. Instead of publishing one bundle and then pulling libraries from it to distribute through Maven, I suggest we focus on the individual components then group them together into bundled distributions. Taking SDO as an example, this would mean that we would decide at some point that we wanted to release the sdo-impl library (that being the executable part of SDO). We would cut and vote on a version of that jar and that could then be published through Maven. We could also bundle that jar in a distribution containing dependencies (e.g. EMF), samples, documentation, ... The two don't need to be in permanent lock-step (although alignment is good) - for example, we could release an updated impl jar with some bugfixes without respinning the bundle. SCA provides a much more complex picture as it contains not just libraries but also host environments, multiple extensions, potentially multiple extensions providing alternative implementations of the same function (e.g. the axis and celtix bindings). To handle this I think we should stage the release process, stabilizing the core first, then whatever set of extensions we define as a bundle, finally voting to release the bundle. During the stabilization process we can published dated unstable builds to the SNAPSHOT repo so that extensions can rely on those rather than trunk all the time. So, having said all that, I would like to propose we start working toward getting the next release out with the following stages: 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support 3) Baseline extensions - ones we think are essential for users idl.wsdl binding.axis binding.celtix binding.rmi databinding.axiom databinding.sdo databinding.jaxb container.javascript container.spring 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready This is an initial strawman of how I think we can pull this together. We can certainly move things around depending on what's ready and what we think are essential modules. If this seems reasonable I will transfer it to the wiki. Cheers -- Jeremy - 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: Process and content for next release?
Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. Thanks, Joel -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 11:04 AM To: tuscany-dev@ws.apache.org Subject: Re: Process and content for next release? We have had a rush of build problems recently which have stopped people from being able to contribute effectively. Some of those have come from the size of the build leading to Jim's proposal to go ahead with the build refactors we have been talking about. For those to work we need some way to publish unstable artifacts and that meshes nicely with this release thread. There have been no comments on this thread since the original burst so I plan to start pulling together a release based on the approach described here (factoring in those comments). -- Jeremy On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote: Our discussions on modularity have gone quiet and Kelvin and Luciano have started to build distributions for SDO and DAS. I'd like to open the discussion up about what should be in our next release, how we should approach it and when we think it might be ready. As the person opening this thread, I guess I'm also volunteering to be Release Manager unless someone else would prefer to do it :-) One of the things we're achieved with the modularization is the ability to decompose what we have into separately releasable modules - we don't have to pull everything together at the same time. We also have the ability to release artifacts individually through various maven repositories, publishing specific jars rather than than entire distribution. This allows us to structure a release differently from what we did in M1. Instead of publishing one bundle and then pulling libraries from it to distribute through Maven, I suggest we focus on the individual components then group them together into bundled distributions. Taking SDO as an example, this would mean that we would decide at some point that we wanted to release the sdo-impl library (that being the executable part of SDO). We would cut and vote on a version of that jar and that could then be published through Maven. We could also bundle that jar in a distribution containing dependencies (e.g. EMF), samples, documentation, ... The two don't need to be in permanent lock-step (although alignment is good) - for example, we could release an updated impl jar with some bugfixes without respinning the bundle. SCA provides a much more complex picture as it contains not just libraries but also host environments, multiple extensions, potentially multiple extensions providing alternative implementations of the same function (e.g. the axis and celtix bindings). To handle this I think we should stage the release process, stabilizing the core first, then whatever set of extensions we define as a bundle, finally voting to release the bundle. During the stabilization process we can published dated unstable builds to the SNAPSHOT repo so that extensions can rely on those rather than trunk all the time. So, having said all that, I would like to propose we start working toward getting the next release out with the following stages: 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support 3) Baseline extensions - ones we think are essential for users idl.wsdl binding.axis binding.celtix binding.rmi databinding.axiom databinding.sdo databinding.jaxb container.javascript container.spring 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready This is an initial strawman of how I think we can pull this together. We can certainly move things around depending on what's ready and what we think are essential modules. If this seems reasonable I will transfer it to the wiki. Cheers -- Jeremy - To unsubscribe, e
Re: Process and content for next release?
Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Process and content for next release?
Thanks - that gives me some dates to shoot for. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 11:48 AM To: tuscany-dev@ws.apache.org Subject: Re: Process and content for next release? Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Process and content for next release?
Joel, If you need any help, ping me. Jim On Aug 30, 2006, at 8:51 AM, Hawkins, Joel wrote: Thanks - that gives me some dates to shoot for. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 11:48 AM To: tuscany-dev@ws.apache.org Subject: Re: Process and content for next release? Basically, when it's done :-) Having said that, see below for the estimates I would make for the separate stages. If they are anywhere near accurate then I think we're looking towards the end of September (which seems like a good time just before ApacheCon). By publish, I mean having a stable but unreleased artifact in the snapshot maven repo. -- Jeremy On Aug 30, 2006, at 8:23 AM, Hawkins, Joel wrote: Jeremy, when is your target date for this next release? I hope to get back to the OSGi binding/hosting code within the next week and I'd really like to try and get something into the release. ... snip ... 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think these are ready and we can publish a stable version now. 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I hope that we can get this wrapped and published by 9/11 3) Baseline extensions - ones we think are essential for users idl.wsdl9/11 binding.axis9/18 (depends on Axis 1.1 release) binding.celtix 9/18 binding.rmi 9/11 databinding.axiom 9/11 databinding.sdo 9/11 (depends on a SDO release) databinding.jaxb9/11 container.javascript container.spring I am assuming the axiom, sdo and jaxb databindings sync with the framework as we need something there to test it out. I don't have a good feeling for how long it will take to get the containers working. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) Based on Jim's feedback I don't think we would be doing a Web-app distribution; instead there would be a web-app maven plugin to package a war with a suitably configured war inside it. See 7) for that. 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready 7) Tools Web-app maven plugin 9/4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - 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: Process and content for next release?
On Aug 16, 2006, at 1:58 PM, Jeremy Boynes wrote: SCA provides a much more complex picture as it contains not just libraries but also host environments, multiple extensions, potentially multiple extensions providing alternative implementations of the same function (e.g. the axis and celtix bindings). To handle this I think we should stage the release process, stabilizing the core first, then whatever set of extensions we define as a bundle, finally voting to release the bundle. During the stabilization process we can published dated unstable builds to the SNAPSHOT repo so that extensions can rely on those rather than trunk all the time. +1 So, having said all that, I would like to propose we start working toward getting the next release out with the following stages: 1) Specs (sdo-api, sca-api, commonj) These should be stable now as the specifications have been published. I think they are mostly stable but we should recheck to ensure they are consistent with the specs 2) SCA Core (spi, core, hostutil, test, plus apis once that refactor is done) Features I would like to see complete before we consider this stable are: Class loading changes Integration of databinding framework Support for async callbacks Support for complex properties Transitive dependency support I'd also like to see much better test coverage than what we have. This is hard to quantify, but while code coverage does not guarantee good tests, it is an indicator. So, to have a metric, I'd like to see core (and other extensions) at 75% coverage when run through Clover. I picked Clover since it is a decent tool and license-friendly but if someone would like to suggest an alternative we could look at it as well. 3) Baseline extensions - ones we think are essential for users idl.wsdl binding.axis binding.celtix binding.rmi databinding.axiom databinding.sdo databinding.jaxb container.javascript container.spring I'm not sure what the difference is between baseline and optional. I think all extensions are optional unless one is being used and has dependencies. If the distinction is to deal with voting issues, maybe we could group things together as long as there is a way to not have them physically bundled together. Can you explain the linkage between 3,4,5 as I think there may be a terminology issue? 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) 6) Sample applications Technology sample framework (subject of another mail) BigBank application if ready This is an initial strawman of how I think we can pull this together. We can certainly move things around depending on what's ready and what we think are essential modules. If this seems reasonable I will transfer it to the wiki. Cheers -- Jeremy - 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: Process and content for next release?
On Aug 16, 2006, at 2:49 PM, Jim Marino wrote: 3) Baseline extensions - ones we think are essential for users idl.wsdl binding.axis binding.celtix binding.rmi databinding.axiom databinding.sdo databinding.jaxb container.javascript container.spring I'm not sure what the difference is between baseline and optional. I think all extensions are optional unless one is being used and has dependencies. If the distinction is to deal with voting issues, maybe we could group things together as long as there is a way to not have them physically bundled together. Can you explain the linkage between 3,4,5 as I think there may be a terminology issue? From a technical perspective, yes, all are optional relative to the core and yes there may be dependencies between them. The grouping here is stuff that we think is useful to a user and want to ship as a bundle and would be input to the host distros in 5). We would want these to be in sync and tested together. 4) Optional extensions - nice to have but which may not be ready to bundle binding.jsonrpc binding.osgi databinding.xmlbeans databinding.castor container.groovy 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) These would be the things we would expect users to download to start using Tuscany. These would be targeted at providing the extensions users would need to do something useful. I was thinking Standalone would be a command line client environment, Web-app would be what you would want to use in a war (the J2EE variety). Perhaps we should add another: Minimal - distro of just the core and its dependencies to which users could add extensions -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Process and content for next release?
On Aug 16, 2006, at 3:17 PM, Jim Marino wrote: 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) That feels like a lot of dependencies are being dragged in which most will never use. Couldn't we just have host distributions which only provide core and the necessary artifacts to bootstrap in a host environment? Extensions could be either dynamically resolved or plugged in as needed? For example, the web app distribution would be enormous with the above combination. The point is to target the distro at what users /do/ use and to make sure the dependencies are already there. There are alternatives for users who want to build up - e.g. the Minimal distro I mentioned previously. For people looking to build a web application that used Tuscany, I would think that a extension to the Maven WAR plugin would be the way to go - the plugin would get core and extension artifacts via Maven and add them to the war that it was building (like the normal WAR plugin does adding dependencies to WEB-INF/lib). We could provide a similar Ant task for people building with Ant. With that option, it may be that we don't need a Web-app distribution at all. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Process and content for next release?
On Aug 16, 2006, at 4:01 PM, Jeremy Boynes wrote: On Aug 16, 2006, at 3:17 PM, Jim Marino wrote: 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) That feels like a lot of dependencies are being dragged in which most will never use. Couldn't we just have host distributions which only provide core and the necessary artifacts to bootstrap in a host environment? Extensions could be either dynamically resolved or plugged in as needed? For example, the web app distribution would be enormous with the above combination. The point is to target the distro at what users /do/ use and to make sure the dependencies are already there. There are alternatives for users who want to build up - e.g. the Minimal distro I mentioned previously. For people looking to build a web application that used Tuscany, I would think that a extension to the Maven WAR plugin would be the way to go - the plugin would get core and extension artifacts via Maven and add them to the war that it was building (like the normal WAR plugin does adding dependencies to WEB-INF/lib). We could provide a similar Ant task for people building with Ant. I like this approach better. For example, I don't think a typical application would use celtix, rmi, axis, json, Spring and Javascript components together. With that option, it may be that we don't need a Web-app distribution at all. -- Jeremy - 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: Process and content for next release?
On Aug 16, 2006, at 5:47 PM, Jim Marino wrote: On Aug 16, 2006, at 4:01 PM, Jeremy Boynes wrote: On Aug 16, 2006, at 3:17 PM, Jim Marino wrote: 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) That feels like a lot of dependencies are being dragged in which most will never use. Couldn't we just have host distributions which only provide core and the necessary artifacts to bootstrap in a host environment? Extensions could be either dynamically resolved or plugged in as needed? For example, the web app distribution would be enormous with the above combination. The point is to target the distro at what users /do/ use and to make sure the dependencies are already there. There are alternatives for users who want to build up - e.g. the Minimal distro I mentioned previously. For people looking to build a web application that used Tuscany, I would think that a extension to the Maven WAR plugin would be the way to go - the plugin would get core and extension artifacts via Maven and add them to the war that it was building (like the normal WAR plugin does adding dependencies to WEB-INF/lib). We could provide a similar Ant task for people building with Ant. I like this approach better. For example, I don't think a typical application would use celtix, rmi, axis, json, Spring and Javascript components together. Unfortunately we don't have said plugin - do you think this should be a prereq for a release? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Process and content for next release?
On Aug 16, 2006, at 6:58 PM, Jeremy Boynes wrote: On Aug 16, 2006, at 5:47 PM, Jim Marino wrote: On Aug 16, 2006, at 4:01 PM, Jeremy Boynes wrote: On Aug 16, 2006, at 3:17 PM, Jim Marino wrote: 5) Host distributions - host environments that each form the basis for each bundle Standalone (with axis, celtix, rmi, spring) Web-app (with axis, celtix, rmi, json, spring, javascript) That feels like a lot of dependencies are being dragged in which most will never use. Couldn't we just have host distributions which only provide core and the necessary artifacts to bootstrap in a host environment? Extensions could be either dynamically resolved or plugged in as needed? For example, the web app distribution would be enormous with the above combination. The point is to target the distro at what users /do/ use and to make sure the dependencies are already there. There are alternatives for users who want to build up - e.g. the Minimal distro I mentioned previously. For people looking to build a web application that used Tuscany, I would think that a extension to the Maven WAR plugin would be the way to go - the plugin would get core and extension artifacts via Maven and add them to the war that it was building (like the normal WAR plugin does adding dependencies to WEB-INF/lib). We could provide a similar Ant task for people building with Ant. I like this approach better. For example, I don't think a typical application would use celtix, rmi, axis, json, Spring and Javascript components together. Unfortunately we don't have said plugin - do you think this should be a prereq for a release? If the only alternative is to ship a bundle that includes the above then yes as I don't think users are going to accept placing that amount of stuff in a WAR and it makes us look like we don't know how to modularize properly :-) I've seen other projects tell users to remove stuff but that's just lame and I think we can do better. Jim -- Jeremy - 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]
