Upgrade JRuby Gradle plugins to 1.0

[mojavelinux]

The JRuby Gradle plugins have reached 1.0. We should upgrade and align with them.

http://jruby-gradle.org/news/2015/08/04/jrubygradle-one-point-oh/

Note that the default JRuby runtime is JRuby 9.0.0.0.

We should also look into the jar plugin again and see if we can use it now. Currently, we're only using the base plugin because the jar plugin didn't fit our use case. If that's still the case, we should make sure to file issues upstream so that eventually we can use it.

I think it's fine to upgrade only the 1.6.0 branch, but I'll leave that decision up to @robertpanzer.

[robertpanzer]

I just wanted to start migrating to the base plugin 1.0.1, but stumbled over this:
jruby-gradle/jruby-gradle-plugin#181

[mojavelinux]

Good to see that you found room for improvement in the new plugin. Let's follow that thread to see where it leads, then head back here once we can use prerelease versions again.

[robertpanzer]

I can actually start already to check if the jar plugin could be used for asciidoctorj-core as this bug only affects the current "satellite" projects around core.

[mojavelinux]

👍

[robertpanzer]

I am unsure if the jar plugin is a good approach.

Testing
For the task named test the environment vars GEM_HOME and JARS_HOME are set to the target directories of the jrubyPrepare task. (See https://github.com/jruby-gradle/jruby-gradle-plugin/blob/master/jruby-gradle-jar-plugin/src/main/groovy/com/github/jrubygradle/jar/JRubyJarPlugin.groovy#L29 )

This means that:

1. If we filter gem contents like we do in the pdf project we test with a different scenario as it will finally run. The tests would always see the full gem contents, but we would use the filtered content after the final jar is built.
2. If we have additional test tasks, e.g. for Osgi integration tests, we have to copy this behavior into our build scripts.
   3: How should we do things like patching Ruby files or gemspecs like we did in the past? I don't see any hooks for that and editing in place after gem installation seems to be a bad idea imo as it would probably break input/output caching of the tasks (correct me from wrong.)

Packaging
Then I have the impression that I did not understand yet what the jrubyJar task should do.
When I invoke the jrubyJar task I get an asciidoctorj-jruby-1.6.0-SNAPSHOT.jar, after 5 minutes(*)!!!, that contains a JRuby jar and a little bit more, but I can't find neither the asciidoctorj classes nor the gems!?
Do I have to configure that myself?

How do we want to enable a user to switch between different JRuby runtimes?
At the moment this is just overriding a dependency or adding another jruby.jar to the classpath.

What should we do with the satellite projects?
We surely don't want to package JRuby into asciidoctorj-pdf as well.

At the moment I think the use case of the jruby-gradle.jar is a totally different one from what we are doing.

(*) And my machine is not too slow, usually a clean AsciidoctorJ build takes about 5 minutes.

[ysb33r]

I've been out of touch on this, but any bugs you might find related to JRubyJar we will fix in the plugin.

The library() in the plugin's configuration, has as it's main use-case the building of asciidoctorj. So most definitely we need to get it fixed.

[abelsromero]

I'll add some context:

I opened this post in the mailing-list: https://groups.google.com/forum/#!topic/jruby-gradle/bktpjT7Si5k.
Mainly it revolves about the library() option not working properly and the possibilty to generate jars like our own directly with the jar plugin.

Finally, during today's gitter talk (to which I arrived late ><), this issue was filled in the jruby-gradle-plugin to see to it.
jruby-gradle/jruby-gradle-plugin#204

[mojavelinux]

Thanks for identifying these requirements, @robertpanzer and @abelsromero. This is exactly the steps we need to take so that we can converge with the plugin. The way I look at the custom scripts in AsciidoctorJ is like a requirements list for what we would need to switch to the plugin. I do believe that rolling this into a Gradle plugin / task is the goal here. If fixing the jar plugin to cover this use case (a very common use case, I might add), then that's great. If it means another plugin or task, then that's what we'll need to do. But I think we definitely want to eventually get rid of the custom scripting.

The custom filtering would be nice, but I wouldn't say it's a hard requirement. We really shouldn't have to be doing that...better is to fix the gems upstream. We just happened to be able to use that workaround in the past.

Of course, all of this packaging would be totally eliminated if JRuby had the ability to use a gem directly, without having to repackage it. I dream of that day :)

[mojavelinux]

At the moment I think the use case of the jruby-gradle.jar is a totally different one from what we are doing.

If we all agree that this is true, we may want to start pushing for a new task, as I suggested in my last comment.

[robertpanzer]

@ysb33r Here you are:)

[ysb33r]

One thing to realise is that once we go for JRuby 9k we wave goodbye to 1.6 compatibility. The latter versions of JRuby-Gradle are also no longer 1.6 compatible. This will also have a knock-on effect on the asciidoctor-gradle plugin.

[robertpanzer]

At the moment the 1.6.0 snapshots already compile for Java 7.
So at least for that release this decision is already done.

Would this be an issue for future gradle plugins?

Am 26.11.2015 um 18:39 schrieb Schalk W. Cronjé [email protected]:

One thing to realise is that once we go for JRuby 9k we wave goodbye to 1.6 compatibility. The latter versions of JRuby-Gradle are also no longer 1.6 compatible. This will also have a knock-on effect on the asciidoctor-gradle plugin.

—
Reply to this email directly or view it on GitHub #375 (comment).

[ysb33r]

@aalmiray might have an opinion, but I would just settle for 1.7. The current asciidoctor-gradle plugin (1.5.3) has enough stable functionality for people who still use 1.6.

[ysb33r]

ALso currently we cannot upgradle the Gradle version as nebula-publishing fails with anythign Gradle 2.3+. (Raised this as nebula-plugins/nebula-publishing-plugin#55).

[ysb33r]

@robertpanzer I have upgraded to jruby-gradle 1.1.5 and simplified the build scripts a bit, but I get a number of errors with jruby 1.7.21. Also using jruby 9.0.5.0 fails >90% of the test. Have you see any failures?

[ysb33r]

Also using jruby 9.0.5.0 fails >90% of the test. Have you see any failures?

Just ignore what I said there. It's late and I had 9.0.0.0 configured. (Also 9.0.5.0 does not exist, latest is 9.0.4.0)

[ysb33r]

I am however seeing 10 failures with both 1.7.21 and 9.0.4.0. All of these failures as InitializationError exceptions with a typical stack trace such as

java.lang.NoSuchMethodError: org.spockframework.runtime.JUnitDescriptionGenerator.attach()V
    at org.jboss.arquillian.spock.ArquillianSputnik.getSpec(ArquillianSputnik.java:181)
    at org.jboss.arquillian.spock.ArquillianSputnik.runExtensionsIfNecessary(ArquillianSputnik.java:190)
    at org.jboss.arquillian.spock.ArquillianSputnik.getDescription(ArquillianSputnik.java:155)
    at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:83)
    at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49)
    at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:69)
    at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:48)

I have upgraded Spock to 1.0-groovy-2.4 and I am wondering whether that is clashing with something in Arquilian.

(The branch is https://github.com/ysb33r/asciidoctorj/tree/jruby-gradle-upgradle).

[robertpanzer]

Arquillian Sputnik does not run with Spock 1.0 yet.
That's why we currently still use Spock 0.7.