Hi, This is certainly a good option. We just about have to do two simple things in this transformer.
- Create a definitions.xml file with the xml declaration and <sca:definitions> start element - The for every definitions.xml file read, skip upto the <sca: definitions.xml> and copy everything else upto the </sca:definitions> element - Finally end this aggregated file with </sca:definitions> Let me look up the link you provided to see if this is quickly workable. Thanks. - Venkat On Fri, Feb 29, 2008 at 1:09 PM, ant elder <[EMAIL PROTECTED]> wrote: > Could we just add our own Shade transformer that knows how to aggregate > the > definitions files? Eg TO SUPPORT something like this in the shade plugin > config: > > <transformer implementation=" > org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer"> > <resource>META-INF/services/definitions.xml</resource> > </transformer> > > You can see the src of other Shade plugins and they're not too complicated > - > > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.java > > ...ant > > On Fri, Feb 29, 2008 at 6:35 AM, 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] > > > > > > > > > > > > > > > >
