Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Mail-Followup-To: commons-dev@jakarta.apache.org
To: commons-dev@jakarta.apache.org
From: =?ISO-8859-15?Q?J=F6rg?= Schaible <joerg.schaible@gmx.de>
Subject: RE: [configuration] Roadmap
Date: Sat, 06 Mar 2004 23:32:08 +0100
Lines: 58
Message-ID: <c2djh9$asd$1@sea.gmane.org>
References: <F0D7281DAB048B438E8F5EC4ECEFBDDC17602E@esmail.elsag.de>
Reply-To: joerg.schaible@gmx.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8Bit
Mail-Copies-To: never
User-Agent: KNode/0.7.6
Sender: news <news@sea.gmane.org>

J�rg Schaible wrote:
> Emmanuel Bourg wrote on Thursday, March 04, 2004 2:48 PM:
> 
>> There has been some good ideas coming around [configuration] lately,
>> I'd like to suggest a roadmap to sort what needs to be done
>> before the 1.0
>> release and what could be added later:
>> 
>> configuration 1.0
>> 
>> - make PropertiesConfiguration a full replacement for
>> ExtendedProperties: add headers to .properties files (Bug 26092) and
>> make Configuration extend Map.
> 
> remove here also the dependency to StringUtils (just used to handle an
> empty String). Basic idea - if I just use properties and DOM, I would like
> to have the least number of dependencies as possible. If other lang
> functionality would have been used here, no problem - but *not* for an
> empty String test ...
> 
>> - comma separated values revamp
>> - DOM4J dependency removal
> 
> Working on this. I understand correctly, that this just means support of
> DOM, but no deprecation of JDOM ?

Had less time this weekend than expected, but here it is at least the DOM
support:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27498

> Working also on a "pluggable" ConfigurationFactory. What is the intension
> for the functionality of the current ConfigurationFactory ? Support any
> Configuration type (= backward compatibility) ? I would introduce an
> AbtractConfigurationFactory refactoring the common parts. Name of the
> PluggableConfigurationFactory (ConfigurableConfigurationFactory <g>) ?
> Introduce a Jdk14ConfigurationFactory (with least number of dependencies)
> ?

I have another idea: We stay with the current class, but change its
configuration files. We could define factory elements:

<factory type="xml"
className="org.apache.commons.configuration.DOMConfiguration" />

and use them now in config elements:

<config type="xml" fileName="conf/test.xml" [at="mail"] />

Then we could deprecate all of the current elements reading a configuration
and may provide a DTD even if a customer writes his own configuration
format. Additionally we remove the direct dependency for all the
implementations from the ConfigurationFactory (no DOM4J, no DB, no JNDI if
not used or needed).

What do you think? IMHO better now than after release.

Regards,
J�rg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org