Hello Hans,
thank you for your attention and support!
On Wednesday 31 March 2010 10:51:24, Hans Dockter wrote:
> On Wed, Mar 31, 2010 at 10:22 AM, Geronimo M. H.
> 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.
I don't think, that the different locations are the source of my confusion.
What I did not expect - to me it looks like gradle caching works at
pull-triggers - and I expected (at least for local project artifacts) cache
updating at the push trigger.
That means, I'd like to update the internal cache whenever I build a local
artifact (no matter, whether the cache already contains the same version, as
I think, that a copy might be faster than a md5-checksum or the like).
Ideally there would be an option, that forces the new artifact replace all
former artifacts (especially those with a (different) timestamp in name). So
a local CI-server could "cleanup" the local repositories.
> 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.
One possibility is, create a jar-file without the "processResources"-task and
then use junit-tests, that indirectly rely on that resources - that was the
problem with my testcases and gradle cache contained the wrong jarfile not
the result from the last build. So I did the visual checks with the wrong
files.
I have no idea, how that jarfile without the resources was created, but it
happened ...
> > 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.
But the master does not contain the changes of the preview yet?
I did the last update the day after your announcement of the preview ...
> > 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.
Sorry, I'm not sure, whether I like that.
For me the buildSrc is an extension of gradle itself, so it should not fail on
errors I do in the projects buildscripts nor check for dependencies, that
don't come into play for the internal build (as I suspect to happen on my
today testing - but it could have been a cache inconsistency too - I don't
know).
So I think it's nice to have a "special" location to extend gradle and I would
vote for keeping the distinction of that directory. At least at userlevel.
> > 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'
> }
Thank you for the hint. Works fine!
kind regards
Geronimo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
