Hi,
On Feb 12, 2008 12:27 AM, Gary Gregory <[EMAIL PROTECTED]> wrote:
> Perhaps we should do the following in trunk:
>
> 1) Generify (I know, it's not a word and it is funny that my spellchecker
> suggests 'gentrify')) everything
> and keep backwards compatibility (this has started)
> 2) Re-imple
ilto:[EMAIL PROTECTED]
> Sent: Monday, February 11, 2008 10:34 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> >>> I still don't see the need to overhaul the entire API.
> >>
> >> And I don't see
I still don't see the need to overhaul the entire API.
And I don't see the point why we shouldn't. Going from from java 1.4
-> 1.5 usually means a bit overhaul.
Perhaps usually, but for Commons IO?
The question was - why not? We are running around in circles here.
I see only a few isolated
sten Curdt [mailto:[EMAIL PROTECTED]
> > Sent: Monday, February 11, 2008 4:39 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > >> Additionally, nobody stops us from shipping an io compat librar
> Sent: Monday, February 11, 2008 4:39 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> >> Additionally, nobody stops us from shipping an io compat library
> >> which translates the
> >> calls original io 1.
Hi,
On Feb 11, 2008 2:38 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > I still don't see the need to overhaul the entire API.
>
> And I don't see the point why we shouldn't. Going from from java 1.4
> -> 1.5 usually means a bit overhaul.
Perhaps usually, but for Commons IO?
I see only a few i
Additionally, nobody stops us from shipping an io compat library
which translates the
calls original io 1.x calls for io2. That one can be used as real
replacement of old 1.x
series, but offers the possibility to use as much Java 5 specifics
as possible in the
new API (varargs, new interface
Hi,
On Feb 11, 2008 11:02 AM, Jörg Schaible
<[EMAIL PROTECTED]> wrote:
> Additionally, nobody stops us from shipping an io compat library which
> translates the
> calls original io 1.x calls for io2. That one can be used as real replacement
> of old 1.x
> series, but offers the possibility to us
Gary Gregory wrote:
> Ag, let's not have /both/ io and io2, this gets messy.
+1
Additionally, nobody stops us from shipping an io compat library which
translates the calls original io 1.x calls for io2. That one can be used as
real replacement of old 1.x series, but offers the possibility to us
TED]>
To: Jakarta Commons Developers List
Sent: Sat Feb 09 10:25:03 2008
Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
Just out of curiosity, would it be possible to maintain a single API and
have separate implementation JARs? Or are there plans to change method
signatures as well (suc
-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > On Behalf Of James Carman
> > Sent: Friday, February 08, 2008 5:50 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > So, you are suggesti
On Feb 9, 2008 8:01 AM, Gary Gregory <[EMAIL PROTECTED]> wrote:
>
> > -Original Message-
> > From: Niall Pemberton [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 08, 2008 5:40 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0
> -Original Message-
> From: Niall Pemberton [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 08, 2008 5:40 PM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On Feb 8, 2008 4:32 PM, Gary Gregory <[EMAIL PROTECTED]&g
On Feb 8, 2008 4:32 PM, Gary Gregory <[EMAIL PROTECTED]> wrote:
> > From: Jukka Zitting [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 08, 2008 8:24 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
&g
Hi,
On Feb 8, 2008 6:32 PM, Gary Gregory <[EMAIL PROTECTED]> wrote:
> > You'd only need to upgrade to SomeClass2 if you actually need the new
> > functionality, otherwise you could just keep using the old API when
> > upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would
> > need
Carman
> Sent: Friday, February 08, 2008 7:24 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On Feb 8, 2008 3:49 PM, James Carman <[EMAI
> From: Jukka Zitting [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 08, 2008 8:24 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> Hi,
>
> On Feb 8, 2008 5:24 PM, James Carman <[EMAIL PROTECTED]> wrote:
> &
Hi,
On Feb 8, 2008 5:24 PM, James Carman <[EMAIL PROTECTED]> wrote:
> On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > be changed extensively to match "Java 5 style", then I'd name the
> > modified version o.a.c.io.S
Ag, let's not have /both/ io and io2, this gets messy.
Thank you,
Gary
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of James Carman
> Sent: Friday, February 08, 2008 5:50 AM
> To: Jakarta Commons Developers List
> Subject:
On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Feb 8, 2008 3:49 PM, James Carman <[EMAIL PROTECTED]> wrote:
> > So, you are suggesting having part of a release in the o.a.c.io
> > package and the other part in the o.a.c.io2?
>
> No. I'd keep everything in o.a.c.io.
>
> If there's
Hi,
On Feb 8, 2008 3:49 PM, James Carman <[EMAIL PROTECTED]> wrote:
> So, you are suggesting having part of a release in the o.a.c.io
> package and the other part in the o.a.c.io2?
No. I'd keep everything in o.a.c.io.
If there's a class or interface, say o.a.c.io.SomeClass, that needs to
be chan
I agree with James here. Spanning across packages makes this whole
thing overly complex. IMO we should keep it easy and consistent.
org.apache.commons.io = 1.x
org.apache.commons.io2 = 2.x
...
I think we are a little too afraid to maintain a second branch here.
I know we are few people. But
So, you are suggesting having part of a release in the o.a.c.io
package and the other part in the o.a.c.io2? It seems rather
inconsistent, but I guess it would work. Isn't that going to get
ugly with 3.x and 4.x releases adding to the mix?
On 2/8/08, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> H
Hi,
On Feb 6, 2008 1:51 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> So the changes are pretty minimal for IO - question is are these
> incompatible changes with generics being erased? If not then perhaps
> we can do this without breaking anything.
+1 If there are cases where we can't avoid b
On Feb 7, 2008 8:10 AM, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> Niall Pemberton wrote:
> >>> [Note CharSequence replaces String and/or StringBuffer flavours]
> >
> > OK for the above I added new methods, rather than changing the method
> > signature - so still compatbile atm:
> >http://
Niall Pemberton wrote:
[Note CharSequence replaces String and/or StringBuffer flavours]
OK for the above I added new methods, rather than changing the method
signature - so still compatbile atm:
http://svn.apache.org/viewvc?view=rev&revision=619188
Although, the API is now bigger. If we de
On Feb 6, 2008 8:25 PM, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> The following would be binary backwards incompatible:
>
> > FileUtils
> > - public static void writeStringToFile(File file, CharSequence data,
> > String encoding)
> >[note CharSequence version replaces String falvour]
>
>
The following would be binary backwards incompatible:
FileUtils
- public static void writeStringToFile(File file, CharSequence data,
String encoding)
[note CharSequence version replaces String falvour]
IOUtils
- public static InputStream toInputStream(CharSequence input)
- public static
Gary Gregory wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Benedict
Niall, I agree as well. I don't see a strong reason for keeping any
deprecations if the package structure is changing. It is no longer binary
compatible -- especially if you begin at version 1.0 again
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Paul Benedict
> Sent: Wednesday, February 06, 2008 7:59 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> Niall, I agree as well. I don't see a str
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of James Carman
> Sent: Wednesday, February 06, 2008 8:05 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On 2/6/08, Paul Benedict <[EMAIL PROTECTED]> wrote:
I only mentioned starting at 1.0 again because I saw "Commons Lang Two 1.0"
listed in JIRA. It makes sense to me, although it is very awkward to digest.
:-) That's why I would rather advocate IO 2.0 keeping the same package
naming. No binary compatibility is guaranteed between major releases anyway
Stephen Colebourne skrev den 06-02-2008 12:00:
IMO, Java 5+ is almost a different language to pre Java 5. The fact that the
Java community has taken ages to move up is a sign of this.
I believe that the sole reason for this is that Sun chose to enforce
that Java 5 could only compile to byt
Niall Pemberton <[EMAIL PROTECTED]> schrieb:
> On Feb 6, 2008 1:44 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> > > Deprecation is useful when a method has been
> > > implemented incorrectly, and we want to push users
> > > to a repla
On 2/6/08, Paul Benedict <[EMAIL PROTECTED]> wrote:
> Niall, I agree as well. I don't see a strong reason for keeping any
> deprecations if the package structure is changing. It is no longer binary
> compatible -- especially if you begin at version 1.0 again.
Version 1.0? So, it'd be org.apache.c
Niall, I agree as well. I don't see a strong reason for keeping any
deprecations if the package structure is changing. It is no longer binary
compatible -- especially if you begin at version 1.0 again.
Paul
On Feb 6, 2008 9:46 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On Feb 6, 2008 1:44
On Feb 6, 2008 1:44 PM, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> > Deprecation is useful when a method has been
> > implemented incorrectly, and we want to push users
> > to a replacement, or for similar issues. Removing deprecated
> > class
Just going to throw in my two cents here...
When a project chooses a different package structure (struts/struts2,
io/io2, etc.), it's advertising itself as truly independent implementations.
That is, you could run Struts 1 and Struts 2 in one application, and also
use Commons IO 1 and Commons IO 2
Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> Deprecation is useful when a method has been
> implemented incorrectly, and we want to push users
> to a replacement, or for similar issues. Removing deprecated
> classes/methods should be considered in a major version change,
> but even there
I don't know if it helps this debate, but when I went thru JDK 1.5
changes for IO I came up with the following (which are mostly
generifying methods):
ConditionalFileFilter (interface)
- public List getFileFilters()
- public void setFileFilters(final List fileFilters) {
AndFileFilter
- publ
Because it is absolutely essential that we allow compatibility
with the older release.
Specifically, it is a requirement that if there are any binary or
source incompatible changes, then an application must be able to
run with both the old and new jar files (v1.4 and v2.0). The only
pract
From: Henri Yandell <[EMAIL PROTECTED]>
On Feb 5, 2008 5:27 AM, Stephen Colebourne
<[EMAIL PROTECTED]> wrote:
> > The practical impact of a new package is small to users that use
commons-io directly - a quick organize imports in an IDE. The impact of NOT
doing this would be jar hell, if your app
From: Jochen Wiedmann <[EMAIL PROTECTED]>
> I second this. IMO, binary compatibility is overemphasized in commons.
> In my practical experience I always found it to be sufficient that a
> change is detected by the compiler.
If your application uses a commons jar directly, then breaking binary
co
On Feb 6, 2008 5:02 AM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> I buy your argument for huge changes, ie) collections-generics is very
> much a different product. I don't buy it for small API changes and
> removal of deprecation. Your argument would imply that we should never
> deprecate (as we
On Feb 5, 2008 5:27 AM, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> On 05.02.2008, at 06:44, Henri Yandell wrote:
> > For Collections it makes sense as there's a big API change planned.
> > For the others, I think they should charge in and see what kind of
> API
> > changes are required. If w
> From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 05, 2008 2:19 PM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> Simon Kitching wrote:
> > Stephen Colebourne <[EMAIL PROTECTED]> schrieb
Simon Kitching wrote:
Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
On Feb 4, 2008 8:47 PM, Niall Pemberton <[EMAIL PROTECTED]>
From memory the preference was to move to a new package name - how
about "org.apache.commons.io2"?
To avoid confusion with version numbers, we could choose [
On Feb 5, 2008 6:09 PM, Gary Gregory <[EMAIL PROTECTED]> wrote:
> > From: Niall Pemberton [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 05, 2008 9:52 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> &
> From: Niall Pemberton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 05, 2008 9:52 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On Feb 5, 2008 5:49 PM, Gary Gregory <[EMAIL PROTECTED]> wrote:
> > Should we
om: Niall Pemberton [mailto:[EMAIL PROTECTED]
> > Sent: Monday, February 04, 2008 8:47 PM
> > To: Commons Developers List
> > Subject: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> > th
bject: [io] 2.0 Moving to minimum of JDK 1.5
>
> We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> theres also an JIRA report here:
>http://issues.apache.org/jira/browse/IO-140
>
> From memory the preference was to move to a new package name
Stephen Colebourne <[EMAIL PROTECTED]> schrieb:
> > On Feb 4, 2008 8:47 PM, Niall Pemberton <[EMAIL PROTECTED]>
>> From memory the preference was to move to a new package name - how
>> about "org.apache.commons.io2"?
To avoid confusion with version numbers, we could choose [io-two]:
org.ap
On Feb 5, 2008 2:27 PM, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> To avoid confusion with version numbers, we could choose [io-two]:
> org.apache.commons.io-two
I do not understand why that's less confusing if you have commons-io
version 3 in package org.apache.commons-io-two?
Jochen
-
> On Feb 4, 2008 8:47 PM, Niall Pemberton <[EMAIL PROTECTED]>
>> From memory the preference was to move to a new package name - how
>> about "org.apache.commons.io2"?
To avoid confusion with version numbers, we could choose [io-two]:
org.apache.commons.io-two
On 05.02.2008, at 06:44, Henri Ya
On 05.02.2008, at 06:44, Henri Yandell wrote:
On Feb 4, 2008 8:47 PM, Niall Pemberton <[EMAIL PROTECTED]>
wrote:
We've discussed moving to a minimum of JDK 1.5 for IO 2.0
previously -
theres also an JIRA report here:
http://issues.apache.org/jira/browse/IO-140
From memory the preference
On Feb 4, 2008 8:47 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> theres also an JIRA report here:
>http://issues.apache.org/jira/browse/IO-140
>
> From memory the preference was to move to a new package name - how
> a
We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
theres also an JIRA report here:
http://issues.apache.org/jira/browse/IO-140
>From memory the preference was to move to a new package name - how
about "org.apache.commons.io2"?
Are there any objections to me creating an IO
57 matches
Mail list logo
