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
