Re: Rules for Revolutionaries [was: M2]
If there are no issues I'd like to look at the bigbank sample converting to the new composite spec. Besides the obvious need to change the SCDL, I suppose refactoring the server (account) side to take advantage of the composite nature maybe see if includes can be used too. Was there immediately more that you were thinking of ? Jean-Sebastien Delfino wrote: Simon Nash wrote: Thanks, Sam; this is very helpful. One part in particular of the James Duncan Davidson post caught my eye: jdd 4) The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted. /jdd I think we have failed to follow this guideline over recent weeks. People have submitted patches for the trunk and they have not been applied (or applied to a sandbox instead). Technical discussions have started that in the normal course of events would have led to commits and patches, but these commits and patches have not been forthcoming. This has generally led to progress on the project (except for sandbox activity) being stalled, presumably because people were waiting to see what would happen with the sandbox code. I believe we need to get the project moving forward again. At the present time, we have an evolutionary trunk and a revolutionary sandbox. We should therefore continue (in reality restart) doing evolutionary work on the trunk for the reasons that JDD gives in the quote above. There is evolutionary work that can usefully be done, such as Raymond's work on databindings, the work on interface represenation that Ant and others have been discussing, Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure there are other things too. If at some point there is a revolution, then we will deal with it when it happens and rework existing code as necessary. Revolutionaries can work in the chianti sandbox, or if they prefer a different brand of revolution, they can create another sandbox to do this. The latter is perfectly legitimate according to the Rules for Revolutionaries, and I think it is healthy for the project for people to be able to show their new ideas in the form of code, as long as the project as a whole (i.e., the whole community) keeps moving forward with ongoing work on the trunk and doesn't focus exclusively on what is happening in the sandboxes. Simon Sam Ruby wrote: Jeremy Boynes wrote: Ant I'm disappointed that you have chosen this path. I will ask one more time if you and Sebastien would consider collaborating with those of us working on core2. A while ago, I agreed to be a mentor for this project. I guess it is about time that I start acting like one. If this project ever hopes to exit incubation, it had better start acting like an ASF project. For starters, I suggest that all committers read the Rules for Revolutionaries[1][2][3]. For those who want the Cliff notes version: anybody who wants to work in an evolutionary fashion on the main trunk is welcome to do so. Anybody who wants to work on a revolutionary branch is welcome to do so. Multiple concurrent revolutionary branches are OK too. One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. Something implicit in the R4R document is that the burden of proof is on the revolutionaries. If you would like to see your particular branch merged back onto the trunk, be prepared to demonstrate why your particular branch is not merely better, but necessary. My experience it that the more concrete and the less hand-wavy the argument, the more likely it will be accepted. So, if you chose to believe that scenarios and test cases are optional, just remember, merging your sandbox back to the trunk is optional too. That does not mean that scenarios and test cases are required, but it does mean that if these aren't present, you need to come up with something just as compelling. - Sam Ruby [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf [3] http://marc2.theaimsgroup.com/?l=apache-communitym=105712356508947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Simon, I agree. I'm going to do some work on the samples in the trunk, I'd like to evolve some of them (starting with the Calculator sample and then Bigbank) to start showing some of the concepts in the evolving SCA specification. In addition, I searched through our JIRA backlog and found the following patches, which should be reviewed and
Re: Rules for Revolutionaries [was: M2]
Thanks, Sam; this is very helpful. One part in particular of the James Duncan Davidson post caught my eye: jdd 4) The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted. /jdd I think we have failed to follow this guideline over recent weeks. People have submitted patches for the trunk and they have not been applied (or applied to a sandbox instead). Technical discussions have started that in the normal course of events would have led to commits and patches, but these commits and patches have not been forthcoming. This has generally led to progress on the project (except for sandbox activity) being stalled, presumably because people were waiting to see what would happen with the sandbox code. I believe we need to get the project moving forward again. At the present time, we have an evolutionary trunk and a revolutionary sandbox. We should therefore continue (in reality restart) doing evolutionary work on the trunk for the reasons that JDD gives in the quote above. There is evolutionary work that can usefully be done, such as Raymond's work on databindings, the work on interface represenation that Ant and others have been discussing, Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure there are other things too. If at some point there is a revolution, then we will deal with it when it happens and rework existing code as necessary. Revolutionaries can work in the chianti sandbox, or if they prefer a different brand of revolution, they can create another sandbox to do this. The latter is perfectly legitimate according to the Rules for Revolutionaries, and I think it is healthy for the project for people to be able to show their new ideas in the form of code, as long as the project as a whole (i.e., the whole community) keeps moving forward with ongoing work on the trunk and doesn't focus exclusively on what is happening in the sandboxes. Simon Sam Ruby wrote: Jeremy Boynes wrote: Ant I'm disappointed that you have chosen this path. I will ask one more time if you and Sebastien would consider collaborating with those of us working on core2. A while ago, I agreed to be a mentor for this project. I guess it is about time that I start acting like one. If this project ever hopes to exit incubation, it had better start acting like an ASF project. For starters, I suggest that all committers read the Rules for Revolutionaries[1][2][3]. For those who want the Cliff notes version: anybody who wants to work in an evolutionary fashion on the main trunk is welcome to do so. Anybody who wants to work on a revolutionary branch is welcome to do so. Multiple concurrent revolutionary branches are OK too. One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. Something implicit in the R4R document is that the burden of proof is on the revolutionaries. If you would like to see your particular branch merged back onto the trunk, be prepared to demonstrate why your particular branch is not merely better, but necessary. My experience it that the more concrete and the less hand-wavy the argument, the more likely it will be accepted. So, if you chose to believe that scenarios and test cases are optional, just remember, merging your sandbox back to the trunk is optional too. That does not mean that scenarios and test cases are required, but it does mean that if these aren't present, you need to come up with something just as compelling. - Sam Ruby [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf [3] http://marc2.theaimsgroup.com/?l=apache-communitym=105712356508947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries [was: M2]
I agree with Simon 100%. Its really bad we've let the main trunk lose momentum, we should all start working on it again. I'll start that tomorrow and hope others will come and help. ...ant (and as a sign of good faith and commitment to the main trunk code I've deleted miral) On 7/12/06, Simon Nash [EMAIL PROTECTED] wrote: Thanks, Sam; this is very helpful. One part in particular of the James Duncan Davidson post caught my eye: jdd 4) The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted. /jdd I think we have failed to follow this guideline over recent weeks. People have submitted patches for the trunk and they have not been applied (or applied to a sandbox instead). Technical discussions have started that in the normal course of events would have led to commits and patches, but these commits and patches have not been forthcoming. This has generally led to progress on the project (except for sandbox activity) being stalled, presumably because people were waiting to see what would happen with the sandbox code. I believe we need to get the project moving forward again. At the present time, we have an evolutionary trunk and a revolutionary sandbox. We should therefore continue (in reality restart) doing evolutionary work on the trunk for the reasons that JDD gives in the quote above. There is evolutionary work that can usefully be done, such as Raymond's work on databindings, the work on interface represenation that Ant and others have been discussing, Venkat's RMI binding, and the ongoing work on Java2WSDL. I'm sure there are other things too. If at some point there is a revolution, then we will deal with it when it happens and rework existing code as necessary. Revolutionaries can work in the chianti sandbox, or if they prefer a different brand of revolution, they can create another sandbox to do this. The latter is perfectly legitimate according to the Rules for Revolutionaries, and I think it is healthy for the project for people to be able to show their new ideas in the form of code, as long as the project as a whole (i.e., the whole community) keeps moving forward with ongoing work on the trunk and doesn't focus exclusively on what is happening in the sandboxes. Simon Sam Ruby wrote: Jeremy Boynes wrote: Ant I'm disappointed that you have chosen this path. I will ask one more time if you and Sebastien would consider collaborating with those of us working on core2. A while ago, I agreed to be a mentor for this project. I guess it is about time that I start acting like one. If this project ever hopes to exit incubation, it had better start acting like an ASF project. For starters, I suggest that all committers read the Rules for Revolutionaries[1][2][3]. For those who want the Cliff notes version: anybody who wants to work in an evolutionary fashion on the main trunk is welcome to do so. Anybody who wants to work on a revolutionary branch is welcome to do so. Multiple concurrent revolutionary branches are OK too. One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. Something implicit in the R4R document is that the burden of proof is on the revolutionaries. If you would like to see your particular branch merged back onto the trunk, be prepared to demonstrate why your particular branch is not merely better, but necessary. My experience it that the more concrete and the less hand-wavy the argument, the more likely it will be accepted. So, if you chose to believe that scenarios and test cases are optional, just remember, merging your sandbox back to the trunk is optional too. That does not mean that scenarios and test cases are required, but it does mean that if these aren't present, you need to come up with something just as compelling. - Sam Ruby [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf [3] http://marc2.theaimsgroup.com/?l=apache-communitym=105712356508947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chianti, was: Rules for Revolutionaries [was: M2]
On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote: One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. To resolve this I propose that we move the code from my sandbox to its own location based on a codename. Once I get the build issues resolved, I plan to move the tree from sandbox/jboynes to sandbox/ chianti and will rename the core2 module back to core -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chianti, was: Rules for Revolutionaries [was: M2]
On Jul 11, 2006, at 2:27 PM, Jeremy Boynes wrote: On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote: One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. To resolve this I propose that we move the code from my sandbox to its own location based on a codename. Once I get the build issues resolved, I plan to move the tree from sandbox/jboynes to sandbox/chianti and will rename the core2 module back to core This should now be complete - if you cd to sandbox and svn up chianti you should get a buildable tree. I changed the artifact versions to 1.0-chianti-SNAPSHOT - the 1.0 is only there to keep maven happy by starting the version with a number. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chianti, was: Rules for Revolutionaries [was: M2]
Jeremy, Sorry, I might have missed some previous emails. I am getting the following error consistently with the build, [INFO] [INFO] Building Tuscany JAXB Data Binding [INFO]task-segment: [install] [INFO] Downloading: https://maven-repository.dev.java.net/repository/com.sun.tools.xjc.maven 2/poms/maven-jaxb-plugin-1.0.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: com.sun.tools.xjc.maven2:maven-jaxb-plugin Reason: Error getting POM for 'com.sun.tools.xjc.maven2:maven-jaxb-plugin' from the repository: Error transferring file com.sun.tools.xjc.maven2:maven-jaxb-plugin:pom:1.0 from the specified remote repositories: ibiblio (http://www.ibiblio.org/maven2), central (http://repo1.maven.org/maven2), java.net (https://maven-repository.dev.java.net/repository) Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 23:33 To: tuscany-dev@ws.apache.org Subject: Re: Chianti, was: Rules for Revolutionaries [was: M2] On Jul 11, 2006, at 2:27 PM, Jeremy Boynes wrote: On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote: One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. To resolve this I propose that we move the code from my sandbox to its own location based on a codename. Once I get the build issues resolved, I plan to move the tree from sandbox/jboynes to sandbox/chianti and will rename the core2 module back to core This should now be complete - if you cd to sandbox and svn up chianti you should get a buildable tree. I changed the artifact versions to 1.0-chianti-SNAPSHOT - the 1.0 is only there to keep maven happy by starting the version with a number. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chianti, was: Rules for Revolutionaries [was: M2]
Sometimes the respository is not very stable and you'll see the issues once a while. Retry helps most of the time. Thanks, Raymond - Original Message - From: Meeraj Kunnumpurath [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 11, 2006 5:21 PM Subject: RE: Chianti, was: Rules for Revolutionaries [was: M2] Jeremy, Sorry, I might have missed some previous emails. I am getting the following error consistently with the build, [INFO] [INFO] Building Tuscany JAXB Data Binding [INFO]task-segment: [install] [INFO] Downloading: https://maven-repository.dev.java.net/repository/com.sun.tools.xjc.maven 2/poms/maven-jaxb-plugin-1.0.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: com.sun.tools.xjc.maven2:maven-jaxb-plugin Reason: Error getting POM for 'com.sun.tools.xjc.maven2:maven-jaxb-plugin' from the repository: Error transferring file com.sun.tools.xjc.maven2:maven-jaxb-plugin:pom:1.0 from the specified remote repositories: ibiblio (http://www.ibiblio.org/maven2), central (http://repo1.maven.org/maven2), java.net (https://maven-repository.dev.java.net/repository) Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 23:33 To: tuscany-dev@ws.apache.org Subject: Re: Chianti, was: Rules for Revolutionaries [was: M2] On Jul 11, 2006, at 2:27 PM, Jeremy Boynes wrote: On Jul 10, 2006, at 9:33 AM, Sam Ruby wrote: One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. To resolve this I propose that we move the code from my sandbox to its own location based on a codename. Once I get the build issues resolved, I plan to move the tree from sandbox/jboynes to sandbox/chianti and will rename the core2 module back to core This should now be complete - if you cd to sandbox and svn up chianti you should get a buildable tree. I changed the artifact versions to 1.0-chianti-SNAPSHOT - the 1.0 is only there to keep maven happy by starting the version with a number. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chianti, was: Rules for Revolutionaries [was: M2]
On Jul 11, 2006, at 5:30 PM, Meeraj Kunnumpurath wrote: Thanks Raymond. I tried the build around four or five times. I shall try a few more times. I wiped the Sun plugin from my repo $ rm -rf ~/.m2/repository/com/sun/tools and tried rebuilding the databinding-jaxb module and everything worked fine (it was a little slow downloading). It may just have been a hiccup on the java.net repo - are you having any better luck now? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chianti, was: Rules for Revolutionaries [was: M2]
No luck, Jeremy. I don't even have com/sun/tools under my Maven repo. I am going to try manually downloading those files. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 02:06 To: tuscany-dev@ws.apache.org Subject: Re: Chianti, was: Rules for Revolutionaries [was: M2] On Jul 11, 2006, at 5:30 PM, Meeraj Kunnumpurath wrote: Thanks Raymond. I tried the build around four or five times. I shall try a few more times. I wiped the Sun plugin from my repo $ rm -rf ~/.m2/repository/com/sun/tools and tried rebuilding the databinding-jaxb module and everything worked fine (it was a little slow downloading). It may just have been a hiccup on the java.net repo - are you having any better luck now? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chianti, was: Rules for Revolutionaries [was: M2]
Jeremy, I can't find the required version of the plugin on the java.net repo? Is it version 1.0 or 2.0EA3? Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 02:13 To: tuscany-dev@ws.apache.org Subject: RE: Chianti, was: Rules for Revolutionaries [was: M2] No luck, Jeremy. I don't even have com/sun/tools under my Maven repo. I am going to try manually downloading those files. -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 02:06 To: tuscany-dev@ws.apache.org Subject: Re: Chianti, was: Rules for Revolutionaries [was: M2] On Jul 11, 2006, at 5:30 PM, Meeraj Kunnumpurath wrote: Thanks Raymond. I tried the build around four or five times. I shall try a few more times. I wiped the Sun plugin from my repo $ rm -rf ~/.m2/repository/com/sun/tools and tried rebuilding the databinding-jaxb module and everything worked fine (it was a little slow downloading). It may just have been a hiccup on the java.net repo - are you having any better luck now? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rules for Revolutionaries [was: M2]
Jeremy Boynes wrote: Ant I'm disappointed that you have chosen this path. I will ask one more time if you and Sebastien would consider collaborating with those of us working on core2. A while ago, I agreed to be a mentor for this project. I guess it is about time that I start acting like one. If this project ever hopes to exit incubation, it had better start acting like an ASF project. For starters, I suggest that all committers read the Rules for Revolutionaries[1][2][3]. For those who want the Cliff notes version: anybody who wants to work in an evolutionary fashion on the main trunk is welcome to do so. Anybody who wants to work on a revolutionary branch is welcome to do so. Multiple concurrent revolutionary branches are OK too. One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. Something implicit in the R4R document is that the burden of proof is on the revolutionaries. If you would like to see your particular branch merged back onto the trunk, be prepared to demonstrate why your particular branch is not merely better, but necessary. My experience it that the more concrete and the less hand-wavy the argument, the more likely it will be accepted. So, if you chose to believe that scenarios and test cases are optional, just remember, merging your sandbox back to the trunk is optional too. That does not mean that scenarios and test cases are required, but it does mean that if these aren't present, you need to come up with something just as compelling. - Sam Ruby [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf [3] http://marc2.theaimsgroup.com/?l=apache-communitym=105712356508947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
