If it matters re: this e-mail... this was as of gradle 0.9 from 2009/11/26.
-Paul
Paul Speed wrote:
I found my issue (though I really think it used to be a more universal
issue)...
It stems from the different between subprojects{} and
subprojects.each{}. I have a few cases where I'm using
subprojects.each{} and in that case I have to use 'it' to refer to the
project in the closer.
The other case is something like [from Chapter 21]:
configure(subprojects.findAll {it.name != 'tropicalFish'}) {
hello << {println '- I love to spend time in the arctic waters.'}
}
If you define tasks within that then 'delegate' is the way to refer to
the subproject. 'project' refers to the last sub-project that was loaded.
One of my specific examples:
// Stuff added to just the root level projects
configure(subprojects.findAll { it.path.lastIndexOf(':') == 0 }) {
// Inject some standard tasks into each project
task 'setclasspath.cmd' << {
task -> // more descriptive than 'it'
// In here:
// 'task' is what one would expect because of the renaming
// above.
// 'task.project' is the subproject
// 'delegate' is the subproject
// 'project' is the last subproject loaded by the main build
[snip code generating a setclasspath.cmd file]
}
}
I don't know if there is a better way to do stuff like that or not.
-Paul
Paul Speed wrote:
Levi Hoogenberg wrote:
Something like
subprojects {
usePlugin 'groovy'
groovydoc {
println project.name <http://project.name>
}
}
I guess. (Which printed the project names that I expected, by the
way, so it could be a cache problem as you suspected.)
Good to know that this printed what was expected. I could have sworn
I had a problem with this before when defining tags for my subprojects
but maybe the issue was rectified at some point.
I will try to track down what my issue was and post back if it still
exists and there is some other thing contributing to the problem. I
may be able to simplify a bunch of builds in the process.
-Paul
On Fri, Dec 11, 2009 at 7:28 PM, Russel Winder
<[email protected] <mailto:[email protected]>>
wrote:
On Fri, 2009-12-11 at 11:47 -0500, Paul Speed wrote:
> Note: I don't know if this is changed recently but in the past,
inside a
> subprojects block 'project' will refer to only the last project
loaded.
> I use 'delegate' now instead... since that's supposed to be the
> sub-project within the subprojects closure.
My problem I guess is that I am still stuck a bit in Gradle 0.5 :-)
If users have to think in terms of delegate, I suspect the
abstractions
have broken -- this is a Groovy internal thing that should really be
exposed outside the Gradle internals.
My feeling is that project.name <http://project.name> is the right
handle for something in a
subproject or all specification. I guess the problem is that the
semantics of subproject is not quite what I think it is or the
groovydoc
specification withint he subproject specification is causing
weirdness.
> I don't know if it changes inside the groovydoc closure as this
is all
> still a little new to me.
>
> ...and maybe it doesn't apply here but you might dump a debug
print of
> project.name <http://project.name> just to double-check.
I suspect my problem is too few painkillers and/or lack of whisky
but I
am not sure what you are proposing by "dump a debug print".
--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp:
[email protected] <mailto:[email protected]>
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip:
sip:[email protected] <mailto:sip%[email protected]>
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
