conflict: jersey 1.x and jersey 2.x

[gsmachado]

Hello all,

I'm using Dropwizard 0.9.3 in the backend, where I have a large project with multiple dependencies.

At the moment, I'm using the following packages/dependencies:

project.ext {
    dropwizardVersion = '0.9.3'
}

dependencies {
    compile (
            'io.dropwizard:dropwizard-core:' + dropwizardVersion,
            'io.dropwizard:dropwizard-hibernate:' + dropwizardVersion,
            'io.dropwizard:dropwizard-migrations:' + dropwizardVersion,
            'io.dropwizard:dropwizard-auth:' + dropwizardVersion,
            'io.dropwizard:dropwizard-client:' + dropwizardVersion,
            'io.dropwizard:dropwizard-testing:' + dropwizardVersion,
            'io.dropwizard:dropwizard-assets:' + dropwizardVersion,
            'io.dropwizard:dropwizard-forms:' + dropwizardVersion,
            'com.github.toastshaman:dropwizard-auth-jwt:0.9.1-1',
            'org.glassfish.jersey.media:jersey-media-multipart:2.22.1',
            'commons-io:commons-io:2.4',
            'javax.mail:mail:1.4',
            'org.apache.httpcomponents:httpmime:4.5.1'
    )

}

However, now, I *must* use a dependency that uses Jersey 1.x. Such library uses some features fro mJersey 1.x and I really can't change it to Jersey 2.x

My question is: is it possible to use Dropwizard 0.9.3, somehow, with Jersey 1.x? If yes, how?

Cheers!

[Ryan Kennedy]

The answer is probably (and sadly), "it depends." It depends on the nature of the dependency and what part of Jersey it's dependent on. If it's depending on part of Jersey 1.x to be running in the guts of the server itself...probably not. If it's depending on part of Jersey 1.x for a client, maybe. Assuming it's not something that wants to be plumbed into the depths of the server, you may need to do some repackaging so you don't have any packaging collisions. Maven Shade has the ability to "relocate" dependencies. So if your app (A) depends on a library (B) that depends on Jersey 1.x (C), you may be able to configure Shade so B's dependency on C is repackaged (move packages com.* to B-internal.com.*). This can get messy, though, if you run into lots of conflicts. I've done this in the past to import my own version of javassist.

Probably not the most satisfying answer. If you can provide more details regarding the affected dependency we might be able to help more.

Ryan

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guilherme Sperb Machado]

Hello Ryan, all,

Sorry not providing more details before, but first I wanted to check
if someone gets interested about this topic or not. It seems so. :-)

Ok, I will provide a bit more info.

Currently, these are all the dependencies I'm using in my application:

repositories {
mavenCentral()

}

dependencies {
compile (
'io.dropwizard:dropwizard-core:' + dropwizardVersion,
'io.dropwizard:dropwizard-hibernate:' + dropwizardVersion,
'io.dropwizard:dropwizard-migrations:' + dropwizardVersion,
'io.dropwizard:dropwizard-auth:' + dropwizardVersion,
'io.dropwizard:dropwizard-client:' + dropwizardVersion,
'io.dropwizard:dropwizard-testing:' + dropwizardVersion,

'org.mariadb.jdbc:mariadb-java-client:1.3.3',

'com.github.toastshaman:dropwizard-auth-jwt:0.9.1-1',
'org.glassfish.jersey.media:jersey-media-multipart:2.22.1',
'commons-io:commons-io:2.4',
'javax.mail:mail:1.4',
'org.apache.httpcomponents:httpmime:4.5.1'
)

compile ('com.emc.ecs:object-client:2.2.2') {
exclude group: 'org.slf4j', module: 'slf4j-log4j12'
}
compile ('com.emc.ecs:atmos-client:2.2.2.1')
}

The dependencies that are causing the conflict are
"com.emc.ecs:atmos-client:2.2.2.1'" and
"com.emc.ecs:object-client:2.2.2", which depend on
"'com.emc.ecs:smart-client:2.1.0'", which, in turn, directly depends
on:

'com.sun.jersey:jersey-client:1.19',
'com.sun.jersey.contribs:jersey-apache-client4:1.19',
'org.apache.httpcomponents:httpclient:4.2.6'

Thus... I attached the output of 'gradle dependencies' in this
message. Take a look at the atmos-client and object-client (at the end
of file). I've realized that the "com.sun.jersey.contribs" depends on
the com.sun.jersey.contribs:jersey-core.

I really don't imagine how I could make dropwizard to use the old
Jersey 1.x. Do you think that the given situation is feasible to make
it work with the 1.x version? In case of a positive answer, how to
proceed. :-)

Cheers!

> You received this message because you are subscribed to a topic in the
> Google Groups "dropwizard-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dropwizard-user/Q_108pJl_Ss/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Ryan Kennedy]

I don't have any experience with Gradle, but in Maven you can use <excludes/> blocks when pulling in dependencies to exclude their sub-dependencies. In this case, you could try excluding jersey-client, jersey-apache-client, and httpclient when you import the com.emc.ecs artifacts. That may work if the packages/classes haven't moved enough to cause issues for the com.emc.ecs libraries.

If they've moved around too much, you probably need to try something like Maven Shade's relocation feature to repackage things. That would help to work around package collisions between Jersey 1.x and 2.x. This can get a bit involved, though. I've never done this with someone else's package, only my own. But since EMC has their stuff on GitHub, there's nothing stopping you from forking and doing it yourself:

https://github.com/EMCECS/smart-client-java

Alternatively, you could upgrade them to the newer Jersey and submit a pull request.

I really doubt you're going to get Dropwizard working with Jersey 1.x (i.e. import Dropwizard and use exclusions to prevent it from bringing Jersey 2.x with it). If I had to guess, the libraries aren't compatible enough for Dropwizard not to notice.

This is one of those places we've seen problems before. I wish we had a better answer.

Ryan