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]
