Hi all,
I'm a bit late in this discussion, I'm quite favorable to an upgrade of
the minimum JDK required, JDK 1.3 compatibility is really handicapping
nowadays. I just hope this doesn't imply designing a new configuration
API based on the current code, or this could turn into another cli2 like
Yes, the configuration2-packaged classes should be part of the 2.x
release series.
On 12/18/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> >> So I will probably follow this road. This is a good opportunity for a
> >> refactoring and polishing of some interfaces and base
> >> classes. Because
> >>
So I will probably follow this road. This is a good opportunity for a
refactoring and polishing of some interfaces and base
classes. Because
we will have major changes, changing the package name (maybe to
o.a.c.configuration2?) will certainly make sense.
I'd go for o.a.c.configuration2 here.
s
Hi Oliver,
[snip]
Oliver Heger wrote:
> This is pretty much the reaction I was hoping for :-)
>
> So I will probably follow this road. This is a good opportunity for a
> refactoring and polishing of some interfaces and base
> classes. Because
> we will have major changes, changing the package na
Oliver Heger skrev den 13-12-2007 08:16:
- Does a switch in the JDK version require a major release?
Please keep any changes in environmental requirements to a major
release. I for one expect that 1.Y may replace 1.X without any thought.
--
Thorbjørn
--
Jörg Schaible wrote:
Oliver Heger wrote:
(There was a similar discussion about commons lang recently.)
Configuration used to support JDK 1.3. For the next release (either
1.6 or 2.0) I would like to drop this compatibility. The number
of feature
requests that require a newer JDK version is incr
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 versio
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
+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.
Just some additional thoughts (maybe they should be in another thread):
- when
+1. We need to come up with a standardized way of dealing with this
though I think. At first I didn't like changing package names, but it
does help avoid the "jar hell" issue.
On 12/13/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
> >> - go for 1.5
> >> - take advantage of generics
> > +
On Dec 13, 2007 8:42 AM, Jörg Schaible
<[EMAIL PROTECTED]> wrote:
> Oliver Heger wrote:
> > (There was a similar discussion about commons lang recently.)
> >
> > Configuration used to support JDK 1.3. For the next release (either
> > 1.6 or 2.0) I would like to drop this compatibility. The number
>
Hi!
>> - go for 1.5
>> - take advantage of generics
> +1!!! Frankly speaking this is probably applies to most of commons.
>
> If commons wants to stay relevant and not become just legacy we also
> need to take some steps forward.
+1 ... long overdue maybe too long!?
Ciao,
Mario
"Jörg Schaible" <[EMAIL PROTECTED]> schrieb:
> Oliver Heger wrote:
> > (There was a similar discussion about commons lang recently.)
> >
> > Configuration used to support JDK 1.3. For the next release (either
> > 1.6 or 2.0) I would like to drop this compatibility. The number
> > of feature
>
On 13.12.2007, at 09:42, Jörg Schaible wrote:
Oliver Heger wrote:
(There was a similar discussion about commons lang recently.)
Configuration used to support JDK 1.3. For the next release (either
1.6 or 2.0) I would like to drop this compatibility. The number
of feature
requests that require
Oliver Heger wrote:
> (There was a similar discussion about commons lang recently.)
>
> Configuration used to support JDK 1.3. For the next release (either
> 1.6 or 2.0) I would like to drop this compatibility. The number
> of feature
> requests that require a newer JDK version is increasing.
>
>
(There was a similar discussion about commons lang recently.)
Configuration used to support JDK 1.3. For the next release (either 1.6
or 2.0) I would like to drop this compatibility. The number of feature
requests that require a newer JDK version is increasing.
This raises a couple of questio
16 matches
Mail list logo
