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

9th
Jul 2015
Schalk W. Cronjé
@ysb33r
Jul 09 2015 11:49
@mkristian your PR #147 review is done
Christian Meier
@mkristian
Jul 09 2015 11:50
ah - cool
what do you mean with 'c-tor' ? probably some silly question - not sure though
Schalk W. Cronjé
@ysb33r
Jul 09 2015 11:53
constructor
Christian Meier
@mkristian
Jul 09 2015 11:53
:)
R. Tyler Croy
@rtyler
Jul 09 2015 16:43
@mkristian @ysb33r for the jruby-jar plugin I think we need to do something about the default jar task
the task is there whether you want it to be or not, and I imagine this is going to be confusing for users
Schalk W. Cronjé
@ysb33r
Jul 09 2015 16:56
If you take the task out, there is bound to be someone who complains too. However...
R. Tyler Croy
@rtyler
Jul 09 2015 16:57
yeah, we're in a pickle here
with 0.3.2 my assemble invocation will produce "foo.jar" and "foo-jruby.jar"
foo.jar is junk basically
Schalk W. Cronjé
@ysb33r
Jul 09 2015 16:58
Does JRubyJar create a fat jar?
R. Tyler Croy
@rtyler
Jul 09 2015 16:58
yes
that's foo-jruby.jar
but foo.jar is an empty vessle with only MANIFEST.MF only
Schalk W. Cronjé
@ysb33r
Jul 09 2015 16:58
Executable as well?
R. Tyler Croy
@rtyler
Jul 09 2015 16:58
no, just empty
Schalk W. Cronjé
@ysb33r
Jul 09 2015 16:59
Mean foo-jruby executable?
R. Tyler Croy
@rtyler
Jul 09 2015 16:59
foo-jruby is correct and executable just fine
see the usability problem here?
Schalk W. Cronjé
@ysb33r
Jul 09 2015 17:02
Mmm... lemme think about this. I'll ask some more questions later on this evening when I have time.
R. Tyler Croy
@rtyler
Jul 09 2015 17:08
yeah, i'm a bit conflicted about it too
I think this might just necessitate an option :/
Blane Dabney
@raelik
Jul 09 2015 19:35
So, I've been playing with the jar plugin, and I think it'll do what I want, but I'm having an issue with getting a subproject archive to automatically build before getting pulled into the jar
if I use this dependency: jrubyJar project(path: 'subproject_name', configuration: 'archives')
it pulls it in, but only if it's already built
but it just throws it into build/jars
doing the same thing, but using the gems configuration, that actually triggers the build process
which isn't what I want to do
Blane Dabney
@raelik
Jul 09 2015 19:47
though, doing a build first is fine
R. Tyler Croy
@rtyler
Jul 09 2015 19:58
@raelik what version of gradle?
Schalk W. Cronjé
@ysb33r
Jul 09 2015 20:07
@rtyler @mkristian I would still want to be able to create a simple jar which purely contains a collection of class files unpacked gems cf. asciidoctor-*.jar. I think the ruby-jar plugin should provide that capability and that is probably how the jar task should be enhanced.
R. Tyler Croy
@rtyler
Jul 09 2015 20:08
wouldn't that be the same as the "library jar" for jrubyJar?
Christian Meier
@mkristian
Jul 09 2015 20:09
@ysb33r jrubyJAr with initSctript library() should to this
Schalk W. Cronjé
@ysb33r
Jul 09 2015 20:10
@raelik The simplest soution is to add a dependsOn ‘:subprojectName:jar’ to the appropriate task. That will force it to be built. That is not the optimal solution, but it will get you going.
R. Tyler Croy
@rtyler
Jul 09 2015 20:14
@ysb33r fwiw I'm defaulting that task to dead in my SAP lookout/service-artifact-gradle-plugin#45
Schalk W. Cronjé
@ysb33r
Jul 09 2015 20:16
@mkristian @rtyler True. I forgot about that.
Schalk W. Cronjé
@ysb33r
Jul 09 2015 20:21

@rtyler. Maybe using beforeEvaluate hook is better and then simply set

tasks.whenTaskAdded { t ->
   if(t instanceof Jar && t.name == ‘jar’) {
     t.enabled = false
   }
}

This will allow configuration to turn it on if necessary.

mmm… that might not necessarily work. It also needs to check at apply time whether the java plugin has already been loaded.
maybe …. when can do this instead
instead of tasks.create( ‘jrubyJar', type : JRubyJar ), do
tasks.replace( ‘jar’, type : JubyJar)
dammit, now why didn’t I think of that before !!
R. Tyler Croy
@rtyler
Jul 09 2015 20:27
no reason not to do that now?
let's do it!
@ysb33r I like that syntax :)
Schalk W. Cronjé
@ysb33r
Jul 09 2015 20:32
I would just say that in order to avoid surprises we also need to do the following:
tasks.replace( ‘jar’, type : JubyJar).configure {
  initScript library()
}
becase by default the output of the jar task is not fat and executable.
R. Tyler Croy
@rtyler
Jul 09 2015 20:35
I think that's also acceptable
gemDir is a bit awkward IMO
@ysb33r @mkristian is there any reason we shouldn't accept a configuration option for JRubyJar
Schalk W. Cronjé
@ysb33r
Jul 09 2015 20:41
in what sense? Related to what we just discussed? Or in a different manner?
configuration option?
R. Tyler Croy
@rtyler
Jul 09 2015 20:43
configurations {
  customConfig
}

jrubyJar {
  configuration customConfig
}

dependencies {
  customConfig 'rubygems:myfancygem:9000'
}
i.e.
R. Tyler Croy
@rtyler
Jul 09 2015 20:56
which is possible now
this would mean we'd need to move away from a single JRubyPrepare and create a jrubyprepare per task
R. Tyler Croy
@rtyler
Jul 09 2015 21:10
@mkristian for JRubyJar, which code is responsible for putting jars into the JRUbyJar
the fattening up part :)
R. Tyler Croy
@rtyler
Jul 09 2015 21:24
oh bother I might have found a bug
not seeing jars getting included for a jar with a custom Main-Class
Blane Dabney
@raelik
Jul 09 2015 21:33
@rtyler Sorry, missed your question earlier. I'm using gradle 2.4
Blane Dabney
@raelik
Jul 09 2015 21:47
Just upgraded to 2.5 though
Christian Meier
@mkristian
Jul 09 2015 22:44
@rtyler basically jars are only "special" types of gems. they are copied with JRubyPrepare to GEM_HOME/jars. jars can be declared inside the "gems" configuration or can come in via transitive dependencies from gems.
the jruby-mains allow to have /jars /gems and /specifications directories for the jars and gems inside the jar, i.e. defaulting JARS_HOME to GEM_HOME/jars