Our tests passed on Groovy 1.6 RC3 !

[Johnny Jian]

Our tests had been being failed before RC3, so I was afraid that we
would have a lot of work to migrate to 1.6.

And now, as the tests passed, the migration will be painless. :)

[Julien Gagnet]

That's a really good news. You did mentionned at some point having the
source code dynamically compile for the current groovy implementation.
Do you still think we should do that?

2009/2/11 Johnny Jian <Johnny...@gmail.com>:

[Johnny]

Seems there are some differences between the bytecodes generated by 1.5
and 1.6, so we had better having the source code dynamically compiled if
we support 1.5 and 1.6 at the same time. I will make sure the
differences on bytecodes after 1.6 is released.

在 2009-02-11三的 09:24 +0000，Julien Gagnet写道：

[Johnny Jian]

It seems it didn't really pass on Groovy 1.6. I was using gmaven 1.0
RC4 to compile gmock against Groovy 1.6, but I found there are no
callsites in the generated classes, that means it is not really
compiled against Groovy 1.6. So I upgrade to gmaven 1.0 RC5, but it
turns out most of the tests are failed :(

[Julien Gagnet]

Ok. So it seems like there is a bit of work to migrate.

2009/3/3 Johnny Jian <Johnny...@gmail.com>:

[Julien]

I noticed your post on the groovy user list. It seems related to it...

On Mar 3, 7:18 am, Julien Gagnet <julien.gag...@gmail.com> wrote:
> Ok. So it seems like there is a bit of work to migrate.
>

> 2009/3/3 Johnny Jian <JohnnyJia...@gmail.com>:

[Johnny]

Yes, I was asking for help for the bug of subclasses of MetaClass. And I
have look at the other failed tests with exception
IncompatibleClassChangeError like:

testMockConstructor(org.gmock.GMockControllerTest) Time elapsed: 0.003
sec <<< ERROR!
java.lang.IncompatibleClassChangeError
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallCurrentSite(CallSiteArray.java:90)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:146)
...

I thought it should be due to the introduction of callsite, but now I
find that it is due to the same bug of subclasses of MetaClass. So, we
cannot migrate to Groovy 1.6.x unless this bug is fixed or even we
rewrite the metaclasses in Java (which is a bad idea as we have
discussed).

在 2009-03-03二的 11:13 -0800，Julien写道：

[Julien Gagnet]

This is really annoying... This would mean that we would have to skip
groovy 1.6.0 to 1.6.1 which is not going to be part of grails for a
while.

2009/3/4 Johnny <johnny...@gmail.com>:

[Johnny]

I have reconsidered this problem. I have considered creating a AST
transformation which is put on the metaclasses and injects GroovyObject
into the metalclasses, but unfortunately there are too much work to do,
and I feel that it is too hacky.

Therefore, I think rewriting the metaclasses in Java is our only choice.
Fortunately, there are only 4 metaclasses (DispatcherProxyMetaClass will
be removed) which are not complex (thanks for that you have moved the
implements of MPMC to MockInternal :) ).

I am trying to rewrite them and hope to get some results soon.

在 2009-03-04三的 07:35 +0000，Julien Gagnet写道：

[Johnny Jian]

Great news! I have rewritten all metaclasses in Java, and our tests
really passed on Groovy 1.6.0 :)

On 3月18日, 下午9时36分, Johnny <johnnyjia...@gmail.com> wrote:
> I have reconsidered this problem. I have considered creating a AST
> transformation which is put on the metaclasses and injects GroovyObject
> into the metalclasses, but unfortunately there are too much work to do,
> and I feel that it is too hacky.
>
> Therefore, I think rewriting the metaclasses in Java is our only choice.
> Fortunately, there are only 4 metaclasses (DispatcherProxyMetaClass will
> be removed) which are not complex (thanks for that you have moved the
> implements of MPMC to MockInternal :) ).
>
> I am trying to rewrite them and hope to get some results soon.
>
> 在 2009-03-04三的 07:35 +0000，Julien Gagnet写道：
>
> > This is really annoying... This would mean that we would have to skip
> > groovy 1.6.0 to 1.6.1 which is not going to be part of grails for a
> > while.
>

