tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip S. Adamsen" <...@fsadev.com>
Subject Re: DISCUSS: Remove Module autoloading
Date Mon, 05 Nov 2007 17:15:49 GMT
+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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message