Conflicting dependencies

[oliviercailloux]

Hi, Using com.jcabi:jcabi-github:0.32 (POM) makes my project fail when I use other APIs related to Rest, Json, or the like. The 0.32 version relies on quite old dependencies, because of its parent, com.jcabi:jcabi:1.20.1 (POM), more precisely because of the parent of com.jcabi:jcabi:1.20.1, which is com.jcabi:parent:0.37.1 (POM).

Please update!

[0crat]

@yegor256 please, pay attention to this issue

[yegor256]

@oliviercailloux let me try here: https://github.com/jcabi/jcabi-github/pull/1327

[oliviercailloux]

I am unsure I understand your previous message. What’s the current status? As far as I can see at #1327 the build is failing (perhaps due to the changes of versions?). Are you still investigating? Should I test something?

[yegor256]

@rultor release, tag is 0.33

[rultor]

@rultor release, tag is 0.33

@yegor256 OK, I will release it now. Please check the progress here

[rultor]

@rultor release, tag is 0.33

@yegor256 Done! FYI, the full log is here (took me 17min)

[yegor256]

@oliviercailloux try version 0.33 please, it has all the updated deps

[oliviercailloux]

Thanks! I still have a problem. When leaving my dependency to org.glassfish.jersey.bundles:jaxrs-ri:2.26, calls to the JAX-RS API (following this pattern) fail with:

java.lang.NoSuchMethodError: org.glassfish.hk2.utilities.ActiveDescriptorBuilder.asType(Ljava/lang/reflect/Type;)Lorg/glassfish/hk2/utilities/ActiveDescriptorBuilder;
	at org.glassfish.jersey.inject.hk2.Hk2Helper.translateToActiveDescriptor(Hk2Helper.java:309)
	at org.glassfish.jersey.inject.hk2.Hk2Helper.bindBinding(Hk2Helper.java:150)
	at org.glassfish.jersey.inject.hk2.Hk2Helper.bind(Hk2Helper.java:112)
	at org.glassfish.jersey.inject.hk2.Hk2Helper.bind(Hk2Helper.java:90)
	at org.glassfish.jersey.inject.hk2.ImmediateHk2InjectionManager.register(ImmediateHk2InjectionManager.java:82)
	at org.glassfish.jersey.client.ClientConfig$State.initRuntime(ClientConfig.java:433)
	at org.glassfish.jersey.internal.util.collection.Values$LazyValueImpl.get(Values.java:341)
	at org.glassfish.jersey.client.ClientConfig.getRuntime(ClientConfig.java:826)
	at org.glassfish.jersey.client.ClientRequest.getConfiguration(ClientRequest.java:285)
	at org.glassfish.jersey.client.JerseyInvocation.validateHttpMethodAndEntity(JerseyInvocation.java:143)
	at org.glassfish.jersey.client.JerseyInvocation.<init>(JerseyInvocation.java:112)
	at org.glassfish.jersey.client.JerseyInvocation.<init>(JerseyInvocation.java:108)
	at org.glassfish.jersey.client.JerseyInvocation.<init>(JerseyInvocation.java:99)
	at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:419)
	at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:319)
	at io.github.oliviercailloux.st_projects.services.git_hub.RepositoryFinder.find(RepositoryFinder.java:49)
	at io.github.oliviercailloux.st_projects.services.git_hub.TestFinder.testNoFindTooLate(TestFinder.java:40)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

When removing that dependency, basic calls succeed but as soon as I need automatic JAX-RS conversion to JsonObject (when invoking JsonObject json = request.get().readEntity(JsonObject.class);), it fails:

org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyReader not found for media type=application/json;charset=utf-8, type=interface javax.json.JsonObject, genericType=interface javax.json.JsonObject.
	at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(ReaderInterceptorExecutor.java:232)
	at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:156)
	at org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(MessageBodyFactory.java:1085)
	at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:853)
	at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:785)
	at org.glassfish.jersey.client.ClientResponse.readEntity(ClientResponse.java:326)
	at org.glassfish.jersey.client.InboundJaxrsResponse$1.call(InboundJaxrsResponse.java:111)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:419)
	at org.glassfish.jersey.client.InboundJaxrsResponse.readEntity(InboundJaxrsResponse.java:108)
	at io.github.oliviercailloux.st_projects.services.git_hub.RepositoryFinder.find(RepositoryFinder.java:50)
	at io.github.oliviercailloux.st_projects.services.git_hub.TestFinder.testNoFindTooLate(TestFinder.java:40)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Could you please update your dependency to org.glassfish.jersey.core:jersey-server to version 2.26? I believe the problem lies there.

Thank you again for taking care of this issue.

[oliviercailloux]

(Just wondering) Should I open a new bug report about this?

[amihaiemil]

@oliviercailloux Can't you exclude any transitive dependency that comes via jcabi-github, and pull in your own? I think you should be able to do that. See the Maven documentation here.

[amihaiemil]

@oliviercailloux Also, there is an annoying bug about Manifest.mf (jcabi-github reads some values from there at runtime...). See here. The fix/workaround is rather simple.

Other than that, The library works fine, and the mock version of it is really very useful when testing.

[oliviercailloux]

I must say I didn’t try that but used another workaround. Even if manual exclusion worked, I still believe this bug would benefit from a fix so that other users do not face the issue. Also, the fix is simple, assuming it really suffices to update the dependency. (And if this is not enough, then anyway manual exclusion using Maven most probably would not work around the problem either.) And having (approximately) up-to-date dependencies is always good.

Thanks for your comment.

[edson-freitas]

@oliviercailloux I had the same issue about the ActiveDescriptorBuilder method, trying to use jersey 2.26. Turns out was the hk2 libs version used (was 2.4.0). After upgrading to 2.5.0-b42, the issue vanished. Maybe this can help you.

[amihaiemil]

@oliviercailloux Was your problem related to Jersey 1.x and 2.x versions? I am confused as to why those 2 versions should conflict. Maybe you can answer my SO question? https://stackoverflow.com/questions/47347072/why-should-jersey-1-x-conflitct-with-jersey-2-x

[oliviercailloux]

@amihaiemil Thanks: excluding org.glassfish.hk2:hk2-api, org.glassfish.hk2.external:javax.inject and org.glassfish.hk2:hk2-locator from com.jcabijcabi-github:0.33.1 indeed solves the problem. However this is probably not the cleanest solution as this leaves old dependencies (that are selected by Maven dependency selection mechanism).

I rather finally opted for including explicit dependencies to org.glassfish.jersey.core:jersey-common:2.26 and org.glassfish.jersey.core:jersey-server:2.26 in my POM, to ensure that those versions are selected rather than the old ones included in the POM of jcabi. (In effect, this also changes the hk2 version selected by Maven.)

Still, I believe that the dependencies should be updated at the level of jcabi itself. The fact that it simply works (at least, apparently) when changing the dependencies in my POM hints that there should be no difficulty in changing the same dependencies in the jcabi POM. (And if some difficulties are found, then I’d like to know because I might hit them as well!)

[oliviercailloux]

@amihaiemil about your remark that “Other than that, The library works fine”: I omitted to write this, but you are right to underline it. The library is pleasant to use and very useful. Those (relatively minor and correctable) glitches do not modify that fact.