Re: New guice svn/git repository?

[Sam Berlin]

The project is mostly stable, without much need for changes.  There's a few changes we have stacked up internally at Google that will be pushed out once we fix some issues with the export-tool... but nothing major.

sam

On Wed, Jan 23, 2013 at 5:58 PM, Roman Ilin <roman...@gmail.com> wrote:

Hi *,

uses guice some new svn/git repo?
Because last commit I can see is dated by 09/31/2012.
http://code.google.com/p/google-guice/source/list

Or guice project is not active any more?

Regards

Roman

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mikhail Mazursky]

With 180+ issues open and most of them in New state and no activity in repository - i would say that this is "stagnating", not "stable". It's a pity to see such a great tool to be abandoned. Though, i use Guice a lot and had not a single problem with it. Big thanks!

Mikhail

2013/1/25 Sam Berlin <sbe...@gmail.com>

To unsubscribe from this group, send email to google-guice...@googlegroups.com.

[Sam Berlin]

Do you not find it a little contradictory that you use it and have no issues, yet you find the project stagnating?

The vast majority of open issues are in extensions.  Not all can be reproduced, and a good number of the others are things that probably should be closed as "sorry, this isn't going to happen, by design".

That's not to say there aren't legitimate issues that need fixing.  But, absence of commit activity does not mean the project is lost -- it means the project is stable enough to not need it.

sam

[Mikhail Mazursky]

I don't want to be offensive but if it's not stagnating (great to hear that!) why are those non-issues not closed to make it clear that everything is ok? That's why i dont find it contradictionary - code is good and stable but little activity and fixes are rare.

2013/2/8 Sam Berlin <sbe...@gmail.com>

[Stephan Classen]

I agree. The community is very active in the google group, but on the issue tracker nothing happens.
I would be great if issues would be treated as important as an entry in the google group.

What also would help to understand the state of guice development for newcomers would be a page in the wiki which explains how guice is developed within google and only now and then a big junk of code is released into the public.

[Christian Gruber]

Well, if all goes well, that process should be more regular - I'm
working on that. That said, as Sam says, most of the active development
isn't (currently) on the core guice system, and most issues and
discussions have been about extensions, many of which we simply don't
use internally.

But I need to do a better job of communicating outward. I'll take your
suggestion about some better documentation on.

cheers,
Christian.

On 8 Feb 2013, at 2:31, Stephan Classen wrote:

> I agree. The community is very active in the google group, but on the
> issue tracker nothing happens.
> I would be great if issues would be treated as important as an entry
> in the google group.
>
> What also would help to understand the state of guice development for
> newcomers would be a page in the wiki which explains how guice is
> developed within google and only now and then a big junk of code is
> released into the public.
>
>
>
>
> On 02/08/2013 07:19 AM, Mikhail Mazursky wrote:
>> I don't want to be offensive but if it's not stagnating (great to
>> hear that!) why are those non-issues not closed to make it clear that
>> everything is ok? That's why i dont find it contradictionary - code
>> is good and stable but little activity and fixes are rare.
>>
>>
>>
>>
>>

>> 2013/2/8 Sam Berlin <[sbe...@gmail.com](mailto:sbe...@gmail.com)>

>>> Do you not find it a little contradictory that you use it and have
>>> no issues, yet you find the project stagnating?
> The vast majority of open issues are in extensions.  Not all can be
> reproduced, and a good number of the others are things that probably
> should be closed as "sorry, this isn't going to happen, by design".
> That's not to say there aren't legitimate issues that need fixing. 
> But, absence of commit activity does not mean the project is lost --
> it means the project is stable enough to not need it.
> sam
> On Feb 7, 2013 11:42 PM, "Mikhail Mazursky"

> <[ash...@gmail.com](mailto:ash...@gmail.com)> wrote:
>>>> With 180+ issues open and most of them in New state and no activity
>>>> in repository - i would say that this is "stagnating", not
>>>> "stable". It's a pity to see such a great tool to be abandoned.
>>>> Though, i use Guice a lot and had not a single problem with it. Big
>>>> thanks!
>>>>
>>>>
>>>> Mikhail
>>>>
>>>>
>>>>
>>>> 2013/1/25 Sam Berlin

>>>> <[sbe...@gmail.com](mailto:sbe...@gmail.com)>

