Re: [fileupload] Remove commons-io dependency

[Stephen Colebourne <sc...@btopenworld.com>]

Stephen Colebourne wrote:
> I am not a [fileupload] maintainer, so cannot -1 or force this issue. 
> All I can do is try to persuade the actual maintainers that this 
> dependency is not in your users best interests.

BTW, here is yet another blogger on the pain of dependencies:

"Compare Jason Hunter's excellent COS package which provides file upload 
capabilities as well as several other servlet utilities with zero 
dependencies, to the Jakarta Commons File Upload which also requires 
Commons Logging, Commons IO, Commons BeanUtils and Commons Digester."

http://jroller.com/page/tfenne?entry=framework_and_library_usability


(Note, this actually isn't true anymore of all except IO, yet the 
perception is out there damaging commons...)

Stephen

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

Re: [fileupload] Remove commons-io dependency

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Tue, 2005-09-13 at 00:15 +0100, Stephen Colebourne wrote:
> Stephen Colebourne wrote:
> > I am not a [fileupload] maintainer, so cannot -1 or force this issue. 
> > All I can do is try to persuade the actual maintainers that this 
> > dependency is not in your users best interests.
> 
> BTW, here is yet another blogger on the pain of dependencies:
> 
> "Compare Jason Hunter's excellent COS package which provides file upload 
> capabilities as well as several other servlet utilities with zero 
> dependencies, to the Jakarta Commons File Upload which also requires 
> Commons Logging, Commons IO, Commons BeanUtils and Commons Digester."
> 
> http://jroller.com/page/tfenne?entry=framework_and_library_usability
> 
> 
> (Note, this actually isn't true anymore of all except IO, yet the 
> perception is out there damaging commons...)

IMHO quite a lot of the stuff out there in the blogosphere that really
isn't very well informed. the reason given in that blog is fundamentally
a middleware and framework issue (not a library one). creators of
middleware and frameworks are becoming more aware of the problems that
their dependencies have on their users and are moving towards
repackaging dependencies.

there are good reasons to avoid core dependencies between basic
libraries. often the coupling is just a class or two but the dependency
drags in a whole lot of different classes. this leads to the cycle
whereby breaking binary compatibility in one library leads to a cascade
of forced upgrades in all dependent projects. the graph also makes it
harder for users to download all the dependencies they need to run the
project. maven is

- robert


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