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 ...
One library I was not able to bring into play, so I had to rename its
directory.
> > 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, 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.
So I had to cut off the Process part and use "cmd.execute()" only.
That works, but without any feedback.
2 of 3 projects are already converted to gradle and working.
The last is the most complex one and I got stuck.
My preferred layout is:
prj
subprj1
subprj2
src
res
test
with prj depending on subprj2.
When I use dependsOnChildren() the build-order is not ok and I get strange
errormessages from subprojects being built before their dependant parts.
I use 'allprojects' to include the extracted parts, but I found no way to
specify a section that is for the root-project only.
Specifying the dependencies at top-level in the buildscript did not work and
using "project(toplevel-name)" did not work either.
At the moment the only way, I see that could work is changing the
project-layout so that the toplevel project becomes a subproject too and than
changing its jar-task ...
May be, you have a better idea ...
I have not converted all tasks yet, but the converted stuff is cleaner now and
I already love gradle! Thanks a lot for your work!
kind regards
Geronimo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
