These are chat archives for jruby-gradle/jruby-gradle-plugin

1st
Jul 2015
R. Tyler Croy
@rtyler
Jul 01 2015 11:36
@ysb33r if you're around, could I get your advice?
Schalk W. Cronjé
@ysb33r
Jul 01 2015 12:30
Can try. Sitting in the pub.
R. Tyler Croy
@rtyler
Jul 01 2015 12:43
hah
@ysb33r I'm assuming that rootProject != project inside of a sub-project's build.gradle, and planning to use that to have some properties cascade for my plugin
i.e. if rootProject.service.foo exists, then project.service.foo will be the value of rootProject's unless otherwise overwritten
off my rocker or does that seem reasonable?
unrelated, task foo(type: Jar), I'm wondering if it's possible for a plugin to inject a symbol into the root namespace the same way Jar is injected
Schalk W. Cronjé
@ysb33r
Jul 01 2015 13:33
IN all normal cases rootProject is always the top build file (the one where settings.grade resides).
rtyler @rtyler nods
Schalk W. Cronjé
@ysb33r
Jul 01 2015 13:33
so you assertion should work
not sure what you mean by the 2nd question though
(and I’m back from the pub - signal was a bit weak there anyway).
R. Tyler Croy
@rtyler
Jul 01 2015 13:36
I think I might have an answer to my second question
I'm thinking about the scope inside of a DSL closure block (i.e. extension) and how to provide clean looking APIs
instead of requiring a user to import something like foo.bar.CONSTANT, scoping CONSTANT inside the closure
Schalk W. Cronjé
@ysb33r
Jul 01 2015 13:38
you can inect those constants into ext
or as final properties on the delegate of the closure (or owner)
rtyler @rtyler nods
Schalk W. Cronjé
@ysb33r
Jul 01 2015 13:53
btw @rtyler do you know where you are stayign in Berlin?
R. Tyler Croy
@rtyler
Jul 01 2015 13:55
prior to, lookout folks will likely be staying in Kreuzberg
for the conference I will be staying wherever the conference organizers put me
Christian Meier
@mkristian
Jul 01 2015 20:13
@rtyler #134 again with more tests
R. Tyler Croy
@rtyler
Jul 01 2015 20:14
woohoo