On 24 Jul 2013, at 00:58, Sam Berlin wrote: > I've been meaning to add Injector.getAllElements() for quite a while now. > Maybe this will push me to finally do it if we have an imminent > new-version-number release..
Personally I'd appreciate a 3.x release (candidate) with the ProvisionListener API and if possible the guava dependency fix* before any 4.x API changes That way users get a stable 3.x build to migrate to while we can work on 4.x API changes which may or may not require changes to extensions, etc.... * this is just because it greatly simplifies the build the coupling between extensions and core - but it's not a show-stopper to getting out a 3.x RC > On Tue, Jul 23, 2013 at 7:35 PM, Christian Gruber <[email protected]> wrote: > Heh, Eric. Let's get it out there for you. :) > > I'll defer to Sam on the numbering. I think he has a better picture of the > full scope of change in head, having written the vast bulk of it. :D > > That said, while we're doing a 4.0, are there any API-incompatible changes we > are interested in making beyond your SPI fix, Sam? I can't see anything > crucial to fix with a breaking change, but now would be the time. > > Christian. > > > On 23 Jul 2013, at 15:48, Eric Tschetter wrote: > > Don't rush a release just for me and this one feature :). If you really > want to use this as an excuse to make one happen though, by all means, use > it ;). > > --Eric > > > On Tue, Jul 23, 2013 at 3:47 PM, Sam Berlin <[email protected]> wrote: > > I'd lean towards a 4.0-beta, and then we can roll in these upcoming > changes too. I'm hoping we can get this particular debugging-change to > change Element.getSource to return a new SPI type (ElementSource) instead > of 'Object'. > > sam > > > On Tue, Jul 23, 2013 at 6:46 PM, Christian Gruber <[email protected]>wrote: > > Le sigh. I'm working on six things. We can roll a release if we think > we have everything we want in it right now. Or if not, I can roll 3.1 beta > (if we are agreed on 3.1 as the version). > c. > > > On 23 Jul 2013, at 15:45, Sam Berlin wrote: > > I think Christian's working on it? We also have a few awesome > in-the-works > changes here that will make debugging a helluva lot easier (including > capturing the chain of Modules involved with each binding, as well as > complete stack traces per binding). > > > On Tue, Jul 23, 2013 at 5:59 PM, Eric Tschetter <[email protected]> > wrote: > > Is there an rc or other semi-stable (and hopefully tagged somewhere) > build > of guice with that in maven central? If so I'll be more than happy to > try > it out. If not, I can wait. > > I already adjusted the code to work with the explicit bindings and it > turned out it required a *lot* fewer than I thought it would. Would > still > prefer just the requireAtInject, but it's easy to relax the restriction > in > the future once that is released. > > --Eric > > > On Tue, Jul 23, 2013 at 2:55 PM, Stuart McCulloch <[email protected] > wrote: > > On 23 Jul 2013, at 22:48, Christian Gruber wrote: > > Wait… didn't we add requireAtInjectOnConstructors(**) as a halfway > > > between full JIT and requireExplicitBindings()? > > Thanks for the reminder - I was going by the online javadoc which > doesn't > have the latest additions > > I see it here: > > http://google-guice.**googlecode.com/git/core/src/** > com/google/inject/Binder.java<http://google-guice.googlecode.com/git/core/src/com/google/inject/Binder.java> > > > > If you're building your own snapshot of Guice, then you should have > > access to it. If not, it should be out shortly when we roll a release > candidate. But please do try it out by rolling a local copy of guice > from > head. > > > c. > > On 23 Jul 2013, at 14:42, Stuart McCulloch wrote: > > On 23 Jul 2013, at 22:28, Eric Tschetter wrote: > > Thanks for the quick response! > > Binder.**requireExplicitBindings() is causing it to fail on binding > > something that has an @Inject annotation on it. I was hoping to just > disable the injection of things without the annotation, but I'm > guessing > that's not possible? > > > Yes with requireExplicitBindings you will have to be more verbose, > > even down to binding the actual implementation classes as follows: > > > bind( MyComponentImpl.class ); > > @Inject just declares a dependency on something, rather than being a > > binding that can provide something, so this is working as designed > > > If that's the case, that's fine, I can deal with being even more > > explicit and requiring a bind for everything. > > > On Tue, Jul 23, 2013 at 2:20 PM, Stuart McCulloch < > [email protected]> > > wrote: > > > On 23 Jul 2013, at 22:13, Eric Tschetter wrote: > > Hello everyone. > > I'm looking for a way to disable JIT bindings in Guice. Google > found > > http://code.google.com/p/**google-guice/issues/detail?id=**342<http://code.google.com/p/google-guice/issues/detail?id=342> > > > For me, but it looks like r1141 referenced in there is a broken > link > > now (probably switched source control systems and the links aren't > updated? > I'm not sure how to search for the old commit...). I also don't know > that > an InjectorBuilder is (can't find the class in the current code, so am > guessing it's something that existed in 2009 and doesn't anymore). > > > I'm guessing this functionality was maintained, but am wondering > how > > to enable it. Basically I want to disable any injection that is > not either > (a) bound in a module or (b) > > of an object with an @Inject binding. > > > The equivalent git hash is > > http://code.google.com/p/**google-guice/source/detail?r=** > 888a264bdee08c82cccd9dcc94a8a4**ac98912bad<http://code.google.com/p/google-guice/source/detail?r=888a264bdee08c82cccd9dcc94a8a4ac98912bad> > > > > Since then the requireExplicitBindings option was moved to the > Binder > > API: > > > > http://google-guice.**googlecode.com/git/javadoc/** > com/google/inject/Binder.html#**requireExplicitBindings()<http://google-guice.googlecode.com/git/javadoc/com/google/inject/Binder.html#requireExplicitBindings()> > > > > --Eric > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
