[jira] Created: (TUSCANY-1747) BUILDING file still says 0.91 release July
BUILDING file still says 0.91 release July -- Key: TUSCANY-1747 URL: https://issues.apache.org/jira/browse/TUSCANY-1747 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.0 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 Should be changed to 1.0 September -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1747) BUILDING file still says 0.91 release July
[ https://issues.apache.org/jira/browse/TUSCANY-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1747. - Resolution: Fixed Fixed BUILDING file still says 0.91 release July -- Key: TUSCANY-1747 URL: https://issues.apache.org/jira/browse/TUSCANY-1747 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.0 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 Should be changed to 1.0 September -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java SCA 0.91 Release related
URL has an extra text on it - 'and'. Here is the correct one. http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatinghttp://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatingand On 7/5/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I was intending to send Java SCA RC2 for a vote but it happens that minotaur is down and I cannot stage RC2. So, meanwhile it would be great if people can take a look at the tag - http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatingand try to give me some inputs on how it looks for a release. Thanks.
Re: Java SCA 0.91 Release related
Hi, I don't see this. Maybe you did a copy paste and copied the 'and' as well. - Venkat On 7/6/07, haleh mahbod [EMAIL PROTECTED] wrote: URL has an extra text on it - 'and'. Here is the correct one. http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatinghttp://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatingand On 7/5/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I was intending to send Java SCA RC2 for a vote but it happens that minotaur is down and I cannot stage RC2. So, meanwhile it would be great if people can take a look at the tag - http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc2-incubatingand try to give me some inputs on how it looks for a release. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Added a Spring based sample, was: 0.91 release?
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Venkata Krishnan wrote: Hi So here is a list of things that will be included for the 0.91 release. - binding-ajax (has sample to demonstrate this) - extension-helper (the scripting extensions demonstrate this) - binding-ejb - binding-feed (the bigbank demo uses this) - implementation-resource (the bigbank demo uses this) - implementation-spring (no sample, no demos, but interesting to have and hope Sebastien is able to contribute a sample for this). As far as demos and samples are concerned I intend to include only the ones that have READMEs. So if you folks can help me fix READMEs for the ones that need to be included and that don't have this, that will be very helpful. Finally, may I request that any improvements or changes which any of you wish to be a included in the release be done on the branch and then also merged with the trunk immediately. I hope we don't have large ones ;-). Thanks. I have added a sample showing how to use the implementation-resource extension under [1]. I can add merge it into the 0.91 branch in a day or two after people get a chance to review it if you think it's useful to have in the release. It doesn't have a README yet, I'll try to add one tomorrow. I'm still working on a Spring sample as well, it will be a variation of the simple-bigbank sample. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/web-resource/ I have added a Spring sample under [2]. This is a variation of the simple-bigbank sample that uses a nested Spring assembly using implementation.spring instead of a nested SCA assembly using implementation.composite. Here are the relevant XML snippets. The original SCA simple-bigbank: BigBank.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:a=http://account; xmlns:s=http://stockquote; name=BigBank component name=AccountServiceComponent implementation.composite name=a:Account/ reference name=stockQuoteService target=StockQuoteServiceComponent/ /component component name=StockQuoteServiceComponent implementation.composite name=s:StockQuote/ /component /composite Account.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://account; name=Account service name=AccountService promote=AccountServiceComponent/ component name=AccountServiceComponent implementation.java class=bigbank.account.AccountServiceImpl/ reference name=accountDataService target=AccountDataServiceComponent/ property name=currencyUSD/property /component component name=AccountDataServiceComponent implementation.java class=bigbank.accountdata.AccountDataServiceImpl/ /component reference name=stockQuoteService promote=AccountServiceComponent/stockQuoteService/ /composite The SCA + Spring based spring-bigbank: BigBank.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:s=http://stockquote; name=BigBank component name=AccountServiceComponent implementation.spring location=Account-spring-context.xml/ reference name=stockQuoteService target=StockQuoteServiceComponent/ /component component name=StockQuoteServiceComponent implementation.composite name=s:StockQuote/ /component /composite Account-spring-context.xml beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:sca=http://www.springframework.org/schema/sca; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd; bean id=AccountServiceBean class=bigbank.account.AccountServiceImpl property name=accountDataService ref=AccountDataServiceBean/ property name=stockQuoteService ref=stockQuoteService/ property name=currency value=USD/ /bean bean id=AccountDataServiceBean class=bigbank.accountdata.AccountDataServiceImpl /bean /beans [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/spring-bigbank/ I improved the sample a bit to show how to declare proper SCA services and references in a Spring assembly, using the Spring SCA extension elements. Account-spring-context.xml now looks like this: beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:sca=http://www.springframework.org/schema/sca; xsi:schemaLocation= http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/sca http://www.springframework.org/schema/sca/spring-sca.xsd; sca:service name=AccountService type=bigbank.account.AccountService target
Re: 0.91 release?
Simon Nash wrote: The current model is as follows: X is an established and widely used technology Tuscany SCA wants to provide support for X The Tuscany SCA community creates an extension for X The Tuscany SCA extension for X is delivered in a Tuscany SCA release There is nothing wrong with this and I would not want to change anything that is currently there. In the future, let's hope that Tuscany SCA becomes an established and widely used technology. It is then possible to imagine the following: Tuscany SCA is an established and widely used technology Another technology X wants to provide support for Tuscany SCA The X community creates a Tuscany SCA extension for X The Tuscany SCA extension for X is delivered in an X release Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. +1 An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. I'm trying to understand this thought. Here are some of our technology dependencies: binding-ws - Axis2 binding-jms - ActiveMQ binding-feed - Rome databinding-sdo - SDO binding-jsonrpc - json implementation-das - DAS implementation-bpel - ODE implementation-spring - Spring implementation-osgi - Equinox databinding-xmlbeans - XMLBeans databinding-jaxb - JAXB binding-ejb - Geronimo http-jetty - Jetty http-tomcat - Tomcat tuscany-core - J2SE 5.0 :) and woodstox I know that many combinations are possible, but as long as something works, I'm not sure why we would exclude it from a Tuscany release. Which ones are you proposing to pick out and not include in a Tuscany SCA release? Ok, it makes sense to me now. Thanks for clarifying. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Added a sample for the implementation-resource extension, was: 0.91 release?
[snip] Venkata Krishnan wrote: Hi So here is a list of things that will be included for the 0.91 release. - binding-ajax (has sample to demonstrate this) - extension-helper (the scripting extensions demonstrate this) - binding-ejb - binding-feed (the bigbank demo uses this) - implementation-resource (the bigbank demo uses this) - implementation-spring (no sample, no demos, but interesting to have and hope Sebastien is able to contribute a sample for this). As far as demos and samples are concerned I intend to include only the ones that have READMEs. So if you folks can help me fix READMEs for the ones that need to be included and that don't have this, that will be very helpful. Finally, may I request that any improvements or changes which any of you wish to be a included in the release be done on the branch and then also merged with the trunk immediately. I hope we don't have large ones ;-). Thanks. I have added a sample showing how to use the implementation-resource extension under [1]. I can add merge it into the 0.91 branch in a day or two after people get a chance to review it if you think it's useful to have in the release. It doesn't have a README yet, I'll try to add one tomorrow. I'm still working on a Spring sample as well, it will be a variation of the simple-bigbank sample. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/web-resource/ -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Added a Spring based sample, was: 0.91 release?
Jean-Sebastien Delfino wrote: [snip] Venkata Krishnan wrote: Hi So here is a list of things that will be included for the 0.91 release. - binding-ajax (has sample to demonstrate this) - extension-helper (the scripting extensions demonstrate this) - binding-ejb - binding-feed (the bigbank demo uses this) - implementation-resource (the bigbank demo uses this) - implementation-spring (no sample, no demos, but interesting to have and hope Sebastien is able to contribute a sample for this). As far as demos and samples are concerned I intend to include only the ones that have READMEs. So if you folks can help me fix READMEs for the ones that need to be included and that don't have this, that will be very helpful. Finally, may I request that any improvements or changes which any of you wish to be a included in the release be done on the branch and then also merged with the trunk immediately. I hope we don't have large ones ;-). Thanks. I have added a sample showing how to use the implementation-resource extension under [1]. I can add merge it into the 0.91 branch in a day or two after people get a chance to review it if you think it's useful to have in the release. It doesn't have a README yet, I'll try to add one tomorrow. I'm still working on a Spring sample as well, it will be a variation of the simple-bigbank sample. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/web-resource/ I have added a Spring sample under [2]. This is a variation of the simple-bigbank sample that uses a nested Spring assembly using implementation.spring instead of a nested SCA assembly using implementation.composite. Here are the relevant XML snippets. The original SCA simple-bigbank: BigBank.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:a=http://account; xmlns:s=http://stockquote; name=BigBank component name=AccountServiceComponent implementation.composite name=a:Account/ reference name=stockQuoteService target=StockQuoteServiceComponent/ /component component name=StockQuoteServiceComponent implementation.composite name=s:StockQuote/ /component /composite Account.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://account; name=Account service name=AccountService promote=AccountServiceComponent/ component name=AccountServiceComponent implementation.java class=bigbank.account.AccountServiceImpl/ reference name=accountDataService target=AccountDataServiceComponent/ property name=currencyUSD/property /component component name=AccountDataServiceComponent implementation.java class=bigbank.accountdata.AccountDataServiceImpl/ /component reference name=stockQuoteService promote=AccountServiceComponent/stockQuoteService/ /composite The SCA + Spring based spring-bigbank: BigBank.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:s=http://stockquote; name=BigBank component name=AccountServiceComponent implementation.spring location=Account-spring-context.xml/ reference name=stockQuoteService target=StockQuoteServiceComponent/ /component component name=StockQuoteServiceComponent implementation.composite name=s:StockQuote/ /component /composite Account-spring-context.xml beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:sca=http://www.springframework.org/schema/sca; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd; bean id=AccountServiceBean class=bigbank.account.AccountServiceImpl property name=accountDataService ref=AccountDataServiceBean/ property name=stockQuoteService ref=stockQuoteService/ property name=currency value=USD/ /bean bean id=AccountDataServiceBean class=bigbank.accountdata.AccountDataServiceImpl /bean /beans [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/spring-bigbank/ -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Hi, I have cleaned up the branch and the corresponding parts in the trunk to fix for missing header files. Here is an updated RAT report. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: Comments inline. Simon ant elder wrote: On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip as long as something works, I'm not sure why we would exclude it from a Tuscany release. I think we need a bit more clarity about what it means to include something in the release. Is it just having the code included in the src distro, or included in the src distro as part of the build, or also included in the binary distro, or included in both distro's along with itests, samples, readme's or web site doc, and mention of the new thing in the release notes? My take is that included in the release means included in both distros along with itests, samples, readmes or web site doc, and mention of the new thing in the release notes. +1 from me. I'm expecting the itest suite to grow over time as not all extensions are covered yet. I just added a sample for the implementation-resource extension, and am still working on a sample for the implementation-spring extension. From the 0.90 release things were pulled out for not being quite there, a lot of the time spent before the final release artifacts got done was because people reviewing the distro's wanted all things up to a certain standard. Getting all this done can take a lot of work. Last minute changes often cause unexpected blocking problems in the distributions resulting in respins and more delay. If we just include everything that works is someone reviewing a release RC going to complain that some new sample is missing a readme, that a demo should have an Ant build script, or that some new extension doesn't even have a sample? If things must be of a certain standard then I don't think its reasonable to expect the release manager to do all the work to get things there. I agree that these things are needed and that the burden of doing them should not fall on the RM. +1 that's what I had in mind as well when I said works, as samples and a readme are the basic requirements for a user to be able to get an extension to work. How about: - by default everything is kept in the src distro unless there's some reason not to I'm not sure about this. What is the value of including modules in the source distro but exluding them from the build? The latest levels of this code (presumably better) are available in trunk. Since these things weren't built or tested as part of the release, the snapshot state they were in on release date has no particular significance. I also recall a discussion some time ago (not specific to Tuscany but on [EMAIL PROTECTED] IIRC) in which it was said that the source distro is what really defines the content of the release, and the binaries are included for convenience. For all of these reasons, it seems better for the source and binary distros to have matching contents unless there's some reason not to. Matching source and bin distros make more sense to me as well. - only the things mentioned on the release wiki page get included in the build, binary distribution, and mentioned in the release notes This seems OK for new function. I'm not sure what process we use for JIRA fixes. They don't seem to be listed on this page. I would expect that marking the Fix version field accordingly is all that is needed. Not sure that it's realistic. - after the brn is cut we need to ask on the ML before adding new things to the wiki release page Agreed. +1 - adding something to the wiki release page implies some commitment to help get it to the required standard in line with the release schedule. Agreed. +1 Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Comments inline. Simon ant elder wrote: On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip as long as something works, I'm not sure why we would exclude it from a Tuscany release. I think we need a bit more clarity about what it means to include something in the release. Is it just having the code included in the src distro, or included in the src distro as part of the build, or also included in the binary distro, or included in both distro's along with itests, samples, readme's or web site doc, and mention of the new thing in the release notes? My take is that included in the release means included in both distros along with itests, samples, readmes or web site doc, and mention of the new thing in the release notes. From the 0.90 release things were pulled out for not being quite there, a lot of the time spent before the final release artifacts got done was because people reviewing the distro's wanted all things up to a certain standard. Getting all this done can take a lot of work. Last minute changes often cause unexpected blocking problems in the distributions resulting in respins and more delay. If we just include everything that works is someone reviewing a release RC going to complain that some new sample is missing a readme, that a demo should have an Ant build script, or that some new extension doesn't even have a sample? If things must be of a certain standard then I don't think its reasonable to expect the release manager to do all the work to get things there. I agree that these things are needed and that the burden of doing them should not fall on the RM. How about: - by default everything is kept in the src distro unless there's some reason not to I'm not sure about this. What is the value of including modules in the source distro but exluding them from the build? The latest levels of this code (presumably better) are available in trunk. Since these things weren't built or tested as part of the release, the snapshot state they were in on release date has no particular significance. I also recall a discussion some time ago (not specific to Tuscany but on [EMAIL PROTECTED] IIRC) in which it was said that the source distro is what really defines the content of the release, and the binaries are included for convenience. For all of these reasons, it seems better for the source and binary distros to have matching contents unless there's some reason not to. - only the things mentioned on the release wiki page get included in the build, binary distribution, and mentioned in the release notes This seems OK for new function. I'm not sure what process we use for JIRA fixes. They don't seem to be listed on this page. I would expect that marking the Fix version field accordingly is all that is needed. - after the brn is cut we need to ask on the ML before adding new things to the wiki release page Agreed. - adding something to the wiki release page implies some commitment to help get it to the required standard in line with the release schedule. Agreed. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Venkata Krishnan wrote: Yes... I guess it should be possible to have them. I'd say, at the least that we have a readme that describes the demo layout, what its intent is and how you get to run it. I guess this is something we have already done for the samples. - Venkat On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon Would it be possible to have the demos in the release? What do we need to do to make it happen? Thanks. -- Jean-Sebastien I'll contribute the README for the Bigbank demo. Hope to have it by tomorrow. The Bigbank demo uses the implementation-resource extension, which makes it much easier to package and run as it doesn't need to be packaged in a WAR anymore, so if bigbank-demo is included and implementation-resource needs to be as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: Yes... I guess it should be possible to have them. I'd say, at the least that we have a readme that describes the demo layout, what its intent is and how you get to run it. I guess this is something we have already done for the samples. - Venkat On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon Would it be possible to have the demos in the release? What do we need to do to make it happen? Thanks. -- Jean-Sebastien I'll contribute the README for the Bigbank demo. Hope to have it by tomorrow. The Bigbank demo uses the implementation-resource extension, which makes it much easier to package and run as it doesn't need to be packaged in a WAR anymore, so if bigbank-demo is included and implementation-resource needs to be as well. Sorry, I meant if bigbank-demo is included then implementation-resource needs to be as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Hi So here is a list of things that will be included for the 0.91 release. - binding-ajax (has sample to demonstrate this) - extension-helper (the scripting extensions demonstrate this) - binding-ejb - binding-feed (the bigbank demo uses this) - implementation-resource (the bigbank demo uses this) - implementation-spring (no sample, no demos, but interesting to have and hope Sebastien is able to contribute a sample for this). As far as demos and samples are concerned I intend to include only the ones that have READMEs. So if you folks can help me fix READMEs for the ones that need to be included and that don't have this, that will be very helpful. Finally, may I request that any improvements or changes which any of you wish to be a included in the release be done on the branch and then also merged with the trunk immediately. I hope we don't have large ones ;-). Thanks. - Venkat On 6/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Yes... I guess it should be possible to have them. I'd say, at the least that we have a readme that describes the demo layout, what its intent is and how you get to run it. I guess this is something we have already done for the samples. - Venkat On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon Would it be possible to have the demos in the release? What do we need to do to make it happen? Thanks. -- Jean-Sebastien I'll contribute the README for the Bigbank demo. Hope to have it by tomorrow. The Bigbank demo uses the implementation-resource extension, which makes it much easier to package and run as it doesn't need to be packaged in a WAR anymore, so if bigbank-demo is included and implementation-resource needs to be as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
On 6/22/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi So here is a list of things that will be included for the 0.91 release. - binding-ajax (has sample to demonstrate this) - extension-helper (the scripting extensions demonstrate this) - binding-ejb - binding-feed (the bigbank demo uses this) - implementation-resource (the bigbank demo uses this) - implementation-spring (no sample, no demos, but interesting to have and hope Sebastien is able to contribute a sample for this). As far as demos and samples are concerned I intend to include only the ones that have READMEs. So if you folks can help me fix READMEs for the ones that need to be included and that don't have this, that will be very helpful. Finally, may I request that any improvements or changes which any of you wish to be a included in the release be done on the branch and then also merged with the trunk immediately. I hope we don't have large ones ;-). Thanks. - Venkat On 6/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: Yes... I guess it should be possible to have them. I'd say, at the least that we have a readme that describes the demo layout, what its intent is and how you get to run it. I guess this is something we have already done for the samples. - Venkat On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon Would it be possible to have the demos in the release? What do we need to do to make it happen? Thanks. -- Jean-Sebastien I'll contribute the README for the Bigbank demo. Hope to have it by tomorrow. The Bigbank demo uses the implementation-resource extension, which makes it much easier to package and run as it doesn't need to be packaged in a WAR anymore, so if bigbank-demo is included and implementation-resource needs to be as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Venkat I fixed up the remaining project version numbers and I've corrected the port numbers in the aggregator demo in the 0.91 branch. I get a clean build and the alert aggregator work for me now. There is a REAMDE for the alert-aggregator. Regards Simon
Re: 0.91 release?
Yes... I guess it should be possible to have them. I'd say, at the least that we have a readme that describes the demo layout, what its intent is and how you get to run it. I guess this is something we have already done for the samples. - Venkat On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon Would it be possible to have the demos in the release? What do we need to do to make it happen? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Hi Simon, the aggregator demo seemed to throw classdefnotfound exception for javax.servlet. ServletException. I guess it would be good to release the demos to give people a better feel of how things work. - Venkat On 6/21/07, Simon Laws [EMAIL PROTECTED] wrote: I can speak for the following binding-jms - Works for sychronous, Java object based messages and implements a part of the spec but not all of it. So it depends on how comfortable we are with spec incomplete bindings. I would leave it out for now binding-sca - part of the distributed runtime. All checked in now with a working sample but uses binding-jms (as there is a lack of point to point protocols that I can leverage without change). Am just writing mail now to describe what I've been up to and now you've taken the branch I'll put it in the build. Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon
Re: 0.91 release?
On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip as long as something works, I'm not sure why we would exclude it from a Tuscany release. I think we need a bit more clarity about what it means to include something in the release. Is it just having the code included in the src distro, or included in the src distro as part of the build, or also included in the binary distro, or included in both distro's along with itests, samples, readme's or web site doc, and mention of the new thing in the release notes? From the 0.90 release things were pulled out for not being quite there, a lot of the time spent before the final release artifacts got done was because people reviewing the distro's wanted all things up to a certain standard. Getting all this done can take a lot of work. Last minute changes often cause unexpected blocking problems in the distributions resulting in respins and more delay. If we just include everything that works is someone reviewing a release RC going to complain that some new sample is missing a readme, that a demo should have an Ant build script, or that some new extension doesn't even have a sample? If things must be of a certain standard then I don't think its reasonable to expect the release manager to do all the work to get things there. How about: - by default everything is kept in the src distro unless there's some reason not to - only the things mentioned on the release wiki page get included in the build, binary distribution, and mentioned in the release notes - after the brn is cut we need to ask on the ML before adding new things to the wiki release page - adding something to the wiki release page implies some commitment to help get it to the required standard in line with the release schedule. ...ant
Re: 0.91 release?
Hi, I have cut a branch for the 0.91 release and have changed over the artifact versions to 0.91-incubating-SNAPSHOT. I am now trying to build it and here are some problems that I have observed. - The SDO dependency seems to be on the current 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl and sdo-lib that are being used as dependencies in the SDO Databinding. This does not match with the last sdo release of 1.0-incubating-beta1. So how are we going to go forward with the SDO dependency for this SCA release? Are we going to roll back things to beta1 (which is not something I'd be happy about) or should we consider using a snapshot from the trunk (which is also something that we have decided not to do) or is there another alternative to this? Could people please help in this. Thanks - Venkat On 6/19/07, Simon Nash [EMAIL PROTECTED] wrote: I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. Simon Venkata Krishnan wrote: Hi Luciano, This is a surprise :)... I was planning on taking the 0.91 brn tomorrow and imediately start getting out RCs to vote on, but I can't do that if it needs to include the DAS beta1 release???. What do people think? - Venkat On 6/18/07, Luciano Resende [EMAIL PROTECTED] wrote: Sorry, I'm having some restricted internet access as I'm traveling since last week... that's probably why we haven't created a DAS release candidate yet... but the community and I think that we are ready to have one. Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the following items: - implementation.das - implementation.data - some samples (maybe including the samples we didn't ship in 0.9) On 6/18/07, Simon Nash [EMAIL PROTECTED] wrote: What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91 have this DAS release as a dependency? Simon Luciano Resende wrote: I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work
Re: 0.91 release?
On 6/20/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have cut a branch for the 0.91 release and have changed over the artifact versions to 0.91-incubating-SNAPSHOT. I am now trying to build it and here are some problems that I have observed. - The SDO dependency seems to be on the current 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl and sdo-lib that are being used as dependencies in the SDO Databinding. This does not match with the last sdo release of 1.0-incubating-beta1 . So how are we going to go forward with the SDO dependency for this SCA release? Are we going to roll back things to beta1 (which is not something I'd be happy about) or should we consider using a snapshot from the trunk (which is also something that we have decided not to do) or is there another alternative to this? Could people please help in this. Thanks - Venkat On 6/19/07, Simon Nash [EMAIL PROTECTED] wrote: I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. Simon Venkata Krishnan wrote: Hi Luciano, This is a surprise :)... I was planning on taking the 0.91 brn tomorrow and imediately start getting out RCs to vote on, but I can't do that if it needs to include the DAS beta1 release???. What do people think? - Venkat On 6/18/07, Luciano Resende [EMAIL PROTECTED] wrote: Sorry, I'm having some restricted internet access as I'm traveling since last week... that's probably why we haven't created a DAS release candidate yet... but the community and I think that we are ready to have one. Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the following items: - implementation.das - implementation.data - some samples (maybe including the samples we didn't ship in 0.9) On 6/18/07, Simon Nash [EMAIL PROTECTED] wrote: What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91have this DAS release as a dependency? Simon Luciano Resende wrote: I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txthttp://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also
Re: 0.91 release?
Hi, I guess the changes after beta1 are to do with some restructuring of classes across packages. Also when I rolled back the SDO DB back to beta1, it seems to build fine with just changes to the package names it was using. So seems like beta1 seems ok for SDO Databinding. Let me do the same for the others and get back. - Venkat On 6/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 6/20/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have cut a branch for the 0.91 release and have changed over the artifact versions to 0.91-incubating-SNAPSHOT. I am now trying to build it and here are some problems that I have observed. - The SDO dependency seems to be on the current 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl and sdo-lib that are being used as dependencies in the SDO Databinding. This does not match with the last sdo release of 1.0-incubating-beta1 . So how are we going to go forward with the SDO dependency for this SCA release? Are we going to roll back things to beta1 (which is not something I'd be happy about) or should we consider using a snapshot from the trunk (which is also something that we have decided not to do) or is there another alternative to this? Could people please help in this. Thanks - Venkat On 6/19/07, Simon Nash [EMAIL PROTECTED] wrote: I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. Simon Venkata Krishnan wrote: Hi Luciano, This is a surprise :)... I was planning on taking the 0.91 brn tomorrow and imediately start getting out RCs to vote on, but I can't do that if it needs to include the DAS beta1 release???. What do people think? - Venkat On 6/18/07, Luciano Resende [EMAIL PROTECTED] wrote: Sorry, I'm having some restricted internet access as I'm traveling since last week... that's probably why we haven't created a DAS release candidate yet... but the community and I think that we are ready to have one. Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the following items: - implementation.das - implementation.data - some samples (maybe including the samples we didn't ship in 0.9) On 6/18/07, Simon Nash [EMAIL PROTECTED] wrote: What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91have this DAS release as a dependency? Simon Luciano Resende wrote: I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt http://people.apache.org
Re: 0.91 release?
Hi, I have the branch building modules, itests, samples and demos (sans the aggregator). I have rolled back the SDO dependencies to the beta1 release in the branch. Now I'd like to figure out the modules that we intend to actually include in this release. Here is a list of the modules that were a part of the trunks build, this morning when I cut the branch and are additions over what we already had for Rel. 0.90. - binding-jms - binding-ajax - binding-ejb - binding-feed - databinding-json - extension-helper - implementation-bpel - implementation-resource - implementation-spring - topology - topology-xml Out of these I know for sure from the wiki ( http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents) that we are going to include the following. The extensions that depend on DAS are not going to be a part of this release and am excluding them though they have been specifed in the wiki. - binding-ajax - extension-helper What do people think about the others. IMHO, I guess we could include the following - binding-ejb - binding-feed - implementation-spring There are a whole lot of others as well on the trunk which are presently not a part of the build but interesting though : - binding-sca - binding-osgi - implementation-osgi - the geronimo integration - implementation-bpel I am really not sure where we are with these but just about feel that they are not ready for the release round the corner as they are not yet a part of the trunk build as of this morning. However I'd like to know if there are other opinions on this. I hope to finalize on this list today so that I may start working on the distributions tomorrow. Also, please feel free to point out anything that I might have missed out on all of this. Thanks - Venkat On 6/20/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I guess the changes after beta1 are to do with some restructuring of classes across packages. Also when I rolled back the SDO DB back to beta1, it seems to build fine with just changes to the package names it was using. So seems like beta1 seems ok for SDO Databinding. Let me do the same for the others and get back. - Venkat On 6/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 6/20/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I have cut a branch for the 0.91 release and have changed over the artifact versions to 0.91-incubating-SNAPSHOT. I am now trying to build it and here are some problems that I have observed. - The SDO dependency seems to be on the current 1.0-incubating-SNAPSHOTversion from the trunk and there is sdo-impl and sdo-lib that are being used as dependencies in the SDO Databinding. This does not match with the last sdo release of 1.0-incubating-beta1 . So how are we going to go forward with the SDO dependency for this SCA release? Are we going to roll back things to beta1 (which is not something I'd be happy about) or should we consider using a snapshot from the trunk (which is also something that we have decided not to do) or is there another alternative to this? Could people please help in this. Thanks - Venkat On 6/19/07, Simon Nash [EMAIL PROTECTED] wrote: I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. Simon Venkata Krishnan wrote: Hi Luciano, This is a surprise :)... I was planning on taking the 0.91 brn tomorrow and imediately start getting out RCs to vote on, but I can't do that if it needs to include the DAS beta1 release???. What do people think? - Venkat On 6/18/07, Luciano Resende [EMAIL PROTECTED] wrote: Sorry, I'm having some restricted internet access as I'm traveling since last week... that's probably why we haven't created a DAS release candidate yet... but the community and I think that we are ready to have one. Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the following items: - implementation.das - implementation.data - some samples (maybe including the samples we didn't ship in 0.9) On 6/18/07, Simon Nash [EMAIL PROTECTED] wrote: What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91have this DAS release as a dependency? Simon
Re: 0.91 release?
I can speak for the following binding-jms - Works for sychronous, Java object based messages and implements a part of the spec but not all of it. So it depends on how comfortable we are with spec incomplete bindings. I would leave it out for now binding-sca - part of the distributed runtime. All checked in now with a working sample but uses binding-jms (as there is a lack of point to point protocols that I can leverage without change). Am just writing mail now to describe what I've been up to and now you've taken the branch I'll put it in the build. Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon
Re: 0.91 release?
The extensions that depend on DAS are not going to be a part of this release and am excluding them though they have been specifed in the wiki. Thanks, I have removed these items from the wiki already... On 6/20/07, Simon Laws [EMAIL PROTECTED] wrote: I can speak for the following binding-jms - Works for sychronous, Java object based messages and implements a part of the spec but not all of it. So it depends on how comfortable we are with spec incomplete bindings. I would leave it out for now binding-sca - part of the distributed runtime. All checked in now with a working sample but uses binding-jms (as there is a lack of point to point protocols that I can leverage without change). Am just writing mail now to describe what I've been up to and now you've taken the branch I'll put it in the build. Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon -- 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: 0.91 release?
[snip] Simon Laws wrote: Are we releasing the demos this time? Were you sans aggregator because there is a problem with it? I can go fix it if so. I know I should go try it but I haven't checked the branch out yet;-) Simon Would it be possible to have the demos in the release? What do we need to do to make it happen? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Simon Nash wrote: I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. +1 An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. I'm trying to understand this thought. Here are some of our technology dependencies: binding-ws - Axis2 binding-jms - ActiveMQ binding-feed - Rome databinding-sdo - SDO binding-jsonrpc - json implementation-das - DAS implementation-bpel - ODE implementation-spring - Spring implementation-osgi - Equinox databinding-xmlbeans - XMLBeans databinding-jaxb - JAXB binding-ejb - Geronimo http-jetty - Jetty http-tomcat - Tomcat tuscany-core - J2SE 5.0 :) and woodstox I know that many combinations are possible, but as long as something works, I'm not sure why we would exclude it from a Tuscany release. Which ones are you proposing to pick out and not include in a Tuscany SCA release? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Hi Luciano, This is a surprise :)... I was planning on taking the 0.91 brn tomorrow and imediately start getting out RCs to vote on, but I can't do that if it needs to include the DAS beta1 release???. What do people think? - Venkat On 6/18/07, Luciano Resende [EMAIL PROTECTED] wrote: Sorry, I'm having some restricted internet access as I'm traveling since last week... that's probably why we haven't created a DAS release candidate yet... but the community and I think that we are ready to have one. Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the following items: - implementation.das - implementation.data - some samples (maybe including the samples we didn't ship in 0.9) On 6/18/07, Simon Nash [EMAIL PROTECTED] wrote: What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91 have this DAS release as a dependency? Simon Luciano Resende wrote: I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work to get done. I'd started a wiki page for 0.91 at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents ...ant On 6/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote: +1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - 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
Re: 0.91 release?
I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. Simon Venkata Krishnan wrote: Hi Luciano, This is a surprise :)... I was planning on taking the 0.91 brn tomorrow and imediately start getting out RCs to vote on, but I can't do that if it needs to include the DAS beta1 release???. What do people think? - Venkat On 6/18/07, Luciano Resende [EMAIL PROTECTED] wrote: Sorry, I'm having some restricted internet access as I'm traveling since last week... that's probably why we haven't created a DAS release candidate yet... but the community and I think that we are ready to have one. Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the following items: - implementation.das - implementation.data - some samples (maybe including the samples we didn't ship in 0.9) On 6/18/07, Simon Nash [EMAIL PROTECTED] wrote: What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91 have this DAS release as a dependency? Simon Luciano Resende wrote: I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt http://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work to get done. I'd started a wiki page for 0.91 at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents ...ant On 6/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote
Re: 0.91 release?
What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91 have this DAS release as a dependency? Simon Luciano Resende wrote: I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txthttp://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work to get done. I'd started a wiki page for 0.91 at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents ...ant On 6/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote: +1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Sorry, I'm having some restricted internet access as I'm traveling since last week... that's probably why we haven't created a DAS release candidate yet... but the community and I think that we are ready to have one. Yes, the idea is to have a DAS beta1 dependency on SCA 0.91 on the following items: - implementation.das - implementation.data - some samples (maybe including the samples we didn't ship in 0.9) On 6/18/07, Simon Nash [EMAIL PROTECTED] wrote: What will be the relationship between SCA 0.91 and DAS? I have seen some discussions on the list about a DAS release. Will SCA 0.91 have this DAS release as a dependency? Simon Luciano Resende wrote: I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txthttp://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work to get done. I'd started a wiki page for 0.91 at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents ...ant On 6/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote: +1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - 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: 0.91 release?
Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work to get done. I'd started a wiki page for 0.91 at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents ...ant On 6/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote: +1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - 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: 0.91 release?
I have updated the wiki [1] page with things that I'm working on, and would like to have in 0.91 . As for the implementation.das question regarding it's canned derby db, we recently created a db utility to create and populate the database, and I have plans to integrate with it. [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents On 6/16/07, ant elder [EMAIL PROTECTED] wrote: Wow 571 license problems! after being clean for 0.90 just a month ago. One question this brings up is what is actually intended to be included in 0.91? There's been quite a few new extensions and demo's etc added recently but no one has said they want those included in 0.91. Should they be by default or should we just include things that are mentioned on the release wiki page? If so anyone else care to help clean things up, add missing license headers, check the distribution works and includes dependencies etc? The implementation.das is including an entire database in the src, is there any way that could be generated by the tests? ...ant On 6/16/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks Ant. So could we all please use this wiki page to put down things that are going to be increments over 0.90. Also I run the RAT on the trunk - just java/sca and here is the report. I intend to go and fix the missing headers just ahead of cutting the branch. Before that if anybody would like to jump in and help with this, please feel free do so. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txthttp://people.apache.org/%7Esvkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/14/07, ant elder [EMAIL PROTECTED] wrote: Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work to get done. I'd started a wiki page for 0.91 at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents ...ant On 6/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote: +1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - 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] -- 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: 0.91 release?
Taking a branch around the 20th sounds ok to me. The high level things I'm focusing on for the 0.91 release are: - Simplification of using script components (working without .componentType side files) - First cut of the simpler binding/implementation SPI - clean up of ajax and jsonrpc bindings - The EJB binding I'd also said to someone on the user list I'd get WS services without wsdl working so will try to do that as well. Most of the code for those is close-ish to being done, though there's still a whole lot of related sample work to get done. I'd started a wiki page for 0.91 at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents ...ant On 6/13/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote: +1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - 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: 0.91 release?
Thanks for the faith and encouragement. This is going to be my first experience and I am sure of getting all the help from you folks to pull this off successfully. So, to start with, I propose to cut a branch around June 20th, 2007. If people are ok with this, then all that we'd like to be a part of 0.91 should get in by then (June 20th, 2007). Does that work fine with everybody? Also, I'd also like to list down the significant additions / enhancements over 0.90 for the Release Notes. You can state the item here on this thread and I will take care of recording it. - Venkat On 6/13/07, Simon Nash [EMAIL PROTECTED] wrote: +1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - 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: 0.91 release?
Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon
Re: 0.91 release?
Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
+1 from me too. I'm sure Venkat will do a fine job. Simon Jean-Sebastien Delfino wrote: Simon Laws wrote: Yeah, Venkat did loads on the last release. +1 from me for Venkat as 0.91 RM Simon +1 from me - 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: 0.91 release?
So we haven't come back to this for a few days. I guess one of the first things we need to do is get a release manager lined up so we can start pulling the list of release content together with some focus. Any volunteers? Simon
Re: 0.91 release?
On 6/11/07, Simon Laws [EMAIL PROTECTED] wrote: So we haven't come back to this for a few days. I guess one of the first things we need to do is get a release manager lined up so we can start pulling the list of release content together with some focus. Any volunteers? I was going to volunteer but then I remembered how much help Venkat was on the 0.90 release. I've just asked and he (a little nervously :)) said ok so here's my +1 for Venkat as 0.91 RM. ..ant
Re: 0.91 release?
ant elder wrote: With the 0.90 release almost out how about starting on 0.91? Its been almost 3 weeks since the code chill for 0.90, be good if we could start doing releases much more regularly and 4 - 6 weeks for a small point release seems good to me, so how about aiming for cutting an 0.91 branch in a week or 2? The main things I'd like to get out are the improvements to the scripting scripting support with optional .componentType sidefiles and dynamic interfaces, and the ajax binding and jsonrpc binding simplification and unification. With those, the new feed binding and the port of the aggregator sample that would give 0.91 a sort of web20/scripting focus, and doing it quick like this should make it relatively easy to get done by using the trunk stability from 0.90. ...ant In addition to what you listed here, I looked at your next release work items list at [1] and there are a few other items from that list + some that were not in your list that I'd like to get into the next release: [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18127.html Web Service binding - work without pre-existing wsdl doc - async - Fix open jira's about ?wsdl and endpoint url - get the Axis2 REST support to work, I tried today and I think that our TuscanyServlet blocks it WebApp - ability to serve HTML files when we embed Jetty or Tomcat Binding-JMS - get going again, I think it's starting to work again as Simon is using it for his SCA domain experiments Spring container - get it going again, Mike Edwards seems to have made good progress at getting it working again, from what I can see in his recent commit SCA Assembly and Domain - include some what Simon Laws has started to allow components to be in multiple runtimes - a number of detail fixes and improvements, support for multiple bindings on references for example - support for import/export in SCA contributions Distributions - don't want to always distribute *everything* - maybe distributions targeting each runtime and you can ± extensions when you build the distro? Java SCA APIs - add missing APIs like RequestContext - would be good to get a first cut of some conversational support Most of this can be done relatively quickly, so having the next release in 4/6 weeks sounds good to me. I agree with you that we should have much more frequent releases from now on, as our SPIs and core are now stable and we're starting to see good progress with extensions. So, we could cut a new branch soon (I'd suggest in 2 or 2.5 weeks rather than 1 week), and having the release branch in place will allow us to decide for each feature or bug fix if we keep it in trunk only (because it's likely to not be ready for that release) or trunk + the branch. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
[snip] Raymond Feng wrote: One thought: would it be possible that we add such features to 0.90 branch instead of creating a new one out of the trunk? I'm not sure, I was thinking about the following: - leave the 0.90 release branch where it is - merge into the trunk the few last minute changes that have been made in the 0.90 branch only - work in trunk from now on - cut a new 0.91 release branch from trunk when we are happy to do so - then continue to work in trunk, have the 0.91 release manager look after the release branch and let people merge small controlled fixes and changes into that branch - release 0.91 Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
+1 for leaving 0.90 as it is and for cutting the 0.91 branch from trunk when the time comes. I think it will be confusing if we start developing new release content on 0.90 in parallel with changes in trunk. Branching the next release from trunk also encourages us to try and keep head building. Simon
Re: 0.91 release?
+1 to leave 0.90 as-is and continue on the trunk. Initially, my impression was 0.91 is just a small patch over 0.90 and now I don't think that's the case. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, June 01, 2007 4:05 PM Subject: Re: 0.91 release? [snip] Raymond Feng wrote: One thought: would it be possible that we add such features to 0.90 branch instead of creating a new one out of the trunk? I'm not sure, I was thinking about the following: - leave the 0.90 release branch where it is - merge into the trunk the few last minute changes that have been made in the 0.90 branch only - work in trunk from now on - cut a new 0.91 release branch from trunk when we are happy to do so - then continue to work in trunk, have the 0.91 release manager look after the release branch and let people merge small controlled fixes and changes into that branch - release 0.91 Thoughts? -- Jean-Sebastien - 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: 0.91 release?
+1 for releasing often, and I agree with Sebastien that we should continue developing in trunk, and when we are ready, cut a branch and release from there, similar to the process we just did for .90 I'm also interested in working on some data extensions, and some improving on the contribution services. BTW, should we summarize these items on the wiki ? I think I remember we created a page for that, but I couldn't find it easily. On 6/1/07, Simon Laws [EMAIL PROTECTED] wrote: +1 for leaving 0.90 as it is and for cutting the 0.91 branch from trunk when the time comes. I think it will be confusing if we start developing new release content on 0.90 in parallel with changes in trunk. Branching the next release from trunk also encourages us to try and keep head building. Simon -- 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]
0.91 release?
With the 0.90 release almost out how about starting on 0.91? Its been almost 3 weeks since the code chill for 0.90, be good if we could start doing releases much more regularly and 4 - 6 weeks for a small point release seems good to me, so how about aiming for cutting an 0.91 branch in a week or 2? The main things I'd like to get out are the improvements to the scripting scripting support with optional .componentType sidefiles and dynamic interfaces, and the ajax binding and jsonrpc binding simplification and unification. With those, the new feed binding and the port of the aggregator sample that would give 0.91 a sort of web20/scripting focus, and doing it quick like this should make it relatively easy to get done by using the trunk stability from 0.90. ...ant
Re: 0.91 release?
It's good to do more frequent releases than we did in the past. I'm not sure about cutting a branch only a week or 2 after delivering the previous release. Maybe we should let 0.90 get out there and give it enough time for people to download and use it and give their reactions, so that we have some user feedback on 0.90 before we decide what should be in the next release. Simon ant elder wrote: With the 0.90 release almost out how about starting on 0.91? Its been almost 3 weeks since the code chill for 0.90, be good if we could start doing releases much more regularly and 4 - 6 weeks for a small point release seems good to me, so how about aiming for cutting an 0.91 branch in a week or 2? The main things I'd like to get out are the improvements to the scripting scripting support with optional .componentType sidefiles and dynamic interfaces, and the ajax binding and jsonrpc binding simplification and unification. With those, the new feed binding and the port of the aggregator sample that would give 0.91 a sort of web20/scripting focus, and doing it quick like this should make it relatively easy to get done by using the trunk stability from 0.90. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
I think it really helps to have a bit of focus and something to aim for, so how about something a bit more specific? The longer the trunk goes between releases the harder and more time consuming it is to get it ready for another release. Its already been two weeks since the 0.90 branch was taken. On top of that it takes about two weeks just polishing and voting once a branch is taken. I proposed another week or two from now before taking a branch as I think thats plenty of time to get the things I'd like to release ready, if thats too quick how long should it be? ...ant On 5/31/07, Simon Nash [EMAIL PROTECTED] wrote: It's good to do more frequent releases than we did in the past. I'm not sure about cutting a branch only a week or 2 after delivering the previous release. Maybe we should let 0.90 get out there and give it enough time for people to download and use it and give their reactions, so that we have some user feedback on 0.90 before we decide what should be in the next release. Simon ant elder wrote: With the 0.90 release almost out how about starting on 0.91? Its been almost 3 weeks since the code chill for 0.90, be good if we could start doing releases much more regularly and 4 - 6 weeks for a small point release seems good to me, so how about aiming for cutting an 0.91 branch in a week or 2? The main things I'd like to get out are the improvements to the scripting scripting support with optional .componentType sidefiles and dynamic interfaces, and the ajax binding and jsonrpc binding simplification and unification. With those, the new feed binding and the port of the aggregator sample that would give 0.91 a sort of web20/scripting focus, and doing it quick like this should make it relatively easy to get done by using the trunk stability from 0.90. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Hi, I agree with Simon that it seems to be a bit rush to have the next release in one or two weeks. Getting user feedback from 0.90 release and figuring out what's next would take some time. But if we have specifc features that can be achieved soon, I'm OK with it. One thought: would it be possible that we add such features to 0.90 branch instead of creating a new one out of the trunk? Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, May 31, 2007 5:10 AM Subject: Re: 0.91 release? It's good to do more frequent releases than we did in the past. I'm not sure about cutting a branch only a week or 2 after delivering the previous release. Maybe we should let 0.90 get out there and give it enough time for people to download and use it and give their reactions, so that we have some user feedback on 0.90 before we decide what should be in the next release. Simon ant elder wrote: With the 0.90 release almost out how about starting on 0.91? Its been almost 3 weeks since the code chill for 0.90, be good if we could start doing releases much more regularly and 4 - 6 weeks for a small point release seems good to me, so how about aiming for cutting an 0.91 branch in a week or 2? The main things I'd like to get out are the improvements to the scripting scripting support with optional .componentType sidefiles and dynamic interfaces, and the ajax binding and jsonrpc binding simplification and unification. With those, the new feed binding and the port of the aggregator sample that would give 0.91 a sort of web20/scripting focus, and doing it quick like this should make it relatively easy to get done by using the trunk stability from 0.90. ...ant - 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]
