RE: [configuration] DOM vs DOM4J
I think a good solution is to do what Log4J has done with there distribution. Include a number of "contrib" classes in the distribution. I agree with the sentiment to get rid of Dom4JConfiguration, as I think it would make it easier to address some larger issues with the API - like why does this thing only load resources from the system classloader? From: Maarten Coene [mailto:[EMAIL PROTECTED] Sent: Wed 6/23/2004 5:30 AM To: Jakarta Commons Developers List Subject: Re: [configuration] DOM vs DOM4J And what about donating the code to the dom4j project if you decide to remove it? Maarten Eric Pugh wrote: >It'll be in CVS if we come up with a reason to reimplement it... > >Eric > > > >>-Original Message- >>From: Jörg Schaible [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, June 23, 2004 9:19 AM >>To: Jakarta Commons Developers List >>Subject: RE: [configuration] DOM vs DOM4J >> >> >>Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: >> >> >> >>>Jörg Schaible wrote: >>> >>> >>> >>>>Taking Paul's comment into account, there seems not to be a real >>>>sufficient solution. DOCConfiguration is quite nice for JDK >= 1.4, >>>>since no additional dependency is generated. Therefore I vote in >>>>first place for the DOMConfiguration, but it might be good to have >>>>DOM4JConfiguration in e.g. commons-configuration-optional around and >>>>the possibility to tell the "core" to use this implementation. >>>> >>>>Comments? >>>> >>>> >>>DOMConfiguration is even nice for JDK 1.3 since most server >>>environnements under this version provide the standard XML >>>APIs. I don't >>>think [configuration] is performance critical enough to >>>justify the use >>>of an additional dependency, and there are other possible >>>optimizations if a better implementation is really needed (for >>>example the properties could be stored only once in the >>>BaseConfiguration and the DOM parser could be dropped for a SAX >>>parser). >>> >>>I tend to prefer a complete removal of the DOM4J classes to >>>cut down the >>>maintenance burden. >>> >>> >>Fine with me. >> >>-- Jörg >> >>- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] DOM vs DOM4J
And what about donating the code to the dom4j project if you decide to remove it? Maarten Eric Pugh wrote: It'll be in CVS if we come up with a reason to reimplement it... Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 9:19 AM To: Jakarta Commons Developers List Subject: RE: [configuration] DOM vs DOM4J Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: Jörg Schaible wrote: Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK >= 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the "core" to use this implementation. Comments? DOMConfiguration is even nice for JDK 1.3 since most server environnements under this version provide the standard XML APIs. I don't think [configuration] is performance critical enough to justify the use of an additional dependency, and there are other possible optimizations if a better implementation is really needed (for example the properties could be stored only once in the BaseConfiguration and the DOM parser could be dropped for a SAX parser). I tend to prefer a complete removal of the DOM4J classes to cut down the maintenance burden. Fine with me. -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] DOM vs DOM4J
It'll be in CVS if we come up with a reason to reimplement it... Eric > -Original Message- > From: Jörg Schaible [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 23, 2004 9:19 AM > To: Jakarta Commons Developers List > Subject: RE: [configuration] DOM vs DOM4J > > > Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: > > > Jörg Schaible wrote: > > > >> Taking Paul's comment into account, there seems not to be a real > >> sufficient solution. DOCConfiguration is quite nice for JDK >= 1.4, > >> since no additional dependency is generated. Therefore I vote in > >> first place for the DOMConfiguration, but it might be good to have > >> DOM4JConfiguration in e.g. commons-configuration-optional around and > >> the possibility to tell the "core" to use this implementation. > >> > >> Comments? > > > > DOMConfiguration is even nice for JDK 1.3 since most server > > environnements under this version provide the standard XML > > APIs. I don't > > think [configuration] is performance critical enough to > > justify the use > > of an additional dependency, and there are other possible > > optimizations if a better implementation is really needed (for > > example the properties could be stored only once in the > > BaseConfiguration and the DOM parser could be dropped for a SAX > > parser). > > > > I tend to prefer a complete removal of the DOM4J classes to > > cut down the > > maintenance burden. > > Fine with me. > > -- Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] DOM vs DOM4J
Emmanuel Bourg wrote on Tuesday, June 22, 2004 5:06 PM: > Jörg Schaible wrote: > >> Taking Paul's comment into account, there seems not to be a real >> sufficient solution. DOCConfiguration is quite nice for JDK >= 1.4, >> since no additional dependency is generated. Therefore I vote in >> first place for the DOMConfiguration, but it might be good to have >> DOM4JConfiguration in e.g. commons-configuration-optional around and >> the possibility to tell the "core" to use this implementation. >> >> Comments? > > DOMConfiguration is even nice for JDK 1.3 since most server > environnements under this version provide the standard XML > APIs. I don't > think [configuration] is performance critical enough to > justify the use > of an additional dependency, and there are other possible > optimizations if a better implementation is really needed (for > example the properties could be stored only once in the > BaseConfiguration and the DOM parser could be dropped for a SAX > parser). > > I tend to prefer a complete removal of the DOM4J classes to > cut down the > maintenance burden. Fine with me. -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] DOM vs DOM4J
Jörg Schaible wrote: Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK >= 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the "core" to use this implementation. Comments? DOMConfiguration is even nice for JDK 1.3 since most server environnements under this version provide the standard XML APIs. I don't think [configuration] is performance critical enough to justify the use of an additional dependency, and there are other possible optimizations if a better implementation is really needed (for example the properties could be stored only once in the BaseConfiguration and the DOM parser could be dropped for a SAX parser). I tend to prefer a complete removal of the DOM4J classes to cut down the maintenance burden. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] DOM vs DOM4J
Is there any harm to leaving it there? I have seen a lot of commons projects start creating these various "optional"/"extended" jars and think it is a pretty slippery slope to go down.. Part of why I turn to the Commons project is because the tools are relatively simple and don't require me to learn a ton about which jar's I need etc. I think we should either keep it or toss it, but not start an "optional" package. At least, not until we get 1.0 out. After all, how do you decide which configurations go in the main versus the optional package? Eric > -Original Message- > From: Jörg Schaible [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 22, 2004 9:00 AM > To: Jakarta Commons Developers List > Subject: RE: [configuration] DOM vs DOM4J > > > Emmanuel Bourg wrote on Monday, June 21, 2004 8:17 PM: > > > Is there a good reason to keep the configurations using DOM4J instead > > of their DOM based equivalent ? If there is no difference > > between the two > > I'm tempted to remove DOM4JConfiguration and > > HierarchicalDOM4JConfiguration (or to move them to a contrib > > directory), and then merge DOMConfiguration into XMLConfiguration and > > HierarchicalDOMJConfiguration into HierarchicalConfiguration. > > > > What do you think ? > > Taking Paul's comment into account, there seems not to be a real > sufficient solution. DOCConfiguration is quite nice for JDK >= > 1.4, since no additional dependency is generated. Therefore I > vote in first place for the DOMConfiguration, but it might be > good to have DOM4JConfiguration in e.g. > commons-configuration-optional around and the possibility to tell > the "core" to use this implementation. > > Comments? > > -- Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] DOM vs DOM4J
Emmanuel Bourg wrote on Monday, June 21, 2004 8:17 PM: > Is there a good reason to keep the configurations using DOM4J instead > of their DOM based equivalent ? If there is no difference > between the two > I'm tempted to remove DOM4JConfiguration and > HierarchicalDOM4JConfiguration (or to move them to a contrib > directory), and then merge DOMConfiguration into XMLConfiguration and > HierarchicalDOMJConfiguration into HierarchicalConfiguration. > > What do you think ? Taking Paul's comment into account, there seems not to be a real sufficient solution. DOCConfiguration is quite nice for JDK >= 1.4, since no additional dependency is generated. Therefore I vote in first place for the DOMConfiguration, but it might be good to have DOM4JConfiguration in e.g. commons-configuration-optional around and the possibility to tell the "core" to use this implementation. Comments? -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] DOM vs DOM4J
On 21-Jun-04, at 20:17 Uhr, Emmanuel Bourg wrote: Is there a good reason to keep the configurations using DOM4J instead of their DOM based equivalent ? If there is no difference between the two I'm tempted to remove DOM4JConfiguration and HierarchicalDOM4JConfiguration (or to move them to a contrib directory), and then merge DOMConfiguration into XMLConfiguration and HierarchicalDOMJConfiguration into HierarchicalConfiguration. What do you think ? Although I'm not involved in configuration I would warn about speed and memory differences. I haven't used dom4j intensively but did, at the time use jdom quite much. They are very similar in memory and speed. And this from a migration from Xerces DOM. Basically it went as follow: - time to build with Xerces DOM 100% - time to build with Xerces SAX on JDOM 50% - time to build with Saxon's Aelfred SAX on JDOM 25% Also, using dom4j might, if you do this well for it, offer you weak xml-loading using XPP... (at least in theory). my 2p paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] DOM vs DOM4J
Emmanuel Bourg wrote: > Is there a good reason to keep the configurations using DOM4J instead of > their DOM based equivalent ? If there is no difference between the two > I'm tempted to remove DOM4JConfiguration and > HierarchicalDOM4JConfiguration (or to move them to a contrib directory), > and then merge DOMConfiguration into XMLConfiguration and > HierarchicalDOMJConfiguration into HierarchicalConfiguration. > > What do you think ? +1 -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] DOM vs DOM4J
Is there a good reason to keep the configurations using DOM4J instead of their DOM based equivalent ? If there is no difference between the two I'm tempted to remove DOM4JConfiguration and HierarchicalDOM4JConfiguration (or to move them to a contrib directory), and then merge DOMConfiguration into XMLConfiguration and HierarchicalDOMJConfiguration into HierarchicalConfiguration. What do you think ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
