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

28th
Jul 2015
R. Tyler Croy
@rtyler
Jul 28 2015 06:45
@ysb33r is it kosher to create multiple dependent tasks in the constructor of a task? i.e. when Foo is created, build a Bar task wihch Foo depends on?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 07:40
I've done that in Gnumake plugin
R. Tyler Croy
@rtyler
Jul 28 2015 09:37
@ysb33r does it make sense for a configure method to be called twice when you pass a config closure to a task?
project.task('foo') { some 'bar' }
the Task configure(Closure configClosure) on the foo task is gettin gcalled twice for some reason
I'm trying to chain my sub-task creation off of the configure of my parent task, that way the children can get the proper configurations
Schalk W. Cronjé
@ysb33r
Jul 28 2015 09:46
You can call configure as many times as you like prior to the end of the configuration phase
R. Tyler Croy
@rtyler
Jul 28 2015 09:46
is there an after configuration hook that would be a good time to add tasks? adding tasks in the project.afterEvaluate hooks seems wrong
i suppose I could just call configure on the subtasks every time that configure is called on the parent task?
feels janky
Schalk W. Cronjé
@ysb33r
Jul 28 2015 09:53
I'll have a look
Schalk W. Cronjé
@ysb33r
Jul 28 2015 10:04
you can still create tasks in afterEvaluate in you want
Some items can be configured, but everything else is read from the ‘parent task’ when exec was called.
It might not be quite applicable to your case, but then I am not sure what you are trying to do
R. Tyler Croy
@rtyler
Jul 28 2015 10:07
really I'm delegating configuration of options out to a subtask
parent.foo = 'bar'
the children also have .foo
which should == 'bar'
Schalk W. Cronjé
@ysb33r
Jul 28 2015 10:08
would you allow someone to change child.foo = ‘bar2’, ?
R. Tyler Croy
@rtyler
Jul 28 2015 10:08
no
Schalk W. Cronjé
@ysb33r
Jul 28 2015 10:08
does child know it’s parent?
R. Tyler Croy
@rtyler
Jul 28 2015 10:09
right now, no, it could
Schalk W. Cronjé
@ysb33r
Jul 28 2015 10:09
if so, you can simply do
def getFoo() { parent.foo }
R. Tyler Croy
@rtyler
Jul 28 2015 10:10
then those tasks won't have @Inputs though :/
which means if I change parent.foo then the subtask won't be told to execute again correct?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 10:11
You can still set @Input on the method
R. Tyler Croy
@rtyler
Jul 28 2015 10:11
on getFoo O_o?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 10:11
aye
R. Tyler Croy
@rtyler
Jul 28 2015 10:11
interesting!
that sounds like a better approach
that is how the tracker tasks in gnumake are created
R. Tyler Croy
@rtyler
Jul 28 2015 10:12
will change my code after food!
R. Tyler Croy
@rtyler
Jul 28 2015 11:42
@ysb33r here's a random question about gradle, can I override dependency versions on the command line in any way?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 13:02
No. you need to code it in your script via system props or project props
R. Tyler Croy
@rtyler
Jul 28 2015 13:03
that would be a very useful plugin to build....
maybe after i fix the storm one :)
R. Tyler Croy
@rtyler
Jul 28 2015 13:23
@ysb33r this super.super call doesn't work in "normal usage" so it must be very execution path specific
or maybe my tests aren't actually invoking this code path, ruh roh
Schalk W. Cronjé
@ysb33r
Jul 28 2015 13:24
I think we need to look at some other way. I have given some thoughts to this.
Possible solution #1. NewTaskType extends JRubyExec.
JRubyExec has protected method getBootstrapName() which return ‘org.ruby.Main’.
NewTaskTYpe overrides this.
JRubyExec’s setMain method uses getBootstrapName( )
Possible solution #2.
Create abstract class JRubyExecAbstractTask extends DefaultTask.
JRubyExec extends JRubyExecAbstractTask implements JRubyExecTraits
NewTaskType extends JRubyExecAsbtractTask
Pull all common functionality into JRubyExecAbstractTask
R. Tyler Croy
@rtyler
Jul 28 2015 13:31
refactoring JRubyExec.exec() to call a prepare() method which does the majority of this junk, and then invokes super.exec() would laso wokr
the problem is that all tihs setup happens in exec
R. Tyler Croy
@rtyler
Jul 28 2015 13:51
@ysb33r do you have a preferred solution? I can eithe rduplicate a lot of this into my JRubyStormLocal task which is currently a JavaExec subclass, or I can implement a solution above
eithe rway, I gotta move forward :P
so we have another exapmle use-case here
@ysb33r I think this points to your 2nd suggestion
Schalk W. Cronjé
@ysb33r
Jul 28 2015 14:30
If you can get somehting going, we could work on it on Thursday
R. Tyler Croy
@rtyler
Jul 28 2015 14:31
heh, I'm thinking of putting something out today
Schalk W. Cronjé
@ysb33r
Jul 28 2015 14:31
I don’t have anytime until I fly
R. Tyler Croy
@rtyler
Jul 28 2015 14:31
this blocks like all my work :P
Schalk W. Cronjé
@ysb33r
Jul 28 2015 14:31
Get something out
R. Tyler Croy
@rtyler
Jul 28 2015 14:31
well not blocks, but I can't make the storm plugin not shitty :P
Schalk W. Cronjé
@ysb33r
Jul 28 2015 14:31
we can always refine it on Thursday
R. Tyler Croy
@rtyler
Jul 28 2015 14:31
I'll document the JRubyAbstractTask as a somewhat internal API for now
rtyler @rtyler doesn't think it belongs in an internal package though
Schalk W. Cronjé
@ysb33r
Jul 28 2015 14:32
The use of AbstractTYask is not uncommon in Gradle - there are a number of instances in the API
rtyler @rtyler nods
R. Tyler Croy
@rtyler
Jul 28 2015 14:35
@ysb33r JRubyExecAbstractTask should extend JavaExec not DefaultTask though right?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 15:05
indeed
R. Tyler Croy
@rtyler
Jul 28 2015 15:11
I'm thinking the abstract task should manage the: dependency setup, gem setup but the actual constructing of the command should be up to the subclasses
R. Tyler Croy
@rtyler
Jul 28 2015 15:48
@ysb33r there's a lot of stuff that is in traits that would need to move into the abstract task (like the gem dir stuff)
I'm still not entirely clear on what the point of keeping JRubyExecTraits around is
other than "neat, groovy traits"
Schalk W. Cronjé
@ysb33r
Jul 28 2015 15:48
possibly. Just remember that project.jrubyexec is not allowed to break
R. Tyler Croy
@rtyler
Jul 28 2015 15:48
hopefully there are tests ;)_
Schalk W. Cronjé
@ysb33r
Jul 28 2015 15:49

