commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michiel Kalkman" <michielgkalk...@gmail.com>
Subject Re: [configuration] JDK compatibility
Date Thu, 13 Dec 2007 16:52:58 GMT
On 12/13/07, Torsten Curdt <tcurdt@apache.org> wrote:
>
> On 13.12.2007, at 14:38, Michiel Kalkman wrote:
>
> > +1/-1
> >
> > I am all for using jdk 1.5, but I guess it will take some time before
> > I can use this jdk at work. Is it possible and easy to generate an 1.4
> > compatible binary version from 1.5 sources ? If so, I'd say go for it.
>
> This comes up all the time. Frankly speaking IMO this is a moo point.
> No one forces people to upgrade to a new version. Fact is though if
> you want the newer features you might have to bite the bullet and
> either upgrade your system or backport changes. The old stable
> version is just in maintenance mode and will not go away. But I am
> quite tired of having this backwards compatibility reasons making
> life at commons so much harder. Time moves on so should we. Of course
> it would be nice to provide binaries via retrotranslator ...if
> possible. But I think we need to move forward on this.

Points taken. I prefer going to jdk 1.5, I just think a number of
companies will not be able to follow soon. Furthermore, if there is a
possibility to make stuff backwards compatible, there is no reason for
a maintenance release.

>
> > Just some additional thoughts (maybe they should be in another
> > thread):
> > - when considering package names, maybe it is an idea to work towards
> > a plugin-alike structuring. It might be interesting if future
> > development of some configuration format (INI,JNDI,etc) could be
> > independent from, say, core components.
>
> Not sure what you mean here.

There is a lot of stuff in org.apache.commons.configuration and if you
want to reconfigure packages, at least consider something like
org.apache.commons.configuration.sources.* with code dealing with
specific formats like XML files or INI files in order to seperate them
from base classes, like BaseConfiguration.

A basic idea behind CommonsConfig is to separate configuration
processing from configuration formats, is it not ? I guess that should
be represented in the package structure.

I was also thinking of something like OSGI. Just a small core.
Format-specific stuff in plugins, etc. Then just use the plugins you
need; if you need XML, include xerces, otherwise don't. Release new
plugins independent from the core. But that is probably too
farfetched.

>
> > - I think some prototype ui components (swing,jsp,etc.) might be a
> > useful future addition, if only as a starting point for developing
> > really useable ui components (and probably also as a teaser for new
> > users), so you might want to consider that when considering package
> > names as well.
>
> You mean as new projects? ...I think that's for some other thread :)

Well, if someone has a sample of using CommonsConfig in swing or jsp,
i am interested :)

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

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


Mime
View raw message