So, I've been struggling with our internal tool for syncing things back
and forth. I'm going to do a hard-push to try to make this happen, and
quickly. Apologies. But we're putting more people behind both guice
and dagger so things should start to move more quickly. I was trying to
solve the repo-management problem once, for the future, but if I can't
make it fly, I'll manually merge and deal with my tooling issues later.
All y'all have been waiting patiently.
Christian.
On 22 Mar 2013, at 13:17, josh gruenberg wrote:
+1 for releasing 3.1 ASAP. My team is still having frequent problems
with
the following issue under 3.0, which has been resolved in
3.1.0-SNAPSHOT:
https://code.google.com/p/google-guice/issues/detail?id=735
We've been working around this bug for many months, uncomfortable with
the
idea of introducing a production dependency on a SNAPSHOT build. A
stable
3.1 release would be a huge relief.
-jg
On Sunday, March 10, 2013 3:34:35 PM UTC-7, Sam Berlin wrote:
There's a few minor changes we wanna put into trunk, and then I think
we
can put a 3.1.0 RC out pretty easily. Sorry for the troubles. :-/
The changes are basically:
* Add some explicit @Inject constructors in the servlet extension (to
play better with requireAtInjectOnConstructors)
* Add a ScopingException subclass, thrown by the ServletScopes
checkState calls, to better identify failures.
* Update Guice to a new CGLIB that uses ASM4.
* Update ProvisionListener so it works with toInstance & bindConstant
bindings.
* Fix ContinuingServletHttpRequest to allow getCookies() to return
null
* Change AssistedInject so it fails if it tries to construct a class
that has a scoping annotation (instead of ignoring the scope).
... there's just some issues with our sync process that's delaying
pushing
them out. Once they're in git, I don't see any reason to delay an
RC. (We
might have to fix-up the poms, particularly for the cglib change.)
sam
On Sun, Mar 10, 2013 at 5:22 PM, Tim Boudreau
<[email protected]<javascript:>
wrote:
I have a number of mini-frameworks that sit on top of Guice, and one
of
them uses features only available in the Guice trunk. I am really
tired of
explaining to people why they need to use an unreleased trunk build
of
Guice in production code, and have had to repeatedly set up
continuous
builds of Guice on my and my customers' continuous integration
servers.
If the trunk is so fabulously stable that no changes have been
necessary
for an age, why not do a 3.1.0 release and get off the pot?
I don't want to just gripe about it - if there's any way I can
contribute
to making that happen (resources, time, code, whatever), I will -
just ask.
-Tim
--
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] <javascript:>.
To post to this group, send email to
[email protected]<javascript:>
.
Visit this group at
http://groups.google.com/group/google-guice?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: [email protected] :::: mobile: +1 (646) 807-9839
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
