I've been giving this a bit of thought lately. It seems to me that a likely scenario is one in which an existing library, such as tapestry-hibernate, doesn't do quite what a user needs, but contains a lot of useful code that could be resused. However, autoloading means that just having the JAR on the classpath wires it up, without giving an option to use the code but not the services.
In addition, another common case is to forget to add a module's JAR to the classpath, and then not understand why things are not working. The solution to both of these problems is to be more explicit about bringing in modules. The approach I'm moving towards is to add a @SubModule annotation to the application's module. With that in place, a missing dependency is a compile time error. Thoughts? -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
