commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: [io] Release 1.1
Date Sun, 11 Sep 2005 08:57:24 GMT
Thanks for your thoughts, Stephen, especially the tip about the SVN
handling. It's really cool we can now do things like that. Unthinkable
with CVS. What you suggest is probably the best approach to avoid any
more trouble on the subject.

On 11.09.2005 00:50:40 Stephen Colebourne wrote:
> Jeremias Maerki wrote:
> > Nothing from me, although I'd like to get something off my chest. I'm
> > having trouble selling the benefit of using Commons IO inside the XML
> > Graphics project. Well, it's only one person but still: The fact that
> > CopyUtils is deprecated now and that all methods get moved (back!) to
> > IOUtils tells him that Commons IO is not a good candidate as a
> > dependency for the XML Graphics Commons components we're going to scrape
> > together from Batik and FOP subprojects. We will probably end up
> > duplicating the few things we absolutely need (IOUtils.closeQuietly(),
> > CopyUtils.copy(InputStream, OutputStream) and CountingOutputStream) for
> > the common components.
> 
> Personally, I'm not averse to the use of commons projects by copying. 
> Other committers have issues with this. If it does happen, I recommend 
> using package scoped classes and recording in comments the SVN version 
> you copied from.
> 
> It also depends on the relative size of the project. If XML Graphics is 
> quite a large project with a number of other dependencies, then having 
> [io] as a dependency makes more sense than if XML Graphics is a very 
> small library.
> 
> Finally, on CopyUtils, I believe we got it wrong creating CopyUtils in 
> the first place. It didn't fit in the library, wasn't about copying code 
> (reading a stream was in IOUtils, but copying/writing was in 
> CopyUtils!). Generally it was a bad call. This release gets it right by 
> renaming the write methods to write() and putting everything in one 
> place (better defining IOUtils as a class working with 
> streams/readers/writers).
> 
> Yes, this change will cause some pain, but its essential, and not really 
> typical of the ongoing likelihood of change in the library.
> 
> Stephen
> (forward this to your mailing list if you wish)


Jeremias Maerki


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


Mime
View raw message