Exclude .txt files from plugin lib/ when setting commonClasspath #73

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants

Edited grails-core/src/main/groovy/org/codehaus/groovy/grails/compiler/GrailsProjectCompiler.groovy via GitHub

See http://grails.1312388.n4.nabble.com/Re-Code-Coverage-running-tests-leads-to-huge-stacktrace-tp3418003p3491065.html

Member

burtbeckwith commented Jun 20, 2011

This is a very specific fix - shouldn't it only include *.jar and *.zip instead?

Hi Burt,

Agree it is very specific, but I decided on a known exclusion to fix the issue rather than second guessing whether any plugins would be pulling in other resources (e.g. .properties) from the commonClasspath.

Cheers,

Robin

Member

pledbrook commented Jun 21, 2011

I agree with Burt on the basis that non-JAR dependencies should go into src/java or grails-app/conf. I'm not even sure about including zip files. 'lib' is really for JARs.

The zip file is a legacy from the olden days of Java (e.g. Oracle JDBC 2.0 driver & support classes used to be distributed as classes111.zip).

I'm happy with Burt's suggestion - but hadn't wanted to propose a breaking change (maybe save that for Grails 2.0?).

Contributor

marcpalmer commented Jun 29, 2011

It is perfectly valid to have any files in the java source tree - code loads this relative to the class using classLoader.getResource without / in the resource path. Example - weceem loads ZIPs this way. Other code can load properties files this way etc. I've seen this in plenty of Java projects over the years...

Member

pledbrook commented Jul 15, 2011

It's now Grails 2.0 :) So I suggest we go with including *.jar and *.zip. We should make a note in the breaking changes, but I seriously can't imagine anyone being affected adversely by this.

Member

lhotari commented Aug 8, 2014

Closing outdated pull requests.

lhotari closed this Aug 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment