On 16/11/2010, at 7:04 AM, jones jones wrote:
> Hello,
> New to Gradle, so please forgive the dumb questions. I've almost got my
> project set up.
> But I'm getting hung up on couple small things..
>
> 1.
> I'm using the eclipseClasspath task. I have some property files that need to
> be included in the classpath. I can't figure out how to add an arbitrary
> fold into my dependencies. When I set it up in Eclipse, the .classpath entry
> looks like this...
> <classpathentry kind="lib" path="lib/resources"/>
> Any ideas on what's the proper entry in my .gradle file to achieve this
> output in my .classpath file?
If you want the directory to be treated as a source directory, you can add it
as a resource directory. For example:
sourceSets.main.resources.srcDir 'lib'
This will also take care of other things such copying the contents of this
directory into the classes dir when running the tests, and including the
contents in the jar.
If you want the directory to be treated as an external dependency, you can add
it as a dependency. For example:
dependencies {
runtime files('lib')
}
Either of these approaches will end up with the directory added to the eclipse
classpath.
>
> 2.
> I'm creating a fat jar with this following task.
> jar {
> from configurations.compile.collect { it.isDirectory() ? it : zipTree(it)
> }
> }
> This works, except I have one oddity that it doesn't consider. I have a lib
> directory with a DLL (one of my jar's uses JNI) file that needs to be in the
> jar. I tried adding a fileset(dir:"lib") to the jar task, but it bombs on
> that. What's the proper way to put the dll into a specific directory in the
> output jar? If I include the DLL file in my dependencies, then it also
> includes it in the output .classpath file, then Eclipse complains about
> having a DLL in there. Any ideas?
You might use one of the approaches above.
>
> 3.
> How do you tell Gradle to clean the .classpath file every time you run
> eclipseClasspath? I tried eclipseClasspath(dependsOn:
> cleanEclipseClasspath), but it didn't like that.
There's 2 ways you can configure an existing task.
1. Call methods or access properties on it directly:
eclipseClasspath.dependsOn(cleanEclipseClasspath)
2. Use a configuration closure. Each method call and property reference in the
closure delegates to the task being configured:
eclipseClasspath {
dependsOn(cleanEclipseClasspath)
}
What you can't do is to use a map like you can when you add a new task. So you
can do
task myNewTask(dependsOn: someDep)
but you can't do
eclipseClasspath(dependsOn: cleanEclipseClasspath)
There's no real reason why not, other than we just haven't gotten around to it
yet. It will happen eventually.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
