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
