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. ;) > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
