Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Pete Robbins wrote: I may get some time tomorrow to look at it. Feel free to make the changes and I can pick it up from there. Cheers, On 12/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: I do not like the central composite file. As I mentioned earlier I'd really like our loader to be able to load all composites under a dir structure and just figure out all the relationships. I do not like enforcing a user to put some files under packages and some under configuration. This may be very good practice and something I would do but I do not think we should enforce it. For now we may have to enforce it, i.e. the loader will first load the composites in the configuration folder then load from the packages folder but ultimately I would like our loader to be able to load these in any order and just work! I'd also like to add the ability to dynamically add a composite to the runtime programatically at some point! So for now let's organise our samples into .../deploy /configuration (system composites) /packages (implementation composites) (other artifacts , .h, libraries etc.) and the loader can load from deploy/configuration/ first then deploy/packages/. Later we can change this to just load from deploy/ and make it all work by magic ;-) In both cases we will have the TUSCANY_SCACPP_SYSTEM_ROOT set as the path to the deploy/ folder. Cheers, Cool, let's go with that approach then. Is anybody volunteering to make these changes to ModelLoader? or do you guys want me to to do it? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I just committed under revision r433553 a set of changes to support the new structure: system root/packages contains the implementations installed on your system system root/configuration contains the configuration of your system While I was doing this refactoring I noticed that the runtime test suite and the myvalue sample still use old SCA 0.9 SCDL files, this needs to be fixed at some point. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
I do not like the central composite file. As I mentioned earlier I'd really like our loader to be able to load all composites under a dir structure and just figure out all the relationships. I do not like enforcing a user to put some files under packages and some under configuration. This may be very good practice and something I would do but I do not think we should enforce it. For now we may have to enforce it, i.e. the loader will first load the composites in the configuration folder then load from the packages folder but ultimately I would like our loader to be able to load these in any order and just work! I'd also like to add the ability to dynamically add a composite to the runtime programatically at some point! So for now let's organise our samples into .../deploy /configuration (system composites) /packages (implementation composites) (other artifacts , .h, libraries etc.) and the loader can load from deploy/configuration/ first then deploy/packages/. Later we can change this to just load from deploy/ and make it all work by magic ;-) In both cases we will have the TUSCANY_SCACPP_SYSTEM_ROOT set as the path to the deploy/ folder. Cheers, On 12/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: [snip] I think we use our samples to demonstrate different ways of working - have the Calculator be deployed in a single directory and have the BigBank show the use of multiple directories. So perhaps have configuration, packages/account and packages/client directories under the root directory? What do you think? Andy Andy, where would you place the two composites files describing the calculator implementation and component? Just to recap, here's what we had in M1: subsystems/ CalculatorSubsystem/ CalculatorSubsystem.composite BigBankSubsystem/ BigBankSubsystem.composite modules/ CalculatorModule/ CalculatorModule.module Accounts/ Accounts.composite I am proposing something like this: configuration/ sample.calculator.composite bigbank.composite packages/ calculator/ calculator.composite bigbank.account/ bigbank.account.composite bigbank.client/ bigbank.client.composite The configuration directory contains the composites included in your system, the packages directory contains implementations (composites or other things). And here's another option: system.composite file ... containing include name=sample.calculator.composite/ include name=bigbank.composite/ and a more free form distribution for the other artifacts: sample.calculator.composite bigbank.composite calculator/ calculator.composite bigbank.account/ bigbank.account.composite bigbank.client/ bigbank.client.composite This would provide less guidance to our users but maybe more flexibility. They would have to edit this central system.composite file instead of just placing files in a well known folder. I'm OK with both the folder structure option or the cenral composite file option. I suggest we start experimenting with a simple scheme that you guys are comfortable and evolve it over time as we implement more scenarios. What do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Pete Robbins wrote: I do not like the central composite file. As I mentioned earlier I'd really like our loader to be able to load all composites under a dir structure and just figure out all the relationships. I do not like enforcing a user to put some files under packages and some under configuration. This may be very good practice and something I would do but I do not think we should enforce it. For now we may have to enforce it, i.e. the loader will first load the composites in the configuration folder then load from the packages folder but ultimately I would like our loader to be able to load these in any order and just work! I'd also like to add the ability to dynamically add a composite to the runtime programatically at some point! So for now let's organise our samples into .../deploy /configuration (system composites) /packages (implementation composites) (other artifacts , .h, libraries etc.) and the loader can load from deploy/configuration/ first then deploy/packages/. Later we can change this to just load from deploy/ and make it all work by magic ;-) In both cases we will have the TUSCANY_SCACPP_SYSTEM_ROOT set as the path to the deploy/ folder. Cheers, Cool, let's go with that approach then. Is anybody volunteering to make these changes to ModelLoader? or do you guys want me to to do it? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
I may get some time tomorrow to look at it. Feel free to make the changes and I can pick it up from there. Cheers, On 12/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: I do not like the central composite file. As I mentioned earlier I'd really like our loader to be able to load all composites under a dir structure and just figure out all the relationships. I do not like enforcing a user to put some files under packages and some under configuration. This may be very good practice and something I would do but I do not think we should enforce it. For now we may have to enforce it, i.e. the loader will first load the composites in the configuration folder then load from the packages folder but ultimately I would like our loader to be able to load these in any order and just work! I'd also like to add the ability to dynamically add a composite to the runtime programatically at some point! So for now let's organise our samples into .../deploy /configuration (system composites) /packages (implementation composites) (other artifacts , .h, libraries etc.) and the loader can load from deploy/configuration/ first then deploy/packages/. Later we can change this to just load from deploy/ and make it all work by magic ;-) In both cases we will have the TUSCANY_SCACPP_SYSTEM_ROOT set as the path to the deploy/ folder. Cheers, Cool, let's go with that approach then. Is anybody volunteering to make these changes to ModelLoader? or do you guys want me to to do it? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
A lot of things referenced from a .composite are a path relative to the .composite file (the compsite root). This is defined in the spec. For example, component name=MyValueServiceComponent implementation.cpp library=MyValuelibrary path=MyValue header=MyValue/MyValueImpl.h/implementation.cpp so if the composite file is in .../deploy/configuration/myValue.composite the library will be located at .../deploy/configuration/MyValue/libMyValuelibrary.so. Similarly the implementation header will be located at .../deploy/configuration/MyValue/MyValueImpl.h ...so I don't think you can have an arbitrary separation of configuration and packages. I think we can use a very simple deployment which is that the runtime will find all the composites under the system root so it could look like: .../deploy fred.composite ( composite name=abc/ ) some_other_artifacts /ANOtherCompo joe.composite ( composite name=xyz/ ) /joes_libraries joe.dll So the name of the folder and composite file is irrelevent as the actual composite name comes from the scdl name=. This, of course, is a little harder for the runtime to load but a lot simpler for the user IMO. So for a MyValue sample I'd develop my composites in a structure that matches the deploy layout. This is necessary for the scagen step that requires the scdl and the interface headers to generate the proxies and wrappers. This strcture may or may not have multiple directories at the choice of the developer, he may want each component in a separate dir for instance. Deployment is simply copying the scdl, libraries and headers to wherever they are to be deployed. (Although the headers are not currently used at runtime it is possible that they may be in the future). So I may end up with: .../MyValue myValue.composite myVal.componentType /CustomerInfo custinfo.componentType custinfo.h etc.. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Pete Robbins wrote: A lot of things referenced from a .composite are a path relative to the .composite file (the compsite root). This is defined in the spec. For example, component name=MyValueServiceComponent implementation.cpp library=MyValuelibrary path=MyValue header=MyValue/MyValueImpl.h/implementation.cpp so if the composite file is in .../deploy/configuration/myValue.composite the library will be located at .../deploy/configuration/MyValue/libMyValuelibrary.so. Similarly the implementation header will be located at .../deploy/configuration/MyValue/MyValueImpl.h ...so I don't think you can have an arbitrary separation of configuration and packages. I think we can use a very simple deployment which is that the runtime will find all the composites under the system root so it could look like: .../deploy fred.composite ( composite name=abc/ ) some_other_artifacts /ANOtherCompo joe.composite ( composite name=xyz/ ) /joes_libraries joe.dll So the name of the folder and composite file is irrelevent as the actual composite name comes from the scdl name=. This, of course, is a little harder for the runtime to load but a lot simpler for the user IMO. So for a MyValue sample I'd develop my composites in a structure that matches the deploy layout. This is necessary for the scagen step that requires the scdl and the interface headers to generate the proxies and wrappers. This strcture may or may not have multiple directories at the choice of the developer, he may want each component in a separate dir for instance. Deployment is simply copying the scdl, libraries and headers to wherever they are to be deployed. (Although the headers are not currently used at runtime it is possible that they may be in the future). So I may end up with: .../MyValue myValue.composite myVal.componentType /CustomerInfo custinfo.componentType custinfo.h etc.. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Pete, I'm OK too with a simpler structure without separate configuration/ and packages/. I was initially trying to build on the structure that we already have with separate subsystems and modules directories. On the other hand, I'm not sure how we'd handle the following scenario with all composites under a single structure: I have developed two composites, bigbank.account and bigbank.client (in 0.9 speak these would be modules). I install these two composites on my runtime. I now want to actually make them live. For this I need to create a new composite, let's call it bigbank. My bigbank composite declares two components (instances of bigbank.account and bigbank.client) configures them, and wires them together. With SCA 0.9 bigbank was a subsytem. I now have 3 composites on my runtime. How will we distinguish between bigbank (describing the composition and configuration of my system and used to create actual instances) and bigbank.account + bigbank.client (just describing composite implementations), once we have these 3 composites under a single folder structure? The other thing is that in the scenario above we probably have 3 different roles: - The developer putting
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
I think we use our samples to demonstrate different ways of working - have the Calculator be deployed in a single directory and have the BigBank show the use of multiple directories. So perhaps have configuration, packages/account and packages/client directories under the root directory? What do you think? Andy On 8/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Andrew Borley wrote: Can't we allow both ways of working? i.e. with or without subdirectory structures? As long as we recurse into directories looking for any .composite files then it should still work (as long as we check for name clashes, etc). Then it's up to users how they package their projects - they can follow structures that make most sense to them. Andy Yes, makes sense. I agree that users should be free to package their projects in the way that makes most sense to them. We can only show and recommend some practices in our samples. So I guess the only remaining question is: one big root directory, or two configuration/ and packages/ directories, and how do we handle my little Bigbank deployment scenario below :) On 8/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: A lot of things referenced from a .composite are a path relative to the .composite file (the compsite root). This is defined in the spec. For example, component name=MyValueServiceComponent implementation.cpp library=MyValuelibrary path=MyValue header=MyValue/MyValueImpl.h/implementation.cpp so if the composite file is in .../deploy/configuration/myValue.composite the library will be located at .../deploy/configuration/MyValue/libMyValuelibrary.so. Similarly the implementation header will be located at .../deploy/configuration/MyValue/MyValueImpl.h ...so I don't think you can have an arbitrary separation of configuration and packages. I think we can use a very simple deployment which is that the runtime will find all the composites under the system root so it could look like: .../deploy fred.composite ( composite name=abc/ ) some_other_artifacts /ANOtherCompo joe.composite ( composite name=xyz/ ) /joes_libraries joe.dll So the name of the folder and composite file is irrelevent as the actual composite name comes from the scdl name=. This, of course, is a little harder for the runtime to load but a lot simpler for the user IMO. So for a MyValue sample I'd develop my composites in a structure that matches the deploy layout. This is necessary for the scagen step that requires the scdl and the interface headers to generate the proxies and wrappers. This strcture may or may not have multiple directories at the choice of the developer, he may want each component in a separate dir for instance. Deployment is simply copying the scdl, libraries and headers to wherever they are to be deployed. (Although the headers are not currently used at runtime it is possible that they may be in the future). So I may end up with: .../MyValue myValue.composite myVal.componentType /CustomerInfo custinfo.componentType custinfo.h etc.. Cheers, On 11/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Andrew Borley wrote: [snip] I think we use our samples to demonstrate different ways of working - have the Calculator be deployed in a single directory and have the BigBank show the use of multiple directories. So perhaps have configuration, packages/account and packages/client directories under the root directory? What do you think? Andy Andy, where would you place the two composites files describing the calculator implementation and component? Just to recap, here's what we had in M1: subsystems/ CalculatorSubsystem/ CalculatorSubsystem.composite BigBankSubsystem/ BigBankSubsystem.composite modules/ CalculatorModule/ CalculatorModule.module Accounts/ Accounts.composite I am proposing something like this: configuration/ sample.calculator.composite bigbank.composite packages/ calculator/ calculator.composite bigbank.account/ bigbank.account.composite bigbank.client/ bigbank.client.composite The configuration directory contains the composites included in your system, the packages directory contains implementations (composites or other things). And here's another option: system.composite file ... containing include name=sample.calculator.composite/ include name=bigbank.composite/ and a more free form distribution for the other artifacts: sample.calculator.composite bigbank.composite calculator/ calculator.composite bigbank.account/ bigbank.account.composite bigbank.client/ bigbank.client.composite This would provide less guidance to our users but maybe more flexibility. They would have to edit this central system.composite file instead of just placing files in a well known folder. I'm OK with both the folder structure option or the cenral composite file option. I suggest we start experimenting with a simple scheme that you guys are comfortable and evolve it over time as we implement more scenarios. What do you think? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Folder structure under $Tuscany_scacpp_system_root
When I started to implement the new composite assembly model I felt a need to adjust a little the folder structure under the Tuscany system root, did half of it, which triggered some questions :) This is a new thread to discuss these changes. Here's what we had in M1: $TUSCANY_SCAPP_SYSTEM_ROOT/ -- your Tuscany-system-root subsystems/ CalculatorSubsystem/ sca.subsystem -- creates and configures the Calculator module component modules/ Calculator -- the Calculator module and code sca.module other artifacts, *.so, *.wsdl, *.xsd etc. Now that the spec has removed subsystem, module and fragment, and generalized the use of composites, here's what I'd like to propose: deploy/ -- your Tuscany-system-root configuration/ CalculatorApp.composite -- creates the Calculator component, we don't need sub-folders here since we can give meaningful name to composite files now packages/ Calculator -- the Calculator composite and code Calculator.composite other artifacts, *.so, *.wsdl, *.xsd etc. - Configuration contains the composites included in your system creating and configuring your top level components. - Packages contains all your other development artifacts (not necessarily just composites that's why I'm proposing packages/ instead of modules/ or composites/). - I think that the samples should use consistent naming convenvions, but you should also be able to pick the names you want for your folders and artifacts and have Foo/Bar.composite containing composite name=Abc/ for example. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
