On Tuesday 23 March 2010 06:34:36, Adam Murdoch wrote:
> On 21/03/10 2:02 AM, Geronimo M. H. wrote:
> > version. So I tried to set the version at the jar-task via configure
> > method, but then the library is not found at dependency resolution.
>
> What error message are you seeing? any stack traces?
no gradle errors, only compile errors about imports that could not be resolved
and unknown classes (normal messages if a library is missing in the
classpath)
> > 2. groovy-methods
> > I created some simple functions like:
> > def myLibraries() {
> > subprojects.findAll { it.name.endsWith('Lib') }
> > }
> > to classify my subprojects. That works fine so far, but I can't place
> > that functions in a file, that gets used by various toplevel projects. Do
> > I need a special variant of the "apply" to get the functions imported, or
> > what can I do to get them known?
> > I searched the groovy-userguide and wiki for that, but it looks like I
> > don't know the right search-token...
>
> Only methods in the project's build script are visible to other build
> scripts. Methods in applied build scripts are not visible. Perhaps we
> might change things so that they are, at some point.
>
> There's 2 ways you can add a method to the project, which other build
> scripts can use:
>
> 1. Using a closure property
>
> myLibraries = { subprojects.findAll { ... } }
>
> 2. Using a convention object (this is what the Java plugin, for example,
> does)
>
> class UtilMethods {
> def project
> def myLibraries() { project.subprojects.findAll { ... } }
> }
>
> convention.plugins.myMethods = new UtilMethods(project: project)
Yes! I like the idea of the convention object.
I was already at the point to add my own java/groovy stuff to gradle build
process, but was not sure, whether to write a plugin or a convention ...
The convention object sounds quite appropriate - as I can add the sourceSet
changes to it too.
The point, where I'm unsure is the location of that code.
I read about the "buildSrc" directory, which should/must reside at root
project level. Is there a way to overwrite/customize that directory from
build.gradle or the like?
... or does gradle provide a systemwide location for build-sources too?
(If not, it might be a sexy improvement - i.e. perl knows about /etc/perl on
linux systems)
The point is, that I want to use my convention class from several
root-projects so I'd like to use a location outside any project-tree.
> > 3. unknown error from my mixed multiproject-build:
> > * Exception is:
> > org.gradle.api.LocationAwareGradleScriptException: Build
> > file '.../build.gradle' line: 5
>
> Could you paste in the build.gradle file around this line?
Phuh! Sorry - I can't.
My build-system already consists of more than 40 gradle files and when I'm
stuck, I change things until I'm free again.
It was from the steps, where I tried to solve a mixed multiproject and I had a
dependency section in the top-level build.gradle ...
I didn't succeed with that, so I moved the root sources to a subproject and
I'm now working on changing the jar-task to get the installers done.
My currently open issues related to gradle are:
- create an offline build-mode (without any usage of the internet)
- watch the internal jar-cache updates respect to real project changes
- add my convention object to all builds
- make the javadoc working
- understand more of gradle and find out how to find informations about my
questions
kind regards
Geronimo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
