Hi Ant, Thats going to remain. The providers that I have in mind will just about load the definitions.xml file using the DocProcessor and hand the resulting model out. If we do end up with a need to create the model programmatically then its upto the provider that gets to be written at that time.
Thanks - Venkat On Fri, Feb 29, 2008 at 12:05 PM, ant elder <[EMAIL PROTECTED]> wrote: > 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] > > > > > > > > >
