Martin Cooper wrote:
On 8/22/05, Stephen Colebourne <[EMAIL PROTECTED]> 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. ;)
I know ;-) [fileupload] is not a component I follow closely :-(
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.
Yes, and I agree with their presence in [io]. My argument is that
doesn't mean a dependency is needed.
Everyone seemed to be in favour at the time.
My views on inter-commons dependencies have changed over time. When I
joined commons I wanted many more dependencies. Now I am arguing for
removing as many as possible.
Many of our key users have stopped using commons, or at the very least
bitch about, the inter-commons dependencies, and the resulting jar
version hell.
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?
This assumes a large number of bugs. Chances are the number will be
small. A comment in each file informs the committer that they should
change another file.
The system is not perfect, but I argue that it is in fact preferable to
adding the dependency. (Preferable to our users, not preferable to us.)
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.
Maybe I've missed it, but the latest TRUNK [fileupload] has no
BeanUtils, Digester or Logging dependency that I can see.
From [fileupload]: "Replaced the ad hoc <code>newInstance()</code>
means of creating <code>FileItem</code> instances with a factory-based
scheme for much greater flexibility and simpler customization. This
change also *eliminates*a*dependency*on Commons BeanUtils."
Why is IO special, so that we should copy classes from it?
Its not. I'm arguing this wherever I see 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...
The argument is that our USERS should CHOOSE to pickup a dependency
because they actually WANT it. They should not be FORCED to have it
because they wanted something else. Forcing something on somebody is a
sure way to generate bad feelings, and commons badly needs to recover
some mind-share.
Inter-commons dependencies are, I believe, the primary complaint that
I've read again and again in non commons-dev discussions. I'm arguing to
reduce them, even where it causes us pain as commons-developers.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
