Test fails when building from source

[Kenneth Kousen-2]

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)




and




assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Roshan Dawrani-2]

Exception details don't seem fully correct. It should be GroovyBean3726D.setBar() and not GroovyBean3726C.setBar() because the test case does not even try to access setBar() on GroovyBean3726C.

A few things:

1) If you are not doing the build from command line, can you try once from command line - "ant clean" and then "ant install"

2) If the build still fails, can you then do "ant install -DskipTests=true" and after that do groovyc on the following 2 scripts using the newly built groovy and send the class files generated?

a)
            public class GroovyBean3726D {
                transient String bar = "anything"
            }
b)
            class Groovy3801C {
                static main() {}
            }

rgds,
Roshan

On Sun, Nov 8, 2009 at 7:04 AM, Kenneth Kousen <ken.kousen@...> wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)




and




assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Paul King]

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

> Hi all,
>
> I want to try to see if I can contribute to Groovy, so I checked out the
> source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and
> tried to build it. When I typed "ant install", I got 2 failures, both in
> the class UberTestCaseBugs.  From the test report on that class:
>
> GroovyBean3726C.setBar(java.lang.String)
>
> |java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
> |
> |
> |and|
> |
> |
> |assert
> nonStdMainMethod.returnType.toString().contains('java.lang.Object') | |
> | | | void void false public static void
> Groovy3801B.main(java.lang.String[])|
>
> The build stopped running at that point.  I'm still pretty new to this.
>  What am I supposed to do now?  Is there some way to skip these tests?
>  Do they cause anybody else problems?
>
> I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.
>
> Thanks for any advice,
>
> Ken
> --
> Kenneth A. Kousen
> President
> Kousen IT, Inc.
>
> Email: ken.kousen@... <mailto:ken.kousen@...>
> Site: http://www.kousenit.com
> Blog: http://kousenit.wordpress.com
> Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kenneth Kousen-2]

I ran an "ant clean" and "ant install".  This time I got an error in UberTestCaseBugs in the "testMainMethodSignature" test again:

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801A.main(java.lang.String[])

Assertion failed: 

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object')
| | | |
| void void false
public static void Groovy3801A.main(java.lang.String[])

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.bugs.Groovy3801Bug.testMainMethodSignature(Groovy3801Bug.groovy:33)
0.062

I'll try to build without the tests, but I don't quite understand what I'm supposed to do after that.

Thanks for the help, though.  I'd really like to be able to do this, but I don't feel I can actually contribute anything until I can do a clean build and test, right?

Ken

On Sat, Nov 7, 2009 at 10:37 PM, Paul King <paulk@...> wrote:

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

|java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
|
|
|and|
|
|
|assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])|

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken
--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@... <mailto:ken.kousen@...>

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Roshan Dawrani-2]

By the time the execution reaches line 33 (where it fails), clazz should point to Groovy3801C and not Groovy3801A.

I think what is happening is that (which also explains why it happens only sometimes on TeamCity CI servers) :-

There are 3 consecutive calls GCL#parseClass(String) happening there - Groovy3801A, Groovy3801B, Groovy3801C.

And for all these 3 calls, parseClass(String) method generates a temporary File name as "script" + System.currentTimeMillis() + ".groovy", so what is happening is that when it does parseClass() for Groovy3801C script string, it is still in the same value of System.currentTimeMillis() that it had when Groovy3801A was compiled.

Since the compiler caches the compiled classes  (and the default behavior is to cache), for parseClass[Groovy3801C] call, it is returning the Groovy3801A class going by the mili-seconds based generated script name.

I am attaching here a slightly modified version of Groovy3801Bug.groovy test file (I have changed parseClass() call to pass specific file names instead of relying on the generated file name). Please try with this and you should not have that issue anymore.

Even Groovy3726Bug.groovy has a similar consecutive calls to parseClass(). I will correct there also after you confirm that you don't get any issues with Groovy3801Bug.groovy attached here anymore.

rgds,
Roshan

On Sun, Nov 8, 2009 at 10:11 AM, Kenneth Kousen <ken.kousen@...> wrote:

I ran an "ant clean" and "ant install".  This time I got an error in UberTestCaseBugs in the "testMainMethodSignature" test again:

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801A.main(java.lang.String[])

Assertion failed: 

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object')
| | | |
| void void false

public static void Groovy3801A.main(java.lang.String[])

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.bugs.Groovy3801Bug.testMainMethodSignature(Groovy3801Bug.groovy:33)
0.062

I'll try to build without the tests, but I don't quite understand what I'm supposed to do after that.

Thanks for the help, though.  I'd really like to be able to do this, but I don't feel I can actually contribute anything until I can do a clean build and test, right?

Ken

On Sat, Nov 7, 2009 at 10:37 PM, Paul King <paulk@...> wrote:

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

|java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
|
|
|and|
|
|
|assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])|

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken
--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@... <mailto:ken.kousen@...>

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

I have fixed the Groovy3801Bug and Groovy3726Bug tests now as per my previous mail.

If you update the code and try again, you should not see the test failures that you reported earlier.

-- Roshan

On Sun, Nov 8, 2009 at 11:13 AM, Roshan Dawrani <roshandawrani@...> wrote:

By the time the execution reaches line 33 (where it fails), clazz should point to Groovy3801C and not Groovy3801A.

