It's on a strictly package-related level. Dependencies aren't
installed, only subpackages.
Sam
On Thu, Oct 2, 2008 at 12:14 PM, famousactress <[EMAIL PROTECTED]> wrote:
>
> Sounds good.. but doesn't that pattern run the risk of duplicating
> Module installations? For instance.. I depend on serviceA and
> serviceB, who both depend on utilC... They'd both attempt to install
> utilC's Module... From glancing at the code, it seems that would lead
> to this:
>
> if (this.builder != null) {
> throw new IllegalStateException("Re-entry is not allowed.");
> }
>
>
> The pattern makes sense if duplicated Module installations are
> ignored... just looks like they may not be.
>
> Phill
>
> On Oct 2, 9:05 am, "Sam Berlin" <[EMAIL PROTECTED]> wrote:
>> We use a pattern of a single Main module that installs the modules in
>> each top-level subpackage, each of those modules installing their
>> further subpackages. So something like:
>>
>> org.mycompany.MainModule {
>> install(new FooModule());
>> install(new BarModule());
>>
>> }
>>
>> org.mycompany.foo.FooModule {
>> install(new org.mycompany.foo.internal.FooInternalsModule());
>> bind(Foo.class).to(FooImpl.class);
>>
>> }
>>
>> org.mycompany.bar.BarModule {
>> install(new org.mycompany.bar.internal.BarInternalsModule());
>> bind(Bar.class).to(BarImpl.class);
>>
>> }
>>
>> Sam
>>
>> On Thu, Oct 2, 2008 at 11:23 AM, famousactress <[EMAIL PROTECTED]> wrote:
>>
>> > That's a really good point....
>>
>> > So... it sounds like 1 Injector per entry-point into the system is a
>> > pattern folks are using.. and that Injector needs to know about all of
>> > the modules of it's dependant packages... So... Is there a recipe
>> > folks are using for making that less cumbersome than it sounds? I was
>> > thinking along the lines of some sort of discovery pattern, or perhaps
>> > a maven plugin? Maybe even a new .jar standard that contains
>> > references to a jar's Guice Module in META-INF?
>>
>> > You have to admit.. .gar is pretty rad sounding.
>>
>> > Anyways.. Let me know if anyone's got a clever way of dealing with
>> > this... the way I see it.. I have a servlet module (take lower case
>> > module to mean a collection of related classes, or a single java
>> > package)... anyways, I have a module that might depend on three or
>> > four other modules. It can bootstrap an Injector, and it's not all
>> > that cumbersome I guess for it to pull in it's dependencies Modules...
>> > but what about _their_ dependencies.
>>
>> > I suppose if you're doing SOA, this problem goes away pretty quickly
>> > since you're more likely to have a fairly close Injector-to-Module
>> > ratio... but I'm curious what other folks are doing.
>>
>> > Phill
>>
>> > On Oct 1, 10:48 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>> >> On Oct 1, 3:35 pm, famousactress <[EMAIL PROTECTED]> wrote:
>>
>> >> > but I'm not sure what the best practice is for organizing modules
>>
>> >> The simplest strategy is to have one Module
>> >> per Java package. This allows you to make
>> >> your implementation classes package-private,
>> >> decreasing their visibility.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