>>>>> The project is mostly stable, without much need for changes.
>>>>>  There's a few changes we have stacked up internally at Google
>>>>> that will be pushed out once we fix some issues with the
>>>>> export-tool... but nothing major.
>
>>>>>
>>>>> sam
>
>>>>>
>>>>>
>>>>> On Wed, Jan 23, 2013 at 5:58 PM, Roman Ilin
>>>>> <[roman...@gmail.com](mailto:roman...@gmail.com)> wrote:
>>>>>> Hi *,
>>>>>>
>>>>>> uses guice some new svn/git repo?
>>>>>> Because last commit I can see is dated by 09/31/2012.

>>>>>> [http://code.google.com/p/google-guice/source/list](http://code.google.com/p/google-guice/source/list)

>>>>>>
>>>>>> Or guice project is not active any more?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Roman
>>>>>> --
>>>>>> 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](mailto:google-guice%2Bunsu...@googlegroups.com).

>>>>>> To post to this group, send email to

>>>>>> [google...@googlegroups.com](mailto:google...@googlegroups.com).
>>>>>> Visit this group at
>>>>>> [http://groups.google.com/group/google-guice?hl=en](http://groups.google.com/group/google-guice?hl=en).
>>>>>> For more options, visit
>>>>>> [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out).

>>>>>>  
>>>>>>  
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "google-guice" group.
>>>>> To post to this group, send email to

>>>>> [google...@googlegroups.com](mailto:google...@googlegroups.com).

>>>>>
>>>>> To unsubscribe from this group, send email to

>>>>> [google-guice...@googlegroups.com](mailto:google-guice%2Bunsu...@googlegroups.com).
>
>>>>> Visit this group at
>>>>> [http://groups.google.com/group/google-guice?hl=en](http://groups.google.com/group/google-guice?hl=en).
>>>>> For more options, visit
>>>>> [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out).

>>>>>  
>>>>>  
>>>>
>>>>
>>>>
>>>> --
>>>> 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](mailto:google-guice%2Bunsu...@googlegroups.com).

>>>> To post to this group, send email to

>>>> [google...@googlegroups.com](mailto:google...@googlegroups.com).
>>>> Visit this group at
>>>> [http://groups.google.com/group/google-guice?hl=en](http://groups.google.com/group/google-guice?hl=en).
>>>> For more options, visit
>>>> [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out).

>>>>  
>>>>  
>>>
>>> --
>>> 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](mailto:google-guice%2Bunsu...@googlegroups.com).

>>> To post to this group, send email to

>>> [google...@googlegroups.com](mailto:google...@googlegroups.com).
>>> Visit this group at
>>> [http://groups.google.com/group/google-guice?hl=en](http://groups.google.com/group/google-guice?hl=en).
>>> For more options, visit
>>> [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out).

>>>  
>>>  
>>
>>
>>
>> --
>> 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](mailto:google-guice...@googlegroups.com).

>> To post to this group, send email to

>> [google...@googlegroups.com](mailto:google...@googlegroups.com).
>> Visit this group at
>> [http://groups.google.com/group/google-guice?hl=en](http://groups.google.com/group/google-guice?hl=en).
>> For more options, visit
>> [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out).

>>  
>>  
>
>
> --
> 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?hl=en](http://groups.google.com/group/google-guice?hl=en).
> For more options, visit
> [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out).
>  
>  

[Tim Boudreau]

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

[Sam Berlin]

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

[Christian Gruber]

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

>> <nift...@gmail.com<javascript:>

>>> email to google-guice...@googlegroups.com <javascript:>.

>>> To post to this group, send email to

>>> google...@googlegroups.com<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: cgr...@google.com :::: mobile: +1 (646) 807-9839

[Tim Boudreau]

Ping?

The offer of assistance stands...

-Tim

[Stuart McCulloch]

Ditto, happy to help where necessary.

Sam - any chance you could put a zip with your internal changes somewhere so that people can give them a spin while the git-sync is fixed?

--

Cheers, Stuart

[Sam Berlin]

I'll see what I can do.

[Gili]

I'm going to repeat a point that was brought up a few years ago: it would be great if you guys would make releases more often than once every two years. The current release schedule is quite painful. Please consider releasing an update at least once every 6 months.

Thank you,

Gili

On Sunday, March 10, 2013 6:34:35 PM UTC-4, Sam Berlin wrote:

[Christian Gruber]

I don't know if this happened (the zip file), but here's the skinny.

tl;dr:

code sync in the next couple of days.

Detail:

I'm going to try to have our changes pushed out into the open-source
repo tomorrow or the day after, now that I have the syncing tool working
more or less. I'm largely just getting all the scrubbing and directory
mapping in place, but it's just a matter of doing it and testing it.

Just to be clear - we had an older version of this syncing tool we were
using but it is no longer supported. Guice never made the transition to
the newer version, and I'm in the process of doing that. The tool (MOE,
for those who care) does the mapping between our maven/ant friendly
structure in the o/s repo and our internal repository as well as
excluding irrelevant files and/or scrubbing things like names, etc.

Yes, it's been a bit of a wait and work to get this thing up, but it
will mean we can push changes between the repos basically as soon as
they are submitted. On the Guava team, we push daily or a few times a
week, typically - we're hoping to get that with Guice, Caliper, Dagger,
and any other products the core libraries folks own. Since we don't
actually make changes daily to Guice, that should mean you see changes
pretty much as they show up.

cheers,
Christian.

>>>> 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?hl=en<http://groups.google.com/group/google-guice?hl=en>
>>>> .
>>>> For more options, visit
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .

[Christian Gruber]

I'm now unblocked on where I was blocked earlier trying to get our
syncing tool to work between the internal google repository and the code
site repository. What that means is we should be able to put out a
release candidate within a week or two, and hopefully have a full
release soon thereafter.

As to more frequent releases overall, I think we all want to see that,
and we have more people focused on dependency injection inside google,
so that should be easier. Though having said that, major releases may
not be that frequent simply because the need for substantial
(Major-version-number) changes to the APIs aren't necessarily needed.
Guice is pretty stable, and largely feature-full. But certainly we'll
be rolling out the incremental changes we have been making inside google
more frequently than we have.

cheers,
Christian.

>> <nift...@gmail.com<javascript:>

>>> email to google-guice...@googlegroups.com <javascript:>.

>>> To post to this group, send email to

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

[Stephan Classen]

Great to hear that !!!!
And thanks a lot for the effort you put into getting the sync to work.

[Tim Boudreau]

On Wed, Apr 17, 2013 at 1:05 AM, Christian Gruber <cgr...@google.com> wrote:

I'm now unblocked on where I was blocked earlier trying to get our
syncing tool to work between the internal google repository and the code
site repository.  

Having set up and also rebuilt from the ground up a lot of build systems over recent years, you've got me curious - what are you guys doing internally that makes this hard?  I know large organizations have their processes and codebases have their history (I worked for Sun, after all!).  But I've got to say, if it takes months to build a diff and apply it, the reason why must be pretty interesting.

-Tim

[Sam Berlin]

It's mostly just the directory structures are pretty different. MOE makes it all magically happen, so we've been banking on using the newer version of that... It just took a while to figure out the right incantation to make it happy. Now that Christian's figured it out, things should be smooth again.

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.

[Christian Gruber]

What Sam said… and…

we have to map a project's internal directory structure but also repository kind and the directory structure around projects.

Imagine you have an SVN repo and a git repo. The svn repo had, say, this structure and a build system that had build files close to the code:

${repo_root}/projects/project{1,2,3}/sources/some/package/build_file
${repo_root}/projects/project{1,2,3}/sources/some/package/MyCode.java

but you were open-sourcing project1 in its own git repo at

${new_repo_root}/build.xml
${new_repo_root}/some/package/MyCode.java

You can't just replay commits. You have to replay commits while simultaneously mapping directories around the projects, as well as within the project. You also have to scrub in both directions so the tool doesn't suck in changes to build.xml about which you may or may not internally care, while similarly ignoring build_file in the other direction. You may also want to scrub out internal-only code, etc.

(Guava also strips out anything with @GwtIncompatible when we generate our GWT-compatible sources so we can maintain fewer sources in duplicate form, though that's not an issue we tackle in Guice)

(A version of) the syncing system we use is here (https://code.google.com/p/moe-java/) though it is maintained by volunteers only. The format has idiosyncrasies and all the experts were very busy remaking the universe in their day jobs.

It really is kind of awesome black magic. Dan Bentley and Yash Parghi are wizards. But for a company to sync two source code bases that are disparate in structure, it's a life-saver (well, ok… a day-job time-saver).

cheers,
Christian.

On 17 Apr 2013, at 4:59, Sam Berlin wrote:

It's mostly just the directory structures are pretty different. MOE makes
it all magically happen, so we've been banking on using the newer version
of that... It just took a while to figure out the right incantation to make
it happy. Now that Christian's figured it out, things should be smooth
again.

sam
On Apr 17, 2013 7:24 AM, "Tim Boudreau" nift...@gmail.com wrote:

On Wed, Apr 17, 2013 at 1:05 AM, Christian Gruber cgr...@google.comwrote:

I'm now unblocked on where I was blocked earlier trying to get our
syncing tool to work between the internal google repository and the code
site repository.

Having set up and also rebuilt from the ground up a lot of build systems
over recent years, you've got me curious - what are you guys doing
internally that makes this hard? I know large organizations have their
processes and codebases have their history (I worked for Sun, after all!).
But I've got to say, if it takes months to build a diff and apply it, the
reason why must be pretty interesting.

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

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency Injection

[Stuart McCulloch]

Any news?  I'm willing to help out where needed...

--

[Christian Gruber]

I'm about to declare frustration and just bulk export all the change in
a big commit. I'm fighting with a regression problem that JavaMoe has
whereby it digs through Change Lists / commits in order to determine
equivalency between two repositories, and then attempts to see what has
changed in each since then, and stages changes from one relative to the
other in a fresh version control workspace. All that is fine, but the
last chagnes that got into our workspace internally were the Pom bumping
changes that I believe you added, Stuart. That should be fine, but it
means that we have all sorts of change _behind_ the changes so its'
having issues syncing.

I was trying to push out something that would reflect each change in our
repository so the external repo would have these changes one-at-a-time,
but that is proving more than JavaMOE can handle in the current state of
the repo(s). So I'm going to bulk-push a big change out today, which
amounts to a diff between git and google-internal. I'll try to collect
change information (commit logs) so at least WHAT changed is reflected.

I do have Moe working well enough that once the two repos are in sync,
as long as we do a regular sync before both repos stray too far from a
common point, we should be fine. I'm sorry to have been so OCD about
this - I was trying to keep the repos in good order for the open-source
community, but at this point, a release is more important than repo
cleanliness. :/

Christian.

[Stuart McCulloch]

On 15 May 2013, at 17:33, Christian Gruber wrote:

> I'm about to declare frustration and just bulk export all the change in a big commit. I'm fighting with a regression problem that JavaMoe has whereby it digs through Change Lists / commits in order to determine equivalency between two repositories, and then attempts to see what has changed in each since then, and stages changes from one relative to the other in a fresh version control workspace. All that is fine, but the last chagnes that got into our workspace internally were the Pom bumping changes that I believe you added, Stuart.

Yes, if it helps with the sync'ing you can drop/back-out that commit - it's only a few lines in a couple of files.

> That should be fine, but it means that we have all sorts of change _behind_ the changes so its' having issues syncing.
>
> I was trying to push out something that would reflect each change in our repository so the external repo would have these changes one-at-a-time, but that is proving more than JavaMOE can handle in the current state of the repo(s). So I'm going to bulk-push a big change out today, which amounts to a diff between git and google-internal. I'll try to collect change information (commit logs) so at least WHAT changed is reflected.
>
> I do have Moe working well enough that once the two repos are in sync, as long as we do a regular sync before both repos stray too far from a common point, we should be fine. I'm sorry to have been so OCD about this - I was trying to keep the repos in good order for the open-source community, but at this point, a release is more important than repo cleanliness. :/

Sounds good - once the repos are in sync will there be a chance to suggest some patches/fixes before you cut a release?

[Christian Gruber]

We might cut a release candidate or beta if you think you have more
stuff. Also, I'll probably not bulk-commit. I'm just going to manually
sync the changes. Sadly, backing out that commit won't work because
it's been committed on both sides, and we can't roll-back-history inside
google the way you can on a single-project-git-repo. : /

Not to worry - I'll start pushing change out today.

c.