> > 2009/3/4 Johnny <johnnyjia...@gmail.com>:

[Julien]

This is a fantastic news. I was a bit nervous about it.

I think we should release 0.7 and 0.8 simultaneously with no other
added feature in 0.8 than the support for groovy 1.6. I've started
updating the docs and think we could do it pretty soon.

Julien

[Johnny]

Actually we have a lot of work to do for version 0.8, as we have to
migrate to a new build system (there are a lot of bugs in gmaven's stub
generation), and I am testing gant and gradle.

What's more, we can have the @WithGMock AST transformation in 0.8 (have
you missed that issue? I haven't seen you accept it.), so some new
features against groovy 1.6 may be added.

在 2009-03-18三的 20:38 +0000，Julien写道：

[Johnny Jian]

One more thing, jarjar will not work on groovy 1.6, because the code
compiled by groovy 1.6 use 'Class.forName("...")' to load classes.

So, we have to jarjarify the dependencies first, and our code should
depend on these jarjarified jar files.

On 3月19日, 上午9时43分, Johnny <johnnyjia...@gmail.com> wrote:
> Actually we have a lot of work to do for version 0.8, as we have to
> migrate to a new build system (there are a lot of bugs in gmaven's stub
> generation), and I am testing gant and gradle.
>
> What's more, we can have the @WithGMock AST transformation in 0.8 (have
> you missed that issue? I haven't seen you accept it.), so some new
> features against groovy 1.6 may be added.
>
> 在 2009-03-18三的 20:38 +0000，Julien写道：
>
> > This is a fantastic news. I was a bit nervous about it.
>
> > I think we should release 0.7 and 0.8 simultaneously with no other  
> > added feature in 0.8 than the support for groovy 1.6. I've started  
> > updating the docs and think we could do it pretty soon.
>
> > Julien
>

[Julien Gagnet]

What are the problems with the current build system and gmaven stub generation? Do we need to move to something different?

I was in a conference about gradle, the technology seems interesting. My only worry could be its incompatibility with maven.

I had seen the AST transformation issue but forget to approve it. I was just thinking that it wasn't entirely required for 0.8 and that we could push it to 0.9.

2009/3/19 Johnny Jian <Johnny...@gmail.com>

[Johnny]

gmaven stub generation doesn't support enums and there are several
classes' constructors which are not generated correctly (doesn't call
super(...) ). Because we rewrote metaclasses in Java, the Java code
depends on the Groovy code, so joint compilation is really needed.

What's more, we have not figured out how to do integration tests in
maven(maybe we cannot do so). These make us need to move to other build
systems.

I don't think gradle is incompatibility with maven, at least it can
interact with maven repositories, which may be the only thing we need
for compatibility.

I have written a gradle build file to test our code against groovy 1.6,
and it is pretty short (much shorter than the gant build file):

usePlugin('groovy')

sourceCompatibility = 1.5
targetCompatibility = 1.5
group = 'org.gmock'
version = '0.7.0-SNAPSHOT'

srcDirNames = []
groovySrcDirNames = ['main/java', 'main/groovy']

dependencies {
addMavenRepo()
groovy "org.codehaus.groovy:groovy-all:1.6.0"
compile "junit:junit:4.5"
compile "cglib:cglib:2.2"
compile "org.objenesis:objenesis:1.1"
testCompile "org.hamcrest:hamcrest-library:1.1"
}

在 2009-03-19四的 07:15 +0000，Julien Gagnet写道：

[Julien Gagnet]

Ok. That sound a sensible approach.

Would you like to create a branch for gmock 0.8 and raises the
different issue of what you think need to be done, so I could join the
0.8 fun.

2009/3/19 Johnny <johnny...@gmail.com>:

[Johnny]

OK, I will do that. I was just wondering whether rewriting the
metaclasses can make it works.

在 2009-03-19四的 07:58 +0000，Julien Gagnet写道：