I think what is happening is that (which also explains why it happens only sometimes on TeamCity CI servers) :-

There are 3 consecutive calls GCL#parseClass(String) happening there - Groovy3801A, Groovy3801B, Groovy3801C.

And for all these 3 calls, parseClass(String) method generates a temporary File name as "script" + System.currentTimeMillis() + ".groovy", so what is happening is that when it does parseClass() for Groovy3801C script string, it is still in the same value of System.currentTimeMillis() that it had when Groovy3801A was compiled.

Since the compiler caches the compiled classes  (and the default behavior is to cache), for parseClass[Groovy3801C] call, it is returning the Groovy3801A class going by the mili-seconds based generated script name.

I am attaching here a slightly modified version of Groovy3801Bug.groovy test file (I have changed parseClass() call to pass specific file names instead of relying on the generated file name). Please try with this and you should not have that issue anymore.

Even Groovy3726Bug.groovy has a similar consecutive calls to parseClass(). I will correct there also after you confirm that you don't get any issues with Groovy3801Bug.groovy attached here anymore.

rgds,
Roshan

On Sun, Nov 8, 2009 at 10:11 AM, Kenneth Kousen <ken.kousen@...> wrote:

I ran an "ant clean" and "ant install".  This time I got an error in UberTestCaseBugs in the "testMainMethodSignature" test again:

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801A.main(java.lang.String[])

Assertion failed: 

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object')
| | | |
| void void false

public static void Groovy3801A.main(java.lang.String[])

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.bugs.Groovy3801Bug.testMainMethodSignature(Groovy3801Bug.groovy:33)
0.062

I'll try to build without the tests, but I don't quite understand what I'm supposed to do after that.

Thanks for the help, though.  I'd really like to be able to do this, but I don't feel I can actually contribute anything until I can do a clean build and test, right?

Ken

On Sat, Nov 7, 2009 at 10:37 PM, Paul King <paulk@...> wrote:

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

|java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
|
|
|and|
|
|
|assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])|

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken
--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@... <mailto:ken.kousen@...>

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Kenneth Kousen-2]

Thanks for the help.  I'm now getting a different failure.  This time it's from "testPackageDefinitionForGroovyClassesInParseClass" triggered by "UberTestCaseGroovySourceSubPackages".  Here's the detailed info:

assert clazz.package.name == expectedPkgName | | | | | | | pkg1 | pkg1.pkg2 | package pkg1 false class pkg1.script1257693809078

Assertion failed: 

assert clazz.package.name == expectedPkgName
| | | | |
| | pkg1 | pkg1.pkg2
| package pkg1 false
class pkg1.script1257693809078

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.lang.GroovyClassLoaderTest.verifyPackageDetails(GroovyClassLoaderTest.groovy:216)
at groovy.lang.GroovyClassLoaderTest$verifyPackageDetails.callCurrent(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:155)
at groovy.lang.GroovyClassLoaderTest.testPackageDefinitionForGroovyClassesInParseClass(GroovyClassLoaderTest.groovy:200)

Again, I appreciate the assistance.

Ken

On Sun, Nov 8, 2009 at 7:04 AM, Roshan Dawrani <roshandawrani@...> wrote:

I have fixed the Groovy3801Bug and Groovy3726Bug tests now as per my previous mail.

If you update the code and try again, you should not see the test failures that you reported earlier. 

-- Roshan

On Sun, Nov 8, 2009 at 11:13 AM, Roshan Dawrani <roshandawrani@...> wrote:

By the time the execution reaches line 33 (where it fails), clazz should point to Groovy3801C and not Groovy3801A.

I think what is happening is that (which also explains why it happens only sometimes on TeamCity CI servers) :-

There are 3 consecutive calls GCL#parseClass(String) happening there - Groovy3801A, Groovy3801B, Groovy3801C.

And for all these 3 calls, parseClass(String) method generates a temporary File name as "script" + System.currentTimeMillis() + ".groovy", so what is happening is that when it does parseClass() for Groovy3801C script string, it is still in the same value of System.currentTimeMillis() that it had when Groovy3801A was compiled.

Since the compiler caches the compiled classes  (and the default behavior is to cache), for parseClass[Groovy3801C] call, it is returning the Groovy3801A class going by the mili-seconds based generated script name.

I am attaching here a slightly modified version of Groovy3801Bug.groovy test file (I have changed parseClass() call to pass specific file names instead of relying on the generated file name). Please try with this and you should not have that issue anymore.

Even Groovy3726Bug.groovy has a similar consecutive calls to parseClass(). I will correct there also after you confirm that you don't get any issues with Groovy3801Bug.groovy attached here anymore.

rgds,
Roshan

On Sun, Nov 8, 2009 at 10:11 AM, Kenneth Kousen <ken.kousen@...> wrote:

I ran an "ant clean" and "ant install".  This time I got an error in UberTestCaseBugs in the "testMainMethodSignature" test again:

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801A.main(java.lang.String[])

Assertion failed: 

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object')
| | | |
| void void false

public static void Groovy3801A.main(java.lang.String[])

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.bugs.Groovy3801Bug.testMainMethodSignature(Groovy3801Bug.groovy:33)
0.062

I'll try to build without the tests, but I don't quite understand what I'm supposed to do after that.

Thanks for the help, though.  I'd really like to be able to do this, but I don't feel I can actually contribute anything until I can do a clean build and test, right?

