Yes, we'll have to change the package names to avoid split packages in OSGi. To follow the same naming convention, I propose a slight different scheme:
For OASIS: org.apache.tuscany.sca.assembly.xml For OSOA: org.apache.tuscany.sca.assembly.xml.osoa Thanks, Raymond From: Simon Laws Sent: Thursday, March 05, 2009 7:26 AM To: [email protected] Subject: Re: [2.x] Progress update on bringing up Tuscany SCA Runtime to the latest OASIS SCA Schemas On Thu, Mar 5, 2009 at 6:06 AM, Raymond Feng <[email protected]> wrote: This is a good step toward the OASIS SCA. I made more changes under r750323 to make sure SCA composite and other files in modules/itest/samples/stest use the oasis SCA namespace. Thanks, Raymond -------------------------------------------------- From: "Luciano Resende" <[email protected]> Sent: Wednesday, March 04, 2009 3:59 PM To: <[email protected]> Subject: [2.x] Progress update on bringing up Tuscany SCA Runtime to the latest OASIS SCA Schemas - Show quoted text - We are now using OASIS Namespace and Schemas in our 2.x trunk. While I handled changes to all modules and also started providing backward compatibility based on our previous discussion [1] to the biggest set of processors responsible by dealing with composite processing, there are still more things to do (and I'd appreciate help from all the community). - Backward compatibility The approach I took is to provide a tuscany-module-xml-osoa module that would handle the specific osoa schema, contribute processors and unit test the specific processors. This is demonstrated in assembly-xml-xsd-osoa and assembly-xml-osoa. This would allow maximum flexibility for us and any users/embedders as it allows us to produce distributions that are OASIS specific (e.g.: by picking up only the default OASIS specific modules) or backward capable (e.g by picking up OASIS and OSOA set of processors). Note that, while I have done the work for our assembly-xsd and assembly-xml, I'd need help from the community to get the same pattern applied to the other extensions. - What's next Update assembly model based on the latest Assembly spec draft and current schemas Finish bring-up of modules outside java/modules to use appropriate ns/schema Provide extension-xml-osoa modules that would be used for backward compatibility Please let me know if you have questions/comments... And "the pool is open" for everybody to help bringing this up. [1] http://www.mail-archive.com/[email protected]/msg05656.html -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/ Thanks Luciano for pushing this along. Re. backward compatibility. How about we also change the package names in the xml modules so that there are no clashes? Something like org.apache.tuscany.sca.assembly.xml org.apache.tuscany.sca.assembly.v11.xml I'm in the builders at the moment looking at Endpoints. There are different semantics here in OASIS compared to OSOA. I'll think about how we represent this variability. My first thought is that we add the sca namespace to the composite model that has been read and use this infromation as appropriate. Builders now have an extension point so we have the option of extending this to load versioned builders or even doing version specific processing inside the builders. I think the first is the most obvious approach. Simon
