Gin snapshot release

[Peter Schmitt]

Hi all,

some of you have been asking for some combination of released jars, jars that work with generated ginjectors and a download that accommodates all versions of GWT. Since Gin changes past r155 are still largely untested in the real world and there are some known bugs (such as problems with cyclic dependencies), cutting at that revision seems safest.

There still remains the problem that r155 is not compatible with GWT 2.1 and before, just like r154 is not compatible with GWT 2.2+. Here's my suggestion: We integrate trunk at r155 into the 1.x.x branch (or create a new branch). In that branch, we apply a patch that uses reflection to make the branch work with all GWT versions (this should be pretty straightforward). Then we release a new Gin version ("1.5") from that branch. This Gin version will require a Guice snapshot or 3.0-rc2 to run.

In the meantime, we're working on getting all bugs and regressions fixed in Gin trunk and adding a few additional features. This will require work in GWT (some of which is already underway) and possibly some work in Guice and the resulting Gin version ("2.0") would require the newest versions of those two libraries.

How does this sound?

Peter

[Jeff Larsen]

I like it. I like it a lot. 

Wouldn't it make sense to apply the patch to both trunk and the new 1.5 branch? 

--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To post to this group, send email to googl...@googlegroups.com.
To unsubscribe from this group, send email to google-gin+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-gin?hl=en.

[Thomas Broyer]

On Mon, Feb 14, 2011 at 5:39 PM, Peter Schmitt <ara...@gmail.com> wrote:
> Hi all,
> some of you have been asking for some combination of released jars, jars
> that work with generated ginjectors and a download that accommodates all
> versions of GWT. Since Gin changes past r155 are still largely untested in
> the real world and there are some known bugs (such as problems with cyclic
> dependencies), cutting at that revision seems safest.
> There still remains the problem that r155 is not compatible with GWT 2.1 and
> before, just like r154 is not compatible with GWT 2.2+. Here's my
> suggestion: We integrate trunk at r155 into the 1.x.x branch (or create a
> new branch). In that branch, we apply a patch that uses reflection to make
> the branch work with all GWT versions (this should be pretty
> straightforward). Then we release a new Gin version ("1.5") from that
> branch. This Gin version will require a Guice snapshot or 3.0-rc2 to run.

...and there would need to be 2 packaged versions: one compiled
against GWT 2.2 and one against an earlier version (binary
incompatibility introduced by GWT 2.2)
This means however that the "GIN 1.5 for GWT up to 2.1.1" could be cut
from r154 while the "GIN 1.5 for GWT 2.2+" could be built directly
from r155 (i.e. no need for any additional patch).

> In the meantime, we're working on getting all bugs and regressions fixed in
> Gin trunk and adding a few additional features. This will require work in
> GWT (some of which is already underway) and possibly some work in Guice and
> the resulting Gin version ("2.0") would require the newest versions of those
> two libraries.
> How does this sound?

SGTM

[Pierre]

Hi Paul,

> > We integrate trunk at r155 into the 1.x.x branch (or create a
> > new branch). In that branch, we apply a patch that uses reflection to make
> > the branch work with all GWT versions (this should be pretty
> > straightforward). Then we release a new Gin version ("1.5") from that
> > branch. This Gin version will require a Guice snapshot or 3.0-rc2 to run.

If the patch to use reflection is applied, then issue 137 will still
be there. Could it be possible to integrate trunk at r154 into 1.x.x
branch, release a new GIN version (1.5.0), apply the r155 changes, and
do another release (1.5.1). It would be more work but this way, a new
GIN version will be available for each GWT version and there will be
no blocking issue. Or maybe could we consider that GIN 1.5 requires
GWT 2.2 and have only one release?

What do you think?

Thanks,
Pierre

[Christian Goudreau]

Well, I'm the kind to say let's release only one Gin, let's rely on Gwt 2.2. But I'm the kind that like to stay up to date and I think that's not the case for every user.

Anyway my vote goes to only one release, but I will be glad with any solution.

Cheers,

--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To post to this group, send email to googl...@googlegroups.com.
To unsubscribe from this group, send email to google-gin+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-gin?hl=en.

--
Christian Goudreau

www.arcbees.com

[Jeff Larsen]

I think he was talking about patching before issue 137 crops up. That one didn't hit until after rev 158 I believe, but yea, I would definitely be for patching in the version before issue 137 rears its ugly head. 

[Peter Schmitt]

If the patch to use reflection is applied, then issue 137 will still