Ken

On Sat, Nov 7, 2009 at 10:37 PM, Paul King <paulk@...> wrote:

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

|java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
|
|
|and|
|
|
|assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])|

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken
--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@... <mailto:ken.kousen@...>

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Roshan Dawrani-2]

I have fixed this test also. Can you try again?

Next time I write consecutive calls to GroovyClassLoader#parseClass(), I will not rely on the dummy file-names it generates.

-- Roshan

On Sun, Nov 8, 2009 at 9:00 PM, Kenneth Kousen <ken.kousen@...> wrote:

Thanks for the help.  I'm now getting a different failure.  This time it's from "testPackageDefinitionForGroovyClassesInParseClass" triggered by "UberTestCaseGroovySourceSubPackages".  Here's the detailed info:

assert clazz.package.name == expectedPkgName | | | | | | | pkg1 | pkg1.pkg2 | package pkg1 false class pkg1.script1257693809078

Assertion failed: 

assert clazz.package.name == expectedPkgName
| | | | |
| | pkg1 | pkg1.pkg2
| package pkg1 false
class pkg1.script1257693809078

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)

at groovy.lang.GroovyClassLoaderTest.verifyPackageDetails(GroovyClassLoaderTest.groovy:216)
at groovy.lang.GroovyClassLoaderTest$verifyPackageDetails.callCurrent(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:155)
at groovy.lang.GroovyClassLoaderTest.testPackageDefinitionForGroovyClassesInParseClass(GroovyClassLoaderTest.groovy:200)

Again, I appreciate the assistance.

Ken

On Sun, Nov 8, 2009 at 7:04 AM, Roshan Dawrani <roshandawrani@...> wrote:

I have fixed the Groovy3801Bug and Groovy3726Bug tests now as per my previous mail.

If you update the code and try again, you should not see the test failures that you reported earlier. 

-- Roshan

On Sun, Nov 8, 2009 at 11:13 AM, Roshan Dawrani <roshandawrani@...> wrote:

By the time the execution reaches line 33 (where it fails), clazz should point to Groovy3801C and not Groovy3801A.

I think what is happening is that (which also explains why it happens only sometimes on TeamCity CI servers) :-

There are 3 consecutive calls GCL#parseClass(String) happening there - Groovy3801A, Groovy3801B, Groovy3801C.

And for all these 3 calls, parseClass(String) method generates a temporary File name as "script" + System.currentTimeMillis() + ".groovy", so what is happening is that when it does parseClass() for Groovy3801C script string, it is still in the same value of System.currentTimeMillis() that it had when Groovy3801A was compiled.

Since the compiler caches the compiled classes  (and the default behavior is to cache), for parseClass[Groovy3801C] call, it is returning the Groovy3801A class going by the mili-seconds based generated script name.

I am attaching here a slightly modified version of Groovy3801Bug.groovy test file (I have changed parseClass() call to pass specific file names instead of relying on the generated file name). Please try with this and you should not have that issue anymore.

Even Groovy3726Bug.groovy has a similar consecutive calls to parseClass(). I will correct there also after you confirm that you don't get any issues with Groovy3801Bug.groovy attached here anymore.

rgds,
Roshan

On Sun, Nov 8, 2009 at 10:11 AM, Kenneth Kousen <ken.kousen@...> wrote:

I ran an "ant clean" and "ant install".  This time I got an error in UberTestCaseBugs in the "testMainMethodSignature" test again:

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801A.main(java.lang.String[])

Assertion failed: 

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object')
| | | |
| void void false

public static void Groovy3801A.main(java.lang.String[])

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.bugs.Groovy3801Bug.testMainMethodSignature(Groovy3801Bug.groovy:33)
0.062

I'll try to build without the tests, but I don't quite understand what I'm supposed to do after that.

Thanks for the help, though.  I'd really like to be able to do this, but I don't feel I can actually contribute anything until I can do a clean build and test, right?

Ken

On Sat, Nov 7, 2009 at 10:37 PM, Paul King <paulk@...> wrote:

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

|java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
|
|
|and|
|
|
|assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])|

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken
--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@... <mailto:ken.kousen@...>

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Kenneth Kousen-2]

That did it.  Thanks!

Ken

On Sun, Nov 8, 2009 at 12:03 PM, Roshan Dawrani <roshandawrani@...> wrote:

I have fixed this test also. Can you try again?

Next time I write consecutive calls to GroovyClassLoader#parseClass(), I will not rely on the dummy file-names it generates.

-- Roshan

On Sun, Nov 8, 2009 at 9:00 PM, Kenneth Kousen <ken.kousen@...> wrote:

Thanks for the help.  I'm now getting a different failure.  This time it's from "testPackageDefinitionForGroovyClassesInParseClass" triggered by "UberTestCaseGroovySourceSubPackages".  Here's the detailed info:

assert clazz.package.name == expectedPkgName | | | | | | | pkg1 | pkg1.pkg2 | package pkg1 false class pkg1.script1257693809078

Assertion failed: 

assert clazz.package.name == expectedPkgName
| | | | |
| | pkg1 | pkg1.pkg2
| package pkg1 false
class pkg1.script1257693809078

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)

