headers
Stefan Glase | 30 Mar 14:26
Gravatar

[Code Coverage] running tests leads to huge stacktrace

Hello everyone,

we are using version 1.2 of the Code Coverage (http://grails.org/plugin/code-coverage) Grails Plugin with our latest Grails 1.3.6 application. 

When running tests with the command "grails test-app -war -coverage -xml" it produces a huge stacktrace:

[snip]
java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:131) at org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1028) at org.apache.tools.ant.AntClassLoader$ResourceEnumeration.findNextResource(AntClassLoader.java:147) at org.apache.tools.ant.AntClassLoader$ResourceEnumeration.<init>(AntClassLoader.java:109) at org.apache.tools.ant.AntClassLoader.findResources(AntClassLoader.java:975) at java.lang.ClassLoader.getResources(ClassLoader.java:1041) at org.apache.tools.ant.taskdefs.Definer.resourceToURLs(Definer.java:364) at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:256) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor195.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at groovy.util.AntBuilder.performTask(AntBuilder.java:250) at groovy.util.AntBuilder.nodeCompleted(AntBuilder.java:212) at groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:147) at groovy.util.AntBuilder.doInvokeMethod(AntBuilder.java:166) at groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:64) at org.codehaus.gant.GantBuilder.invokeMethod(GantBuilder.java:93) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:45) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) at _Events.defineCoberturaPathAndTasks(_Events.groovy:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1058) at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1070) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)[snip]

I was able to trace down the Exception with the help of the stacktrace to the following lines in _Events.groovy inside the code-coverage-1.2/scripts directory.

def defineCoberturaPathAndTasks() {
    ant.taskdef(classpathRef: "grails.test.classpath", resource: "tasks.properties")
}

Any suggestions what I am missing or doing wrong? What can I do to get rid of this Exception that also leads to incorrect coverage data on Jenkins?

Stefan
Permalink | Reply |
headers
rbramley | 30 Mar 14:50
Gravatar

Re: [Code Coverage] running tests leads to huge stacktrace

Hi Stefan,

Any reason for the -war argument? 

This post covers testing & test coverage with Grails on Hudson (pre-dates
the Jenkins fork):
http://leanjavaengineering.wordpress.com/2010/09/09/grails-testing-in-hudson/

Regards,

Robin

--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3417981.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Lucas F. A. Teixeira | 30 Mar 15:40
Picon
Gravatar

Re: Re: [Code Coverage] running tests leads to huge stacktrace

I'm facing the same problem using just


grails test-app -coverage

Will blow the exception for me, but is not a big problem, as the report is generated normally.

[]s,


Lucas Frare Teixeira .·.
- lucastex <at> gmail.com
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Wed, Mar 30, 2011 at 9:50 AM, rbramley <robin <at> rbramley.com> wrote:
Hi Stefan,

Any reason for the -war argument?

This post covers testing & test coverage with Grails on Hudson (pre-dates
the Jenkins fork):
http://leanjavaengineering.wordpress.com/2010/09/09/grails-testing-in-hudson/

Regards,

Robin


--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3417981.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
rbramley | 30 Mar 16:27
Gravatar

Re: [Code Coverage] running tests leads to huge stacktrace

