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