at groovy.lang.GroovyClassLoaderTest.verifyPackageDetails(GroovyClassLoaderTest.groovy:216)
at groovy.lang.GroovyClassLoaderTest$verifyPackageDetails.callCurrent(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:155)
at groovy.lang.GroovyClassLoaderTest.testPackageDefinitionForGroovyClassesInParseClass(GroovyClassLoaderTest.groovy:200)

Again, I appreciate the assistance.

Ken

On Sun, Nov 8, 2009 at 7:04 AM, Roshan Dawrani <roshandawrani@...> wrote:

I have fixed the Groovy3801Bug and Groovy3726Bug tests now as per my previous mail.

If you update the code and try again, you should not see the test failures that you reported earlier. 

-- Roshan

On Sun, Nov 8, 2009 at 11:13 AM, Roshan Dawrani <roshandawrani@...> wrote:

By the time the execution reaches line 33 (where it fails), clazz should point to Groovy3801C and not Groovy3801A.

I think what is happening is that (which also explains why it happens only sometimes on TeamCity CI servers) :-

There are 3 consecutive calls GCL#parseClass(String) happening there - Groovy3801A, Groovy3801B, Groovy3801C.

And for all these 3 calls, parseClass(String) method generates a temporary File name as "script" + System.currentTimeMillis() + ".groovy", so what is happening is that when it does parseClass() for Groovy3801C script string, it is still in the same value of System.currentTimeMillis() that it had when Groovy3801A was compiled.

Since the compiler caches the compiled classes  (and the default behavior is to cache), for parseClass[Groovy3801C] call, it is returning the Groovy3801A class going by the mili-seconds based generated script name.

I am attaching here a slightly modified version of Groovy3801Bug.groovy test file (I have changed parseClass() call to pass specific file names instead of relying on the generated file name). Please try with this and you should not have that issue anymore.

Even Groovy3726Bug.groovy has a similar consecutive calls to parseClass(). I will correct there also after you confirm that you don't get any issues with Groovy3801Bug.groovy attached here anymore.

rgds,
Roshan

On Sun, Nov 8, 2009 at 10:11 AM, Kenneth Kousen <ken.kousen@...> wrote:

I ran an "ant clean" and "ant install".  This time I got an error in UberTestCaseBugs in the "testMainMethodSignature" test again:

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801A.main(java.lang.String[])

Assertion failed: 

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object')
| | | |
| void void false

public static void Groovy3801A.main(java.lang.String[])

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.bugs.Groovy3801Bug.testMainMethodSignature(Groovy3801Bug.groovy:33)
0.062

I'll try to build without the tests, but I don't quite understand what I'm supposed to do after that.

Thanks for the help, though.  I'd really like to be able to do this, but I don't feel I can actually contribute anything until I can do a clean build and test, right?

Ken

On Sat, Nov 7, 2009 at 10:37 PM, Paul King <paulk@...> wrote:

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

|java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
|
|
|and|
|
|
|assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])|

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken
--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@... <mailto:ken.kousen@...>

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Roshan Dawrani-2]

Good that you are able to proceed now, Ken.

However, I think the behavior you encountered raises an issue for GroovyClassLoader.

I think its "parseClass(String text)" method should not cache the classes it generates. For example, if we have

def gcl = new GroovyClassLoader()

gcl.parseClass("class A {}")
gcl.parseClass("class B {}")
gcl.parseClass("class C {}")

Right now, if all the 3 calls above happen to get executed within the same milli-second, then they will get the same dummy script name generated by groovy, and therefore 2nd and 3rd parseClass() calls will return class A (because caching is happening by file name), when they should not.

If we remove the caching behavior for "parseClass(String text)", then that will not happen.

I want to raise a JIRA for it and fix that.

Does anyone see any side-effects of that? Any reason that should not be done?

rgds,
Roshan

On Mon, Nov 9, 2009 at 2:01 AM, Kenneth Kousen <ken.kousen@...> wrote:

That did it.  Thanks!

Ken

On Sun, Nov 8, 2009 at 12:03 PM, Roshan Dawrani <roshandawrani@...> wrote:

I have fixed this test also. Can you try again?

Next time I write consecutive calls to GroovyClassLoader#parseClass(), I will not rely on the dummy file-names it generates.

-- Roshan

On Sun, Nov 8, 2009 at 9:00 PM, Kenneth Kousen <ken.kousen@...> wrote:

Thanks for the help.  I'm now getting a different failure.  This time it's from "testPackageDefinitionForGroovyClassesInParseClass" triggered by "UberTestCaseGroovySourceSubPackages".  Here's the detailed info:

assert clazz.package.name == expectedPkgName | | | | | | | pkg1 | pkg1.pkg2 | package pkg1 false class pkg1.script1257693809078

Assertion failed: 

assert clazz.package.name == expectedPkgName
| | | | |
| | pkg1 | pkg1.pkg2
| package pkg1 false
class pkg1.script1257693809078

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)

at groovy.lang.GroovyClassLoaderTest.verifyPackageDetails(GroovyClassLoaderTest.groovy:216)
at groovy.lang.GroovyClassLoaderTest$verifyPackageDetails.callCurrent(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:143)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:155)
at groovy.lang.GroovyClassLoaderTest.testPackageDefinitionForGroovyClassesInParseClass(GroovyClassLoaderTest.groovy:200)

Again, I appreciate the assistance.

Ken

On Sun, Nov 8, 2009 at 7:04 AM, Roshan Dawrani <roshandawrani@...> wrote:

