Thanks for the compliment. Let me try to address your questions:
1. If I have classes across multiple applications, I typically create a separate project called
<company name>-framework, with its own RCS repository. It contains utility classes, design pattern implementions, etc. that can be used across any application.
All this 'framework' project does is produce a
<company name>-framework.jar file that I treat like any other 3rd party library (like commons-logging.jar or hibernate.jar, etc).
By including this jar in your application's lib directory (as described in the article) you treat it as a 3rd party library, only upgrading that jar when you need new functionality. This allows applications to keep their own copy and prevents dependencies on other apps.
2. Your number 2 point is exactly why I created a hierarchical build in the first place. If you define a task in any parent build file, it is immediately available to the children build files because they
<import> the parent definitions. So if I declare an ant task:
<target name="styleCheck"> ...
in the root build.xml file, all modules and submodules may now use that task and can depend on it.
I've worked on projects with over 50 submodules before, and this technique is just what saved us from rewriting tasks over and over again. Just define it once at a parent level, and its immediately available to any of its children.