The ruby runtime plugin fails to load when running Jenkins with Java 11. I
think that is one more reason to discuss deprecation of the ruby-runtime
plugin again.
The failure message is "*unsupported Java version: 11*":
2021-04-14 17:46:48.215+0000 [id=31] INFO
ruby.RubyRuntimePlugin#start: Injecting JRuby into XStream
2021-04-14 17:46:48.451+0000 [id=31] WARNING
jenkins.model.Jenkins$5#runTask: Loading plugin ruby-runtime v0.12
(ruby-runtime) failed perhaps due to plugin dependency issues
*java.lang.RuntimeException: unsupported Java version: 11*
at
org.jruby.RubyInstanceConfig.initGlobalJavaVersion(RubyInstanceConfig.java:1674)
at
org.jruby.RubyInstanceConfig.<clinit>(RubyInstanceConfig.java:1387)
Caused: java.lang.ExceptionInInitializerError
at
org.jruby.embed.internal.AbstractLocalContextProvider.<init>(AbstractLocalContextProvider.java:42)
at
org.jruby.embed.internal.SingleThreadLocalContextProvider.<init>(SingleThreadLocalContextProvider.java:43)
at
org.jruby.embed.ScriptingContainer.getProviderInstance(ScriptingContainer.java:242)
at
org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:226)
at
org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:192)
at
org.kohsuke.stapler.jelly.jruby.JRubyFacet.<init>(JRubyFacet.java:65)
at
ruby.RubyRuntimePlugin.registerJRubyFacet(RubyRuntimePlugin.java:39)
at ruby.RubyRuntimePlugin.start(RubyRuntimePlugin.java:30)
at
hudson.ClassicPluginStrategy.startPlugin(ClassicPluginStrategy.java:406)
at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:395)
Caused: java.io.IOException: Failed to initialize
at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:398)
at hudson.PluginManager$2$1$1.run(PluginManager.java:551)
at
org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at
jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
2021-04-14 17:46:48.457+0000 [id=32] SEVERE
jenkins.InitReactorRunner$1#onTaskFailed: Failed Loading plugin Rvm v0.6
(rvm)
java.io.IOException: Failed to load: Rvm (0.6)
- Plugin is missing: ruby-runtime (0.12)
at
hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:950)
at hudson.PluginManager$2$1$1.run(PluginManager.java:550)
at
org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at
jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
com.google.inject.internal.cglib.core.$ReflectUtils$2
(file:/home/mwaite/tmp/JENKINS-65243/war/WEB-INF/lib/guice-4.0.jar) to
method java.lang.ClassLoader.
defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of
com.google.inject.internal.cglib.core.$ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
On Wednesday, April 14, 2021 at 10:34:37 AM UTC-6 [email protected]
wrote:
> So revisiting this really old ticket.
>
> As i've been working on rewriting/improving the process of processing
> metadata to produce plugin documentation, I'm noticing we have a lot more
> legacy bad data than I expected. While I am handling it, I also want to try
> and improve things. As such, ruby runtime is going to be on my list to
> discuss.
>
> Looking at the original list that db generated, all of them have not been
> released in at least 5 years (most are 7-9 years), including gitlab-hook
> which has huge security errors listed. I was certain at one point I saw
> ruby runtime being no longer supported in core but I can't find
> confirmation of that, so may have been thinking of this discussion.
>
> So revisiting, Can we suspend distribution of these plugins now? take them
> out of update center, prevent new installs from happening. As stated in the
> earlier comments by Jesse, this wouldn't prevent existing installs from
> using them (although they probably don't work), but would prevent peoples
> installs from getting worse.
>
> If the only blocker to doing so was writing up a blog post I can draft
> something and we can start the process of removing the support and plugins
> for ruby runtime
>
> Gavin
>
> On Friday, August 17, 2018 at 4:40:03 AM UTC-7 Oleg Nenashev wrote:
>
>> Hi Daniel,
>>
>> Thanks for the amendment!
>> Would it be also possible to add an "Announcement" section to reasoning
>> and explicitly document why proposals (blogpost, administrative warning,
>> direct maintainer notification) are rejected?
>>
>> I still disagree with the user notification approach taken in this
>> proposal, and I believe we should do the best possible effort to notify
>> users.
>> Spending 1 hour to write a blogpost with heads-up and workaround
>> guidelines (and invitations to contribute) is the most obvious way to do
>> that.
>> I do not understand why there is so much resistance about that.
>>
>> CCing all known plugin maintainers in this thread is another obvious way
>> to make them aware of the thread. We cannot expect that any plugin
>> maintainer carefully reads every thread in the mailing list.
>>
>> "Scriptler, Build Flow, Copy to Slave, or Perforce."
>>>
>>
>> I do not buy that justification for JEP-7. All these plugins have been
>> depublished due to security reasons, so there was no way to properly notify
>> users in advance. But even in such case, the users know about the incoming
>> security release in advance so they can prepare to mitigate breaking
>> changes. Maintainers also got directly contacted, and they acknowledged the
>> action. Here you propose to depublish a bunch of
>> non-healthy-but-operational plugins, and the proposed notification process
>> is "let's just do that, they should have read mailing lists". And there are
>> low-cost ways to let users know in advance and to soften the change. I
>> cannot agree with such approach, sorry.
>>
>> Best regards,
>> Oleg
>>
>>
>> On Thursday, August 16, 2018 at 9:45:33 PM UTC+2, Daniel Beck wrote:
>>>
>>>
>>> > On 16. Aug 2018, at 19:45, Oleg Nenashev <[email protected]> wrote:
>>> >
>>> >> You mean, so that _new_ users can _install_ the plugins? I would say
>>> no.
>>> >
>>> > How would you define a "new" user in the new configuration-as-code
>>> world? If somebody uses official Jenkins Docker image with plugins.txt, the
>>> plugins will fail to install when you rebuild the image after the change
>>> gets deployed. And it is a pretty popular approach nowadays. Plugin
>>> installation features in JCasC 1.0 RC would be also affected AFAICT.
>>>
>>> As of last count, 111 installs of CasC plugin. I'd be _very_ surprised
>>> if this ended up affecting more than 5 systems total.
>>>
>>> And while this isn't the only approach to configuration-as-code, people
>>> should not expect us to continue distributing plugins indefinitely after we
>>> blacklisted the likes of Scriptler, Build Flow, Copy to Slave, or Perforce.
>>>
>>> Notably, update sites only have the newest release, which isn't suitable
>>> for C-as-C anyway, so I expect the more stable approaches to use our Maven
>>> repo anyway -- which will not be affected.
>>>
>>> Running one's own Maven repo has been an important best practice for a
>>> long time. With C-as-C, running one's own update site should be similar.
>>>
>>> I will amend the JEP to record this concern and the answers. I don't
>>> think we need to change anything about the chosen approach.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/22ac20c3-486c-4d4d-bb2c-873c5d20a887n%40googlegroups.com.
