joptsimple library not bundled?

[kevinduffey]

Getting a runtime exception in ramltopojo.Names class, joptsimple no such method found. I dont see anything about having to depend on that library, and even when I do add the maven dependency, it still fails.

java.lang.NoSuchMethodError: joptsimple.internal.Strings.join(Ljava/util/List;Ljava/lang/String;)Ljava/lang/String;

at org.raml.ramltopojo.Names.typeName(Names.java:61)
at org.raml.ramltopojo.object.ObjectTypeHandler.javaClassName(ObjectTypeHandler.java:41)
at org.raml.ramltopojo.object.ObjectTypeHandler.javaClassReference(ObjectTypeHandler.java:49)
at org.raml.ramltopojo.TypeDeclarationType.calculateTypeName(TypeDeclarationType.java:394)
at org.raml.ramltopojo.RamlToPojoImpl.buildPojos(RamlToPojoImpl.java:27)

[kevinduffey]

So I figured out the problem.. sort of.. I am using this library within a spring boot application, which bundles an earlier version of joptsimple library (4.6) that is apparently found first on the classpath. One thing about providing a library like this is the concern of any dependencies being part of projects that use this library.. with diff versions of those dependencies. It would be good to provide some sort of disclaimer that indicates the dependencies/versions and how if those same libraries are used in a project also using this library, there could be runtime classpath issues.

[jpbelang]

It's not my library (although I use it). It's used by a library used by the parser (it's two or three levels removed). I'll try to remove it from my library (honestly, I'm not really tied to it: I'm using it only to join strings...).

My code now uses Guava. Hope it helps.

[kevinduffey]

That may work. However, this is one of those sad issues with Java and using libraries that use other libraries that you may use inadvertently... version/classpath hell. What I cant seem to find good info on his.. how can I have one library that uses version 1.. use version 1.. while another library that needs version 2 just use version 2. I did a full blown eclipse style plugin engine years ago, and the whole class loading order made a difference. In our engine, we had plugins first find libraries within its own path before reaching outside. That allowed each plugin to use the same library with different versions without runtime issues. In this case... I suspect your update should fix it... assuming Spring doesnt use a wrong version of guava :D

[jpbelang]

There is not enough beer in the world to discuss this :-)

Java 9 addresses some of these issues. So does OSGi. They both come with their own set of issues....

[kevinduffey]

So I grabbed the repo, built the library, added your changes, and ran a test... works. Simple User type, but it generates the java code with equals and hash.