On Tue, Nov 26, 2013 at 3:47 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Tue, Nov 26, 2013 at 4:05 AM, Emmanuel Bourg <ebo...@apache.org> wrote: > >> Hi Damjan, >> >> Le 26/11/2013 06:31, Damjan Jovanovic a écrit : >> >> > Firstly, we discussed several options before for the 1.0 release, and >> > agreed that the contents of trunk would be quickly pushed out as 1.0 >> > with minimal changes (many/most users are using 1.0-SNAPSHOT), and >> > then the big API redesign would be 2.0. I've also been thinking of >> > doing a complete rewrite for 2.0 and only pulling in some of the good >> > bits we have now. So it's extremely discouraging to be pushed for more >> > and more changes, many of which will have no post-1.x value, and don't >> > even fit in with what was originally agreed on. >> >> Sorry for the late review. I'm not opposed to the release and I won't >> mind if you prefer to ignore my feedback :) >> >> >> > It looks like CachingInputStream is used by IccProfileParser, and >> > appears to be used to store data that has been read from the >> > underlying stream so it can be re-read later. You can copy it to >> > commons-io, but I'd prefer not having a runtime dependency on it. And >> > it's ByteSourceInputStream you really want in commons-io and/or >> > commons-compress, a gem that allows seeking over an InputStream. >> >> I would be possible to avoid a runtime dependency by shading the classes. >> > > That's not necessary, the POM shows this is a test-only dependency.
But it will be necessary if CachingInputStream is moved into commons-io instead of copied. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
