I also quiet liked being able to define these in definitions.xml files instead of programmatically, is that still going to be an option? Seems a shame if we have to give that up just because of a problem with our build assembly.
...ant On Thu, Feb 28, 2008 at 9:27 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > 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] > > > > >
