You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2006/08/11 01:47:30 UTC
[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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Pete Robbins <ro...@googlemail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Pete
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Pete Robbins <ro...@googlemail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Pete
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Andrew Borley <aj...@gmail.com>.
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 <js...@apache.org> 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 <js...@apache.org> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> 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 together software artifacts in a folder.
> >> - The deployer installing the software to the runtime.
> >> - The administrator configuring and wiring parts of the system.
> >>
> >> My view was that the developer would work in "project" folders.
> >> The deployer would install software under packages/.
> >> The administrator would work in his configuration/ folder.
> >>
> >> But again if we manage to reconcile system composition/configuration
> and
> >> software install under a single folder I'll be happy too. Less code and
> >> less folders is always better :)
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@apache.org> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >>
>> >>
>> >
>> >
>> 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 together software artifacts in a folder.
>> - The deployer installing the software to the runtime.
>> - The administrator configuring and wiring parts of the system.
>>
>> My view was that the developer would work in "project" folders.
>> The deployer would install software under packages/.
>> The administrator would work in his configuration/ folder.
>>
>> But again if we manage to reconcile system composition/configuration and
>> software install under a single folder I'll be happy too. Less code and
>> less folders is always better :)
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Andrew Borley <aj...@gmail.com>.
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
On 8/11/06, Jean-Sebastien Delfino <js...@apache.org> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> >
> 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 together software artifacts in a folder.
> - The deployer installing the software to the runtime.
> - The administrator configuring and wiring parts of the system.
>
> My view was that the developer would work in "project" folders.
> The deployer would install software under packages/.
> The administrator would work in his configuration/ folder.
>
> But again if we manage to reconcile system composition/configuration and
> software install under a single folder I'll be happy too. Less code and
> less folders is always better :)
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
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 together software artifacts in a folder.
- The deployer installing the software to the runtime.
- The administrator configuring and wiring parts of the system.
My view was that the developer would work in "project" folders.
The deployer would install software under packages/.
The administrator would work in his configuration/ folder.
But again if we manage to reconcile system composition/configuration and
software install under a single folder I'll be happy too. Less code and
less folders is always better :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Folder structure under $Tuscany_scacpp_system_root
Posted by Pete Robbins <ro...@googlemail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Pete