commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <>
Subject Re: [fileupload] Remove commons-io dependency
Date Tue, 13 Sep 2005 06:47:44 GMT
Henri Yandell <> writes:

[rereading this thread because Stephen brought up the blogger article]

>* some kind of subversion sym link? Unsure if it supports that yet.
>svn:externals could be done?

"Gotcha!". I fell into that trap, too. No, this does not
work. svn:externals can only reference directories, not single

It wouldn't work either unless you want to repackage the files under
the same java package as they were in the original jar. Which would
lead to real hell (what if you missed a dependency of class a.x
repackaged into b.jar which now references a.y that is in c.jar while
both a.* classes should've been referenced from a.jar which just
happened to be on the back of the class path. Now along _that_ path
lies madness. I wouldn't dare to go there.

>* custom maven.xml which copies the file from commons-io, search and
>replace on 'public class' on those N files and quietly inlines the

How? You would have to automatically find out all dependencies (what
if you reference a.x from a.jar which in turn relies on b.y. Will you
put both a.x and b.y into your c.jar?).

I understand Stephens' reason for concern. The idea of commons is to
have working building blocks for applications. Making these blocks
independent is IMHO a "nice to have feature". If this means to copy a
few stable methods into a FooUtils class that is package private (like
we did with commons-email) is fine IMHO.

commons-fileupload has dependencies to commons-io, that introduce
things like a thread for reaping files. Copying these classes simply
into commons-fileupload would mean that there is not just one but
suddently two reaper threads (FileCleaner). Something to look out for.

Once you don't have just a number of trivial dependencies but actually
use large parts of the functionality of another component, it makes no
longer sense to copy methods over. Where to draw the line? 

Our problem is, that the commons are not good at _documenting_
dependencies. Basically, we throw maven in and let it generate a
dependencies page. Look e.g. at

To everyone _not_ familiar with c-e, this implies that you need
dumbster and the maven-findbugs-plugin to work with commons-email. 

In contrast, look at

They did a really good job to identify which part of
commons-configuration needs which dependencies.

I understand the concerns of commons users not to be dragged into
"dependency hell". 

- As few dependencies as possible. If just StringUtils.isEmpty()
  and StringUtils.isNotEmpty() from commons-lang are needed , these
  two methods should be copied into an Utils class. These are
  methods that are unlikely to change in c-l

- When using dependencies, try to stay in the commons.

- The commons _should_ strive for maximum backwards
  compatibility. Especially commons core packages like -lang and
  -collections. If we consider the commons as "building blocks" then our
  building blocks should have maximum compatibility to each other (think Lego).

- Document the dependencies. The current maven-built "dependencies.html"
  page is sub-optimal. If a component does not depend on "a.jar" all the
  time but only when a special sub-package is needed (think commons-fileupload
  and portlet-api), document this.

In the longer run, we might think a bit more about the current commons
structure. There is "commons proper" and "commons sandbox". But we
have e.g. "building blocks" like commons-lang, commons-collections or
commons-math where every external dependency really hurts and then we
have almost 2nd level projects like jelly, latka or vfs (random
selection) that are not exactly "building blocks" any longer but
larger components that build on functionality from many packages.

It might be a good thing to define something like "commons-core" where
external dependencies without good reason is frowned upon and then
"commons-proper" where dependencies are ok.

	Best regards

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH        +49 9131 50 654 0

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

		      4 - 8 - 15 - 16 - 23 - 42

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message