Code coverage 1.2 is definitely working for me with Grails 1.3.5. 
Just tested again with "grails test-app -coverage -xml" against a test
application (available from https://github.com/rbramley/GroovyMag29). 

Will upgrade the Grails version when I get a chance later on to see what
happens...

--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3418227.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Lucas F. A. Teixeira | 30 Mar 16:43
Picon
Gravatar

Re: Re: [Code Coverage] running tests leads to huge stacktrace

I'm using 1.3.6...


This is the output I've got: https://gist.github.com/894526

[]s,


Lucas Frare Teixeira .·.
- lucastex <at> gmail.com
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Wed, Mar 30, 2011 at 11:27 AM, rbramley <robin <at> rbramley.com> wrote:
Code coverage 1.2 is definitely working for me with Grails 1.3.5.
Just tested again with "grails test-app -coverage -xml" against a test
application (available from https://github.com/rbramley/GroovyMag29).

Will upgrade the Grails version when I get a chance later on to see what
happens...


--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3418227.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email



Permalink | Reply |
headers
Lucas F. A. Teixeira | 30 Mar 16:56
Picon
Gravatar

Re: Re: [Code Coverage] running tests leads to huge stacktrace

Robin,


That output was when i just ran the code as you can see.
But then, the test runs normally, after that I get another exception, I think it is the same..


But as I said before, the test reports gets generated.

[]s,
 

Lucas Frare Teixeira .·.
- lucastex <at> gmail.com
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Wed, Mar 30, 2011 at 11:43 AM, Lucas F. A. Teixeira <lucastex <at> gmail.com> wrote:
I'm using 1.3.6...

This is the output I've got: https://gist.github.com/894526

[]s,


Lucas Frare Teixeira .·.
- lucastex <at> gmail.com
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Wed, Mar 30, 2011 at 11:27 AM, rbramley <robin <at> rbramley.com> wrote:
Code coverage 1.2 is definitely working for me with Grails 1.3.5.
Just tested again with "grails test-app -coverage -xml" against a test
application (available from https://github.com/rbramley/GroovyMag29).

Will upgrade the Grails version when I get a chance later on to see what
happens...


--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3418227.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email




Permalink | Reply |
headers
Antoine Roux | 31 Mar 11:22
Favicon

Re: Re: [Code Coverage] running tests leads to huge stacktrace

I usually have this kind of exception when one of the files (plugin or jar) is corrupted. Maybe you could try to remove the plugins and folders from your disk to let them be downloaded again, hoping they won't be corrupted?



On Wed, Mar 30, 2011 at 4:56 PM, Lucas F. A. Teixeira <lucastex <at> gmail.com> wrote:
Robin,

That output was when i just ran the code as you can see.
But then, the test runs normally, after that I get another exception, I think it is the same..


But as I said before, the test reports gets generated.

[]s,
 

Lucas Frare Teixeira .·.
- lucastex <at> gmail.com
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Wed, Mar 30, 2011 at 11:43 AM, Lucas F. A. Teixeira <lucastex <at> gmail.com> wrote:
I'm using 1.3.6...

This is the output I've got: https://gist.github.com/894526

[]s,


On Wed, Mar 30, 2011 at 11:27 AM, rbramley <robin <at> rbramley.com> wrote:
Code coverage 1.2 is definitely working for me with Grails 1.3.5.
Just tested again with "grails test-app -coverage -xml" against a test
application (available from https://github.com/rbramley/GroovyMag29).

Will upgrade the Grails version when I get a chance later on to see what
happens...


--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3418227.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email





Permalink | Reply |
headers
Lucas F. A. Teixeira | 31 Mar 15:12
Picon
Gravatar

Re: Re: [Code Coverage] running tests leads to huge stacktrace

Hi Antoine,


I bet this wouldn't be the problem, since I have my project in my notebook, work's desktop, home desktop and jenkins CI, all giving the same error.
Maybe a corrupted file in the plugin structure in the plugin repo, but this would trigger the exception to everyone... :(

[]s,

 
Lucas Frare Teixeira .·.
- lucastex <at> gmail.com
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Thu, Mar 31, 2011 at 6:22 AM, Antoine Roux <antoine.roux <at> net-vitesse.com> wrote:
I usually have this kind of exception when one of the files (plugin or jar) is corrupted. Maybe you could try to remove the plugins and folders from your disk to let them be downloaded again, hoping they won't be corrupted?




On Wed, Mar 30, 2011 at 4:56 PM, Lucas F. A. Teixeira <lucastex <at> gmail.com> wrote:
Robin,

That output was when i just ran the code as you can see.
But then, the test runs normally, after that I get another exception, I think it is the same..


But as I said before, the test reports gets generated.

[]s,
 
On Wed, Mar 30, 2011 at 11:43 AM, Lucas F. A. Teixeira <lucastex <at> gmail.com> wrote:
I'm using 1.3.6...

This is the output I've got: https://gist.github.com/894526

[]s,


On Wed, Mar 30, 2011 at 11:27 AM, rbramley <robin <at> rbramley.com> wrote:
Code coverage 1.2 is definitely working for me with Grails 1.3.5.
Just tested again with "grails test-app -coverage -xml" against a test
application (available from https://github.com/rbramley/GroovyMag29).

Will upgrade the Grails version when I get a chance later on to see what
happens...


--
View this message in context: http://grails.1312388.n4.nabble.com/Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3417930p3418227.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email






Permalink | Reply |
headers
Mike Joyce | 2 May 23:35
Picon

Re: [Code Coverage] running tests leads to huge stacktrace

After facing the same problem for weeks, I finally took time to investigate
it. It looks like some plugins (such as the export plugin) have non-jar
files in their lib dir. As the AntClassLoader is going through each of the
files in the classpath, the AntClassLoader.getResourceURL() method is called
for each of them, and if the resource is a valid file, it attempts to open
it as a ZipFile. When java.util.zip.ZipFile throws the exception because the
file is not a zip file, the stacktrace is printed to the screen, causing the
ugly stack we see in the console.

Because I don't have enough knowledge about the Ant classpath loading, my
solution was to simply remove the TXT license files which the export plugin
put into it's lib directory. I realize this is a hacky fix and the problem
will crop up again when we upgrade the plugin. But for now, it'll get rid of
the stack trace.

I hope this helps,

Mike Joyce

--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Andreas Schmitt | 3 May 17:53

Re: Re: [Code Coverage] running tests leads to huge stacktrace

Hi Mike,

thank you very much for posting this. In which context do you get this
error concerning the export plugin?
I would like to fix this issue, currently I'm thinking about where one
should put the license files that are related to those jars.
Ideally those files shouldn't be picked up, because they are nor jar files.

Best regards,
Andreas

2011/5/2 Mike Joyce <multimike <at> gmail.com>:
> After facing the same problem for weeks, I finally took time to investigate
> it. It looks like some plugins (such as the export plugin) have non-jar
> files in their lib dir. As the AntClassLoader is going through each of the
> files in the classpath, the AntClassLoader.getResourceURL() method is called
> for each of them, and if the resource is a valid file, it attempts to open
> it as a ZipFile. When java.util.zip.ZipFile throws the exception because the
> file is not a zip file, the stacktrace is printed to the screen, causing the
> ugly stack we see in the console.
>
> Because I don't have enough knowledge about the Ant classpath loading, my
> solution was to simply remove the TXT license files which the export plugin
> put into it's lib directory. I realize this is a hacky fix and the problem
> will crop up again when we upgrade the plugin. But for now, it'll get rid of
> the stack trace.
>
> I hope this helps,
>
> Mike Joyce
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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
Permalink | Reply |
headers
Konstantinos Kostarellis | 4 May 09:30
Picon
Gravatar

Re: Re: [Code Coverage] running tests leads to huge stacktrace

Hi Andreas,


when looking at grails plugins in general authors tend to use a LICENSE.txt file in the plugins main directory. Some of them simply list all licences of all plugin artefacts in there. 
So you could either extend your LICENSE.txt or put the others (itext, odf, jexcelapi, opencsv, xercesimpl) aside. Just a suggestion. << The bug affects me too.

As an alternative approach the code-coverage plugin could ignore those ;)

Cheers,
   Kosta

On Tue, May 3, 2011 at 5:53 PM, Andreas Schmitt <andreas.schmitt.mi <at> googlemail.com> wrote:
Hi Mike,

thank you very much for posting this. In which context do you get this
error concerning the export plugin?
I would like to fix this issue, currently I'm thinking about where one
should put the license files that are related to those jars.
Ideally those files shouldn't be picked up, because they are nor jar files.

Best regards,
Andreas

2011/5/2 Mike Joyce <multimike <at> gmail.com>:
> After facing the same problem for weeks, I finally took time to investigate
> it. It looks like some plugins (such as the export plugin) have non-jar
> files in their lib dir. As the AntClassLoader is going through each of the
> files in the classpath, the AntClassLoader.getResourceURL() method is called
> for each of them, and if the resource is a valid file, it attempts to open
> it as a ZipFile. When java.util.zip.ZipFile throws the exception because the
> file is not a zip file, the stacktrace is printed to the screen, causing the
> ugly stack we see in the console.
>
> Because I don't have enough knowledge about the Ant classpath loading, my
> solution was to simply remove the TXT license files which the export plugin
> put into it's lib directory. I realize this is a hacky fix and the problem
> will crop up again when we upgrade the plugin. But for now, it'll get rid of
> the stack trace.
>
> I hope this helps,
>
> Mike Joyce
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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



Permalink | Reply |
headers
Mike Joyce | 5 May 15:51
Picon

Re: [Code Coverage] running tests leads to huge stacktrace

My understanding is that the test classpath includes all of the plugin lib directories ($GRAILS_HOME/scripts/_GrailsClasspath.groovy; testClasspath() closure), and all of the files in it. When the code-coverage plugin initializes it's ant task, it needs to load the "tasks.properties" out of the cobertura jar file ($PROJECT/plugins/code-coverage-1.2.4/scripts/_Events.groovy; defineCoberturaPathAndTasks() ). The "java.util.zip.ZipException: error in opening zip file" stack trace is shown as Ant is looping through every file on the classpath and opening it to see if it contains the desired "tasks.properties". When it hits the license files that the export plugin has in the lib directory, we see the stack trace since they are not zip files (jars).

After digging looking through the AntClassLoader closer, it looks like they intended to call log() instead of e.printStackTrace() when this exception occurs. Infact, in v1.8.0 of ant, that catch block has already been fixed to use the proper log() instead of just e.printStackTrace()... so if ant v1.8.0 was being used, then we're be able to ignore the logs via log config.

Since I don't think ant 1.8.0 is planning to be brought into Grails, I think the best solution is to have the license files in the export plugin removed from the lib directory.

Mike

On Wed, May 4, 2011 at 2:31 AM, Konstantinos Kostarellis [via Grails] <[hidden email]> wrote:
Hi Andreas,

when looking at grails plugins in general authors tend to use a LICENSE.txt file in the plugins main directory. Some of them simply list all licences of all plugin artefacts in there. 
So you could either extend your LICENSE.txt or put the others (itext, odf, jexcelapi, opencsv, xercesimpl) aside. Just a suggestion. << The bug affects me too.

As an alternative approach the code-coverage plugin could ignore those ;)

Cheers,
   Kosta

On Tue, May 3, 2011 at 5:53 PM, Andreas Schmitt <[hidden email]> wrote:
Hi Mike,

thank you very much for posting this. In which context do you get this
error concerning the export plugin?
I would like to fix this issue, currently I'm thinking about where one
should put the license files that are related to those jars.
Ideally those files shouldn't be picked up, because they are nor jar files.

Best regards,
Andreas

2011/5/2 Mike Joyce <[hidden email]>:
> After facing the same problem for weeks, I finally took time to investigate
> it. It looks like some plugins (such as the export plugin) have non-jar
> files in their lib dir. As the AntClassLoader is going through each of the
> files in the classpath, the AntClassLoader.getResourceURL() method is called
> for each of them, and if the resource is a valid file, it attempts to open
> it as a ZipFile. When java.util.zip.ZipFile throws the exception because the
> file is not a zip file, the stacktrace is printed to the screen, causing the
> ugly stack we see in the console.
>
> Because I don't have enough knowledge about the Ant classpath loading, my
> solution was to simply remove the TXT license files which the export plugin
> put into it's lib directory. I realize this is a hacky fix and the problem
> will crop up again when we upgrade the plugin. But for now, it'll get rid of
> the stack trace.
>
> I hope this helps,
>
> Mike Joyce
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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





If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3494736.html
To unsubscribe from Re: [Code Coverage] running tests leads to huge stacktrace, click here.


View this message in context: Re: [Code Coverage] running tests leads to huge stacktrace
Sent from the Grails - user mailing list archive at Nabble.com.
Permalink | Reply |
headers
rbramley | 29 May 00:21
Gravatar

Re: [Code Coverage] running tests leads to huge stacktrace

A better fix would be for the classpath to ignore any text files in plugin
lib folders. Can be achieved with the following patch:

--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig	Wed Feb 16 07:14:06
2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy	Sat May 28 23:14:36 2011
@@ -119,7 +119,7 @@

     def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll {
it.exists() }
     for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
     }
 }

Robin

------
Twitter: @rbramley
Blog: http://leanjavaengineering.wordpress.com

--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3558137.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Ed Young | 31 May 22:11
Gravatar

Re: Re: [Code Coverage] running tests leads to huge stacktrace

This seems to solve the problem so thanks for the simple fix.

Anyone see any undesirable side effects to this?

On Sat, May 28, 2011 at 4:21 PM, rbramley <robin <at> rbramley.com> wrote:
A better fix would be for the classpath to ignore any text files in plugin
lib folders. Can be achieved with the following patch:


--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig   Wed Feb 16 07:14:06
2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy        Sat May 28 23:14:36 2011
<at> <at> -119,7 +119,7 <at> <at>

    def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll {
it.exists() }
    for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
    }
 }



