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 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
