Hi, Alright, point taken :). I am going to resolve this with the provider option and also clean up based on your suggestions. Thanks.
- Venkat On Thu, Feb 28, 2008 at 12:17 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Venkata Krishnan wrote: > > Hi Sebastien, > > > > Thanks for the suggestion. Going by the ProviderExtesionPoint way... > > > > - first I'd prefer load the definitions.xml instead of creating > > programmatically so that we don't have to touch the code for every > change to > > the definitions. > > Definitions.xml is code, it's just XML code and not Java code. > > The choice really depends on what you have in your policy definitions, > and which one is simpler in each extension case: > > SCADefinitions definition = new SCADefinitionsImpl(); > SCABindingType bindingType = new SCABindingTypeImpl(); > definition.getBindingTypes().add(bindingType); > > or > > <sca:definitions xmlns="http://www.osoa.org/xmlns/sca/1.0" > targetNamespace="http://www.osoa.org/xmlns/sca/1.0" > xmlns:sca="http://www.osoa.org/xmlns/sca/1.0" > xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"> > > <bindingType.../> > > </sca:definitions> > > BTW I noticed that there are two copies of BindingTypeImpl in the policy > and definitions modules, but no factories for these policy model objects > (forcing code to depend on the model implementation classes). > > Also I think it would be simpler to regroup the definitions model and > the policies model in a single module. > > > - every module that has its own definitions.xml must define it in a > unique > > path so that the file does not get lost when we are making the > > tuscany-sca-all jar file in the distro. > > > > So, given that every module HAS to define its definitions.xml in a > unique > > path I am wondering if it would just enuf for each module then to just > about > > publish the path for this in a file similar to the ones in > > META-INF/services. So even when this file is aggregated by the shade > plugin > > when making the tuscany-sca-all jar, we still have the location paths of > all > > definitions.xml. Is this a viable alternative ? > > > > It is a viable alternative but adds yet another mechanism to contribute > pieces of extensions. I think it's better to stick to a single > consistent mechanism. > > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >