Oliver Heger a écrit :
I added an explicit dependency to the newest version of the checkstyle
plugin to project.xml. This should solve the problem with checkstyle.
Thank you Oliver and Niall, it does indeed fix this issue.
For the other problem I agree with Nial's answer: Obviously the lower
version of the xdoc plugin causes more problems than it solves. So we
should better go with the current version, especially if this is the
standard for most of the commons components.
That's the easy solution I agree, I don't want to waste too much time
getting the titles right if Maven impose its own standard.
But I'm concerned about our nightly reports sending false positives
(xdoc) and missing real issues (checkstyle). Maybe it's time to
reinstall Maven for the nightly builds, or is this too much trouble ?
Now the new dependency to javax.mail causes me trouble: Compiling with
JDK 1.3 fails now because the compiler reports an invalid class version.
The mail jar has been compiled with a JDK > 1.3. So what do we do?
I'll check if we can use a previous version of javamail compatible with
Java 1.3.
In general I wonder whether all these specialized get methods make sense
for DataConfiguration. Wouldn't it be better and more flexible to have a
generic method
Object getProperty(String key, Class targetClass)
and then provide a means for registering arbitrary converters? We could
indeed use the Beanutils converters for this purpose as was suggested by
one jira ticket.
Actually we have the generic methods ! :) I didn't add more specialized
get methods in DataConfiguration for the new types, instead I introduced
generic getters :
get(Class cls, String key)
getArray(Class cls, String key)
getList(Class cls, String key)
The specialized getters now call the generic getters (except for Date
and Calendar), this cuts the nloc by a half. It might be worth moving
these methods into AbstractConfiguration now, they offer the features of
DataConfiguration without the horde of methods. They would be a nice
addition to the Configuration interface for the next major release too.
Regarding the converters I believe we'll probably delegate this part to
another API sooner or later (Morph, Beanutils...), but I don't want to
add another core dependency. I was thinking about a pluggable conversion
system, we would provide a basic implementation derived from the current
code in PropertyConverter, and if someone wants more complex conversions
he could plug a custom converter using another API.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
