How much time does google have to fixe larger issues for 4.0?

[scl]

After Sam's call to bump the issues we would like to have fixed in 4.0 I went through the list of issues regarding the persist extension.
Simply because I know it the best and because I ran into some of the issues myself.

Going over the list I found a bunch of issues which are more or less straight forward to fix.
But what disturbed me was, that several issues which have gotten a lot of attention (or at least a lot of comments) have the same root cause which is not trivial to solve.

So my question is how much time do you have at google for discussing and reviewing the possible solutions (including tests and patches).
Or would you prefer to address the more complex problems in extensions at a later time, since extensions can be released separately from the core?


The issues I'm talking about are 597, 604, 730, 739 (issue 731 requests a new feature which could be used as a workaround).
The underlying cause is that calling Provider<EntityManager>.get() outside of a UnitOfWork will implicitly start a UnitOfWork which is never ended.

If you do have time to address the above issue I would be more than willing to participate in the process of getting it solved.

[Sam Berlin]

To be perfectly honest, I would like to drop persist from the extensions we ship. The original author more or less dropped the code in the repository and then stopped maintaining it immediately.  No one within Google really uses it, and we have no familiarity with it.  If another project wants to fork and maintain it, that would be great.

sam

--
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 google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.

[Christian Gruber]

So that's not entirely true anymore. We have a few folks using it
internally. I had originally been cool with detaching it (I guess I
still am, since the author did effectively drop it after adding it) from
the main Guice project, but we should see if there are users internally
who want to maintain our side of it.

c.

On 19 Dec 2013, at 4:57, Sam Berlin wrote:

> To be perfectly honest, I would like to drop persist from the
> extensions we
> ship. The original author more or less dropped the code in the
> repository
> and then stopped maintaining it immediately. No one within Google
> really
> uses it, and we have no familiarity with it. If another project wants
> to
> fork and maintain it, that would be great.
>
> sam
> On Dec 19, 2013 1:50 AM, "scl" <st.cl...@gmx.ch> wrote:
>
>> After Sam's call to

>> bump<https://groups.google.com/forum/#!topic/google-guice/ZZpFD3e_8v0>the

>> issues we would like to have fixed in 4.0 I went through the list of
>> issues regarding the persist extension.
>> Simply because I know it the best and because I ran into some of the
>> issues myself.
>>
>> Going over the list I found a bunch of issues which are more or less
>> straight forward to fix.
>> But what disturbed me was, that several issues which have gotten a
>> lot of
>> attention (or at least a lot of comments) have the same root cause
>> which is
>> not trivial to solve.
>>
>> So my question is how much time do you have at google for discussing
>> and
>> reviewing the possible solutions (including tests and patches).
>> Or would you prefer to address the more complex problems in
>> extensions at
>> a later time, since extensions can be released separately from the
>> core?
>>
>>
>> The issues I'm talking about are

>> 597<http://code.google.com/p/google-guice/issues/detail?id=597>,
>> 604 <http://code.google.com/p/google-guice/issues/detail?id=604>,
>> 730<http://code.google.com/p/google-guice/issues/detail?id=730>,
>> 739 <http://code.google.com/p/google-guice/issues/detail?id=739>
>> (issue
>> 731 <http://code.google.com/p/google-guice/issues/detail?id=731>

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: cgr...@google.com :::: mobile: +1 (646) 807-9839

[Stephan Classen]

Since the hollidays are over and everybody is back to work: any update
on this?
does somebody at google want to maintain the persist extension?

[Stephan Classen]

Still no news?
anybody???

[Christian Gruber]

Sorry - some internal discussion. It's not clear at this point. I've
been out most of the last week and a bit, so I'll try to get discussions
restarted.

c.

[Stephan Classen]

Thanks for the update.

Take all the time you need. I feel such decisions need to be thoroughly
be thought through.
I just don't want them to be buried by the daily workload of other
important stuff.

[Tim Boudreau]

I've got a soon-to-ship non-trivial application running on Guice 4 beta.  While it's working fine, it would be nice not to see "beta" in that list of dependencies...

-Tim

[Christian Gruber]

I think we are a little ways still away from a final release of 4, but
that's mostly because of how many balls the various folks are juggling.
The goal with getting the beta out was that it was more than just a
snapshot, but a credible working version. It's really not "beta" in the
normal sense. Google's applications all run at head. So, if the word
makes you feel twitchy, I can understand that, but the code
reliability/viability is "production" from Google's perspective.

I think we had a few more things we wanted to accomplish in order to
call this 4. But we should talk it over and figure out what we really
do need/want in before rolling another version. I think it is severely
unlikely we will have any API-risky changes forthcoming.

Christian.

[Sam Berlin]

+1.  If it makes you feel any better, the very system you're writing/reading this email on is using the latest Guice code, and it seems to be working fine. :-)

 sam

On Tue, Feb 18, 2014 at 4:56 PM, Christian Gruber <cgr...@google.com> wrote:

I think we are a little ways still away from a final release of 4, but that's mostly because of how many balls the various folks are juggling.  The goal with getting the beta out was that it was more than just a snapshot, but a credible working version.  It's really not "beta" in the normal sense.  Google's applications all run at head. So, if the word makes you feel twitchy, I can understand that, but the code reliability/viability is "production" from Google's perspective.

I think we had a few more things we wanted to accomplish in order to call this 4.  But we should talk it over and figure out what we really do need/want in before rolling another version.  I think it is severely unlikely we will have any API-risky changes forthcoming.

Christian.

On 18 Feb 2014, at 3:30, Tim Boudreau wrote:

I've got a soon-to-ship non-trivial application running on Guice 4 beta.
While it's working fine, it would be nice not to see "beta" in that list
of dependencies...

-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 google-guice+unsubscribe@googlegroups.com.

To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency Injection
email: cgr...@google.com :::: 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 google-guice+unsubscribe@googlegroups.com.

[Tim Boudreau]

If there's anything those of us outside Google can do to help get the release out the way you want it to be, I'm sure I'm not the only one willing to donate some of my time.

-Tim