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 w
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 r
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
Any news? I'm willing to help out where needed...
On 18 Apr 2013, at 20:29, Christian Gruber wrote:
> 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 g
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:
`
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
agai
On Wed, Apr 17, 2013 at 1:05 AM, Christian Gruber 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
ove
Great to hear that
And thanks a lot for the effort you put into getting the sync to work.
--
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+unsub
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.
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 j
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, M
I'll see what I can do.
On Apr 1, 2013 6:56 AM, "Stuart McCulloch" wrote:
> 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
>
> On 1 Apr 2
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
On 1 Apr 2013, at 06:24, Tim Boudreau wrote:
> Ping?
>
> The offer of assistance stands...
>
> -
Ping?
The offer of assistance stands...
-Tim
On Sunday, March 10, 2013 6:34:35 PM UTC-4, 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:
>
>* Ad
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 r
+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 intr
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
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
build
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 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 ne
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
> Do you no
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 t
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
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 wrote:
> Hi *,
>
> uses guice s
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" g
25 matches
Mail list logo
