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]
>
>

Reply via email to