I have fixed the Groovy3801Bug and Groovy3726Bug tests now as per my previous mail.

If you update the code and try again, you should not see the test failures that you reported earlier. 

-- Roshan

On Sun, Nov 8, 2009 at 11:13 AM, Roshan Dawrani <roshandawrani@...> wrote:

By the time the execution reaches line 33 (where it fails), clazz should point to Groovy3801C and not Groovy3801A.

I think what is happening is that (which also explains why it happens only sometimes on TeamCity CI servers) :-

There are 3 consecutive calls GCL#parseClass(String) happening there - Groovy3801A, Groovy3801B, Groovy3801C.

And for all these 3 calls, parseClass(String) method generates a temporary File name as "script" + System.currentTimeMillis() + ".groovy", so what is happening is that when it does parseClass() for Groovy3801C script string, it is still in the same value of System.currentTimeMillis() that it had when Groovy3801A was compiled.

Since the compiler caches the compiled classes  (and the default behavior is to cache), for parseClass[Groovy3801C] call, it is returning the Groovy3801A class going by the mili-seconds based generated script name.

I am attaching here a slightly modified version of Groovy3801Bug.groovy test file (I have changed parseClass() call to pass specific file names instead of relying on the generated file name). Please try with this and you should not have that issue anymore.

Even Groovy3726Bug.groovy has a similar consecutive calls to parseClass(). I will correct there also after you confirm that you don't get any issues with Groovy3801Bug.groovy attached here anymore.

rgds,
Roshan

On Sun, Nov 8, 2009 at 10:11 AM, Kenneth Kousen <ken.kousen@...> wrote:

I ran an "ant clean" and "ant install".  This time I got an error in UberTestCaseBugs in the "testMainMethodSignature" test again:

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801A.main(java.lang.String[])

Assertion failed: 

assert nonStdMainMethod.returnType.toString().contains('java.lang.Object')
| | | |
| void void false

public static void Groovy3801A.main(java.lang.String[])

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:377)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:662)
at groovy.bugs.Groovy3801Bug.testMainMethodSignature(Groovy3801Bug.groovy:33)
0.062

I'll try to build without the tests, but I don't quite understand what I'm supposed to do after that.

Thanks for the help, though.  I'd really like to be able to do this, but I don't feel I can actually contribute anything until I can do a clean build and test, right?

Ken

On Sat, Nov 7, 2009 at 10:37 PM, Paul King <paulk@...> wrote:

Roshan beat me to it. The only thing I would add is that we get an
error similar to that sometimes on one of the TeamCity CI servers
though I have never seen it locally myself.

Cheers, Paul.

Kenneth Kousen wrote:

Hi all,

I want to try to see if I can contribute to Groovy, so I checked out the source from https://svn.codehaus.org/groovy/trunk/groovy/groovy-core and tried to build it. When I typed "ant install", I got 2 failures, both in the class UberTestCaseBugs.  From the test report on that class:

GroovyBean3726C.setBar(java.lang.String)

|java.lang.NoSuchMethodException: GroovyBean3726C.setBar(java.lang.String)|
|
|
|and|
|
|
|assert nonStdMainMethod.returnType.toString().contains('java.lang.Object') | | | | | void void false public static void Groovy3801B.main(java.lang.String[])|

The build stopped running at that point.  I'm still pretty new to this.  What am I supposed to do now?  Is there some way to skip these tests?  Do they cause anybody else problems?

I'm running on a Windows XP box with JDK 1.6.0_16 and Ant 1.7.1.

Thanks for any advice,

Ken
--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@... <mailto:ken.kousen@...>

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...

Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: ken.kousen@...
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

[Guillaume Laforge-2]

On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani <roshandawrani@...> wrote:
> [...]
> If we remove the caching behavior for "parseClass(String text)", then that
> will not happen.
>
> I want to raise a JIRA for it and fix that.
>
> Does anyone see any side-effects of that? Any reason that should not be
> done?

I can't think of a side-effect. It should be fixed if we can find a
better dummy name generation.
What kind of dummy name will you use to ensure we don't get the same
twice in a row?
Appending some hashCode for instance?


--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

I think an alternate way of generating the dummy name may not be required.

I was just thinking of making sure that GroovyCodeSource instance has cachable attribute set to false when it comes via the route GCL#parseClass(String).

If we don't cache, we don't run into that issue even if multiple calls happen to come with the same generated name.

What do you think?

rgds,
Roshan

On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge <glaforge@...> wrote:

On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani <roshandawrani@...> wrote:
> [...]

> If we remove the caching behavior for "parseClass(String text)", then that
> will not happen.
>
> I want to raise a JIRA for it and fix that.
>
> Does anyone see any side-effects of that? Any reason that should not be
> done?

I can't think of a side-effect. It should be fixed if we can find a
better dummy name generation.
What kind of dummy name will you use to ensure we don't get the same
twice in a row?
Appending some hashCode for instance?


--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

On the contrary, I was thinking a more appropriate name generation
would be better.
There's basically a collision for two different classes to be somehow
created under one single name instead of two.
It's not really a problem of caching per se (in the sense something
should be cacheable or not), but a problem of name which should be
different.
So perhaps a name with the hashcode of the content and time would
really avoid all possible collisions.

On Mon, Nov 9, 2009 at 07:54, Roshan Dawrani <roshandawrani@...> wrote:

