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

29th
Nov 2014
Schalk W. Cronjé
@ysb33r
Nov 29 2014 14:18
@rtyler I am not quite in agreement of making shadow plugin an implicit dependency for the jar plugin. My reasoning is that the script author should decide whether they want that and which which version of the shadow plugin they want. Aslo it makes it harder to add support for another exec jar plugin such as oneJar.
R. Tyler Croy
@rtyler
Nov 29 2014 15:36
@ysb33r why would using onejar be preferrable?
without shadow will the plugin bake executable or fat jars at all?
@ysb33r I understand the point, but I'm not sure how much "batteries included" functionality we would have without the jar plugin declaring that dependency
Schalk W. Cronjé
@ysb33r
Nov 29 2014 17:12
The basic idea (for me) was pack a gem into a jar.
the executable jar was a second feature set
R. Tyler Croy
@rtyler
Nov 29 2014 19:36
@ysb33r huh, I don't think I fully realized that, my primary use case is the other way around :P
R. Tyler Croy
@rtyler
Nov 29 2014 19:46
@ysb33r packaging a gem as a jar, what would use that besides jruby-gradle?
Schalk W. Cronjé
@ysb33r
Nov 29 2014 19:47
over at asciidoctor they are talking about packing various asciidotor extensions (which are just GEMs) as JARs.
R. Tyler Croy
@rtyler
Nov 29 2014 19:47
ah
Schalk W. Cronjé
@ysb33r
Nov 29 2014 19:48
Now, even if we keep Shadow plugin as an implicit dependency, we need to modify it via an extension so that the script author can control the version. (overide default).
R. Tyler Croy
@rtyler
Nov 29 2014 19:49
right, I'm okay with that, I want to make sure that it's really clear how to use this to create standalone ruby apps
I don't think I fully undersood your usecase previously when I made the dependency explicit