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

12th
Aug 2015
Schalk W. Cronjé
@ysb33r
Aug 12 2015 07:27
There is potentially such a system, that we might just be able to utilise.
Schalk W. Cronjé
@ysb33r
Aug 12 2015 09:22
We can use this up to Gradle 2.4, whereafter it will still work, but emit a deprecation warning:
// Assuming the configuration is called jrubyexec
def jrubyconf = project.configurations.jrubyexec
jrubyconf.incoming.beforeResolve {
   def useMe = project.dependencies.create(“org.jruby:jruby-complete:”${project.jruby.jrubyVersion}”)
  jrubyconf.dependencies.add(useMe)
}
@rtyler Woudl you like to try the above to see wehther it works?
R. Tyler Croy
@rtyler
Aug 12 2015 14:19
@ysb33r what causes a dependencyset to be finalized/resolved anyways, perhaps the problem we need to address is what causes that before afterEvaluate is complete
R. Tyler Croy
@rtyler
Aug 12 2015 18:04
@ysb33r I have an integration test which reproduces the problem and I believe I've solved it
I think I found another issue with how jrubyJar is treating jruby.defaultVersion too
what a huge pain in the ass
Blane Dabney
@raelik
Aug 12 2015 18:05
Yeah, I had to explicitly set both defaultVersion and execVersion for both the tasks and the jar to end up using the same jRuby version
Dunno if that's what you're talking about though
R. Tyler Croy
@rtyler
Aug 12 2015 18:06
```gradlejruby.defaultVersion = '1.7.11'
jrubyJar { initScript 'main.rb' }
er
jruby.defaultVersion = '1.7.11'
jrubyJar { initScript 'main.rb' }
that results in the wrong version of JRuby executing inside the jar
because of when we add that dependency
Blane Dabney
@raelik
Aug 12 2015 18:07
oh gross
R. Tyler Croy
@rtyler
Aug 12 2015 18:08
heh
not quite the behavior that's expected
Christian Meier
@mkristian
Aug 12 2015 18:10
is jruby.defaultVersion for all jruby related tasks ?
R. Tyler Croy
@rtyler
Aug 12 2015 18:11
what do you mean?
the presumption with defaultVersion is that would be the default version used for packaging, etc
the way I've thought about it's function being: everything should use defaultVersion unless stated otherwise
if execVersion is defined, all JRubyExec tasks should use that unless stated otherwise
I think the solution to my problem here is to make it such that setting defaultVersion and execVersion can call some callbacks when they're set
so things like JRubyJar can register a callback for when that's changed
Christian Meier
@mkristian
Aug 12 2015 18:19
so basically you are saying the problem is the order of when things get evaluated and/or declared. I would just make a new configuration just before I need jruby-complete with whatever version, resolve it on at this time and then use the jar from this resolution.
R. Tyler Croy
@rtyler
Aug 12 2015 18:23
there already is a separate configuration, the problem is that, right now, there's an afterEvaluate hook which ensures that the dependencies are present
but what's happening is that the configuration is being resolved too early
which results in the error from #183
R. Tyler Croy
@rtyler
Aug 12 2015 18:28
so like I mention in the ticket, with a callback system, then when defaultVersion changes the JRubyJar task will know it should at least consider changing the version in its jrubyJar configuration as well
Christian Meier
@mkristian
Aug 12 2015 19:30
in think one thing changed over time. in the beginning the jruby-complete and all the jars for the ruby app needed to be in one configuration. now jruby-complete has nothing to do the jars for the ruby application. all we need is piece of code: giveMeTheJarFileLocationFor(jrubyVersion) at least when we execute jruby. the jrubyJar might be a little different since it needs jruby-mains as well.
R. Tyler Croy
@rtyler
Aug 12 2015 19:42
@mkristian that's not entirely true, the jruby-complete stuff is still in the configuration, it's just put there by the plugin instead of explicitly by the user
Christian Meier
@mkristian
Aug 12 2015 19:49
yes, for exec and for the jar building I need to filter this jruby-complete.jar since it has a different purpose then all the other jars. the configuration is used for two purposes. whenever you use this configuration you have to separate the two purposes manually.
R. Tyler Croy
@rtyler
Aug 12 2015 19:50
only in the case of packing a jar is the special casing on jruby-complete necessary though
Christian Meier
@mkristian
Aug 12 2015 19:52
also on the exec. all jars will be loaded by jruby via jars/setup. one hte complete-jar needs to be found to retrieve the file on hte filesystem for the "classpath"
R. Tyler Croy
@rtyler
Aug 12 2015 19:52
I'm still not sure what you're getting at here
Christian Meier
@mkristian
Aug 12 2015 19:56
I think I would remove jruby-complete from the configuration and when ever I need the file location from it I would create a detach configuration and add jjruby-complete dependency and resolve it, i.e. giveMeTheJarFileLocationFor(jrubyVersion)
R. Tyler Croy
@rtyler
Aug 12 2015 19:57
detached configuration? I'm not sure that is a thing that exists
the problem is not just jruby-complete though, for pre JRuby 1.7.20 we need to add a new jar-dependencies to the resolution graph
Christian Meier
@mkristian
Aug 12 2015 19:59
I think I used it on my first draft of the rspec plugin I did what I tried to explain to you.
R. Tyler Croy
@rtyler
Aug 12 2015 20:04
@mkristian this approach is more or less the same of what we have in the JRubyJar task, but the problem is that afterEvaluate hooks aren't guaranteed to be ordered
so for #183 some other afterEvaluate hook is causing hte configuration's dependencies to be resolved
then we try to add deps to it
Christian Meier
@mkristian
Aug 12 2015 20:05
which fails then
R. Tyler Croy
@rtyler
Aug 12 2015 20:06
right
is what I have in mind. just do not add it to a maybe resolved configuration, just create a new one and resolve it. but anyways, maybe these callbacks are easier to implement.
R. Tyler Croy
@rtyler
Aug 12 2015 20:13
I think what you're suggesting would make sense just in the JRubyJar case but if we want to preserve the user expectation that jruby.defaultVersion applies across the jruby-gradle plugins then I think we need the callback system for ourselves to allow for the potential adding of jruby-complete late in the configuration/evaluation phase
R. Tyler Croy
@rtyler
Aug 12 2015 20:29
since @ysb33r hasn't had any time to respond or tell me I'm being crazy, I'm not sure if I should move forward here :P