This may be less of an issue with the move to MIMA (#102) but there may still be error-handling improvements possible.
The classic jar-dependencies logic based on ruby-maven depends upon a call-out to the Maven APIs successfully building a dependency list and writing it to a "deps.lst" file. The logic for this exists here (based on the newer MIMA logic):
https://github.com/jruby/jar-dependencies/blob/master/lib/jars/maven_exec.rb#L59-L81
The old Maven logic looks like this:
|
def resolve_dependencies_list(file) |
|
factory = MavenFactory.new(@options) |
|
maven = factory.maven_new(File.expand_path('gemspec_pom.rb', __dir__)) |
|
|
|
is_local_file = File.expand_path(File.dirname(@specfile)) == File.expand_path(Dir.pwd) |
|
maven.attach_jars(@spec, all_dependencies: is_local_file) |
|
|
|
maven['jars.specfile'] = @specfile.to_s |
|
maven['outputAbsoluteArtifactFilename'] = 'true' |
|
maven['includeTypes'] = 'jar' |
|
maven['outputScope'] = 'true' |
|
maven['useRepositoryLayout'] = 'true' |
|
maven['outputDirectory'] = Jars.home.to_s |
|
maven['outputFile'] = file.to_s |
|
|
|
maven.exec('dependency:copy-dependencies', 'dependency:list') |
|
end |
The "deps.lst" file is consumed in installer.rb and if the file does not exist, it will fail with an ENOENT error that provides no additional help. This logic is the same with the new MIMA implementation.
|
def self.load_from_maven(file) |
|
result = [] |
|
File.read(file).each_line do |line| |
|
dep = Dependency.new(line) |
|
result << dep if dep && dep.scope == :runtime |
|
end |
|
result |
|
end |
The old Maven logic did not check for error results from the Maven call, and would silently proceed to the "deps.lst" reading without reporting any issues. The newer MIMA logic should be more robust, since it manually writes the file based on MIMA results, but there's no guarantee those results are complete or that anything will actually be written.
A recent re-emergence of the ENOENT issue (reported and then deleted as a comment on ruby/psych#690) was actually due to Maven rate-limiting preventing the Maven logic from completing successfully.
We need to improve error-handling of this logic (perhaps by eliminating the "deps.lst" file altogether) so that any issues resolving Maven dependencies is reported as such and not allowed to trigger unrelated errors later on.
This may be less of an issue with the move to MIMA (#102) but there may still be error-handling improvements possible.
The classic jar-dependencies logic based on ruby-maven depends upon a call-out to the Maven APIs successfully building a dependency list and writing it to a "deps.lst" file. The logic for this exists here (based on the newer MIMA logic):
https://github.com/jruby/jar-dependencies/blob/master/lib/jars/maven_exec.rb#L59-L81
The old Maven logic looks like this:
jar-dependencies/lib/jars/maven_exec.rb
Lines 67 to 83 in 3a299d6
The "deps.lst" file is consumed in installer.rb and if the file does not exist, it will fail with an ENOENT error that provides no additional help. This logic is the same with the new MIMA implementation.
jar-dependencies/lib/jars/installer.rb
Lines 74 to 81 in 3a299d6
The old Maven logic did not check for error results from the Maven call, and would silently proceed to the "deps.lst" reading without reporting any issues. The newer MIMA logic should be more robust, since it manually writes the file based on MIMA results, but there's no guarantee those results are complete or that anything will actually be written.
A recent re-emergence of the ENOENT issue (reported and then deleted as a comment on ruby/psych#690) was actually due to Maven rate-limiting preventing the Maven logic from completing successfully.
We need to improve error-handling of this logic (perhaps by eliminating the "deps.lst" file altogether) so that any issues resolving Maven dependencies is reported as such and not allowed to trigger unrelated errors later on.