Update nokogiri -v to include versions of new libraries

[jvshahid]

#1212 has introduced new java libraries in nokogiri. It would be nice if we can include their versions in the output of nokogiri -v:

1. xalan-j
2. serializer.jar
3. [xml-apis.jar] Found this class could be relevant org/apache/xmlcommons/Version.class

This leaves the following dependencies with no way to get their versions at runtime afaik:

1. isorelax.jar
2. jing.jar
3. nekodtd.jar

While we are at it, we should add a README to the lib directory explaining how each dependency is used and which jars need to be upgraded together.

[mkristian]

how can I use nokogiri gem in simple setup like this:
https://gist.github.com/mkristian/a46851705427f68ce310

the Jarfile actually has a single jar (the sqlline one is an inconsistency on maven central). I have to admit that the dependency tree does not contain a conflict with nokogiri but xalan, xerces and xml-apis are still common java libraries. sometimes libraries reduce xerces to xercesMinimal.

in the above example their are a couple of problematic nested dependencies like joda-time, jcodings which are part of jruby-core. one day jar-dependencies will be able handle this somehow. nokogiri just loads its jars without checking if those jars are already loaded. jar-dependencies does not check but tracks the version of the loaded jars and guards against having multiple versions of the same jar loaded into the jruby-classloader. declaring the jar dependencies in your gemspec allows tools like gradle or maven to negotiate the version with your java application which might use embedded jruby with some gems like nokogiri.

[mkristian]

ah more thought I wanted to mention: if some application setup forces nokogiri to use other jars then the declared ones that is actually a common situation for maven or gradle projects as the dependency resolution has its way to resolve version conflicts. so for nokogiri declaring its versions which maven or gralde or or jbundler or jar-dependencies can use would be helpful to manage jars and gems in more symmetrical manner (or something like this).

[jvshahid]

Thanks @mkristian for bringing this up. What you are proposing sounds like a much bigger change than what the original issue was trying to address. Can you start a thread on the mailing list, I'm interested in hearing what everyone thinks about your proposal.

[flavorjones]

Once we address #1253 (using jar-dependencies) we should easily be able to do this.

[flavorjones]

#2432 introduces this, at least for direct java dependencies. I'm leaving this open so I can circle back and make it work for transitive java dependencies as well.