tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Tomasini" <ben.tomas...@gmail.com>
Subject Re: DISCUSS: Remove Module autoloading
Date Mon, 05 Nov 2007 23:12:46 GMT
What abound some kind of include / exclude filters like ant?  An empty
set could imply **/*

Ben

On Nov 3, 2007 8:53 PM, Robert Zeigler <robertz@scazdl.org> wrote:
> 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