commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: [fileupload] Remove commons-io dependency
Date Mon, 22 Aug 2005 23:29:31 GMT
On 8/22/05, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> I would like to propose the removal of the commons-io dependency from
> [fileupload].

I am *not* in favour of this. (And it would have been nice if you'd
expressed this opinion a year and a half ago, when these classes were
introduced to IO from FileUpload, and the dependency was created. ;)

> The dependency consists of three classes:
> - FileCleaner
> - DeferredFileOutputStream
> - ThresholdingOutputStream (required by DeferredFileOutputStream)

Yes. Those classes were added to IO specifically so that they would be
available outside of the FileUpload component, which is where they
originated. Everyone seemed to be in favour at the time.

> This proposal is to copy-and-paste these three classes to package scoped
> in the [fileupload] project, and mark them in documentation (in both io
> and fileupload) as duplicates. (There is the potential for FileCleaner
> to use reflection to try and contact the commons-io version of the class
> to avoid a thread creation)

And who is going to keep them in sync? Are the IO developers going to
notify the FileUpload folks when bugs get fixed, or do the FileUpload
folks need to watch all of the changes to IO in order to pick up such
fixes?

> While I understand that many people have an instinctive reaction against
> copy-and paste, and that it might seem normal and rational to eat our
> own dogfood and reuse code, the truth is that in complex servlet
> environments it causes issues.

Issues? FileUpload 1.1 also introduces dependencies on BeanUtils,
Digester and Logging. Why is IO special, so that we should copy
classes from it?

> Unless every method in every class in every release that your dependency
> makes is 100% binary, source and semantically compatible forevermore,
> then you may have a problem. These problems are generally rare, but are
> in many cases unecessary.

This seems like an argument for not having Commons components. Seems a
little odd...

> [fileupload] 1.0 had no dependency on [io]. Lets remove that dependency
> from v1.1 and thus speed a release.

Why are the dependencies of FileUpload 1.0 relevant here? Are we not
allowed to expand a component with new functionality, and hence
require additional dependencies?

--
Martin Cooper


> Stephen
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message