On Thu, 2009-03-26 at 12:36 -0700, Matthew Fudge wrote:
> The way I have done this is
> addFlatDirResolver('serverlib').addArtifactPattern(new
> File('libs/[artifact].[ext]')
>
> compile 'org.apache:apache-commons:unknown'
I am wondering if I am addressing the wrong hurt here. I am wondering
if I am just missing something about using the Groovy plugin. Certainly
it seems that the trick of using:
groovyJarList = groovyLib.listFiles ( [ accept : { File dir , String
name -> ( name =~ '.jar$' ).find ( ) } ] as FilenameFilter ) as List
compile.unmanagedClasspath = groovyJarList
Solves the problem of having to know the version numbers when it comes
to the compilation of the Groovy code of the project -- though what I
loose by using this technique I have no idea.
My real problem is:
dependencies.groovy
I am not sure what this is doing or why I have to specify it. Gradle
comes with its own Groovy and so there is no need to specify the version
of Groovy to use for actual Gradle execution. Yet if I don't specify
something here everything falls apart.
(I get the error:
Cause: Forked groovyc returned error code: 1
if I don't explicitly specify a Groovy.)
I think the solution to my problem is that I should be able to specify a
Groovy installation directory here are Gradle does the right thing. So
I tried:
dependencies {
. . .
groovy ( groovyLib )
}
and got the error:
Cause: The dependency notation: /Users/russel/lib/Java/groovy/lib is
invalid!
So clearly there is no overload of organizing this property that uses
Files -- which is irritating.
I guess I should write a JIRA for an enhancement.
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip:
sip:[email protected]
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: [email protected]
signature.asc
Description: This is a digitally signed message part