Robin

------
Twitter: <at> rbramley
Blog: http://leanjavaengineering.wordpress.com


--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3558137.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email





--
- Ed
Permalink | Reply |
headers
Mike Joyce | 1 Jun 00:06
Picon

Re: [Code Coverage] running tests leads to huge stacktrace

That is perfect for me.

Mike

On Tue, May 31, 2011 at 3:12 PM, edward.young [via Grails] <[hidden email]> wrote:
This seems to solve the problem so thanks for the simple fix.

Anyone see any undesirable side effects to this?

On Sat, May 28, 2011 at 4:21 PM, rbramley <[hidden email]> wrote:
A better fix would be for the classpath to ignore any text files in plugin
lib folders. Can be achieved with the following patch:


--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig   Wed Feb 16 07:14:06
2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy        Sat May 28 23:14:36 2011
<at> <at> -119,7 +119,7 <at> <at>

    def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll {
it.exists() }
    for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
    }
 }



Robin

------
Twitter: <at> rbramley
Blog: http://leanjavaengineering.wordpress.com


--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3558137.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email





--
- Ed


If you reply to this email, your message will be added to the discussion below:
http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3564205.html
To unsubscribe from Re: [Code Coverage] running tests leads to huge stacktrace, click here.


View this message in context: Re: [Code Coverage] running tests leads to huge stacktrace
Sent from the Grails - user mailing list archive at Nabble.com.
Permalink | Reply |
headers
Konstantinos Kostarellis | 9 Nov 11:25
Picon
Gravatar

Re: Re: [Code Coverage] running tests leads to huge stacktrace

Nice tweak,

but you can still run into the problem with other non-"zip-py" files.
E.g. the tomcat .1.3.7.2 plugin comes with a "ivy-1.0.xml" file, which obviously
results in the same problem.


2011/5/29 rbramley <robin <at> rbramley.com>
A better fix would be for the classpath to ignore any text files in plugin
lib folders. Can be achieved with the following patch:


--- grails-1.3.7/scripts/_GrailsClasspath.groovy.orig   Wed Feb 16 07:14:06
2011
+++ grails-1.3.7/scripts/_GrailsClasspath.groovy        Sat May 28 23:14:36 2011
<at> <at> -119,7 +119,7 <at> <at>

    def pluginLibDirs = pluginSettings.pluginLibDirectories.findAll {
it.exists() }
    for (pluginLib in pluginLibDirs) {
-        fileset(dir: pluginLib.file.absolutePath)
+        fileset(dir: pluginLib.file.absolutePath, excludes:'**/*.txt')
    }
 }



Robin

------
Twitter: <at> rbramley
Blog: http://leanjavaengineering.wordpress.com


--
View this message in context: http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3558137.html
Sent from the Grails - user mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email



Permalink | Reply |

Gmane