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]

Reply via email to