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