On 30/03/10 6:13 PM, Geronimo M. H. wrote:
Hello,
both changes look really good, so I did some new investigations.
As the logs did not help me find my errors, I added some exceptions and
finally I found my error related to version numbering. The error was so ugly
that I wonder, how a jar with a timestamp could ever be created.
anyway ...
So I switched to the preview and found out, that my junit-test now fail. Looks
like as the junit-tests does not respect the dependencies.
Just to ensure, that I don't get trapped with my own errors, I switched back
to gradle-0.9-20100330050003+0200, where all junit test passed.
After switching back to the 0.9-preview, the test passed too!
Then I did a "gradle clean test" and all tests failed again.
If there is some configuration-changes, I have to do, I'd missed that.
It's really difficult to diagnose this problem without more information.
How did they fail? What error messages did you get? From where? Also,
stack traces are always valuable information.
Another point I realized, is that buildSrc now gets compiled at version
change, but stil does not get rid of source changes with changed sourceSet.
From release-notes/New and Noteworthy/Incremental builds I thought, dependency
checks would work now for any task.
Generally, yes, though there's still a few places where this is not
working yet (that's why we did a preview release, rather than a real
release). We will sort them out before the 0.9 release. One such place
is in the buildSrc project, where any source files outside the buildSrc
directory are being ignored. This doesn't happen with the real projects
of the build.
The JIRA issue is http://jira.codehaus.org/browse/GRADLE-881
Next point may be my misunderstanding - gradle clean stil works.
From the announcement I thought, it has been renamed to delete?
The class name was changed from Clean to Delete. The Delete instance
added by the java plugin still has the name 'clean'. So the command-line
interface hasn't changed.
The last point is just an issue in the context "gradle does not lock you in":
I'd like to have the testreports at rootProject-level with subdirectories for
each project, so I tried:
testReportDirName = new File(rootProject.projectDir.absolutePath
+ "/reports/", project.name)
but gradle did not respect the absolute path.
Then I read in the userguide, that the testReportDir is relative to the
reportdir, which is relative to the builddir.
Well, from my point of view this is kind of "locked in".
You want testReportDir = new File(...)
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
