Separate the machine from the materials. I think this is good idea.
Right now if you do a rename let say rename FooModule to BarModule
@GinModules(FooModule.class) -> @GinModules(BarModule.class)
public class MyInjector{....}
and refresh the TypeOracleMediator will blow up with an NPE when
trying to get the annotation (ClassNotFound).
Maybe it should return BarModule.class from the special class loader?
It shouldn't break the generator unless it is a moving part of a
generator.
How about a special classloader that is aware of the generator and
gives only classes from ccl that are not a moving part of the
generator (not in source or super source or recursive source/ssource
of dependencies of the generator, libraries aren't in ccl anyway)?
In the above case MyInjector and BarModule would be loaded from CCL
while GinModules from System (since it is part of the generator).
This way libraries and generators can be left in the system cl.
On Jul 22, 7:30 pm, Scott Blum <[email protected]> wrote:
> Brian, do you know if Guice allows you to specify a ClassLoader other than
> the "active" one?
> In principle, I would be okay with GeneratorContext providing a special
> "other" ClassLoader to generators that contained only client code; it would
> have exactly what TypeOracle does.and just be another way to get the exact
> same information.
>
> I just think we need to separate the machine from the materials. :)
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
