Deployment question: Does the name of the .composite file HAVE to match the name of the composite? Previously we just loaded any sca.module file and the name="" parameter gave the module name. There is still a name="" parameter so we end up with a file called CalculatorComposite.composite with
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"; name="CalculatorComposite"> Either the file naming convention or the name= is redundant? On 09/08/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
I'll take a look at the windows side of things. Cheers, On 09/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Jean-Sebastien Delfino wrote: > > Pete Robbins wrote: > >> So are you changing the loader to load the schema from xsd/new > >> instead of > >> xsd? Personally I would just "go for it" and check in the new xsds as > we > >> need to get this working anyway. > >> > >> Cheers, > >> > >> > > So I just went for it and made a set of changes to provide an initial - > minimal - support for the 0.95 composite assembly model and checked in > these changes earlier this morning. > > Here's a quick summary of changes: > - most Module, EntryPoint, ExternalService have been renamed to > Composite, Service, Reference > - build descriptors and scripts updated and working - on Linux only > - new XSDs for the composite model > - the ModelLoader ported to the new XSDs > - application packaging structure changed to use composites to describe > "subsystems" > - Calculator sample ported to the composite model and working > - BigBank sample ported to the composite and one inch from working > > Obvious limitations: > - includes are not supported, we are scanning for composite files right > now, this should be changed to use <include> > - properties not really supported, I couldn't figure out to get the > defaultValue from the XML element content - it's just my ignorance of > the SDO APIs and I think I'll never get how the SDO Sequence actually > works :) > - no recursion / support for nested composites, this will require some > code restructuring but is not needed by the samples > - the application packaging story still based on the old structure from > M1 (a subsystems and composites directory), we may want to start a > design discussion to see where we want to take this. > > > To summarize, this is just a first step... there is a lot to do to > provide complete support. Support for includes and properties would be > great to have... Also I am still not able to test on Windows, I'm not > sure how to refactor the Windows build scripts and VC projects. Is > anybody interested in helping with the code changes and/or the Windows > integration? > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete
-- Pete
