On 12/13/07, Torsten Curdt <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
