On 15/03/10 3:31 PM, Geronimo M. H. wrote:
Hello,
thank you very much for your attention!
What is going wrong with the above? What are you seeing that suggests
that its not working?
I got some strange error messages, which I did not know to solve.
Then I read some groovy tutorials and looked at the output of 'gradle -d' and
found out, that those error messages where the result of typos in the
dependencies.
I added properties to the subprojects and gradle claimed, that the properties
don't exists. With the output of 'gradle -d' I found a note telling something
like 'using empty build script' - and I had no empty build scripts - so I
found my mistakes.
...
repositories {
add(new org.apache.ivy.plugins.resolver.FileSystemResolver()) {
name = 'local'
addArtifactPattern(new File('common/3rdParty').getAbsolutePath() +
'/([organization]/)[module]/[artifact](-[revision])
(-[classified]).
[ext]')
}
}
Ok, I got a bit further with this too, but I did not find a way to specify a
module-name. I guess, the organisation is mapped to the group-id and artifact
is the name ...
You specify the name in the dependency:
dependencies {
compile group: 'group', name: 'module', version: 'version'
compile 'group:module:version' // the short form
}
We map group -> ivy organization, name -> ivy module, version -> ivy
revision
One library I was not able to bring into play, so I had to rename its
directory.
What was it's name? what sort of error message did you get?
Furthermore I'd like to extract my project-layout and the settings about
the shared lib-dir to a property-file, that is shared by all major
projects (several toplevel build.gradle). How can I to that?
I would use some of the features available in a recent Gradle 0.9
snapshot (we haven't released 0.9 yet, but we're gearing up to do so
soon). More specifically, I would extract this stuff into a separate
build script, which can then be applied from multiple builds.
Ok, I succeeded in part of that.
The support for external files is great!
I found a minor issue with dependencies:
When I use the project dependency pattern:
dependencies {
compile project(':other_subproject')
}
the build-graph does not get rid of that dependency, so I have to duplicate
the dependency that way:
dependsOn(':other_subproject')
dependendies {
compile project(':other_subproject')
}
I would appreciate, if gradle could use the 'compile project(...)' for
rearranging the buildgraph too,
It already does this. If you add a project dependency to the compile
configuration, for example, then the compileJava task will depend on the
jar task from the other project.
What did you see that made you think that the dependencies were not
being added?
as I think, the compile dependency does not
make much sense without the right build order.
I read about gradle support for logging external tools, but it did not work
for me. I use a perl-script during build and tried this:
cmd = file(rootProject.projectDir).absolutePath + '/../common/bin/mysript.pl'
+ ' --verbose' + ' --clean' ...
Process p = cmd.execute()
p.err.eachLine { line -> println line }
but with this, gradle hangs and never comes back from that loop.
You generally need to drain the child process' output stream, as well as
the error stream, to stop the child process from hanging. This is a
standard Java Process behaviour, and nothing really to do with Gradle.
You might have a look at http://groovy.codehaus.org/groovy-jdk/ to see
some of the extra methods which Groovy adds to Process to make it easier
to work with.
Alternatively, you could use the Ant exec task to run the child process.
It takes care of things like this for you.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