> I think an alternate way of generating the dummy name may not be required.
>
> I was just thinking of making sure that GroovyCodeSource instance has
> cachable attribute set to false when it comes via the route
> GCL#parseClass(String).
>
> If we don't cache, we don't run into that issue even if multiple calls
> happen to come with the same generated name.
>
> What do you think?
>
> rgds,
> Roshan
>
>
> On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge <glaforge@...>
> wrote:
>>
>> On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani <roshandawrani@...>
>> wrote:
>> > [...]
>> > If we remove the caching behavior for "parseClass(String text)", then
>> > that
>> > will not happen.
>> >
>> > I want to raise a JIRA for it and fix that.
>> >
>> > Does anyone see any side-effects of that? Any reason that should not be
>> > done?
>>
>> I can't think of a side-effect. It should be fixed if we can find a
>> better dummy name generation.
>> What kind of dummy name will you use to ensure we don't get the same
>> twice in a row?
>> Appending some hashCode for instance?
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani]

Alright. If that makes more sense, then that's the change I'll put in. The point is the removal of the GCL bug that has got highlighted and that gets solved either way.

---------------------------------------------------
Sent from BlackBerry

-----Original Message-----
From: Guillaume Laforge <glaforge@...>
Date: Mon, 9 Nov 2009 09:59:57
To: <dev@...>
Subject: Re: [groovy-dev] Test fails when building from source
On the contrary, I was thinking a more appropriate name generation
would be better.
There's basically a collision for two different classes to be somehow
created under one single name instead of two.
It's not really a problem of caching per se (in the sense something
should be cacheable or not), but a problem of name which should be
different.
So perhaps a name with the hashcode of the content and time would
really avoid all possible collisions.

On Mon, Nov 9, 2009 at 07:54, Roshan Dawrani <roshandawrani@...> wrote:

> I think an alternate way of generating the dummy name may not be required.
>
> I was just thinking of making sure that GroovyCodeSource instance has
> cachable attribute set to false when it comes via the route
> GCL#parseClass(String).
>
> If we don't cache, we don't run into that issue even if multiple calls
> happen to come with the same generated name.
>
> What do you think?
>
> rgds,
> Roshan
>
>
> On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge <glaforge@...>
> wrote:
>>
>> On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani <roshandawrani@...>
>> wrote:
>> > [...]
>> > If we remove the caching behavior for "parseClass(String text)", then
>> > that
>> > will not happen.
>> >
>> > I want to raise a JIRA for it and fix that.
>> >
>> > Does anyone see any side-effects of that? Any reason that should not be
>> > done?
>>
>> I can't think of a side-effect. It should be fixed if we can find a
>> better dummy name generation.
>> What kind of dummy name will you use to ensure we don't get the same
>> twice in a row?
>> Appending some hashCode for instance?
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

Yes.

On Mon, Nov 9, 2009 at 10:05,  <roshandawrani@...> wrote:

> Alright. If that makes more sense, then that's the change I'll put in. The point is the removal of the GCL bug that has got highlighted and that gets solved either way.
>
> ---------------------------------------------------
> Sent from BlackBerry
>
> -----Original Message-----
> From: Guillaume Laforge <glaforge@...>
> Date: Mon, 9 Nov 2009 09:59:57
> To: <dev@...>
> Subject: Re: [groovy-dev] Test fails when building from source
> On the contrary, I was thinking a more appropriate name generation
> would be better.
> There's basically a collision for two different classes to be somehow
> created under one single name instead of two.
> It's not really a problem of caching per se (in the sense something
> should be cacheable or not), but a problem of name which should be
> different.
> So perhaps a name with the hashcode of the content and time would
> really avoid all possible collisions.
>
> On Mon, Nov 9, 2009 at 07:54, Roshan Dawrani <roshandawrani@...> wrote:
>> I think an alternate way of generating the dummy name may not be required.
>>
>> I was just thinking of making sure that GroovyCodeSource instance has
>> cachable attribute set to false when it comes via the route
>> GCL#parseClass(String).
>>
>> If we don't cache, we don't run into that issue even if multiple calls
>> happen to come with the same generated name.
>>
>> What do you think?
>>
>> rgds,
>> Roshan
>>
>>
>> On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge <glaforge@...>
>> wrote:
>>>
>>> On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani <roshandawrani@...>
>>> wrote:
>>> > [...]
>>> > If we remove the caching behavior for "parseClass(String text)", then
>>> > that
>>> > will not happen.
>>> >
>>> > I want to raise a JIRA for it and fix that.
>>> >
>>> > Does anyone see any side-effects of that? Any reason that should not be
>>> > done?
>>>
>>> I can't think of a side-effect. It should be fixed if we can find a
>>> better dummy name generation.
>>> What kind of dummy name will you use to ensure we don't get the same
>>> twice in a row?
>>> Appending some hashCode for instance?
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Groovy Project Manager
>>> Head of Groovy Development at SpringSource
>>> http://www.springsource.com/g2one
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

Well, a property that holds most of the time, but fails rarely, is worse
than something that never holds.  People may be tricked into thinking
the names are unique, then run into exactly the same problem you had.

So I'd vote for either fixing the dummy name generation, or getting rid
of it altogether and having everything have the same name.

Fixing it wouldn't be hard though.  You could just have a global
counter, and increment it on every call.  If threading is an issue, you
can either synchronize access to the counter, or have per-thread
counters and append a thread id.

