I don't like the idea of being so tighted to a specific implementation (especially a xml parser) but AFAIK this feature unfortunately does not exist in other parsers (except with the DOM L2 importNode), and I didn't feel like cloning all elements of the tree right now (this is prototype after all, no need to reinvent the wheel :-).

Once this is validated I would prefer to remains parser independant and add additional code, at least it will avoid parser transition problem, and plus performance should not be an issue.

--
 Stéphane Bailliez
 Software Engineer, Paris - France
 iMediation - http://www.imediation.com
 Disclaimer: All the opinions expressed above are mine and not those from my company.



> -----Original Message-----
> From: Conor MacNeill [mailto:conor@cognet.com.au]
> Sent: Tuesday, January 02, 2001 2:18 PM
> To: ant-dev@jakarta.apache.org
> Subject: Re: License problem
>
>
> Stephane,
>
> Sure, I didn't consider antidote as I don't use the GUI, at
> least not yet.
> Not that keen on tying the GUI or JUnit to a particular XML
> parser either.
>
> Conor
>
>
> ----- Original Message -----
> From: "Stephane Bailliez" <sbailliez@imediation.com>
> To: <ant-dev@jakarta.apache.org>
> Cc: <Guillaume.Rousse@univ-reunion.fr>
> Sent: Tuesday, January 02, 2001 11:28 PM
> Subject: RE: License problem
>
>
>
> Actually this is possible for the ant core, but there are
> explicit import
> of
> com.sun.xml into ACS and there possibly could be some in the
> optional tasks
> (even though there is no one right now)
>
> I'm writing some prototype classes for the JUnit task that involves
> (unfortunatly) a specific operation of the sun xml parser
> (the ability to
> aggregate xml documents by using changeNodeOwner). The intent is to be
> somewhat a quick fix to aggregate all test results into a
> single document
> while I'm thinking about an enhanced design of the JUnit task.
>
> --
>  Stéphane Bailliez
>  Software Engineer, Paris - France
>  iMediation - http://www.imediation.com
>  Disclaimer: All the opinions expressed above are mine and
> not those from
> my
> company.
>
>
>
> > -----Original Message-----
> > From: Conor MacNeill [mailto:conor@cognet.com.au]
> > Sent: Tuesday, January 02, 2001 12:57 PM
> > To: ant-dev@jakarta.apache.org
> > Cc: Guillaume.Rousse@univ-reunion.fr
> > Subject: Re: License problem
> >
> >
> > Guillaume,
> >
> > I think you have two choices.
> >
> > 1. Take out the two jars and instruct the users to place
> > their favourite
> > JAXP parser into the ant/lib directory
> > 2. just drop xerces.jar in there in their place.
> >
> > I tried this with a xerces.jar, I built from the latest
> source and it
> > worked nicely. If you do go down that path, you need to pick
> > a particular
> > xerces released version, I guess. You would probably want to
> > test that it
> > works too.
> >
> > The downside of the xerces solution is that the xerces.jar is ~770k,
> > compared with ~140k for the reference JAXP implementation.
> > Not a big deal,
> > IMHO, but may be important to some.
> >
> > Cheers
> > Conor
> >
> >
> > ----- Original Message -----
> > From: "Guillaume Rousse" <Guillaume.Rousse@univ-reunion.fr>
> > To: <ant-dev@jakarta.apache.org>
> > Sent: Tuesday, January 02, 2001 10:51 AM
> > Subject: License problem
> >
> >
> > > Hello.
> > > I wanted to package ant for Mandrake, but i saw those two infamous
> > > binaries ;-) file in ant sources : jaxp.jar and parser.jar,
> > which are (i
> > > suppose) covered by Sun's java license. If i wanted to do a
> > open-source
> > > only package, can i:
> > > -externalise those two files into another binary package, than put
> > > depencies on it for building/running ant ?
> > > -replace them completly by xerces ?
> > > In both case, what sould i change in ant buildfile for
> building it ?
> > >
> > > As i'm not subscribed, please send your answer to my adress too.
> > > Thanks for your help.
> > > --
> > > Guillaume Rousse
> > >
> > > Murphy's law : If anything can go wrong, it will.
> > > O'Tool's commentary : Murphy was an optimist.
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>