I'm still not entirely clear on what the point of keeping JRubyExecTraits around is

For project.jrubyexec

R. Tyler Croy
@rtyler
Jul 28 2015 15:50
hm
the reason to have them the same is to share the patterns for configuration right?
or rather, the reason for the traits?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 15:51
It might be possible to make abstract task implement the traits instead
R. Tyler Croy
@rtyler
Jul 28 2015 15:52
there's a lot there that doesn't apply to the abstract task though
like the script and script args stuff
Schalk W. Cronjé
@ysb33r
Jul 28 2015 15:52
it is just there to share code between JRubyExec and project.jrubyexec
rtyler @rtyler nmods
R. Tyler Croy
@rtyler
Jul 28 2015 15:52
I think this will be workable, I'm not confident in our test coverage on project.jrubyexec
it's certainly not used in anything I've ever written
there's some underscore quasi-internal methods being used, garggggh
Schalk W. Cronjé
@ysb33r
Jul 28 2015 15:53
…because I had to shoehorn in a workaround for Gradle
R. Tyler Croy
@rtyler
Jul 28 2015 15:54
if we're going to drag around some of these API compatibility burdens we might as well call this 1.0
I mean, if we're holding ourselves to API stability, then fuck it let's call it 1.0
Schalk W. Cronjé
@ysb33r
Jul 28 2015 15:56
Nah,
I don;’t think anyone except ourselves are programmatically coupling to jruby-gradle JARs other than via build scripts
so let’s go to a 1.0 when we are ready to go to jruby9k
Then I’ll be caring about API stability
I assume even you Lookout guys are only using the plugins in build scripts
R. Tyler Croy
@rtyler
Jul 28 2015 16:01
as opposed to?
also, we can go 9k now as far as I care, why don't I announce 1.0 in my talk? :)
you mean binding to the APIs in other plugins that aren't our own jruby-gradle plugins?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 16:12
yip
R. Tyler Croy
@rtyler
Jul 28 2015 16:13
I'm using it for a Lookout plugin, but other than that, build scripts all the way
even then though, not futzing with jruby-exec internals
@ysb33r if I create a pull request today, do you think you'll be able to look at it soon?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 16:16