Best,
Martin

Roshan Dawrani wrote:

> I think an alternate way of generating the dummy name may not be required.
>
> I was just thinking of making sure that GroovyCodeSource instance has
> cachable attribute set to false when it comes via the route
> GCL#parseClass(String).
>
> If we don't cache, we don't run into that issue even if multiple calls
> happen to come with the same generated name.
>
> What do you think?
>
> rgds,
> Roshan
>
>
> On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge
> <glaforge@... <mailto:glaforge@...>> wrote:
>
>     On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani
>     <roshandawrani@... <mailto:roshandawrani@...>> wrote:
>      > [...]
>      > If we remove the caching behavior for "parseClass(String text)",
>     then that
>      > will not happen.
>      >
>      > I want to raise a JIRA for it and fix that.
>      >
>      > Does anyone see any side-effects of that? Any reason that should
>     not be
>      > done?
>
>     I can't think of a side-effect. It should be fixed if we can find a
>     better dummy name generation.
>     What kind of dummy name will you use to ensure we don't get the same
>     twice in a row?
>     Appending some hashCode for instance?
>
>
>     --
>     Guillaume Laforge
>     Groovy Project Manager
>     Head of Groovy Development at SpringSource
>     http://www.springsource.com/g2one
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>        http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

If hashCode + currentMillis is also considered a combination that may fail rarely, then how about a global AtomicInteger (incremented on each parseClass(String) call) + Thread-Id combination?

On Mon, Nov 9, 2009 at 5:25 PM, Martin C. Martin <martin@...> wrote:

Well, a property that holds most of the time, but fails rarely, is worse than something that never holds.  People may be tricked into thinking the names are unique, then run into exactly the same problem you had.

So I'd vote for either fixing the dummy name generation, or getting rid of it altogether and having everything have the same name.

Fixing it wouldn't be hard though.  You could just have a global counter, and increment it on every call.  If threading is an issue, you can either synchronize access to the counter, or have per-thread counters and append a thread id.

Best,
Martin

Roshan Dawrani wrote:

I think an alternate way of generating the dummy name may not be required.

I was just thinking of making sure that GroovyCodeSource instance has cachable attribute set to false when it comes via the route GCL#parseClass(String).

If we don't cache, we don't run into that issue even if multiple calls happen to come with the same generated name.

What do you think?

rgds,
Roshan

On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge <glaforge@... <mailto:glaforge@...>> wrote:

   On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani

   <roshandawrani@... <mailto:roshandawrani@...>> wrote:
    > [...]
    > If we remove the caching behavior for "parseClass(String text)",
   then that
    > will not happen.
    >
    > I want to raise a JIRA for it and fix that.
    >
    > Does anyone see any side-effects of that? Any reason that should
   not be
    > done?

   I can't think of a side-effect. It should be fixed if we can find a
   better dummy name generation.
   What kind of dummy name will you use to ensure we don't get the same
   twice in a row?
   Appending some hashCode for instance?


   --
   Guillaume Laforge
   Groovy Project Manager
   Head of Groovy Development at SpringSource
   http://www.springsource.com/g2one

   ---------------------------------------------------------------------
   To unsubscribe from this list, please visit:

      http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

Or currentMillis + AtomicInteger (incremented on each parseClass(String) call)? I'd go for this combination. Seems safe enough to not cause anymore collision within GCL.

On Mon, Nov 9, 2009 at 6:07 PM, Roshan Dawrani <roshandawrani@...> wrote:

If hashCode + currentMillis is also considered a combination that may fail rarely, then how about a global AtomicInteger (incremented on each parseClass(String) call) + Thread-Id combination?

On Mon, Nov 9, 2009 at 5:25 PM, Martin C. Martin <martin@...> wrote:

Well, a property that holds most of the time, but fails rarely, is worse than something that never holds.  People may be tricked into thinking the names are unique, then run into exactly the same problem you had.

So I'd vote for either fixing the dummy name generation, or getting rid of it altogether and having everything have the same name.

Fixing it wouldn't be hard though.  You could just have a global counter, and increment it on every call.  If threading is an issue, you can either synchronize access to the counter, or have per-thread counters and append a thread id.

Best,
Martin

Roshan Dawrani wrote:

I think an alternate way of generating the dummy name may not be required.

I was just thinking of making sure that GroovyCodeSource instance has cachable attribute set to false when it comes via the route GCL#parseClass(String).

If we don't cache, we don't run into that issue even if multiple calls happen to come with the same generated name.

What do you think?

rgds,
Roshan

On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge <glaforge@... <mailto:glaforge@...>> wrote:

   On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani

   <roshandawrani@... <mailto:roshandawrani@...>> wrote:
    > [...]
    > If we remove the caching behavior for "parseClass(String text)",
   then that
    > will not happen.
    >
    > I want to raise a JIRA for it and fix that.
    >
    > Does anyone see any side-effects of that? Any reason that should
   not be
    > done?

   I can't think of a side-effect. It should be fixed if we can find a
   better dummy name generation.
   What kind of dummy name will you use to ensure we don't get the same
   twice in a row?
   Appending some hashCode for instance?


   --
   Guillaume Laforge
   Groovy Project Manager
   Head of Groovy Development at SpringSource
   http://www.springsource.com/g2one

   ---------------------------------------------------------------------
   To unsubscribe from this list, please visit:

      http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

