Henri Yandell <[EMAIL PROTECTED]> 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 files. 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 >classes? 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 http://jakarta.apache.org/commons/email/dependencies.html 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 http://jakarta.apache.org/commons/configuration/dependencies.html 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 Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
