Thanks,
I actually came across Onami after reading up on the multiple persistent
unit setup for Guice Persist - it's not exactly optimal.
Wasn't sure what the release status was for the project so was a little
reluctant, but will give it a try now.
Any idea if there are any plans to introduc
Awesome. Thanks!
On Wed, May 28, 2014 at 7:07 PM, 'Will Norris' via google-guice <
google-guice@googlegroups.com> wrote:
> https://github.com/angular/google-cla-verifier-for-github it's a bit of a
> hack, but seems to work for them.
>
> It needs a GitHub account to run as (for commenting on pul
https://github.com/angular/google-cla-verifier-for-github it's a bit of a
hack, but seems to work for them.
It needs a GitHub account to run as (for commenting on pull requests to
point people at the CLA). We setup https://github.com/googlebot for
exactly that sort of thing, so I'll follow up off
AFAICT, CLAhub uses the statuses API (the same that Travis CI also uses):
https://developer.github.com/v3/repos/statuses/
You can find the CLAhub code at https://github.com/clahub/clahub
On Thu, May 29, 2014 at 12:58 AM, Christian Gruber wrote:
> Can you point me at it Will? I would love to imp
Can you point me at it Will? I would love to implement that for a few
projects in the short term until something more comprehensive is in
place.
c.
On 28 May 2014, at 15:51, Will Norris wrote:
GitHub's API already provides all the pieces to make this possible...
I
assume that's what clahub
GitHub's API already provides all the pieces to make this possible... I
assume that's what clahub uses, we just haven't built it all out yet for
Google-owned projects. Gerrit has CLA checks today, Google projects on
GitHub will have them... eventually. :) The Angular team has an Apps
Script h
Wait, Thomas... didn't we have this conversation about a year ago? :D I
seem to recall you mentioning this.
But I actually think hosting a CLA isn't what I'm looking for so much as
being able to tie in your own association of "CLA-signers" to github
users, so there can be some signal as to wh
Wow, that's a lot of permissions it requires on the project.
On Wed, May 28, 2014 at 6:36 PM, Thomas Broyer wrote:
>
>
> On Wednesday, May 28, 2014 10:25:36 PM UTC+2, Christian Gruber wrote:
>>
>> Agreed on all counts. Though we already have a process for CLA
>> management in google, though th
On Wednesday, May 28, 2014 10:25:36 PM UTC+2, Christian Gruber wrote:
>
> Agreed on all counts. Though we already have a process for CLA
> management in google, though that's a good feature request to ask of the
> github folks.
>
Something like https://www.clahub.com/ ?
--
You received thi
Agreed on all counts. Though we already have a process for CLA
management in google, though that's a good feature request to ask of the
github folks.
c.
On 28 May 2014, at 8:35, Sam Berlin wrote:
Guava follows a different process than Guice. I'd like to try and
encourage more community dev
I'm happy enough with the github issues list - I've played enough with
tags that I have found a nice balance on some other projects.
c.
On 28 May 2014, at 5:54, Sam Berlin wrote:
Unless folks strongly prefer the codesite issue tracker, I'd rather
just
move everything over to github (if poss
Creating the injector can be rather expensive.
You may consider either of the following:
- Create child injectors instead of the main injector for every
request.
- Use RequestScope (see:
https://code.google.com/p/google-guice/wiki/Scopes) to have an
inst
I think it's perfectly reasonable to use Guice this way. You may want to
make sure that you're being careful about not leaking memory (i.e. it looks
like your event bus is shared across calls, so you'll want to make sure
things like that aren't holding on to the object graph). Also, if you use
Guic
If you want you can have a look at http://onami.apache.org/persist/
The code is final and will be released in the next few weeks.
It supports multiple persistence units and fixes some of the known
issues of guice-persist.
On 05/28/2014 01:34 PM, Robert
+1 for github
Mike Burton
RoboGuice
http://about.me/michaelburton
On Wednesday, May 28, 2014 8:36:37 AM UTC-7, Shawn Pearce wrote:
>
> On Wed, May 28, 2014 at 8:31 AM, Shawn Pearce
> > wrote:
>
>> On Wed, May 28, 2014 at 7:14 AM, Sam Berlin
>> > wrote:
>>
>>> Yeah, I see now. I have nothing a
On Wed, May 28, 2014 at 7:14 AM, Sam Berlin wrote:
> Yeah, I see now. I have nothing against using gerrit for code reviews if
> folks want to do that
>
We are more than happy to host Guice on Gerrit at googlesource.com, if that
is where you want to host.
One advantage over GitHub is Gerrit inh
On Wed, May 28, 2014 at 8:31 AM, Shawn Pearce wrote:
> On Wed, May 28, 2014 at 7:14 AM, Sam Berlin wrote:
>
>> Yeah, I see now. I have nothing against using gerrit for code reviews if
>> folks want to do that
>>
>
> We are more than happy to host Guice on Gerrit at googlesource.com, if
> that i
Guava follows a different process than Guice. I'd like to try and
encourage more community development here.
sam
On Wed, May 28, 2014 at 11:33 AM, Shawn Pearce wrote:
> On Wed, May 28, 2014 at 8:31 AM, Shawn Pearce wrote:
>
>> On Wed, May 28, 2014 at 7:14 AM, Sam Berlin wrote:
>>
>>> Yeah,
Hi, I work with legacy web app that have a ojbect in session scope.
I create a new front end with Vaadin and mvp lite that work togheter with
old Struts front end.
Now in my vaadin application class at every request, i create a new
injector with an object because i retrieve a UserContextInfo obj
Yeah, I see now. I have nothing against using gerrit for code reviews if
folks want to do that... but overall, I think hosting the project itself on
GitHub is the best option. GitHub just seems to have better community
engagement tools. We generally do most development of Guice internally
(with
OK, i thought it was clear.
I mean to host Guice development on Gerrit Code Review,
like Gerrit [1] itself and GWT library [2].
The code review process is much easier on Gerrit as on GH.
And of course you could still replicate to GH from Gerrit. That's what
Openstack [3], Wikimedia [4] and LibreO
On 28 May 2014, at 14:58, Sam Berlin wrote:
> That link 404s, so I'm not totally sure what you're referring to.
I think David was suggesting to use Gerrit at googlesource, like:
https://android-review.googlesource.com
Personally I'm +1 on moving Guice over to github
> googlesource.co
That link 404s, so I'm not totally sure what you're referring to.
googlesource.com seems to be the cover page for "open source stuff at
google", which just links back to codesite. Google already has an
organization at GitHub (https://github.com/google), so this would just fit
as another project in
Am Dienstag, 27. Mai 2014 22:31:37 UTC+2 schrieb Sam Berlin:
>
> What do folks think of the idea? It'd make accepting patches easier (with
> pull requests, etc), and I'm sure there's other benefits for folks using
> the code too.
>
>
I have to ask why not to move to:
https://guice-review.goog
On Wed, May 28, 2014 at 5:07 AM, Thomas Broyer wrote:
>
>
> On Tuesday, May 27, 2014 10:31:37 PM UTC+2, Sam Berlin wrote:
>>
>> What do folks think of the idea? It'd make accepting patches easier
>> (with pull requests, etc), and I'm sure there's other benefits for folks
>> using the code too.
>
Thanks for the reply.
So I assume the only way to have multiple isolation levels in the one one
application would be to do something like:
- Create two persistence units, each one with the desired isolation level
- Use private modules to separate the two persistence units from each other
in the
On Tuesday, May 27, 2014 10:31:37 PM UTC+2, Sam Berlin wrote:
>
> What do folks think of the idea? It'd make accepting patches easier (with
> pull requests, etc), and I'm sure there's other benefits for folks using
> the code too.
>
+1
> We could also migrate issues if anyone knows a way t
27 matches
Mail list logo