why don't I announce 1.0 in my talk

Haha, do the geeky thing and release it on stage

will you look at that list and maybe add other tihngs that absolutely must happen for one-oh
I can work almost full time on it this week, so long as I get my storm work done
Schalk W. Cronjé
@ysb33r
Jul 28 2015 16:18
OK
I can look tomorrow during the day - very busy tonight
what about getting jar & wat to 1.0?
R. Tyler Croy
@rtyler
Jul 28 2015 16:19
  • What went wrong:
    Execution failed for task ':jruby-gradle-base-plugin:compileGroovy'.
    BUG! exception in phase 'class generation' in source unit '/home/tyler/source/github/jruby-gradle/jruby-gradle-plugin/jruby-gradle-base-plugin/src/main/groovy/com/github/jrubygradle/JRubyExec.groovy' Trying to access private constant field [com.github.jrubygradle.JRubyExecAbstractTask#JRUBYEXEC_CONFIG] from inner class
fak
the three plugins go together IMHO
but I think I'll annotate war as a "-beta"
since it's fucking broken :P
Schalk W. Cronjé
@ysb33r
Jul 28 2015 16:20
Bad compile error...
R. Tyler Croy
@rtyler
Jul 28 2015 16:34
@ysb33r I'm removing JRubyExec.jrubyConfigurationName
it's duplicattive with JRubyExec.configuration as far as I'm concerned
Schalk W. Cronjé
@ysb33r
Jul 28 2015 16:50
IIRC jrubyConfigurationName might have referred to the configuration where to find ruby-complete, where as configuration was where to find gems.
R. Tyler Croy
@rtyler
Jul 28 2015 16:51
it makes no sense to me to put those into two separate configuration buckets
since we're adding jruby0complete with the exec version already
(inside of JRubyExec.updateJRubyDependencies)
R. Tyler Croy
@rtyler
Jul 28 2015 16:56
I think I'm going to remove this jrubyExec$$taskname stuff too
<_<
rtyler @rtyler isn't sure that's useful
R. Tyler Croy
@rtyler
Jul 28 2015 17:51
@ysb33r when do you arrive?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 18:27
Should be in the city around noon
R. Tyler Croy
@rtyler
Jul 28 2015 19:15
@ysb33r thursday yes?
Schalk W. Cronjé
@ysb33r
Jul 28 2015 19:44
Indeed
Ja wohl!
R. Tyler Croy
@rtyler
Jul 28 2015 19:54
i'll email you my number, my wife gets in that day
not sure what my schedule will be
Schalk W. Cronjé
@ysb33r
Jul 28 2015 20:09
Oh nice
R. Tyler Croy
@rtyler
Jul 28 2015 20:11
growl, integ tests are busted now
i'll have to finish this up in the morning