I'm for autoloading, and being able to disable it,... sth like moduleLocators in hivemind...
While arround the subject... If I have two modules that have same submodule.. tap-ioc will break, this should just work if we look at the Submodule as an dependancy. On Nov 5, 2007 6:15 PM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: > +1 to autoloading with finer-grained control. > > Robert Zeigler skrev: > > Howard Lewis Ship wrote: > >> 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? > >> > >> > >> > > > > I think autoloading has a lot of merits, and would hate to see it ripped > > out. What I /would/ like to see is finer-grained control over > > autoloading. For example, a mechanism to specify which modules should > > /not/ be autoloaded. > > > > Robert > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
