On Nov 3, 2007 3:58 PM, Howard Lewis Ship <[EMAIL PROTECTED]> 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?

Personally the first reason why I've chosen HiveMind first then T5 IoC
was/is the presence of this feature. It's incredibly amazing how easy
it is to switch implementations of add features, just drop the jar, so
i depend on this feature plus it's a distinction from any other
framework.

I can see the point on "use the code without using the services" but
(for me) it's not worth the change. If that is the direction T5 IoC
will take i would like to suggest to make this a user choice with a
default behaviour but not cut it off.

-- 
Massimo
http://meridio.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to