Re: SCA 2.0, was Re: Next SCA release
I was thinking about a branch to make it clear that it was shared and that this work was open to all, but I'm also happy to see that work start in shared sandboxes. I guess from whats been said so far then I'd favour using sandboxes for now for specific work that really can't be done in trunk, and where ever possible continue to use trunk to do what can be done there (looking at that list of examples i think we could find ways to do a lot in trunk). ...ant
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: I was thinking about a branch to make it clear that it was shared and that this work was open to all, but I'm also happy to see that work start in shared sandboxes. I guess from whats been said so far then I'd favour using sandboxes for now for specific work that really can't be done in trunk, and where ever possible continue to use trunk to do what can be done there (looking at that list of examples i think we could find ways to do a lot in trunk). I also think that many of these could be done in trunk. It would be good to talk about each of these and come to a conclusion on what the options are for a solution, and whether or not these proposed options can be implemented in trunk. Simon
Re: SCA 2.0, was Re: Next SCA release
On Wed, May 14, 2008 at 11:01 AM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon It doesn't really make a difference for me: just 2 folders, one for 1.x one for 2.0, and just make clear which one is which and what's its purpose. I'm fine with whatever option people prefer: trunk for 2.0 and branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, whatever keeps our community happy. -- Jean-Sebastien Given the amount of activity we have going on in trunk at the moment, I would support 1.x remaining as trunk and cutting a branch to allow for more innovative (read breaking) development in a 2.0 code stream. Simon It sounds like I (and a lot of the other committers) are going to be quite busy developing the current trunk for the next couple of months and that will make it difficult to participate fully in what happens in a parallel branch. Can this new work really not happen in trunk? Whats changed to make all the comments at the bottom of [1] no longer relevant? ...ant [1] http://apache.markmail.org/message/7ksuvizroitpafnp
Re: SCA 2.0, was Re: Next SCA release
On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon It doesn't really make a difference for me: just 2 folders, one for 1.x one for 2.0, and just make clear which one is which and what's its purpose. I'm fine with whatever option people prefer: trunk for 2.0 and branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, whatever keeps our community happy. -- Jean-Sebastien Given the amount of activity we have going on in trunk at the moment, I would support 1.x remaining as trunk and cutting a branch to allow for more innovative (read breaking) development in a 2.0 code stream. Simon
Re: SCA 2.0, was Re: Next SCA release
+1 to Simon's view point. I also see this good from one of our earlier objective to keep our trunk stable. I'd prefer that we evolve the (potentially breaking) changes that we want to do in our road to 2.0 initially in a branch. Just a worry - would it be challenging to keep the branch and trunk in sync from a feature enhancements perspective. i.e. if there are some feature enhancements that go into the trunk then we have to ensure that equivalent ones go into the branch smoothly riding over the changes that have happened in there. - Venkat On Wed, May 14, 2008 at 3:31 PM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon It doesn't really make a difference for me: just 2 folders, one for 1.x one for 2.0, and just make clear which one is which and what's its purpose. I'm fine with whatever option people prefer: trunk for 2.0 and branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, whatever keeps our community happy. -- Jean-Sebastien Given the amount of activity we have going on in trunk at the moment, I would support 1.x remaining as trunk and cutting a branch to allow for more innovative (read breaking) development in a 2.0 code stream. Simon
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: [EMAIL PROTECTED] wrote: I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. [EMAIL PROTECTED] wrote: So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? [EMAIL PROTECTED] wrote: It doesn't really make a difference for me: just 2 folders, one for 1.x one for 2.0, and just make clear which one is which and what's its purpose. I'm fine with whatever option people prefer: trunk for 2.0 and branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, whatever keeps our community happy. [EMAIL PROTECTED] wrote: Given the amount of activity we have going on in trunk at the moment, I would support 1.x remaining as trunk and cutting a branch to allow for more innovative (read breaking) development in a 2.0 code stream. +1 that makes sense to me ant elder wrote: It sounds like I (and a lot of the other committers) are going to be quite busy developing the current trunk for the next couple of months and that will make it difficult to participate fully in what happens in a parallel branch. Can this new work really not happen in trunk? Whats changed to make all the comments at the bottom of [1] no longer relevant? ...ant [1] http://apache.markmail.org/message/7ksuvizroitpafnp What's changed is the design discussions that have recently popped up on the list (I gave 9 examples) [2], which IMO will require concrete work including breaking changes, and I think we need a place for that kind of work to happen without breaking the stability of the current code base in trunk. The earlier email you referenced [1] also said this: Many of the items suggested for 2.0 have previously been the subject of discussions that have not been easy to close. Until we have agreement on how to approach these things, I think it's better for 2.0 development to happen in an investigative branch. Doing this will allow us to try different approaches and see which we prefer, without causing a lot of churn to the trunk. That's consistent with my view, and I'm looking for the right Subversion folder to make progress on the 9 mentioned items, hoping that it'll help the community discuss and reach consensus based on concrete work / code. I was thinking about a branch to make it clear that it was shared and that this work was open to all, but I'm also happy to see that work start in shared sandboxes. On a related note, it looks like this is what Adriano and Oscar are doing with the Android port for example. [2] http://marc.info/?l=tuscany-devm=121066365312526 Thoughts? -- Jean-Sebastien
Re: SCA 2.0, was Re: Next SCA release
Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien
Re: SCA 2.0, was Re: Next SCA release
On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym I don't think we should be putting 1.x into maintenance mode now. I'm open to having an exploratory branch for 2.0 that would be used as a place to experiment with new ideas that can't be done in the 1.x trunk because they are too disruptive. If we do this, we'll need to have a clear understanding of what things would be done in the 2.0 branch and what activity would continue in
Re: SCA 2.0, was Re: Next SCA release
Simon Nash wrote: ant elder wrote: On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym I don't think we should be putting 1.x into maintenance mode now. I agree. In my initial email I said 'maintain ... live'. By 'live' I meant that non-breaking changes, evolutions, improvements would still go into 1.x to support our user community and the efforts to help increase adoption of SCA based on that code (tutorials, samples,
Re: SCA 2.0, was Re: Next SCA release
snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon
Re: SCA 2.0, was Re: Next SCA release
Simon Laws wrote: snip I prefer a branch to make it clear that all in the community can work in it, to make it clear that it's accepted by the project, that it's buildable etc, instead of having work buried in the middle of a sandbox together with obsolete or broken stuff, with an unclear status. So you mean a branch for 2.0 (you did say this in your previous post and my eyes skipped over it) and trunk would remain as 1.x ? Simon It doesn't really make a difference for me: just 2 folders, one for 1.x one for 2.0, and just make clear which one is which and what's its purpose. I'm fine with whatever option people prefer: trunk for 2.0 and branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0, whatever keeps our community happy. -- Jean-Sebastien
Re: SCA 2.0, was Re: Next SCA release
Hi, +1 for moving the trunk to 2.0 and working on all the changes that we have been wanted to make to the SPIs, distribution packaging, runtimes etc. +1 for having 1.2 as maintenance branch and keeping it stable. Any improvements keeping this as base could continue on the branch and maybe if our 2.0 release if going to take a while, we could make some 1.2.x sort of minor releases. Since the branch has been cleaned up the release work for these should hopefully be less too. +1 for keeping the same space for the docs but create a separate stream of docs for version 2 specific things. This is 'option 2' in the proposal related to documentation. Thanks - Venkat On Sat, Apr 12, 2008 at 5:34 AM, Luciano Resende [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 3:28 AM, ant elder [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash [EMAIL PROTECTED] wrote: snip +1. Many of the items suggested for 2.0 have previously been the subject of discussions that have not been easy to close. Until we have agreement on how to approach these things, I think it's better for 2.0 development to happen in an investigative branch. Doing this will allow us to try different approaches and see which we prefer, without causing a lot of churn to the trunk. So based on the comments so far I think we should hold off on moving to 2.0 for now. +1, let's get consensus first. That said I'm extremely wary of the having work going on in investigative branches, given Tuscany's history of branches and forks I really really hope this doesn't happen much and we'd instead all try to work together in the trunk. +1 ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. That sounds scary. Are you saying you don't think its the right time for 2.0? No, and I'm not sure about what's not clear in I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. and why it sounds scary. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
Luciano Resende wrote: On Fri, Apr 11, 2008 at 3:28 AM, ant elder [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash [EMAIL PROTECTED] wrote: snip +1. Many of the items suggested for 2.0 have previously been the subject of discussions that have not been easy to close. Until we have agreement on how to approach these things, I think it's better for 2.0 development to happen in an investigative branch. Doing this will allow us to try different approaches and see which we prefer, without causing a lot of churn to the trunk. So based on the comments so far I think we should hold off on moving to 2.0 for now. +1, let's get consensus first. That said I'm extremely wary of the having work going on in investigative branches, given Tuscany's history of branches and forks I really really hope this doesn't happen much and we'd instead all try to work together in the trunk. +1 ...ant After a week away I thought we'd have a clearer picture on this. Yesterday I put together some improvements of the admin app and some of the tutorial modules. I must say I'm a little lost now as to where I should commit that stuff. It's difficult to see where we are in this long thread. Is there a consensus? Can somebody please summarize where we are? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
On Tue, Apr 15, 2008 at 8:29 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip After a week away I thought we'd have a clearer picture on this. Yesterday I put together some improvements of the admin app and some of the tutorial modules. I must say I'm a little lost now as to where I should commit that stuff. Thats easy - to trunk. Development happens in the trunk. ...ant
Re: SCA 2.0, was Re: Next SCA release
On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash [EMAIL PROTECTED] wrote: snip +1. Many of the items suggested for 2.0 have previously been the subject of discussions that have not been easy to close. Until we have agreement on how to approach these things, I think it's better for 2.0 development to happen in an investigative branch. Doing this will allow us to try different approaches and see which we prefer, without causing a lot of churn to the trunk. So based on the comments so far I think we should hold off on moving to 2.0 for now. That said I'm extremely wary of the having work going on in investigative branches, given Tuscany's history of branches and forks I really really hope this doesn't happen much and we'd instead all try to work together in the trunk. ...ant
Re: SCA 2.0, was Re: Next SCA release
On Fri, Apr 11, 2008 at 3:28 AM, ant elder [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash [EMAIL PROTECTED] wrote: snip +1. Many of the items suggested for 2.0 have previously been the subject of discussions that have not been easy to close. Until we have agreement on how to approach these things, I think it's better for 2.0 development to happen in an investigative branch. Doing this will allow us to try different approaches and see which we prefer, without causing a lot of churn to the trunk. So based on the comments so far I think we should hold off on moving to 2.0 for now. +1, let's get consensus first. That said I'm extremely wary of the having work going on in investigative branches, given Tuscany's history of branches and forks I really really hope this doesn't happen much and we'd instead all try to work together in the trunk. +1 ...ant -- 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: SCA 2.0, was Re: Next SCA release
On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. That sounds scary. Are you saying you don't think its the right time for 2.0? I started this discussion to see if there was consensus to move to 2.0, if there's not consensus then we should not do it. The last thing we need is dev going on in multiple branches as happened in the old days. ...ant
Re: SCA 2.0, was Re: Next SCA release
On Thu, Apr 10, 2008 at 8:12 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. That sounds scary. Are you saying you don't think its the right time for 2.0? I started this discussion to see if there was consensus to move to 2.0, if there's not consensus then we should not do it. The last thing we need is dev going on in multiple branches as happened in the old days. ...ant Maybe this means we should consider the trunk to be 1.X and branch for 2.0 at the point at which someone wants to start investigating 2.0. I've been thinking of this 2.0 exercise as investigative in the first instance hence [1]. By that I mean that I would fully expect us to do other 1.X releases before any 2.0 features appear in released form. B.t.w - have copied in the user list as we neglected to do this and this is as much a user discussion as a developer discussion. Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30237.html
Re: SCA 2.0, was Re: Next SCA release
On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 8:12 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. That sounds scary. Are you saying you don't think its the right time for 2.0? I started this discussion to see if there was consensus to move to 2.0, if there's not consensus then we should not do it. The last thing we need is dev going on in multiple branches as happened in the old days. ...ant Maybe this means we should consider the trunk to be 1.X and branch for 2.0 at the point at which someone wants to start investigating 2.0. I've been thinking of this 2.0 exercise as investigative in the first instance hence [1]. By that I mean that I would fully expect us to do other 1.X releases before any 2.0 features appear in released form. B.t.w - have copied in the user list as we neglected to do this and this is as much a user discussion as a developer discussion. Simon Keeping maintenance branches going and porting fixes from trunk back to them seems fine but as has been demonstrated several times in Tuscany's history we are not able to maintain a consensus based approach to development when new development is going on in multiple branches. If we're not ready to make backward compatibility breaking changes to the trunk code then IMHO we should just wait. ...ant
RE: SCA 2.0, was Re: Next SCA release
-Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: 10 April 2008 12:26 To: tuscany-dev@ws.apache.org Subject: Re: SCA 2.0, was Re: Next SCA release On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 8:12 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. That sounds scary. Are you saying you don't think its the right time for 2.0? I started this discussion to see if there was consensus to move to 2.0, if there's not consensus then we should not do it. The last thing we need is dev going on in multiple branches as happened in the old days. ...ant Maybe this means we should consider the trunk to be 1.X and branch for 2.0 at the point at which someone wants to start investigating 2.0. I've been thinking of this 2.0 exercise as investigative in the first instance hence [1]. By that I mean that I would fully expect us to do other 1.X releases before any 2.0 features appear in released form. B.t.w - have copied in the user list as we neglected to do this and this is as much a user discussion as a developer discussion. Simon Keeping maintenance branches going and porting fixes from trunk back to them seems fine but as has been demonstrated several times in Tuscany's history we are not able to maintain a consensus based approach to development when new development is going on in multiple branches. If we're not ready to make backward compatibility breaking changes to the trunk code then IMHO we should just wait. ...ant It all depends on the development focus. I am presuming that: * Version 2.x will be the main focus * Most of the development effort happens on Version 2.x * We will make API changes which means that it will not be backwards compatible with version 1 * Version 1.x will go into maintenance mode. * May get some bug fixes and minor updates If my presumptions are correct then, from my point of view, we should keep the trunk as the most up to date version - i.e. Version 2. Any maintenance for previous Version 1.x release should be done on their own branches. ant also makes an interesting point about timing. Without clear goals and objectives for Version 2.x, perhaps we should hold off on branching. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack [EMAIL PROTECTED] wrote: -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: 10 April 2008 12:26 To: tuscany-dev@ws.apache.org Subject: Re: SCA 2.0, was Re: Next SCA release On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 8:12 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. That sounds scary. Are you saying you don't think its the right time for 2.0? I started this discussion to see if there was consensus to move to 2.0, if there's not consensus then we should not do it. The last thing we need is dev going on in multiple branches as happened in the old days. ...ant Maybe this means we should consider the trunk to be 1.X and branch for 2.0 at the point at which someone wants to start investigating 2.0. I've been thinking of this 2.0 exercise as investigative in the first instance hence [1]. By that I mean that I would fully expect us to do other 1.X releases before any 2.0 features appear in released form. B.t.w - have copied in the user list as we neglected to do this and this is as much a user discussion as a developer discussion. Simon Keeping maintenance branches going and porting fixes from trunk back to them seems fine but as has been demonstrated several times in Tuscany's history we are not able to maintain a consensus based approach to development when new development is going on in multiple branches. If we're not ready to make backward compatibility breaking changes to the trunk code then IMHO we should just wait. ...ant It all depends on the development focus. I am presuming that: * Version 2.x will be the main focus * Most of the development effort happens on Version 2.x * We will make API changes which means that it will not be backwards compatible with version 1 * Version 1.x will go into maintenance mode. * May get some bug fixes and minor updates If my presumptions are correct then, from my point of view, we should keep the trunk as the most up to date version - i.e. Version 2. Any maintenance for previous Version 1.x release should be done on their own branches. ant also makes an interesting point about timing. Without clear goals and objectives for Version 2.x, perhaps we should hold off on branching. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Mark I agree and specifically on your last point this was the basis of my comment about us being in the investigation stage, i.e. working out what our goals are. We definitely don't have a clear view of those at the moment other than the hazy things that we haven't yet clearly articulated. I don't have any feeling that we are in the position to jump into V2.0 development with a view to doing a release any time soon. I would also like to hear some user input on the things that are really important and whether they fall into the category of V2.0 breaking changes or V1.X compatible changes. Regards Simon
Re: SCA 2.0, was Re: Next SCA release
On Thu, Apr 10, 2008 at 4:43 AM, Mark Combellack [EMAIL PROTECTED] wrote: * Version 2.x will be the main focus * Most of the development effort happens on Version 2.x * We will make API changes which means that it will not be backwards compatible with version 1 * Version 1.x will go into maintenance mode. * May get some bug fixes and minor updates If my presumptions are correct then, from my point of view, we should keep the trunk as the most up to date version - i.e. Version 2. Any maintenance for previous Version 1.x release should be done on their own branches. +1 I still think this is the way we should go. As I said in my original proposal, I was expecting community members to have interest in keep maintaining and adding small enhancements to the 1.x branch, we have many users consuming releases from that branch, that might need bug fixes, etc. ant also makes an interesting point about timing. Without clear goals and objectives for Version 2.x, perhaps we should hold off on branching. We have spent a good amount of time to make sure the 1.2 branch is very clean, and working perfectly for the release. With this said, I think it should be considered to be the source for 1.x branch, and we should consider cutting the branch at the moment we have 1.2 out of the door. Mark - 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: SCA 2.0, was Re: Next SCA release
Comments inline. Simon Simon Laws wrote: On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack [EMAIL PROTECTED] wrote: -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: 10 April 2008 12:26 To: tuscany-dev@ws.apache.org Subject: Re: SCA 2.0, was Re: Next SCA release On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 8:12 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. That sounds scary. Are you saying you don't think its the right time for 2.0? I started this discussion to see if there was consensus to move to 2.0, if there's not consensus then we should not do it. The last thing we need is dev going on in multiple branches as happened in the old days. ...ant Maybe this means we should consider the trunk to be 1.X and branch for 2.0 at the point at which someone wants to start investigating 2.0. I've been thinking of this 2.0 exercise as investigative in the first instance hence [1]. By that I mean that I would fully expect us to do other 1.X releases before any 2.0 features appear in released form. This is my expectation as well. B.t.w - have copied in the user list as we neglected to do this and this is as much a user discussion as a developer discussion. Simon Keeping maintenance branches going and porting fixes from trunk back to them seems fine but as has been demonstrated several times in Tuscany's history we are not able to maintain a consensus based approach to development when new development is going on in multiple branches. If we're not ready to make backward compatibility breaking changes to the trunk code then IMHO we should just wait. ...ant It all depends on the development focus. I am presuming that: * Version 2.x will be the main focus * Most of the development effort happens on Version 2.x * We will make API changes which means that it will not be backwards compatible with version 1 * Version 1.x will go into maintenance mode. * May get some bug fixes and minor updates If my presumptions are correct then, from my point of view, we should keep the trunk as the most up to date version - i.e. Version 2. Any maintenance for previous Version 1.x release should be done on their own branches. I don't think we are ready yet to retire the 1.x codebase to the extent that's stated here. Like Sebastien, I plan to work on improvements to the 1.x codebase over the next few weeks. ant also makes an interesting point about timing. Without clear goals and objectives for Version 2.x, perhaps we should hold off on branching. +1. Many of the items suggested for 2.0 have previously been the subject of discussions that have not been easy to close. Until we have agreement on how to approach these things, I think it's better for 2.0 development to happen in an investigative branch. Doing this will allow us to try different approaches and see which we prefer, without causing a lot of churn to the trunk. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Mark I agree and specifically on your last point this was the basis of my comment about us being in the investigation stage, i.e. working out what our goals are. We definitely don't have a clear view of those at the moment other than the hazy things that we haven't yet clearly articulated. I don't have any feeling that we are in the position to jump into V2.0 development with a view to doing a release any time soon. +1. I would also like to hear some user input on the things that are really important and whether they fall into the category of V2.0 breaking changes or V1.X compatible changes. I think this is very important. I'd like to take the current 1.x codebase as far as we can without making breaking changes, and I don't think we have reached that point yet. When we have a list of things that 1. we agree need doing, and how to do them 2. are based on user requirements 3. can't be done in 1.x I think that would be the right time to switch the main project focus over to the 2.0 codebase. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
On Tue, Apr 8, 2008 at 6:57 PM, Dan Becker [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws [EMAIL PROTECTED] wrote: We may need to branch the documentation also. Normally I would suggest that we ask for a new space but as our documentation could not be considered complete for 1.1 and as the suggested first actions are internal restructuring we may find it less onerous to maintain 2.X documents alongside the the 1.X documents with suitable comments to point out where they diverge. Do people have a preference. I wondered about the doc too, if there was a new wiki space for 2.x could it be initially be populated with the existing content? If so then it seems to me like it would be easiest to have the new space than to try point out the differences for each release all in the one space. +1 on versioning and branching the docs and the wikis. Customers on older levels will want to see the proper docs, configs, and samples for their version, and customers on newer levels will want to see proper docs, configs, and samples for their version. We should support them both. (This is also how the Geronimo team is tacking docs and samples.) -- Thanks, Dan Becker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If the concensus is for a completely separate space then it would seem that we need a new space to hold just Java SCA V2 docs (The current site space holds all the pages for all of the Tuscany projects). Maybe we want to reorganize along the same lines as Geronimo e.g. multiple spaces such as Apache Tuscany - our current site wiki Apache Tuscany SCA Java V1 Apache Tuscany SCA Java V2 I still slightly favour creating a V2 Documentation page on the existing wiki and populate it as and when required for the time being though. Simon
Re: Next SCA release
On Tue, Apr 8, 2008 at 8:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant Ant Now discussion of the prospect of moving to 1.X and 2.X releases has moved to a separate thread [1] was your intention to separately start enumerating the burning issues that we feel would be too disruptive in the context of a 1.X release. An issue that has been on my mind is that I think it would be useful to restructure the way that the runtime is started so, instead of relying on the black box ReallySmallRuntime to perform explicit module configuration, we could provide the registry to each module and let it configure itself. Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30209.html
Re: Next SCA release
Was going to start separate threads for each item related to those but do think its helpful to keep a thread going with a high level summary like this. ...ant +1 If we keep this thread going with the high level shopping list and spin of threads for the detail we have a chance of spotting where people have complimentary/conflicting objectives. Simon
Re: SCA 2.0, was Re: Next SCA release
+1 on versioning SCA docs Assuming two versions of SCA Java, I can see that the following page will change to point to two different versions of SCA Java, 1.x and 2.x and their related documentation. http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html Tuscany SCA Java general page would contain general information that would pertain to both versions. So, it might need to change. http://incubator.apache.org/tuscany/sca-java.html On the left navigation of sca-java page, we would have two boxes SCA Java 2.x SCA Java 1.x each would point to their own releases and their own documentations and source code tree. There is a set of documentations under SCA Java that are generic, like development guide. We could share these pages between the two versions. Does this make sense? On 4/9/08, Simon Laws [EMAIL PROTECTED] wrote: On Tue, Apr 8, 2008 at 6:57 PM, Dan Becker [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws [EMAIL PROTECTED] wrote: We may need to branch the documentation also. Normally I would suggest that we ask for a new space but as our documentation could not be considered complete for 1.1 and as the suggested first actions are internal restructuring we may find it less onerous to maintain 2.X documents alongside the the 1.X documents with suitable comments to point out where they diverge. Do people have a preference. I wondered about the doc too, if there was a new wiki space for 2.x could it be initially be populated with the existing content? If so then it seems to me like it would be easiest to have the new space than to try point out the differences for each release all in the one space. +1 on versioning and branching the docs and the wikis. Customers on older levels will want to see the proper docs, configs, and samples for their version, and customers on newer levels will want to see proper docs, configs, and samples for their version. We should support them both. (This is also how the Geronimo team is tacking docs and samples.) -- Thanks, Dan Becker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If the concensus is for a completely separate space then it would seem that we need a new space to hold just Java SCA V2 docs (The current site space holds all the pages for all of the Tuscany projects). Maybe we want to reorganize along the same lines as Geronimo e.g. multiple spaces such as Apache Tuscany - our current site wiki Apache Tuscany SCA Java V1 Apache Tuscany SCA Java V2 I still slightly favour creating a V2 Documentation page on the existing wiki and populate it as and when required for the time being though. Simon
Re: SCA 2.0, was Re: Next SCA release
On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod [EMAIL PROTECTED] wrote: +1 on versioning SCA docs Assuming two versions of SCA Java, I can see that the following page will change to point to two different versions of SCA Java, 1.x and 2.x and their related documentation. http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html Tuscany SCA Java general page would contain general information that would pertain to both versions. So, it might need to change. http://incubator.apache.org/tuscany/sca-java.html On the left navigation of sca-java page, we would have two boxes SCA Java 2.x SCA Java 1.x each would point to their own releases and their own documentations and source code tree. There is a set of documentations under SCA Java that are generic, like development guide. We could share these pages between the two versions. Does this make sense? Generally make sense to me. On the particular question of where to host V2 and V2 docs we have identified 3 choices so far. 1 - [] Put V2 doc changes in V1 pages and mark them as such 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current site wiki 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces Are there other cunning options we need to consider. I'm for option 2 at the current time. Simon How would that option [2] actually work? Lets say I change the way the dwr binding works and want to update the doc for V2, the current wiki page is at http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what would i do for the new v2 page? ...ant
Re: SCA 2.0, was Re: Next SCA release
On Wed, Apr 9, 2008 at 5:03 PM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod [EMAIL PROTECTED] wrote: +1 on versioning SCA docs Assuming two versions of SCA Java, I can see that the following page will change to point to two different versions of SCA Java, 1.x and 2.x and their related documentation. http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html Tuscany SCA Java general page would contain general information that would pertain to both versions. So, it might need to change. http://incubator.apache.org/tuscany/sca-java.html On the left navigation of sca-java page, we would have two boxes SCA Java 2.x SCA Java 1.x each would point to their own releases and their own documentations and source code tree. There is a set of documentations under SCA Java that are generic, like development guide. We could share these pages between the two versions. Does this make sense? Generally make sense to me. On the particular question of where to host V2 and V2 docs we have identified 3 choices so far. 1 - [] Put V2 doc changes in V1 pages and mark them as such 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current site wiki 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces Are there other cunning options we need to consider. I'm for option 2 at the current time. Simon How would that option [2] actually work? Lets say I change the way the dwr binding works and want to update the doc for V2, the current wiki page is at http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what would i do for the new v2 page? ...ant You would make http://incubator.apache.org/tuscany/sca-java-v2-bindingajax.htmlhttp://incubator.apache.org/tuscany/sca-java-bindingajax.html. Copy the existing contents there. Edit them which whatever change you need to make and and then add a link to this page to the V2 index (which I expect will, by default, link to the existing pages). Simon
Re: SCA 2.0, was Re: Next SCA release
1 - [] Put V2 doc changes in V1 pages and mark them as such 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current site wiki 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces Option 2 seems reasonable. Option 3 can be considered in the future if there is a need. It would be good to get user's perspective on all this. On 4/9/08, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 5:03 PM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod [EMAIL PROTECTED] wrote: +1 on versioning SCA docs Assuming two versions of SCA Java, I can see that the following page will change to point to two different versions of SCA Java, 1.x and 2.x and their related documentation. http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html Tuscany SCA Java general page would contain general information that would pertain to both versions. So, it might need to change. http://incubator.apache.org/tuscany/sca-java.html On the left navigation of sca-java page, we would have two boxes SCA Java 2.x SCA Java 1.x each would point to their own releases and their own documentations and source code tree. There is a set of documentations under SCA Java that are generic, like development guide. We could share these pages between the two versions. Does this make sense? Generally make sense to me. On the particular question of where to host V2 and V2 docs we have identified 3 choices so far. 1 - [] Put V2 doc changes in V1 pages and mark them as such 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current site wiki 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces Are there other cunning options we need to consider. I'm for option 2 at the current time. Simon How would that option [2] actually work? Lets say I change the way the dwr binding works and want to update the doc for V2, the current wiki page is at http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what would i do for the new v2 page? ...ant You would make http://incubator.apache.org/tuscany/sca-java-v2-bindingajax.html http://incubator.apache.org/tuscany/sca-java-bindingajax.html. Copy the existing contents there. Edit them which whatever change you need to make and and then add a link to this page to the V2 index (which I expect will, by default, link to the existing pages). Simon
Re: SCA 2.0, was Re: Next SCA release
Simon Laws wrote: I'm +1 on this. Comments in line Simon. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. I propose that we create the branch for 1.x develop directly after 1.2 is out to make clear our intentions. It's not clear if the suggestion here is to create sca-java-1.X or sca-java-1.3. My vote would be for the latter (reserving sca-java-1.2.1 in case we need to address specific concerns in 1.2 that are not subject to ongoing maintenance activities). 1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk? I'm asking because I'm interested in working on some improvements of 1.2 in the next few weeks. This shouldn't delay any 2.0 work however, which can go in parallel. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
haleh mahbod wrote: 1 - [] Put V2 doc changes in V1 pages and mark them as such 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current site wiki 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces Option 2 seems reasonable. Option 3 can be considered in the future if there is a need. It would be good to get user's perspective on all this. +0.5 for options [1], [2] and maybe [3] later :) I'm just saying 0.5 as looking at our current docs as I'm not sure about how people are planning to change them in 2.0. It's a little difficult to discuss a process to manage changes without knowing the extent and nature of the changes :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Next SCA release
With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant
SCA 2.0, was Re: Next SCA release
I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant -- 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: SCA 2.0, was Re: Next SCA release
Yep, this is exactly what i'm was suggesting, was just leaving the name till later :) ...ant On Tue, Apr 8, 2008 at 5:27 PM, Luciano Resende [EMAIL PROTECTED] wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
I'm +1 on this. Comments in line Simon. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. I propose that we create the branch for 1.x develop directly after 1.2 is out to make clear our intentions. It's not clear if the suggestion here is to create sca-java-1.X or sca-java-1.3. My vote would be for the latter (reserving sca-java-1.2.1 in case we need to address specific concerns in 1.2 that are not subject to ongoing maintenance activities). Thoughts ? We may need to branch the documentation also. Normally I would suggest that we ask for a new space but as our documentation could not be considered complete for 1.1 and as the suggested first actions are internal restructuring we may find it less onerous to maintain 2.X documents alongside the the 1.X documents with suitable comments to point out where they diverge. Do people have a preference.
Re: SCA 2.0, was Re: Next SCA release
On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws [EMAIL PROTECTED] wrote: snip We may need to branch the documentation also. Normally I would suggest that we ask for a new space but as our documentation could not be considered complete for 1.1 and as the suggested first actions are internal restructuring we may find it less onerous to maintain 2.X documents alongside the the 1.X documents with suitable comments to point out where they diverge. Do people have a preference. I wondered about the doc too, if there was a new wiki space for 2.x could it be initially be populated with the existing content? If so then it seems to me like it would be easiest to have the new space than to try point out the differences for each release all in the one space. ...ant
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws [EMAIL PROTECTED] wrote: We may need to branch the documentation also. Normally I would suggest that we ask for a new space but as our documentation could not be considered complete for 1.1 and as the suggested first actions are internal restructuring we may find it less onerous to maintain 2.X documents alongside the the 1.X documents with suitable comments to point out where they diverge. Do people have a preference. I wondered about the doc too, if there was a new wiki space for 2.x could it be initially be populated with the existing content? If so then it seems to me like it would be easiest to have the new space than to try point out the differences for each release all in the one space. +1 on versioning and branching the docs and the wikis. Customers on older levels will want to see the proper docs, configs, and samples for their version, and customers on newer levels will want to see proper docs, configs, and samples for their version. We should support them both. (This is also how the Geronimo team is tacking docs and samples.) -- Thanks, Dan Becker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next SCA release distributions
On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1, do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules - tuscany-rmi? Should this be a binding I've checked in a build.xml to the calculator sample that I'm playing with (I took it from M2). But thinking about this if we go with ant builds for this release it would be good if they work for the binary release and the src release. Even if its just the run target. So how to we construct the classpath to make this work. I'm just building th src distro to see if it creats a lib dir but we could do with something like tuscan-sca-manifest to keep the ant script simple. As I'm looking at the calculator sample I'm updating the readme.html. I plan to reinstate sca/doc/css if no one has any objections. Regards Simon
Re: Next SCA release distributions
On 5/2/07, ant elder [EMAIL PROTECTED] wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1 , do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules The idea is that tuscany-sca-manifest.jar is an easy way for users to be able to add tuscany-sca and all the dependencies to their classpath when they have the binary distribution. It only works when its in the same directory as all the other jars so its not distributed out side of the binary distro so i don't think it needs -incubating- in the name, and because its not distributed separately i left off a version number, not sure if thats good or not but it does make the name nice and short. Ok, fair point. The tuscany-sca-all-1.0-incubating-SNAPSHOT.jar is made from combining all the tuscany-sca modules into a single jar. It would get published to the maven repository so needs -incubating- and a version number in the name. The idea
Re: Next SCA release distributions
On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, ant elder [EMAIL PROTECTED] wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1 , do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules The idea is that tuscany-sca-manifest.jar is an easy way for users to be able to add tuscany-sca and all the dependencies to their classpath when they have the binary distribution. It only works when its in the same directory as all the other jars so its not distributed out side of the binary distro so i don't think it needs -incubating- in the name, and because its not distributed separately i left off a version number, not sure if thats good or not but it does make the name nice and short. Ok, fair point. The
Re: Next SCA release distributions
Hi, I believe that it is better to wait until having a more consistent version of what already it is. 2007/5/2, ant elder [EMAIL PROTECTED]: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 5/2/07, ant elder [EMAIL PROTECTED] wrote: On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote: On 4/30/07, ant elder [EMAIL PROTECTED] wrote: Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.examplepackages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1 , do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jarcontaining all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant Hi I just this minute took a fresh update of sca to make ant scripts for the samples. I have some questions... - why does tuscany-sca-manifest.jar not have a version number? - What is intention of tuscany-sca-all I need a classpath with all tuscany jars on. Currently its in tuscany-sca-manifest but it doesn't pick up the dependencies in the modules directory as they are in ../modules The idea is that tuscany-sca-manifest.jar is an easy way for users to be able to add tuscany-sca and all the dependencies to their classpath when they have the binary distribution. It only works when its in the same directory as all the
Re: Next SCA release distributions
[snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next SCA release distributions
On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are right. I didn't spot that. I must be going blind. Agree with the move to using host in the name. Simon
Re: Next SCA release distributions
Simon Laws wrote: On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are right. I didn't spot that. I must be going blind. Agree with the move to using host in the name. Simon Ok, I'll do that rename some time later today then. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next SCA release distributions
On 5/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: - tuscany-rmi? Should this be a binding Yes, would be better as tuscany-binding-rmi. We already have a tuscany-binding-rmi module: the implementation of the RMI binding. The tuscany-rmi module defines an RMI hosting extension point, similar to how the tuscany-http module provides an HTTP host extension point. To make that clear, I'd suggest to rename tuscany-rmi to tuscany-host-rmi and tuscany-http to tuscany-host-http. +1 to changing to tuscany-host-rmi and tuscany-host-http But we also have a tuscany-host-spi and tuscany-host-embedded which have nothing to do with and aren't used by tuscany-host-rmi and tuscany-host-http, could these be renamed to something like tuscany-host-spi be tuscany-runtime-spi and tuscany-host-embedded be tuscany-runtime-embedded? If there's going to be any module name changes then the package name used withing the module will also have to be renamed right? So how about starting to change things to org.apache.tuscany.sca at the same time? And vaguely related, everywhere we have a dependency on tuscany-host-embedded we also have a dependency on tuscany-implementation-java-runtime, how about to simplify things (eg for the sample pom's) we add tuscany-implementation-java-runtime as a dependency in tuscany-host-embedded? ...ant
Re: Next SCA release distributions
ant elder wrote: On 4/29/07, ant elder [EMAIL PROTECTED] wrote: What do we want the Tuscany SCA distribution to look like for the next release? I'll suggest the following straw man as start, please suggest changes. I'm using the name 'beta1' here till we decide on the real name. All the artifacts in the default build would be published to the maven repository, and there'd be two downloadable distributions, a source and binary: tuscany-sca-1.0-beta1.zip tuscany-sca-1.0-beta1.tar.gz tuscany-sca-1.0-beta1-src.zip tuscany-sca-1.0-beta1-src.tar.gz The binary unzips to a directory named tuscany-sca-1.0-beta1 with the following contents: tuscany-sca-1.0-beta1 - DISCLAIMER - LICENSE - NOTICE - release-notes.txt + javadoc - the OSOA SCA API Javadoc - the Tuscany SPI Javadoc + lib - tuscany-sca-beta1.jar (this is all the tuscany-*.jars munged into a single jar) - tuscany-sca-manifest-beta1.jar (this is an empty jar with just a manifest which has all the tuscany and dependent jars in the manifest classpath) - (all the other dependency jars - stax, jetty, axis2 etc) + modules - (each individual Tuscany module jar) + samples - (all the samples) How should the samples work, should there be ant or mvn build scripts for each sample? Should there be pre-build sample jars in the binary distro? The src distro unzips to a directory named tuscany-sca-1.0-beta1-src with the following contents: tuscany-sca-1.0-beta1-src - BUILDING - DISCLAIMER - LICENSE - NOTICE + distribution + itest + modules + samples There's now a sca\distribution folder which has build scritps to create the above to try this out. This should be working now so running mvn in sca\distribution should create the distributions in the sca\distribution\target directory. The binary distro should work to run all the samples, eg, unzip the binary distro somewhere and then change into the directory tuscany-sca-1.0-incubating-SNAPSHOT\samples\calculator and from there you should be able to run a sample with: java -cp target\tuscany-sample-calculator-1.0-incubating-SNAPSHOT.jar ;..\..\lib\tuscany-sca-manifest-1.0-incubating-SNAPSHOT.jar calculator.CalculatorClient ...ant Ant, I built and took a look at the distribution. It looks very good to me. I like the overall structure and the idea of providing as an option a single JAR for Tuscany. I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? - I guess we're going to rename this to sca-1.0-beta1-incubating? - Like you said above, we'll have to include the javadoc for our SPIs. - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? - We have two different servlet-api JARs, should we pick one? - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? - The NOTICE will have to be updated as it contains obsolete dependencies. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. Thanks! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next SCA release distributions
Excellent thanks, thats type type feedback I was looking for! Comments in line... On 4/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ I have a few questions and suggestions. - tuscany-sca.jar contains .svn directories, I guess they should be removed from the JAR. I can't see these, i could just be blind or maybe its something different about our environments could you give an example of what the file names are? - Also 2 empty xsds at the root of the JAR and com.example packages, they must be coming from one of the examples? The com.example.* files are coming from the databinding-jaxb and databinding-sdo modules, we need to fix those modules but I'm not sure how. It looks like the jaxb and sdo plugins need to some way to say they're test resources. Any one know how to fix this? I can't see the 2 empty xsds, something different about our environments again? - I guess we're going to rename this to sca-1.0-beta1-incubating? Yes, the name should be being picked up from the pom, but i'll test it does change. (Using the current format the name would be 1.0-incubating-beta1, do we really want 1.0-beta1-incubating?) - Like you said above, we'll have to include the javadoc for our SPIs. Yes, I guess I can add that in now even though the SPIs aren't done by just including the tuscany-core-spi module javadoc. Is javadoc for just these two modules enough (sca-api and core-spi). I've added this now, are there other modules we want javadoc for? - How did you produce the single META-INF/services/...ModuleActivator file? is it generated? This is done in the java/sca/distribution/bundle project using the Maven Shade plugin, see in the pom.xml the shade config where a Shade AppendingTransformer is used to merge all the ModuleActivator files into one. No doc at all about the Shade plugin that I could find, I got this from looking at the CXF build and the Shade plugin source code. - We have two different servlet-api JARs, should we pick one? Fixed. The 6.0.10 one was coming from the http-tomcat module so i've added exclusions in that pom.xml. - Could we have, in the bin distro, a tuscany-sca-src.jar containing all the source code for the classes in tuscany-sca.jar? Thats a good idea, I'm not sure how though. The tuscany-sca.jar is built from all the dependency elements listed in the distribution/bundle/pom.xml, I could make a src jar by just zipping up everything in sca/modules but it may end up including more than is in the tuscany-sca.jar. Anyone have any better ideas on how to do this? - How about renaming tuscany-sca.jar to tuscany-sca-all.jar, or any name indicating that it's all the tuscany code? OK, done. - The NOTICE will have to be updated as it contains obsolete dependencies. Yep. Over the next days I'll trawl through all the license and notice files to make sure they're correct. - I think it would be great to have Ant build scripts for some of the samples, as not everybody is using Maven. Me too, I'll try to get one going today. Should we have all the samples have both maven and Ant build scripts, or just Ant, or some samples have Ant and others have Maven? - Pre-built sample JARs would be great too, but not as important if we have a simple Ant build for the samples. There are pre-built sample jars in the sample target directory, eg, samples\calculator\target\tuscany- sample-calculator-1.0-incubating-SNAPSHOT.jar I've updated the distribution build scripts with the above changes now. ...ant
Next SCA release distributions
What do we want the Tuscany SCA distribution to look like for the next release? I'll suggest the following straw man as start, please suggest changes. I'm using the name 'beta1' here till we decide on the real name. All the artifacts in the default build would be published to the maven repository, and there'd be two downloadable distributions, a source and binary: tuscany-sca-1.0-beta1.zip tuscany-sca-1.0-beta1.tar.gz tuscany-sca-1.0-beta1-src.zip tuscany-sca-1.0-beta1-src.tar.gz The binary unzips to a directory named tuscany-sca-1.0-beta1 with the following contents: tuscany-sca-1.0-beta1 - DISCLAIMER - LICENSE - NOTICE - release-notes.txt + javadoc - the OSOA SCA API Javadoc - the Tuscany SPI Javadoc + lib - tuscany-sca-beta1.jar (this is all the tuscany-*.jars munged into a single jar) - tuscany-sca-manifest-beta1.jar (this is an empty jar with just a manifest which has all the tuscany and dependent jars in the manifest classpath) - (all the other dependency jars - stax, jetty, axis2 etc) + modules - (each individual Tuscany module jar) + samples - (all the samples) How should the samples work, should there be ant or mvn build scripts for each sample? Should there be pre-build sample jars in the binary distro? The src distro unzips to a directory named tuscany-sca-1.0-beta1-src with the following contents: tuscany-sca-1.0-beta1-src - BUILDING - DISCLAIMER - LICENSE - NOTICE + distribution + itest + modules + samples There's now a sca\distribution folder which has build scritps to create the above to try this out. ...ant
Re: Next SCA release distributions
why not with a sign --M3 ? like this : tuscany-sca-1.0-M3-beta1.zip tuscany-sca-1.0-M3-beta1.tar.gz tuscany-sca-1.0-M3-beta1-src.zip tuscany-sca-1.0-M3-beta1-src.tar.gz 2007/4/29, ant elder [EMAIL PROTECTED]: What do we want the Tuscany SCA distribution to look like for the next release? I'll suggest the following straw man as start, please suggest changes. I'm using the name 'beta1' here till we decide on the real name. All the artifacts in the default build would be published to the maven repository, and there'd be two downloadable distributions, a source and binary: tuscany-sca-1.0-beta1.zip tuscany-sca-1.0-beta1.tar.gz tuscany-sca-1.0-beta1-src.zip tuscany-sca-1.0-beta1-src.tar.gz The binary unzips to a directory named tuscany-sca-1.0-beta1 with the following contents: tuscany-sca-1.0-beta1 - DISCLAIMER - LICENSE - NOTICE - release-notes.txt + javadoc - the OSOA SCA API Javadoc - the Tuscany SPI Javadoc + lib - tuscany-sca-beta1.jar (this is all the tuscany-*.jars munged into a single jar) - tuscany-sca-manifest-beta1.jar (this is an empty jar with just a manifest which has all the tuscany and dependent jars in the manifest classpath) - (all the other dependency jars - stax, jetty, axis2 etc) + modules - (each individual Tuscany module jar) + samples - (all the samples) How should the samples work, should there be ant or mvn build scripts for each sample? Should there be pre-build sample jars in the binary distro? The src distro unzips to a directory named tuscany-sca-1.0-beta1-src with the following contents: tuscany-sca-1.0-beta1-src - BUILDING - DISCLAIMER - LICENSE - NOTICE + distribution + itest + modules + samples There's now a sca\distribution folder which has build scritps to create the above to try this out. ...ant
Re: Next SCA release distributions
On 4/29/07, ant elder [EMAIL PROTECTED] wrote: What do we want the Tuscany SCA distribution to look like for the next release? I'll suggest the following straw man as start, please suggest changes. I'm using the name 'beta1' here till we decide on the real name. All the artifacts in the default build would be published to the maven repository, and there'd be two downloadable distributions, a source and binary: tuscany-sca-1.0-beta1.zip tuscany-sca-1.0-beta1.tar.gz tuscany-sca-1.0-beta1-src.zip tuscany-sca-1.0-beta1-src.tar.gz The binary unzips to a directory named tuscany-sca-1.0-beta1 with the following contents: tuscany-sca-1.0-beta1 - DISCLAIMER - LICENSE - NOTICE - release-notes.txt + javadoc - the OSOA SCA API Javadoc - the Tuscany SPI Javadoc + lib - tuscany-sca-beta1.jar (this is all the tuscany-*.jars munged into a single jar) - tuscany-sca-manifest-beta1.jar (this is an empty jar with just a manifest which has all the tuscany and dependent jars in the manifest classpath) - (all the other dependency jars - stax, jetty, axis2 etc) + modules - (each individual Tuscany module jar) + samples - (all the samples) How should the samples work, should there be ant or mvn build scripts for each sample? Should there be pre-build sample jars in the binary distro? The src distro unzips to a directory named tuscany-sca-1.0-beta1-src with the following contents: tuscany-sca-1.0-beta1-src - BUILDING - DISCLAIMER - LICENSE - NOTICE + distribution + itest + modules + samples There's now a sca\distribution folder which has build scritps to create the above to try this out. This should be working now so running mvn in sca\distribution should create the distributions in the sca\distribution\target directory. The binary distro should work to run all the samples, eg, unzip the binary distro somewhere and then change into the directory tuscany-sca-1.0-incubating-SNAPSHOT\samples\calculator and from there you should be able to run a sample with: java -cp target\tuscany-sample-calculator-1.0-incubating-SNAPSHOT.jar ;..\..\lib\tuscany-sca-manifest-1.0-incubating-SNAPSHOT.jar calculator.CalculatorClient ...ant
Re: Next SCA release distributions
I guess this is the question about what should we call the next release - M3 or beta1 or something else? See: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] ...ant On 4/29/07, 王洪伟 [EMAIL PROTECTED] wrote: why not with a sign --M3 ? like this : tuscany-sca-1.0-M3-beta1.zip tuscany-sca-1.0-M3-beta1.tar.gz tuscany-sca-1.0-M3-beta1-src.zip tuscany-sca-1.0-M3-beta1-src.tar.gz 2007/4/29, ant elder [EMAIL PROTECTED]: What do we want the Tuscany SCA distribution to look like for the next release? I'll suggest the following straw man as start, please suggest changes. I'm using the name 'beta1' here till we decide on the real name. All the artifacts in the default build would be published to the maven repository, and there'd be two downloadable distributions, a source and binary: tuscany-sca-1.0-beta1.zip tuscany-sca-1.0-beta1.tar.gz tuscany-sca-1.0-beta1-src.zip tuscany-sca-1.0-beta1-src.tar.gz The binary unzips to a directory named tuscany-sca-1.0-beta1 with the following contents: tuscany-sca-1.0-beta1 - DISCLAIMER - LICENSE - NOTICE - release-notes.txt + javadoc - the OSOA SCA API Javadoc - the Tuscany SPI Javadoc + lib - tuscany-sca-beta1.jar (this is all the tuscany-*.jars munged into a single jar) - tuscany-sca-manifest-beta1.jar (this is an empty jar with just a manifest which has all the tuscany and dependent jars in the manifest classpath) - (all the other dependency jars - stax, jetty, axis2 etc) + modules - (each individual Tuscany module jar) + samples - (all the samples) How should the samples work, should there be ant or mvn build scripts for each sample? Should there be pre-build sample jars in the binary distro? The src distro unzips to a directory named tuscany-sca-1.0-beta1-srcwith the following contents: tuscany-sca-1.0-beta1-src - BUILDING - DISCLAIMER - LICENSE - NOTICE + distribution + itest + modules + samples There's now a sca\distribution folder which has build scritps to create the above to try this out. ...ant
