Russel Winder wrote:
On Sat, 2009-07-11 at 08:03 -0400, Steve Appling wrote:
I think I may have gotten that with mismatched curly braces before. Why don't
you post your build.gradle (or at least the part that you changed to cause the
failure).
I don't think that is it in this case. The two bits of the Gradle file
that are the bits that depend on the variation are:
groovyHome = System.getenv ( ).'GROOVY_HOME'
if ( groovyHome ) {
groovyLib = new File ( groovyHome , 'lib' )
def groovyVersionPatternString = /^groovy-(all-)?([0-9].*)\.jar/
def items = groovyLib.listFiles ( [ accept : { File dir , String name
-> return ( name =~ groovyVersionPatternString ).find ( ) } ] as FilenameFilter
)
assert items
groovyVersion = ( items[0].name =~ groovyVersionPatternString )[0][2]
assert groovyVersion
}
else {
groovyVersion = ant.antProject.properties.groovyStandaloneVersion
}
. . .
repositories {
if ( groovyHome ) { flatDir ( name : 'groovyInstallation' , dirs : [
new File ( groovyHome , 'embeddable' ) , groovyLib ] ) }
mavenCentral ( )
}
If I unset GROOVY_HOME then it all compiles fine (it's the Gant build).
If I have GROOVY_HOME set then I get the error. So on the one hand the
problem cannot be in the code other than the above, and on the other
hand it shouldn't be in the code above either :-)
I think that perhaps when you have GROOVY_HOME set, it is not getting the groovy
jar correctly. I certainly don't have an answer for you, but I may have some
insights:
The GroovyCompile task uses AntGroovyC to do the compile with a different
classloadder. It does this by writing a small anonymous groovy script and
running it with another classloader. This is the "Script1.groovy" you are
seeing. I'm not sure exactly why you are getting this problem, but you can get
strange errors here if it can't find the ant or groovy jars in the groovy classpath.
Are you running with the version of gradle from the trunk? If so, there may be
some issue with some changes I made to track whether any files compiled or not.
It did introduce a parameter called "task" to the script used to do the compile.
If you run it with -d you should see a log message like: "Using groovyc as:" -
this will contain the content of the script that is executed. It would be
helpful to see that.
The total message without stack trace is:
Using Groovy version 1.7-beta-1-SNAPSHOT
:compile
:: problems summary ::
:::: ERRORS
unknown resolver Local
:: problems summary ::
:::: ERRORS
unknown resolver Local
Build failed with an exception.
Run with -s or -d option to get more details. Run with -f option to get
the full (very verbose) stacktrace.
Build file '/home/users/russel/Repositories/Bazaar/Masters/Gant/Trunk_Development/build.gradle'
Execution failed for task ':compile'.
Cause: startup failed:
Script1.groovy: 6: unexpected token: task @ line 6, column 104.
1 error
BUILD FAILED
Total time: 6.985 secs
I have no idea why I get "unknown resolver Local" I deleted that line
very early this morning. Hummm... hysteresis I wonder if there is some
not compiling of Gradle files going on. I tried "gradle -C rebuild
compile" but that didn't help.
I deleted the .gradle directory and the same thing results. I guess the
cache must be somewhere else. The resolver called Local is never used
in the Gradle file. I think the fact that it is remembered in this way
is clearly wrong. I guess I should submit a bug report -- the problem
is that I need to create a useful test first and this is not it :-(
I even tried deleting ~/.gradle/cache. That got rid of the "unknown
resolver Local" message -- so there is a bug somewhere in the updating
of metadata for Gradle files.
This is a very annoying bug in Ivy that Hans has already reported (but they
haven't fixed yet). If you resolve something using one resolver, Ivy caches the
name of that resolver and gives the annoying error message if you ever try to
resolve that same jar with another resolver. I am running into this all the
time. Please vote for it at http://issues.apache.org/jira/browse/IVY-758.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
