Re: SCA Java samples for M2
Also, as I think there has been some consensus on large parts of this how about making some incremental changes? For example, I think there's agreement that the vast majority of the existing top level 'samples' folder would move to 'sca/samples', and that the top level folder which contains bigbank will be renamed from 'sampleapps' to 'samples'. So how about I go ahead and make those changes now? I'll go ahead and do this unless I hear any objections (but it would be nice to hear at least couple of okays). ...ant On 10/10/06, ant elder [EMAIL PROTECTED] wrote: Putting aside the when they get built question for now, what i was really asking (in a very unclear way) a few emails ago was if I've really got the directory structure quite right yet? For example, there's the existing JavaScript container maven project at: sca/services/containers/container.javascript I'd suggested samples would go at: sca/services/containers/container.javascript/src/samples/calculator But can maven projects really be nested like this? If there's a pom.xml in that calculator folder does that work nested in the JavaScript project with a pom.xml in the container.javascript folder? What references the sample pom.xml and how would it ever get built? I've not tried this but it seems odd, could someone who understands maven projects comment on if this ok? ...ant On 10/9/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. The samples are not part of the regular build, they are part of the root one. The root build should never have to be run for a checkin of Java SCA as it includes SDO and DAS, which we agreed should not be required by the former for modularity. I'm not going to rehash old ground but I will state that we need an integration test framework run as part of a continuous integration process that will include samples testing but goes well beyond that. In addition, the check-in build should contain test cases that verify basic things like bootstrapping (standalone, webapp); this can all be done using EasyMock without the need for code to execute in- container. The reason the samples are breaking is not because we don't run them as part of the build, it's because our basic test coverage is lacking. I propose we work to resolve this by the following: 1. Put testcases that verify bootstrapping in the checkin build. these should only use EasyMock and not run any containers (e.g. Jetty) 2. Move to a continuous integration framework, perhaps Continuum. These tests should - Run the samples in a number of container hosts we support (Tomcat, Jetty, Standalone, etc.) - Perform a deeper level of integration tests between various subsystems, such as wiring between component implementation types, interop testing, etc. - Be run periodically. We may eventually want to break them into parts. Some which run every 15 minutes or so, others (more resource intensive) which run around twice a day I'm willing to help out if there are some volunteers. Any volunteers? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
On Oct 10, 2006, at 12:47 PM, ant elder wrote: Also, as I think there has been some consensus on large parts of this how about making some incremental changes? For example, I think there's agreement that the vast majority of the existing top level 'samples' folder would move to 'sca/samples', and that the top level folder which contains bigbank will be renamed from 'sampleapps' to 'samples'. So how about I go ahead and make those changes now? I think we should be clear on what the incremental changes are...Will the existing samples specific to extensions then be refactored into their respective extension projects, e.g. JavaScript samples under the JavaScript extension? Also, I'm not sure we are clear on what the move entails. Specifically, the samples should *not* be built as part of the standard checkin build. What I propose is: 1. There is a samples directory under root that contains a version of BigBank which spans multiple Tuscany sub-projects (SDO/DAS/SCA) 2. There is a samples directory under /sca for baseline samples. These baseline samples would comprise a samples distribution consisting of source. The source would be buildable by end-users from the distribution and we could add a variety of artifacts to assist in that, including a build.xml, .project (Eclipse), and .iml (IDEA) files. This distribution would not be built by the standard Tuscany check-in build. Since it is important for samples to *work* (not just build), there would be a series of integration tests run periodically somewhere. Samples would only be guaranteed to work on a stable snapshot of core. 3. An extension could also choose to include samples with it. These samples would also be distributed as source and would *not* be built as part of the main checkin process. The difference with #2 is that these samples would be non-baseline (e.g. contrib samples) and could release independently from the main samples distribution. In terms of the svn repo format, the sample artifacts could either go under a sibling folder of java/main (e.g. java/samples) or be contained within a Maven sub-module of the extension. I think this would address issues we are having around modularity as well as provide a way for us to verify samples are working through integration testing (which cannot be done by seeing if they compile). I'd like to have a plan agreed on before we make repo changes given we are trying to also get a release out. Jim I'll go ahead and do this unless I hear any objections (but it would be nice to hear at least couple of okays). ...ant On 10/10/06, ant elder [EMAIL PROTECTED] wrote: Putting aside the when they get built question for now, what i was really asking (in a very unclear way) a few emails ago was if I've really got the directory structure quite right yet? For example, there's the existing JavaScript container maven project at: sca/services/containers/container.javascript I'd suggested samples would go at: sca/services/containers/container.javascript/src/samples/ calculator But can maven projects really be nested like this? If there's a pom.xml in that calculator folder does that work nested in the JavaScript project with a pom.xml in the container.javascript folder? What references the sample pom.xml and how would it ever get built? I've not tried this but it seems odd, could someone who understands maven projects comment on if this ok? ...ant On 10/9/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. The samples are not part of the regular build, they are part of the root one. The root build should never have to be run for a checkin of Java SCA as it includes SDO and DAS, which we agreed should not be required by the former for modularity. I'm not going to rehash old ground but I will state that we need an integration test framework run as part of a continuous integration process that will include samples testing but goes well beyond that. In addition, the check-in build should contain test cases that verify basic things like bootstrapping (standalone, webapp); this can all be done using EasyMock without the need for code to execute in- container. The reason the samples are breaking is not because we don't run them as part of the build, it's because our basic test coverage is lacking. I propose we work to resolve this by the following: 1. Put testcases that verify bootstrapping in the checkin build. these should only use EasyMock and not run any containers (e.g. Jetty) 2. Move to a continuous integration framework, perhaps Continuum. These tests should - Run the samples in a number of container
Re: SCA Java samples for M2
All i was suggesting for right now was moving the entire top level samples folder as-is to sca/samples and renaming the top level sampleapps folder to be samples. I don't think there's consensus on anything else yet. ...ant On 10/10/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 10, 2006, at 12:47 PM, ant elder wrote: Also, as I think there has been some consensus on large parts of this how about making some incremental changes? For example, I think there's agreement that the vast majority of the existing top level 'samples' folder would move to 'sca/samples', and that the top level folder which contains bigbank will be renamed from 'sampleapps' to 'samples'. So how about I go ahead and make those changes now? I think we should be clear on what the incremental changes are...Will the existing samples specific to extensions then be refactored into their respective extension projects, e.g. JavaScript samples under the JavaScript extension? Also, I'm not sure we are clear on what the move entails. Specifically, the samples should *not* be built as part of the standard checkin build. What I propose is: 1. There is a samples directory under root that contains a version of BigBank which spans multiple Tuscany sub-projects (SDO/DAS/SCA) 2. There is a samples directory under /sca for baseline samples. These baseline samples would comprise a samples distribution consisting of source. The source would be buildable by end-users from the distribution and we could add a variety of artifacts to assist in that, including a build.xml, .project (Eclipse), and .iml (IDEA) files. This distribution would not be built by the standard Tuscany check-in build. Since it is important for samples to *work* (not just build), there would be a series of integration tests run periodically somewhere. Samples would only be guaranteed to work on a stable snapshot of core. 3. An extension could also choose to include samples with it. These samples would also be distributed as source and would *not* be built as part of the main checkin process. The difference with #2 is that these samples would be non-baseline (e.g. contrib samples) and could release independently from the main samples distribution. In terms of the svn repo format, the sample artifacts could either go under a sibling folder of java/main (e.g. java/samples) or be contained within a Maven sub-module of the extension. I think this would address issues we are having around modularity as well as provide a way for us to verify samples are working through integration testing (which cannot be done by seeing if they compile). I'd like to have a plan agreed on before we make repo changes given we are trying to also get a release out. Jim I'll go ahead and do this unless I hear any objections (but it would be nice to hear at least couple of okays). ...ant On 10/10/06, ant elder [EMAIL PROTECTED] wrote: Putting aside the when they get built question for now, what i was really asking (in a very unclear way) a few emails ago was if I've really got the directory structure quite right yet? For example, there's the existing JavaScript container maven project at: sca/services/containers/container.javascript I'd suggested samples would go at: sca/services/containers/container.javascript/src/samples/ calculator But can maven projects really be nested like this? If there's a pom.xml in that calculator folder does that work nested in the JavaScript project with a pom.xml in the container.javascript folder? What references the sample pom.xml and how would it ever get built? I've not tried this but it seems odd, could someone who understands maven projects comment on if this ok? ...ant On 10/9/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. The samples are not part of the regular build, they are part of the root one. The root build should never have to be run for a checkin of Java SCA as it includes SDO and DAS, which we agreed should not be required by the former for modularity. I'm not going to rehash old ground but I will state that we need an integration test framework run as part of a continuous integration process that will include samples testing but goes well beyond that. In addition, the check-in build should contain test cases that verify basic things like bootstrapping (standalone, webapp); this can all be done using EasyMock without the need for code to execute in- container. The reason the samples are breaking is not because we don't run them as part of the build, it's because our basic test coverage is lacking. I propose we work to resolve this by the following: 1. Put testcases that verify bootstrapping
Re: SCA Java samples for M2
On Oct 10, 2006, at 1:26 PM, ant elder wrote: All i was suggesting for right now was moving the entire top level samples folder as-is to sca/samples and renaming the top level sampleapps folder to be samples. I don't think there's consensus on anything else yet. One thing I would be against is having the samples built from the main checkin build under /sca. If that's not the case (i.e. samples are not built by the default goal) then my preference would be to have a more definite plan before we moved stuff. If people feel moving these around prior to getting a plan in place is progress, and there are no other objections, then I'd be o.k. (again as long as the samples are not part of the main build). Ultimately, I think our release manager needs to chime in given our goals of delivering something soon... Jim ...ant On 10/10/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 10, 2006, at 12:47 PM, ant elder wrote: Also, as I think there has been some consensus on large parts of this how about making some incremental changes? For example, I think there's agreement that the vast majority of the existing top level 'samples' folder would move to 'sca/samples', and that the top level folder which contains bigbank will be renamed from 'sampleapps' to 'samples'. So how about I go ahead and make those changes now? I think we should be clear on what the incremental changes are...Will the existing samples specific to extensions then be refactored into their respective extension projects, e.g. JavaScript samples under the JavaScript extension? Also, I'm not sure we are clear on what the move entails. Specifically, the samples should *not* be built as part of the standard checkin build. What I propose is: 1. There is a samples directory under root that contains a version of BigBank which spans multiple Tuscany sub-projects (SDO/DAS/SCA) 2. There is a samples directory under /sca for baseline samples. These baseline samples would comprise a samples distribution consisting of source. The source would be buildable by end-users from the distribution and we could add a variety of artifacts to assist in that, including a build.xml, .project (Eclipse), and .iml (IDEA) files. This distribution would not be built by the standard Tuscany check-in build. Since it is important for samples to *work* (not just build), there would be a series of integration tests run periodically somewhere. Samples would only be guaranteed to work on a stable snapshot of core. 3. An extension could also choose to include samples with it. These samples would also be distributed as source and would *not* be built as part of the main checkin process. The difference with #2 is that these samples would be non-baseline (e.g. contrib samples) and could release independently from the main samples distribution. In terms of the svn repo format, the sample artifacts could either go under a sibling folder of java/main (e.g. java/samples) or be contained within a Maven sub-module of the extension. I think this would address issues we are having around modularity as well as provide a way for us to verify samples are working through integration testing (which cannot be done by seeing if they compile). I'd like to have a plan agreed on before we make repo changes given we are trying to also get a release out. Jim I'll go ahead and do this unless I hear any objections (but it would be nice to hear at least couple of okays). ...ant On 10/10/06, ant elder [EMAIL PROTECTED] wrote: Putting aside the when they get built question for now, what i was really asking (in a very unclear way) a few emails ago was if I've really got the directory structure quite right yet? For example, there's the existing JavaScript container maven project at: sca/services/containers/container.javascript I'd suggested samples would go at: sca/services/containers/container.javascript/src/samples/ calculator But can maven projects really be nested like this? If there's a pom.xml in that calculator folder does that work nested in the JavaScript project with a pom.xml in the container.javascript folder? What references the sample pom.xml and how would it ever get built? I've not tried this but it seems odd, could someone who understands maven projects comment on if this ok? ...ant On 10/9/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. The samples are not part of the regular build, they are part of the root one. The root build should never have to be run for a checkin of Java SCA as it includes SDO and DAS, which we agreed should not be required by the former for modularity. I'm not going to rehash old ground but I will
Re: SCA Java samples for M2
Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes Jim.. so that the pattern is clear to the user. i.e the user would see and feel in the samples at a particular level, only those features that exist at that level. For example a user could get a feel of individual extensions from the various samples, be able to digest them and then move out to the SCA level to get a feel of how the extensions could be combined. Then moving futher out to the base wherein the samples there demonstrate the roles of SCA, SDO and DAS in providing uniform service access, data proecessing and data access mechanism for SOA based applications. - Venkat On 10/8/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: Hi, I'd prefer to have business samples under 'samples' itself. I perceive that technology samples will go to the respective project directories and all others are to demonstrate the cool things of combining containers, transports - the integration story and they would all get under samples i.e. samples/BigBang, samples/SupplyChain .. and so on. I want to check that we are saying the same thing. Here is what I understand the proposed structuring to be: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/ calculator To me this means: 1. Samples which are designed to illustrate multiple Tuscany sub- projects (SCA/SDO/DAS) working together go under java/samples. These are generally applications or as some people like to refer to them business samples 2. Samples which are applications that are designed to illustrate one Tuscany sub-project go under their respective sub-project samples directory. For example, das/samples/companyweb or sca/samples/bigbank for a version of BigBank that only uses SCA. 3. SCA samples that illustrate a particular Java SCA runtime extension go in a samples folder under the extension, e.g. sca/ services/containers/container.javascript/src/samples/calculator. SDO and DAS may choose to follow a similar scheme if it makes sense for those projects. Does that align with what you are saying? Jim - Venkat On 10/7/06, ant elder [EMAIL PROTECTED] wrote: I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote: Previously we had discussed having a sampleapps directory to distinguish business samples from technology samples.[1] Do we want to continue this distinction? Brent [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/ calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much
Re: SCA Java samples for M2
In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. -- Jeremy On Oct 9, 2006, at 7:12 AM, Rick wrote: What is the reasoning behind not wanting to build samples? You can always go in a subdir while developing and only re-build a particular extension or the core. I'm worried that this will lead the samples to go out of date. ant elder wrote: A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/ calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes Jim.. so that the pattern is clear to the user. i.e the user would see and feel in the samples at a particular level, only those features that exist at that level. For example a user could get a feel of individual extensions from the various samples, be able to digest them and then move out to the SCA level to get a feel of how the extensions could be combined. Then moving futher out to the base wherein the samples there demonstrate the roles of SCA, SDO and DAS in providing uniform service access, data proecessing and data access mechanism for SOA based applications. - Venkat On 10/8/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: Hi, I'd prefer to have business samples under 'samples' itself. I perceive that technology samples will go to the respective project directories and all others are to demonstrate the cool things of combining containers, transports - the integration story and they would all get under samples i.e. samples/BigBang, samples/SupplyChain .. and so on. I want to check that we are saying the same thing. Here is what I understand the proposed structuring to be: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/ calculator To me this means: 1. Samples which are designed to illustrate multiple Tuscany sub- projects (SCA/SDO/DAS) working together go under java/ samples. These are generally applications or as some people like to refer to them business samples 2. Samples which are applications that are designed to illustrate one Tuscany sub-project go under their respective sub-project samples directory. For example, das/samples/companyweb or sca/samples/ bigbank for a version of BigBank that only uses SCA. 3. SCA samples that illustrate a particular Java SCA runtime extension go in a samples folder under the extension, e.g. sca/ services/containers/container.javascript/src/samples/ calculator. SDO and DAS may choose to follow a similar scheme if it makes sense for those projects. Does that align with what you are saying? Jim - Venkat On 10/7/06, ant elder [EMAIL PROTECTED] wrote: I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote: Previously we had discussed having a sampleapps directory to distinguish business samples from technology samples. [1] Do we want to continue this distinction? Brent [1] -
Re: SCA Java samples for M2
I see value that we know they still build and we may have in the future some unit tests for these too. I agree the was is still lacking is an integration test - which does not run during normal build. Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. -- Jeremy On Oct 9, 2006, at 7:12 AM, Rick wrote: What is the reasoning behind not wanting to build samples? You can always go in a subdir while developing and only re-build a particular extension or the core. I'm worried that this will lead the samples to go out of date. ant elder wrote: A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes Jim.. so that the pattern is clear to the user. i.e the user would see and feel in the samples at a particular level, only those features that exist at that level. For example a user could get a feel of individual extensions from the various samples, be able to digest them and then move out to the SCA level to get a feel of how the extensions could be combined. Then moving futher out to the base wherein the samples there demonstrate the roles of SCA, SDO and DAS in providing uniform service access, data proecessing and data access mechanism for SOA based applications. - Venkat On 10/8/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: Hi, I'd prefer to have business samples under 'samples' itself. I perceive that technology samples will go to the respective project directories and all others are to demonstrate the cool things of combining containers, transports - the integration story and they would all get under samples i.e. samples/BigBang, samples/SupplyChain .. and so on. I want to check that we are saying the same thing. Here is what I understand the proposed structuring to be: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/ calculator To me this means: 1. Samples which are designed to illustrate multiple Tuscany sub- projects (SCA/SDO/DAS) working together go under java/samples. These are generally applications or as some people like to refer to them business samples 2. Samples which are applications that are designed to illustrate one Tuscany sub-project go under their respective sub-project samples directory. For example, das/samples/companyweb or sca/samples/bigbank for a version of BigBank that only uses SCA. 3. SCA samples that illustrate a particular Java SCA runtime extension go in a samples folder under the extension, e.g. sca/ services/containers/container.javascript/src/samples/calculator. SDO and DAS may choose to follow a similar scheme if it makes sense for those projects. Does that align with what you are saying? Jim - Venkat On 10/7/06, ant elder [EMAIL PROTECTED] wrote: I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote: Previously we had discussed having a sampleapps directory to distinguish business
Re: SCA Java samples for M2
I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. Simon Jeremy Boynes wrote: I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
I agree. Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
And where was I advocating that? I was *pointing out the reasoning* which was Rick's question so helpfully cut from this thread. Sorry for trying to be helpful, I'll shut up now. -- Jeremy On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. Simon Jeremy Boynes wrote: I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp- based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Jeremy, I understand the reasoning (thanks for restating it) and as I said, this is a good long term goal. The question had been raised (not by you) about whether or not the samples should continue to be built as part of the regular build, and I was responding to that discussion. Simon Jeremy Boynes wrote: And where was I advocating that? I was *pointing out the reasoning* which was Rick's question so helpfully cut from this thread. Sorry for trying to be helpful, I'll shut up now. -- Jeremy On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. Simon Jeremy Boynes wrote: I was pointing out the reasoning behind (which is what Rick asked) which should be fairly well known given the number of times we have had this particular discussion. IMO we need integration tests that pass. That would include testing the samples. Given the resources required to run real integration tests it is impractical to run them as part of a developer build. They should run on a ongoing basis, perhaps using a framework like Continuum. A plea to everyone - let's not rehash this all over again unless something has changed to make it a productive discussion. -- Jeremy On Oct 9, 2006, at 7:28 AM, Andy Piper wrote: At 15:21 09/10/2006, Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp- based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. Better samples that build and don't run than samples that don't build at all IMO. andy __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: SCA Java samples for M2
On Oct 9, 2006, at 8:37 AM, Simon Nash wrote: I agree with Andy. An integration test framework ro build and run the samples is the right long term solution, but until we have that framework, we should not remove building the samples from the regular build. The samples are not part of the regular build, they are part of the root one. The root build should never have to be run for a checkin of Java SCA as it includes SDO and DAS, which we agreed should not be required by the former for modularity. I'm not going to rehash old ground but I will state that we need an integration test framework run as part of a continuous integration process that will include samples testing but goes well beyond that. In addition, the check-in build should contain test cases that verify basic things like bootstrapping (standalone, webapp); this can all be done using EasyMock without the need for code to execute in- container. The reason the samples are breaking is not because we don't run them as part of the build, it's because our basic test coverage is lacking. I propose we work to resolve this by the following: 1. Put testcases that verify bootstrapping in the checkin build. these should only use EasyMock and not run any containers (e.g. Jetty) 2. Move to a continuous integration framework, perhaps Continuum. These tests should - Run the samples in a number of container hosts we support (Tomcat, Jetty, Standalone, etc.) - Perform a deeper level of integration tests between various subsystems, such as wiring between component implementation types, interop testing, etc. - Be run periodically. We may eventually want to break them into parts. Some which run every 15 minutes or so, others (more resource intensive) which run around twice a day I'm willing to help out if there are some volunteers. Any volunteers? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Not really part of this thread, but a question that came to mind because of it; would an integration test deploy and use Tomcat like we had before? If we ever got to using a continuum type build in apache would that be an issue ? Opening and sending through a socket at build/test time ? Jeremy Boynes wrote: In many cases building the sample does not actually prove anything as they are not executed. This applies, for example, to the webapp-based samples we have. When they are executed, we still don't know that they run in the end-user environment - e.g. the standalone samples that run from SCATestCase but which fail to run from the launcher. Where they should be built/run is as part of an integration test suite. We don't have that ATM. -- Jeremy On Oct 9, 2006, at 7:12 AM, Rick wrote: What is the reasoning behind not wanting to build samples? You can always go in a subdir while developing and only re-build a particular extension or the core. I'm worried that this will lead the samples to go out of date. ant elder wrote: A final part of this is how the samples get built. One thing Jim wanted was for the samples to not get built with a regular build. If there's a (or some?) sample in sca/services/containers/container.javascript/src/samples/calculator how does that fit in with the maven build? ...ant On 10/9/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, So can we finalize on this and start moving the samples. While doing this can we also do the following: - - Go up to the wiki http://wiki.apache.org/ws/Tuscany/TuscanyJava/M2Tasks#preview and update the samples section - If the sample is tried and includes a readme that explains how to go about setting it up and running it mark the sample as complete. - If there are issues related to the sample, please update the issues that are pending or being worked upon. Thoughts ? - Venkat On 10/8/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes Jim.. so that the pattern is clear to the user. i.e the user would see and feel in the samples at a particular level, only those features that exist at that level. For example a user could get a feel of individual extensions from the various samples, be able to digest them and then move out to the SCA level to get a feel of how the extensions could be combined. Then moving futher out to the base wherein the samples there demonstrate the roles of SCA, SDO and DAS in providing uniform service access, data proecessing and data access mechanism for SOA based applications. - Venkat On 10/8/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: Hi, I'd prefer to have business samples under 'samples' itself. I perceive that technology samples will go to the respective project directories and all others are to demonstrate the cool things of combining containers, transports - the integration story and they would all get under samples i.e. samples/BigBang, samples/SupplyChain .. and so on. I want to check that we are saying the same thing. Here is what I understand the proposed structuring to be: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/ calculator To me this means: 1. Samples which are designed to illustrate multiple Tuscany sub- projects (SCA/SDO/DAS) working together go under java/samples. These are generally applications or as some people like to refer to them business samples 2. Samples which are applications that are designed to illustrate one Tuscany sub-project go under their respective sub-project samples directory. For example, das/samples/companyweb or sca/samples/bigbank for a version of BigBank that only uses SCA. 3. SCA samples that illustrate a particular Java SCA runtime extension go in a samples folder under the extension, e.g. sca/ services/containers/container.javascript/src/samples/calculator. SDO and DAS may choose to follow a similar scheme if it makes sense for those projects. Does that align with what you are saying? Jim - Venkat On 10/7/06, ant elder [EMAIL PROTECTED] wrote: I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote:
Re: SCA Java samples for M2
I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote: Previously we had discussed having a sampleapps directory to distinguish business samples from technology samples.[1] Do we want to continue this distinction? Brent [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Hi, I'd prefer to have business samples under 'samples' itself. I perceive that technology samples will go to the respective project directories and all others are to demonstrate the cool things of combining containers, transports - the integration story and they would all get under samples i.e. samples/BigBang, samples/SupplyChain .. and so on. - Venkat On 10/7/06, ant elder [EMAIL PROTECTED] wrote: I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote: Previously we had discussed having a sampleapps directory to distinguish business samples from technology samples.[1] Do we want to continue this distinction? Brent [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Venkat, +1 from me. This seems exactly right. Simon Venkata Krishnan wrote: Hi, I'd prefer to have business samples under 'samples' itself. I perceive that technology samples will go to the respective project directories and all others are to demonstrate the cool things of combining containers, transports - the integration story and they would all get under samples i.e. samples/BigBang, samples/SupplyChain .. and so on. - Venkat On 10/7/06, ant elder [EMAIL PROTECTED] wrote: I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote: Previously we had discussed having a sampleapps directory to distinguish business samples from technology samples.[1] Do we want to continue this distinction? Brent [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: SCA Java samples for M2
On Oct 7, 2006, at 10:01 AM, Venkata Krishnan wrote: Hi, I'd prefer to have business samples under 'samples' itself. I perceive that technology samples will go to the respective project directories and all others are to demonstrate the cool things of combining containers, transports - the integration story and they would all get under samples i.e. samples/BigBang, samples/SupplyChain .. and so on. I want to check that we are saying the same thing. Here is what I understand the proposed structuring to be: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/ calculator To me this means: 1. Samples which are designed to illustrate multiple Tuscany sub- projects (SCA/SDO/DAS) working together go under java/samples. These are generally applications or as some people like to refer to them business samples 2. Samples which are applications that are designed to illustrate one Tuscany sub-project go under their respective sub-project samples directory. For example, das/samples/companyweb or sca/samples/bigbank for a version of BigBank that only uses SCA. 3. SCA samples that illustrate a particular Java SCA runtime extension go in a samples folder under the extension, e.g. sca/ services/containers/container.javascript/src/samples/calculator. SDO and DAS may choose to follow a similar scheme if it makes sense for those projects. Does that align with what you are saying? Jim - Venkat On 10/7/06, ant elder [EMAIL PROTECTED] wrote: I guess I was thinking that the technology type samples would be the ones that are now moved further down into the folder hierarchy so the only thing left up at the top would be the business samples so there wasn't the need for the two folders 'samples' and 'sampleapps' so sampleapps might as well just be renamed to samples to keep everything consistent. Please anyone say if they disagree with that. I'd also still like to hear comments or suggestions on all this from others who've expressed an interest in the samples in the past before I make the changes - Jim , Rick, Simon? ...ant On 10/6/06, Brent Daniel [EMAIL PROTECTED] wrote: Previously we had discussed having a sampleapps directory to distinguish business samples from technology samples.[1] Do we want to continue this distinction? Brent [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/ calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant -
Re: SCA Java samples for M2
Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Hi... Yes this makes sense to me. - Venkat where I'd like to put component implementations On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
On Oct 6, 2006, at 1:57 AM, ant elder wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/ sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? +1 -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Ken, I don't think the existence of a sample that uses multiple extensions restricts the ability to work with those extensions separately. It is true that anyone wanting to work with just one of the extensions will be unable to use the multi-extension sample, but they can still use the extension. I believe the requirement is that every extension should have samples that don't require the use of other extensions as well. Simon Ken Tam wrote: +1. It sounds like we still have an issue wrt samples that use multiple extensions (in that the existence of such samples restricts the ability to separately work with those extensions), but I'm fine with not addressing that now. On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Right -- I was just elaborating on Jeremy's earlier statement re: one motivation for packing extension-specific samples with the extensions themselves: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. and pointing out that the existence of samples using multiple extensions inherently complicates (though not ruling out) scenarios like tagging/releasing extension modules separately. On 10/6/06, Simon Nash [EMAIL PROTECTED] wrote: Ken, I don't think the existence of a sample that uses multiple extensions restricts the ability to work with those extensions separately. It is true that anyone wanting to work with just one of the extensions will be unable to use the multi-extension sample, but they can still use the extension. I believe the requirement is that every extension should have samples that don't require the use of other extensions as well. Simon Ken Tam wrote: +1. It sounds like we still have an issue wrt samples that use multiple extensions (in that the existence of such samples restricts the ability to separately work with those extensions), but I'm fine with not addressing that now. On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Previously we had discussed having a sampleapps directory to distinguish business samples from technology samples.[1] Do we want to continue this distinction? Brent [1] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg01812.html On 10/6/06, ant elder [EMAIL PROTECTED] wrote: Ok I think we're getting some agreement but I'd like to be clear everyone agrees and is happy before I make any changes. Sounds like for things like the Groovy/JavaScript/etc helloworld and calculator type samples they would go with the extension, I'm guessing samples that use just sca and java would go in an sca/samples directory. Samples that use multiple extensions but still just SCA would also go in the sca/samples directory, and there'd be a top level samples directory for things like bigbank that use sca/sdo/das. So: samples/bingbank das/samples/companyweb sca/samples/calculator sca/services/containers/container.javascript/src/samples/calculator Comments? ...ant On 10/5/06, Jim Marino [EMAIL PROTECTED] wrote: On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
There was a discussion on the samples a while back [1] where i think there was some agreement to restructure the samples based on the extension they are demonstrating. It wasn't so clear what the out come of that discussion was so how about the following (for now ignoring whats in/out/works/broken): sampleapps/bigbank bigbank samples/echo - echo.binding - echo.databinding samples/javascript helloworld samples/axis2 helloworldws helloworldwsclient helloworldwsclientOM helloworldwsOM samples/celtix helloworldws-celtix samples/spring spring.simple spring samples/rmi helloworld.rmiReference helloworld.rmiService samples/jsonrpc helloworldjsonrpc samples/java? calculator eagerinit inner.composite local.wire local.wire.cdi simplecallback supplychain webapp In the same thread there was the suggestion about using a calculator sample instead of or as well as helloworld so I'll also add a javascript calculator sample and look at doing both for the other script languages as well. If we can reach some consensus about what this should look like I can do the changes. ...ant [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06572.html On 10/4/06, Simon Nash [EMAIL PROTECTED] wrote: I'm planning to go through all the SCA Java samples, building them and runnning them, to make sure that they work. We also need to consider whether this is the right set of samples to introduce users to the capabilities of SCA and Tuscany. Right now we have the following in the samples/sca directory. Samples that are currently building: bigbank calculator eagerinit echo.binding echo.databinding helloworldJavaScript helloworldws helloworldws-celtix helloworldwsclient local.wire local.wire.cdi spring.simple supplychain webapp Samples that are not currently building: helloworld.rmiReference helloworld.rmiService helloworldjsonrpc helloworldwsclientOM helloworldwsOM inner.composite simplecallback spring For a first pass I would assume that we are intending to deliver the former list in our M2 binary release but not the latter. Is this a correct assumption? Should any of the not building samples be included? Should any of the building samples be excluded? Should we be adding any more samples that are currently not in either list? From a quick look through these lists, I have the following questions. 1. It is my understanding that we are including RMI, so presumably we need the RMI samples. 2. It is my understanding that we are not including celtix in the binary release, so presumably we don't need the celtix sample. 3. I don't know whether we will be including Spring, so I'm not whether we will need the spring.simple sample. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Hi... I have posted a patch on the JIRA to fix the RMI samples. Now they must work with the current state of the Standalone. http://issues.apache.org/jira/browse/TUSCANY-799 Thanks - Venkat On 10/5/06, ant elder [EMAIL PROTECTED] wrote: There was a discussion on the samples a while back [1] where i think there was some agreement to restructure the samples based on the extension they are demonstrating. It wasn't so clear what the out come of that discussion was so how about the following (for now ignoring whats in/out/works/broken): sampleapps/bigbank bigbank samples/echo - echo.binding - echo.databinding samples/javascript helloworld samples/axis2 helloworldws helloworldwsclient helloworldwsclientOM helloworldwsOM samples/celtix helloworldws-celtix samples/spring spring.simple spring samples/rmi helloworld.rmiReference helloworld.rmiService samples/jsonrpc helloworldjsonrpc samples/java? calculator eagerinit inner.composite local.wire local.wire.cdi simplecallback supplychain webapp In the same thread there was the suggestion about using a calculator sample instead of or as well as helloworld so I'll also add a javascript calculator sample and look at doing both for the other script languages as well. If we can reach some consensus about what this should look like I can do the changes. ...ant [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06572.html On 10/4/06, Simon Nash [EMAIL PROTECTED] wrote: I'm planning to go through all the SCA Java samples, building them and runnning them, to make sure that they work. We also need to consider whether this is the right set of samples to introduce users to the capabilities of SCA and Tuscany. Right now we have the following in the samples/sca directory. Samples that are currently building: bigbank calculator eagerinit echo.binding echo.databinding helloworldJavaScript helloworldws helloworldws-celtix helloworldwsclient local.wire local.wire.cdi spring.simple supplychain webapp Samples that are not currently building: helloworld.rmiReference helloworld.rmiService helloworldjsonrpc helloworldwsclientOM helloworldwsOM inner.composite simplecallback spring For a first pass I would assume that we are intending to deliver the former list in our M2 binary release but not the latter. Is this a correct assumption? Should any of the not building samples be included? Should any of the building samples be excluded? Should we be adding any more samples that are currently not in either list? From a quick look through these lists, I have the following questions. 1. It is my understanding that we are including RMI, so presumably we need the RMI samples. 2. It is my understanding that we are not including celtix in the binary release, so presumably we don't need the celtix sample. 3. I don't know whether we will be including Spring, so I'm not whether we will need the spring.simple sample. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. Also, the samples that are in java and echo need the standalone installation to run so how about grouping them with that? The web-app based ones (webapp and potentially bigbank) don't need the user to download/install the standalone installation at all and we could package those as a separate unit as well. -- Jeremy On Oct 5, 2006, at 5:04 AM, ant elder wrote: There was a discussion on the samples a while back [1] where i think there was some agreement to restructure the samples based on the extension they are demonstrating. It wasn't so clear what the out come of that discussion was so how about the following (for now ignoring whats in/out/works/ broken): sampleapps/bigbank bigbank samples/echo - echo.binding - echo.databinding samples/javascript helloworld samples/axis2 helloworldws helloworldwsclient helloworldwsclientOM helloworldwsOM samples/celtix helloworldws-celtix samples/spring spring.simple spring samples/rmi helloworld.rmiReference helloworld.rmiService samples/jsonrpc helloworldjsonrpc samples/java? calculator eagerinit inner.composite local.wire local.wire.cdi simplecallback supplychain webapp In the same thread there was the suggestion about using a calculator sample instead of or as well as helloworld so I'll also add a javascript calculator sample and look at doing both for the other script languages as well. If we can reach some consensus about what this should look like I can do the changes. ...ant [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ msg06572.html On 10/4/06, Simon Nash [EMAIL PROTECTED] wrote: I'm planning to go through all the SCA Java samples, building them and runnning them, to make sure that they work. We also need to consider whether this is the right set of samples to introduce users to the capabilities of SCA and Tuscany. Right now we have the following in the samples/sca directory. Samples that are currently building: bigbank calculator eagerinit echo.binding echo.databinding helloworldJavaScript helloworldws helloworldws-celtix helloworldwsclient local.wire local.wire.cdi spring.simple supplychain webapp Samples that are not currently building: helloworld.rmiReference helloworld.rmiService helloworldjsonrpc helloworldwsclientOM helloworldwsOM inner.composite simplecallback spring For a first pass I would assume that we are intending to deliver the former list in our M2 binary release but not the latter. Is this a correct assumption? Should any of the not building samples be included? Should any of the building samples be excluded? Should we be adding any more samples that are currently not in either list? From a quick look through these lists, I have the following questions. 1. It is my understanding that we are including RMI, so presumably we need the RMI samples. 2. It is my understanding that we are not including celtix in the binary release, so presumably we don't need the celtix sample. 3. I don't know whether we will be including Spring, so I'm not whether we will need the spring.simple sample. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. ...ant
Re: SCA Java samples for M2
On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. Yes, I mean moving the samples into (e.g.) the Javascript folder so that JavaScript becomes a standalone module that can be treated as a single item when it comes to building/releasing. We've seen from sdo and das that grouping things in that way makes this much much easier. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
On Oct 5, 2006, at 7:14 AM, ant elder wrote: On 10/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I think organizing the samples like this is a good idea. I'd suggest going one step further and place each sample with the implementation of the service that it is illustrating. That way it becomes much easier to tag/release each module on its own. I'm not sure I follow place each sample with the implementation of the service that it is illustrating , do you mean something like: samples/helloworld/java samples/helloworld/javascript samples/calculator/java samples/calculator/javascript Or do you mean include them with the extension so the JavaScript folder would include samples/helloworld and samples/calculator? I didn't think Jim liked this way, from the previous thread - In other words, each sample project should not be a sibling to the project containing extension code but should go under a samples folder in separate projects. I was thinking samples for particular extensions would go under the particular extension's directory. For samples that used multiple extensions, they would go under the master samples folder. I liked what was done with the calculator where stuff is shared between projects (component reuse) so if that structuring won't work for re- use I would be fine with what Ant just outlined. My preference, though, would be to group samples with individual extensions. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
At 18:45 04/10/2006, Simon Nash wrote: 3. I don't know whether we will be including Spring, so I'm not whether we will need the spring.simple sample. I have this sample fixed. I'm working with Ken on getting it submitted andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Java samples for M2
Hi Simon, I shall get the RMI samples up by tomorrow for sure. Thanks - Venkat On 10/4/06, Andy Piper [EMAIL PROTECTED] wrote: At 18:45 04/10/2006, Simon Nash wrote: 3. I don't know whether we will be including Spring, so I'm not whether we will need the spring.simple sample. I have this sample fixed. I'm working with Ken on getting it submitted andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