I don't have a strong opinion on either way.

With the first one, the collision would really be unlikely, or else it's really the same class/script being compiled twice :-)

For the latter, I think I wouldn't use an integer (even if atomic) as we could somehow get a reference to a script loaded from elsewhere that could possibly have the same integer? (and hence same generated name)?

On Mon, Nov 9, 2009 at 13:37, Roshan Dawrani <roshandawrani@...> wrote:

If hashCode + currentMillis is also considered a combination that may fail rarely, then how about a global AtomicInteger (incremented on each parseClass(String) call) + Thread-Id combination?

On Mon, Nov 9, 2009 at 5:25 PM, Martin C. Martin <martin@...> wrote:

Well, a property that holds most of the time, but fails rarely, is worse than something that never holds.  People may be tricked into thinking the names are unique, then run into exactly the same problem you had.

So I'd vote for either fixing the dummy name generation, or getting rid of it altogether and having everything have the same name.

Fixing it wouldn't be hard though.  You could just have a global counter, and increment it on every call.  If threading is an issue, you can either synchronize access to the counter, or have per-thread counters and append a thread id.

Best,
Martin

Roshan Dawrani wrote:

I think an alternate way of generating the dummy name may not be required.

I was just thinking of making sure that GroovyCodeSource instance has cachable attribute set to false when it comes via the route GCL#parseClass(String).

If we don't cache, we don't run into that issue even if multiple calls happen to come with the same generated name.

What do you think?

rgds,
Roshan

On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge <glaforge@... <mailto:glaforge@...>> wrote:

   On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani

   <roshandawrani@... <mailto:roshandawrani@...>> wrote:
    > [...]
    > If we remove the caching behavior for "parseClass(String text)",
   then that
    > will not happen.
    >
    > I want to raise a JIRA for it and fix that.
    >
    > Does anyone see any side-effects of that? Any reason that should
   not be
    > done?

   I can't think of a side-effect. It should be fixed if we can find a
   better dummy name generation.
   What kind of dummy name will you use to ensure we don't get the same
   twice in a row?
   Appending some hashCode for instance?


   --
   Guillaume Laforge
   Groovy Project Manager
   Head of Groovy Development at SpringSource
   http://www.springsource.com/g2one

   ---------------------------------------------------------------------
   To unsubscribe from this list, please visit:

      http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

[Martin C. Martin]

Sounds good to me!  Although to be clear, we need either an
AtomicInteger (so that ids are unique across threads), or using a
ThreadLocal<Integer> + thread-id.  I'm guessing the AtomicInteger is
much simpler, and that either way this won't be the performance bottleneck.

Best,
Martin

Roshan Dawrani wrote:

> If hashCode + currentMillis is also considered a combination that may
> fail rarely, then how about a global AtomicInteger (incremented on each
> parseClass(String) call) + Thread-Id combination?
>
>
> On Mon, Nov 9, 2009 at 5:25 PM, Martin C. Martin
> <martin@... <mailto:martin@...>> wrote:
>
>     Well, a property that holds most of the time, but fails rarely, is
>     worse than something that never holds.  People may be tricked into
>     thinking the names are unique, then run into exactly the same
>     problem you had.
>
>     So I'd vote for either fixing the dummy name generation, or getting
>     rid of it altogether and having everything have the same name.
>
>     Fixing it wouldn't be hard though.  You could just have a global
>     counter, and increment it on every call.  If threading is an issue,
>     you can either synchronize access to the counter, or have per-thread
>     counters and append a thread id.
>
>     Best,
>     Martin
>
>     Roshan Dawrani wrote:
>
>         I think an alternate way of generating the dummy name may not be
>         required.
>
>         I was just thinking of making sure that GroovyCodeSource
>         instance has cachable attribute set to false when it comes via
>         the route GCL#parseClass(String).
>
>         If we don't cache, we don't run into that issue even if multiple
>         calls happen to come with the same generated name.
>
>         What do you think?
>
>         rgds,
>         Roshan
>
>
>         On Mon, Nov 9, 2009 at 12:17 PM, Guillaume Laforge
>         <glaforge@... <mailto:glaforge@...>
>         <mailto:glaforge@... <mailto:glaforge@...>>>
>         wrote:
>
>            On Mon, Nov 9, 2009 at 07:38, Roshan Dawrani
>            <roshandawrani@...
>         <mailto:roshandawrani@...>
>         <mailto:roshandawrani@...
>         <mailto:roshandawrani@...>>> wrote:
>             > [...]
>             > If we remove the caching behavior for "parseClass(String
>         text)",
>            then that
>             > will not happen.
>             >
>             > I want to raise a JIRA for it and fix that.
>             >
>             > Does anyone see any side-effects of that? Any reason that
>         should
>            not be
>             > done?
>
>            I can't think of a side-effect. It should be fixed if we can
>         find a
>            better dummy name generation.
>            What kind of dummy name will you use to ensure we don't get
>         the same
>            twice in a row?
>            Appending some hashCode for instance?
>
>
>            --
>            Guillaume Laforge
>            Groovy Project Manager
>            Head of Groovy Development at SpringSource
>            http://www.springsource.com/g2one
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe from this list, please visit:
>
>               http://xircles.codehaus.org/manage_email
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email