be there. Could it be possible to integrate trunk at r154 into 1.x.x
branch, release a new GIN version (1.5.0), apply the r155 changes, and
do another release (1.5.1). It would be more work but this way, a new
GIN version will be available for each GWT version and there will be
no blocking issue. Or maybe could we consider that GIN 1.5 requires
GWT 2.2 and have only one release?

Issue 137 is present in neither revision. It was introduced in r159.

...and there would need to be 2 packaged versions: one compiled

against GWT 2.2 and one against an earlier version (binary
incompatibility introduced by GWT 2.2)
This means however that the "GIN 1.5 for GWT up to 2.1.1" could be cut
from r154 while the "GIN 1.5 for GWT 2.2+" could be built directly
from r155 (i.e. no need for any additional patch).

 

I haven't tried it but I believe the way we access the "binary incompatibility" (by using reflection to look up the methods) also means we don't have to have two separately compiled jars. Unless there are other binary incompatibilities that I'm not aware of. The patch that allows us to run against either GWT version would try to load one version of the access method and if that doesn't work try the other.

Peter

[Pierre]

Sorry, I thought by applying a patch that uses reflection you meant
applying the changes made at r159. But now I see that you want to use
to reflection just on methods impacted by the GWT change (and not on
the whole GIN library).

Your solution sounds good to me.

[Thomas Broyer]

On Monday, February 14, 2011 7:33:28 PM UTC+1, Aragos wrote:

...and there would need to be 2 packaged versions: one compiled

against GWT 2.2 and one against an earlier version (binary
incompatibility introduced by GWT 2.2)
This means however that the "GIN 1.5 for GWT up to 2.1.1" could be cut
from r154 while the "GIN 1.5 for GWT 2.2+" could be built directly
from r155 (i.e. no need for any additional patch).

 

I haven't tried it but I believe the way we access the "binary incompatibility" (by using reflection to look up the methods) also means we don't have to have two separately compiled jars. Unless there are other binary incompatibilities that I'm not aware of. The patch that allows us to run against either GWT version would try to load one version of the access method and if that doesn't work try the other.

GWT 2.2 is binary-incompatible with previous versions because the com.google.gwt.core.ext.typeinfo classes have been changed into interfaces (compare the 2.1.1 and 2.2 docs), which causes IncompatibleClassChangeError-s as soon as you reference them in your code (which is very likely for any generator, and is obviously the case for GIN).

[Peter Schmitt]

GWT 2.2 is binary-incompatible with previous versions because the com.google.gwt.core.ext.typeinfo classes have been changed into interfaces (compare the 2.1.1 and 2.2 docs), which causes IncompatibleClassChangeError-s as soon as you reference them in your code (which is very likely for any generator, and is obviously the case for GIN).

In that case, there is really no point in a patch trying to unify the handling of the two gwt versions. So we'll release two jars, with versions "1.5-gwt-2.1.1" and "1.5-gwt-2.2". cut at r154 and r155 respectively. Does that sound acceptable?

[Philippe Beaudoin]

SGTM.

[Carlo Alberto Degli Atti]

I agree!

On Feb 15, 5:40 am, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

[Thomas Broyer]

On Tuesday, February 15, 2011 4:30:54 AM UTC+1, Aragos wrote:

GWT 2.2 is binary-incompatible with previous versions because the com.google.gwt.core.ext.typeinfo classes have been changed into interfaces (compare the 2.1.1 and 2.2 docs), which causes IncompatibleClassChangeError-s as soon as you reference them in your code (which is very likely for any generator, and is obviously the case for GIN).

In that case, there is really no point in a patch trying to unify the handling of the two gwt versions. So we'll release two jars, with versions "1.5-gwt-2.1.1" and "1.5-gwt-2.2". cut at r154 and r155 respectively. Does that sound acceptable?

SGTM

[Jeff Larsen]

I like it. 

[Pierre]

SGTM

[Christian Goudreau]

SGTM

On Tue, Feb 15, 2011 at 9:50 AM, Pierre <plco...@gmail.com> wrote:

SGTM

--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To post to this group, send email to googl...@googlegroups.com.
To unsubscribe from this group, send email to google-gin+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-gin?hl=en.

--
Christian Goudreau

www.arcbees.com

[George Moschovitis]

So, are these jars released? Is there a public repo containing a GWT2.2 compatible version of GIN?

thanks,
-g.

[Philippe Beaudoin]

I have a version of r170 compiled against GWT-2.2 on GWT-platform download area:

    http://code.google.com/p/gwt-platform/downloads/list

Hopefully I can get rid of it soon, when there is an official release. :)

Cheers,

    Philippe