[IO] Almost ready for a 1.1 release?

[Martin Cooper <mf...@gmail.com>]

There have been a lot of changes since IO 1.0 was released, and I'm
thinking we're in pretty good shape for a 1.1 release in the near
future.

I've worked through the bug reports, and got us down to four
outstanding change requests, as follows:

Bugs:
#29140 - NPE in FileUtils.listFiles(dir, extensions, recursive)
#30974 - problem with copyFileToDirectory(File, File)

Enhancements:
#28977 - [io] ProxyOutputStream: no need to define proxy
#30667 - [io] new throttled input and output stream classes

With respect to the bugs, I have been unable to reproduce #29140 and
have requested a test case to nail it down. I suspect #30974 is the
infamous timing issue that I'm not clear that there's a good solution
for, unfortunately.

With respect to the enhancements, they're not my particular itches,
and I'd be more comfortable with someone else reviewing them (or
flagging them for later). However, I'm willing to apply the changes
for #30667 if I get a green light from another IO committer who's
reviewed them.

So what do folks think? I'm willing to act as RM, unless someone else
feels like rolling the release.

--
Martin Cooper

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

Re: [IO] Almost ready for a 1.1 release?

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Martin Cooper" <mf...@gmail.com>
> On Mon, 25 Oct 2004 18:55:08 -0400, Henri Yandell <fl...@gmail.com>
wrote:
> > I hadn't realised we were this close to a 1.1, but I'm +1 for a release.

Release early... means we should get a release out.

> > I just moved WildcardUtils up a directory as it's used by two
> > different subpackages of IO.
Should this just be a method on FilenameUtils? Although the class isn't
specific, maybe we should make it specific.

> > There are a couple of options on the finder code which are not
> > implemented yet (time ones I think).
> I guess it might be better to finish that up than release it not fully
> baked. ;-)
I'd rather release without the finder directory at present. I'm not sure
quite how it fits with the rest of [io] yet.

> > Is there any reason for the IOTestSuite class? It doesn't seem
> > necessary with Maven and seems unlikely to be needed by the generated
> > Maven build.xml (which we need to make sure we redo).
> Hmm, probably not. I'll make sure first, and then take it out assuming
> all is OK.
I've just fixed it, renamed it and added the other missing test suite
classes. They are used by IDE developers who don't want to run ant (and are
in fact faster if you do run ant)

> > > So what do folks think? I'm willing to act as RM, unless someone else
> > > feels like rolling the release.
+1

I currently have two errors, though:
There were 2 errors:
1)
testIsFileNewer(org.apache.commons.io.FileUtilsFileNewerTestCase)java.lang.I
llegalStateException: The temporary file hasn't the right last modification
date
 at
org.apache.commons.io.FileUtilsFileNewerTestCase.testIsFileNewer(FileUtilsFi
leNewerTestCase.java:122)
 at
org.apache.commons.io.FileUtilsFileNewerTestCase.testIsFileNewer(FileUtilsFi
leNewerTestCase.java:72)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
 at org.apache.commons.io.AllIOTestSuite.main(AllIOTestSuite.java:30)
2)
testIsFileNewerImaginaryFile(org.apache.commons.io.FileUtilsFileNewerTestCas
e)java.lang.IllegalStateException: The temporary file hasn't the right last
modification date
 at
org.apache.commons.io.FileUtilsFileNewerTestCase.testIsFileNewer(FileUtilsFi
leNewerTestCase.java:122)
 at
org.apache.commons.io.FileUtilsFileNewerTestCase.testIsFileNewerImaginaryFil
e(FileUtilsFileNewerTestCase.java:89)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
 at org.apache.commons.io.AllIOTestSuite.main(AllIOTestSuite.java:30)

and its too late to look at them. I'm Win98 in case anyone has a chance to
look.

For the release we must ensure that we run jdiff and clirr to check what has
changed and avoid all backwards binary/source incompatability.

Stephen



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

Re: [IO] Almost ready for a 1.1 release?

[Henri Yandell <fl...@gmail.com>]

On Mon, 25 Oct 2004 16:33:51 -0700, Martin Cooper <mf...@gmail.com> wrote:
> On Mon, 25 Oct 2004 18:55:08 -0400, Henri Yandell <fl...@gmail.com> wrote:
> > I hadn't realised we were this close to a 1.1, but I'm +1 for a release.
> 
> If you don't think we're ready, or there's more that you'd like to do
> / see done prior to a 1.1, then by all means speak up. ;-) I'm not in
> that much of a hurry that we should rush it out.

I'm a little tied up with a newborn at the moment, and IO 1.1 is
behind Lang 2.1 on my target list. Neither are being driven by itches,
apart from a general itch to get the Finder code to more people and to
get new releases with bugfixes out there.

> (My personal itch for this is that FileUpload now has a dependency on
> a recent nightly build of IO, and I'd like to do a 1.1 of FileUpload
> reasonably soon, but I'm not in a big rush. I'd rather do things
> right.)

I'd quite happily do 1.1-alpha releases and things. Much rather
release-early than release-right.

> > I just moved WildcardUtils up a directory as it's used by two
> > different subpackages of IO.
> 
> Saw that.

To answer Gary's suggestion of moving this into FilenameUtils; I'm not
anti that suggestion. Obviously FilenameUtils would have to be closer
to release first.

> > There are a couple of options on the finder code which are not
> > implemented yet (time ones I think).
> 
> I guess it might be better to finish that up than release it not fully
> baked. ;-)

