lock_jars error: No plugin found for prefix 'gem' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories ...

[AndyObtiva]

lock_jars prints the error: No plugin found for prefix 'gem' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (~/.m2/repository), central (https://repo.maven.apache.org/maven2)]

Environment Information

Provide at least:

• JRuby version (jruby -v) and command line (flags, JRUBY_OPTS, etc): 9.4.9.0
• Operating system and platform (e.g. uname -a): Darwin Andys-MacBook-Pro-2.local 24.0.0 Darwin Kernel Version 24.0.0: Tue Sep 24 23:37:36 PDT 2024; root:xnu-11215.1.12~1/RELEASE_ARM64_T6020 arm64

Other relevant info you may wish to add:

• Installed or activated gems: glimmer-dsl-swt
• Application/framework version (e.g. Rails, Sinatra): glimmer-dsl-swt 4.30.0.0
• Environment variables: export JRUBY_OPTS="$JRUBY_OPTS -J-XstartOnFirstThread"

Expected Behavior

Running:

lock_jars --vendor-dir vendor/jars 

... used to lock jars under a vendor directory.

Actual Behavior

Running the lock_jars command now gives me this error:

% lock_jars --vendor-dir vendor/jars
Installing gem 'ruby-maven' . . .

using maven for the first time results in maven
downloading all its default plugin and can take time.
as those plugins get cached on disk and further execution
of maven is much faster then the first time.


-- jar root dependencies --

      isorelax:isorelax:20030108:compile
      org.nokogiri:nekodtd:0.1.11.noko2:compile
      net.sourceforge.htmlunit:neko-htmlunit:2.63.0:compile
      nu.validator:jing:20200702VNU:compile
      xalan:serializer:2.7.3:compile
      xalan:xalan:2.7.3:compile
      xerces:xercesImpl:2.12.2:compile
      xml-apis:xml-apis:1.4.01:compile
      org.snakeyaml:snakeyaml-engine:2.7:compile
[ERROR] No plugin found for prefix 'gem' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (~/.m2/repository), central (https://repo.maven.apache.org/maven2)] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundForPrefixException

I discovered the issue while attempting to upgrade this project to the latest JRuby and package as a native app with Glimmer DSL for SWT (you can clone the GitHub repo, bundle, and then try to run that command or glimmer "package[dmg]" on Mac, which invokes it indirectly):

https://github.com/AndyObtiva/dcr

glimmer "package[dmg]" on the Mac invokes lock_jars --vendor-dir vendor/jars, but it is failing now. It worked in the past. I have been able to package this application about 2-3 years ago.

[headius]

I will try to look into this tomorrow. Did this break recently or is this your first time trying it?

[AndyObtiva]

I believe it broke recently because I tried this command about 3-4 months ago and was able to use it in packaging a Glimmer DSL for SWT app without a problem.

[AndyObtiva]

After upgrading to JRuby 9.4.10.0 and jar-dependencies 0.5.2, now I get this error:

 % lock_jars --vendor-dir vendor/jars
ArgumentError: wrong number of arguments (given 3, expected 0)
  lock_down at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/gems/jar-dependencies-0.5.2/lib/jar_dependencies.rb:61
     <main> at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/gems/jar-dependencies-0.5.2/exe/lock_jars:54
       load at org/jruby/RubyKernel.java:1223
     <main> at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/bin/lock_jars:25
       eval at org/jruby/RubyKernel.java:1277
     <main> at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/bin/jruby_executable_hooks:22

[headius]

Looks like a new bug introduced by recent changes in jar-dependencies. Checking.

[headius]

@AndyObtiva Try manually patching that file with this fix and confirm it for me:

diff --git a/exe/lock_jars b/exe/lock_jars
index f883227..2ef0363 100755
--- a/exe/lock_jars
+++ b/exe/lock_jars
@@ -51,4 +51,4 @@ optparse = OptionParser.new do |opts|
 end
 optparse.parse!
 
-Jars.lock_down(options[:debug], options[:verbose], options)
+Jars.lock_down(**options)

[AndyObtiva]

OK, after making that change, I now get this error:

% lock_jars --vendor-dir vendor/jars                                       
ArgumentError: unknown keyword: :vendor_dir
  lock_down at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/gems/jar-dependencies-0.5.2/lib/jars/lock_down.rb:65
  lock_down at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/gems/jar-dependencies-0.5.2/lib/jar_dependencies.rb:64
     <main> at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/gems/jar-dependencies-0.5.2/exe/lock_jars:55
       load at org/jruby/RubyKernel.java:1223
     <main> at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/bin/lock_jars:25
       eval at org/jruby/RubyKernel.java:1277
     <main> at ~/.rvm/gems/jruby-9.4.10.0@glimmer_tetris/bin/jruby_executable_hooks:22

[headius]

Ok I guess that hash is used downstream as keyword args so it needs to be split up.

Try this:

diff --git a/exe/lock_jars b/exe/lock_jars
index f883227..ec82b3b 100755
--- a/exe/lock_jars
+++ b/exe/lock_jars
@@ -51,4 +51,4 @@ optparse = OptionParser.new do |opts|
 end
 optparse.parse!
 
-Jars.lock_down(options[:debug], options[:verbose], options)
+Jars.lock_down(debug: options[:debug], verbose: options[:verbose], **options)

This worked locally for me.

[AndyObtiva]

That gives me the same error. I doin't know why that options isn't supported.

[headius]

If this doesn't work show me how I can repro and I'll figure it out.

diff --git a/exe/lock_jars b/exe/lock_jars
index ec82b3b..0d998d4 100755
--- a/exe/lock_jars
+++ b/exe/lock_jars
@@ -51,4 +51,4 @@ optparse = OptionParser.new do |opts|
 end
 optparse.parse!
 
-Jars.lock_down(debug: options[:debug], verbose: options[:verbose], **options)
+Jars.lock_down(debug: options.delete(:debug), verbose: options.delete(:verbose), **options)
diff --git a/lib/jar_dependencies.rb b/lib/jar_dependencies.rb
index 419e34f..9da5ebe 100644
--- a/lib/jar_dependencies.rb
+++ b/lib/jar_dependencies.rb
@@ -61,7 +61,7 @@ module Jars
     def lock_down(debug: false, verbose: false, **kwargs)
       ENV[SKIP_LOCK] = 'true'
       require 'jars/lock_down' # do this lazy to keep things clean
-      Jars::LockDown.new(debug, verbose).lock_down(**kwargs)
+      Jars::LockDown.new(debug, verbose).lock_down(options.delete(:vendor_dir, **kwargs))
     ensure
       ENV[SKIP_LOCK] = nil
     end

[AndyObtiva]

That worked. It fixed the problem reported in this issue.

BTW, the 2nd code change needed a little tweak as options didn't exist in that method (but I assume you meant kwargs), so I updated the line you gave me to the following:

Jars::LockDown.new(debug, verbose).lock_down(**kwargs.except(:vendor_dir))

I look forward to a gem update that would include this fix.

[headius]

@AndyObtiva okay thanks for catching my mistake. I was just testing the lock_jars command from the root of the JRuby repository and I don't think it hits the lockdown logic (the first patch was sufficient). Clearly we need better tests in the jar-dependencies repository. 😆

I will apply these changes with your edit and get a release out tonight or early tomorrow US time.

[headius]

@AndyObtiva I think this is the correct line for the call to lock_down in jar_dependencies.rb, because that method requires the first argument be vendor_id:

Jars::LockDown.new(debug, verbose).lock_down(kwargs.delete(:vendor_dir), **kwargs)

The line you provided would not pass the vendor_id positional argument. Are you sure that worked?