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

15th
May 2015
Christian Meier
@mkristian
May 15 2015 13:35
@ysb33r @rtyler just a quick look at #122 please, before I merge it :)
Schalk W. Cronjé
@ysb33r
May 15 2015 13:35
ok
Christian Meier
@mkristian
May 15 2015 13:42
Schalk W. Cronjé
@ysb33r
May 15 2015 13:43
you can't
Christian Meier
@mkristian
May 15 2015 13:44
hmm - then that is how it is ;)
Schalk W. Cronjé
@ysb33r
May 15 2015 13:44
unfortunately this is where the underlying implementation language pollutes the buildscript
but typically we get around that problem, by making at least one task of the that type available when the plugin gets applied
for your demo you need more than on ekind of the task so that is what it is
I tend to hide the imports as high up in the build script as where I can
Christian Meier
@mkristian
May 15 2015 13:48
for getting jrubyJar { jruby { initScript 'app.rb' } } and JRubyJar to work I need to do the "traits" thingy from JRubyExec ?
Schalk W. Cronjé
@ysb33r
May 15 2015 13:49
With traits do you mean Groovy traits?
which I did use to consolidate JRubyExec and project.jrubyexec
OR do you mean task extension?
Christian Meier
@mkristian
May 15 2015 13:49
yes
Schalk W. Cronjé
@ysb33r
May 15 2015 13:50
As that is the way I implemented ruby {} on top of the Jar task
Christian Meier
@mkristian
May 15 2015 13:52
no the Jar task and the configurator is clear and still in use. I meant the first about JRubyExec and project.jrubyexec. since it sounds the "same" as JRubyJar and project.jrubyJar to me. but I might be wrong
and wonder if this jrubyExec is the right direction
Schalk W. Cronjé
@ysb33r
May 15 2015 14:00
It could be

Usually a lot of the DSL is common between the project extension as the task. Under normal circumstances you could have done it via an intermediate base class, but this is not possible here because

  • Your task class is already in a hierarchy and Java does not allow multiple inheritance.
  • Fields in Gradle task classesrequire annotation to simplify determining inputs and outputs - those cannot be used in a project extension

So one way to achive commonality is to use traits, BUT it it still a bit of a kludge as you can see from my usage of convertXXX methods.

Schalk W. Cronjé
@ysb33r
May 15 2015 14:06
Also an important thing to remember is that with JRubyJar everything gets configured first and executed later. With project.jrubyJar everything get evaluated as soon as project.jrubyJar gets called.
That is the technicalities. The usage question though, why do you actually need a project.jrubyJar ?
Christian Meier
@mkristian
May 15 2015 14:08
well, I do not know :) - but it looks convenient and fits to jar, shadowJar, etc
Schalk W. Cronjé
@ysb33r
May 15 2015 14:11
I think you are getting confused. jar is a task of type Jar. shadowJar is a task of type ShadowJar (I think). project.jrubyexec is a project extension in the valour of project.exec and project.javaexec. These are not tasks.
I think what you want is a task called jrubyJar which is of type JRubyJar and gets added when the plugin is applied.
Christian Meier
@mkristian
May 15 2015 14:12
yes
Schalk W. Cronjé
@ysb33r
May 15 2015 14:12
The latter is easy. Just do it in the JRubyPlugin.apply method.
Christian Meier
@mkristian
May 15 2015 14:13
ok
Schalk W. Cronjé
@ysb33r
May 15 2015 14:13
project.tasks.create( ‘jrubyJar’,JRubyJar)
Christian Meier
@mkristian
May 15 2015 14:13
:)
thanx a lot that is exactly what I wanted and it just works
Schalk W. Cronjé
@ysb33r
May 15 2015 14:17
you can add a test in JRubyJarPluginSpec which is something like
    def “Checking tasks exist"() {
        expect:
            project.tasks.getByName('jrubyJar')
    }
rtyler @rtyler waves
Christian Meier
@mkristian
May 15 2015 15:42
@mkristian waves back
R. Tyler Croy
@rtyler
May 15 2015 15:42
Jars.lock? did I miss something?
Christian Meier
@mkristian
May 15 2015 15:44
probably not. when you require_jar then jar-dependencies looks for this Jars.lock and if it exists it just loads all the jars from there.
at leafy we have see a lot of "version" conflicts just because dropwizard just do not clean up their conflicts and let maven just silently fix them.
R. Tyler Croy
@rtyler
May 15 2015 15:45
ah
Christian Meier
@mkristian
May 15 2015 15:45
Jars.lock is just a way to "enforce" specific versions of jars avoiding the conflict warnings
R. Tyler Croy
@rtyler
May 15 2015 15:46
is the plugin generating that file though?
Christian Meier
@mkristian
May 15 2015 15:46
yes, the base plugin does generate this file BUT it format was wrong
R. Tyler Croy
@rtyler
May 15 2015 15:47
hrm
Christian Meier
@mkristian
May 15 2015 15:47
the test was wrong as well ;)
R. Tyler Croy
@rtyler
May 15 2015 15:48
I really don't like .lock files but I'll bite my tongue for now :P
Christian Meier
@mkristian
May 15 2015 15:48
with gradle it is well hidden you will probably never see it :)