It's a clone as such of the unix command line tool, so a few of the
flags that may be done in unix find are yet to be coded. Not that
necessary for a release-early. Someone did post a different way to do
the flags though; which needs to be looked at. I'm a huge fan of the
find command in Unix, and wanted something to let me write similar
style scripts in Java. It was partly written to be called from Groovy.

> I just noticed a couple of items on the IO wiki page:
> 
> http://wiki.apache.org/jakarta-commons/IO
> 
> Can you (or someone else) elaborate on what it means to get
> FilenameUtils and ClassLoaderObjectInputStream "release ready"? It's a
> bit vague... ;-)

Yep, tis vague. Remember that much of IO is accumulated code, which is
then cleaned up and tests written for it.

FilenameUtils had a lot of issues. We'll need to go back in the list
history to see what they were. Methods need killing, writing, testing
etc.

ClassLoaderOIS needs unit tests written. The effort of figuring out
how to unit test it was always greater than the itch to include it in
an IO release :)

Hen

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

Re: [IO] Almost ready for a 1.1 release?

[Martin Cooper <mf...@gmail.com>]

On Mon, 25 Oct 2004 18:55:08 -0400, Henri Yandell <fl...@gmail.com> wrote:
> I hadn't realised we were this close to a 1.1, but I'm +1 for a release.

If you don't think we're ready, or there's more that you'd like to do
/ see done prior to a 1.1, then by all means speak up. ;-) I'm not in
that much of a hurry that we should rush it out.

(My personal itch for this is that FileUpload now has a dependency on
a recent nightly build of IO, and I'd like to do a 1.1 of FileUpload
reasonably soon, but I'm not in a big rush. I'd rather do things
right.)

> I just moved WildcardUtils up a directory as it's used by two
> different subpackages of IO.

Saw that.

> There are a couple of options on the finder code which are not
> implemented yet (time ones I think).

I guess it might be better to finish that up than release it not fully
baked. ;-)

> Is there any reason for the IOTestSuite class? It doesn't seem
> necessary with Maven and seems unlikely to be needed by the generated
> Maven build.xml (which we need to make sure we redo).

Hmm, probably not. I'll make sure first, and then take it out assuming
all is OK.

I've been regenerating the Ant build file as I've been making changes
to the Maven one, so we're actually in good shape on that at the
moment.

I just noticed a couple of items on the IO wiki page:

http://wiki.apache.org/jakarta-commons/IO

Can you (or someone else) elaborate on what it means to get
FilenameUtils and ClassLoaderObjectInputStream "release ready"? It's a
bit vague... ;-)

--
Martin Cooper


> Hen
> 
> 
> 
> On Sun, 24 Oct 2004 20:15:41 -0700, Martin Cooper <mf...@gmail.com> wrote:
> > There have been a lot of changes since IO 1.0 was released, and I'm
> > thinking we're in pretty good shape for a 1.1 release in the near
> > future.
> >
> > I've worked through the bug reports, and got us down to four
> > outstanding change requests, as follows:
> >
> > Bugs:
> > #29140 - NPE in FileUtils.listFiles(dir, extensions, recursive)
> > #30974 - problem with copyFileToDirectory(File, File)
> >
> > Enhancements:
> > #28977 - [io] ProxyOutputStream: no need to define proxy
> > #30667 - [io] new throttled input and output stream classes
> >
> > With respect to the bugs, I have been unable to reproduce #29140 and
> > have requested a test case to nail it down. I suspect #30974 is the
> > infamous timing issue that I'm not clear that there's a good solution
> > for, unfortunately.
> >
> > With respect to the enhancements, they're not my particular itches,
> > and I'd be more comfortable with someone else reviewing them (or
> > flagging them for later). However, I'm willing to apply the changes
> > for #30667 if I get a green light from another IO committer who's
> > reviewed them.
> >
> > So what do folks think? I'm willing to act as RM, unless someone else
> > feels like rolling the release.
> >
> > --
> > Martin Cooper
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

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

Re: [IO] Almost ready for a 1.1 release?

[Henri Yandell <fl...@gmail.com>]

I hadn't realised we were this close to a 1.1, but I'm +1 for a release. 

I just moved WildcardUtils up a directory as it's used by two
different subpackages of IO.

There are a couple of options on the finder code which are not
implemented yet (time ones I think).

Is there any reason for the IOTestSuite class? It doesn't seem
necessary with Maven and seems unlikely to be needed by the generated
Maven build.xml (which we need to make sure we redo).

Hen

On Sun, 24 Oct 2004 20:15:41 -0700, Martin Cooper <mf...@gmail.com> wrote:
> There have been a lot of changes since IO 1.0 was released, and I'm
> thinking we're in pretty good shape for a 1.1 release in the near
> future.
> 
> I've worked through the bug reports, and got us down to four
> outstanding change requests, as follows:
> 
> Bugs:
> #29140 - NPE in FileUtils.listFiles(dir, extensions, recursive)
> #30974 - problem with copyFileToDirectory(File, File)
> 
> Enhancements:
> #28977 - [io] ProxyOutputStream: no need to define proxy
> #30667 - [io] new throttled input and output stream classes
> 
> With respect to the bugs, I have been unable to reproduce #29140 and
> have requested a test case to nail it down. I suspect #30974 is the
> infamous timing issue that I'm not clear that there's a good solution
> for, unfortunately.
> 
> With respect to the enhancements, they're not my particular itches,
> and I'd be more comfortable with someone else reviewing them (or
> flagging them for later). However, I'm willing to apply the changes
> for #30667 if I get a green light from another IO committer who's
> reviewed them.
> 
> So what do folks think? I'm willing to act as RM, unless someone else
> feels like rolling the release.
> 
> --
> Martin Cooper
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

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