On Wed, Mar 31, 2010 at 10:22 AM, Geronimo M. H. <[email protected]>wrote:
> Hello,
>
> I got a bit further with my investigations and it looks like most errors, I
> reported, where related to gradles internal caching.
>
> The error about failing junit-tests was related to older jarfiles from my
> projects, that have been cached and probabely misused.
> With today tests, I removed all .gradle directories from the projects,
> removed
> all project-jars from local repository and removed anything related to my
> projects from ~/.gradle/cache (rm -rf ~/gradle/cache/{*de.schwarzrot*,
> *unspecified*} ).
>
> Then the build works, but whenever I forgot to remove all cached stuff,
> strange things happened. I have no idea, which of the removal is really
> necessary, so I do all. So - I beg your pardon - but I'm not convinced yet,
> that incremental gradle builds are reliable.
They will become very reliable. We don't see a conceptual reasons why they
shouldn't. And this is crucial for their adoption. But as this is a complex
domain, we expect issues particularly at the beginning.
So reproducible failing test cases are the killer app for making our
incremental build more reliable. But I see that they are also sometimes hard
to create.
I understand your confusion about the different locations of cached stuff.
You can always run Gradle with -C rebuild to start with a clean cache.
> But I admit, that it's hard to
> get rid of without making errors.
>
> After all I think, gradle is a good base, I can live with, so there's no
> need
> to think about the way back ;)
>
Excellent :)
> Just have to learn to deal with the pitfalls.
>
>
> How about your git repository? When will it reflect the preview sources?
> or is there another way to stay up-to-date with your ultimative changes?
>
There is a 0.9-preview-1 branch and tag. But we don't intend to use it. 0.9
will be released from master.
>
>
> I tried to update the dependency of groovy for buildSrc/build.gradle from
> 1.7.0 to 1.7.1 - but then I get:
> - unresolved dependency: org.fusesource.jansi#jansi;1.1: not found
>
> That must be a transient dependency of groovy or the like, I did not code
> that
> dependency.
>
It is. That means the groovy pom has changed. Are you retrieving from
mavenCentral? An alternative especially for the build sources it to do:
dependencies {
groovy localGroovy()
}
where the groovy shipped with Gradle is added.
>
>
> I got sometimes strange exceptions from my version class, which made me
> suspect, that gradle checks project dependencies from rootproject
> build.gradle on building its own classes from buildSrc. I'm sorry, but
> currently I can't reproduce it - so I don't have further informations.
>
We don't use project dependencies yet for the build sources. But we should.
In the future we will allow for normal project dependencies to be added to
the build script classpath. The buildsrc would be just a default project
dependency.
>
>
> Just to understand the buildscripts - what happens, when I have 2 sections
> of
> i.e. "allprojects" and additionally a section "subprojects" - when will the
> build.gradle of a subproject get evaluated?
>
By default the evaluation order of the .gradle scritps is from top to
bottom. So if you have:
root
-- sub
The allprojects and the subprojects closure of root will configure the
project instance of sub first as part of evaluating the root build script.
After the root build script is evaluated, The sub build script will be
evaluated against the project instance of sub. Often the sub build.gradle
expects some preconfiguration of root (e.g. applying the JavaPlugin). But
this is a question of your particular domain and the degree of coupling
between the projects.
The evaluation order is configurable but we haven't run into use cases where
the default is not what people want.
>
> The point is, I have a working-dir definition for the test task in a file,
> that will be imported in all build.gradle files. Now I'd like to overwrite
> that working directory for just one subproject.
>
That's easy.
>
> I tried to use "test.doLast",
That would be happening after the tests are executed, therefore to late.
> but I guess, that definition will be evaluated
> before the "normal" setting of the working directory, wich looks like:
>
> test {
> workingDir = ...
> }
>
> Is there a way to code the setting of the working directory (with multiple
> overriding) independant of the time of evaluation?
>
For your scenario I don't see the requirement for evaluation time
independence (for such scenarios our rules might be used). The following
should work, relying on the fact that root is applied before sub.
root:
subprojects {
apply plugin: 'java'
test {
workingDir = 'a'
}
}
specialSub:
test {
workingDir = 'b'
}
- Hans
--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
>
>
> kind regards
>
> Geronimo
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
