Upgrade spotify docker-client to 3.2.1

[gbougeard]

Using the spotify docker client in Play 2.4.x projects leads to jackson errors like :
[error] (docker:publishLocal) com.spotify.docker.client.DockerException: java.util.concurrent.ExecutionException: javax.ws.rs.ProcessingException: java.lang.AbstractMethodError: com.fasterxml.jackson.jaxrs.base.ProviderBase._configForReading(Lcom/fasterxml/jackson/databind/ObjectReader;[Ljava/lang/annotation/Annotation;)Lcom/fasterxml/jackson/jaxrs/cfg/EndpointConfigBase;

Upgrading to 3.2.1 fixes it.

[muuki88]

Thanks a lot for keeping an eye on that. At some point we made refactor these modules out into subpackages to avoid that kind of issues (JDeb, DockerSpotifiy,... )

[huntc]

@muuki88 It appears as though this PR has brought in a ton of new dependencies on glassfish artifacts via Spotify's docker-client. I waited considerably longer for the latest native packager to download (1.0.6).

Do we really need the spotify client? Should we consider an alternative?

When we require docker communication then we just use the process API. Thoughts?

[huntc]

Perhaps it is also time to consider factoring out Docker into its own plugin. It ain't the only container format. ;-)

[muuki88]

Yeah, I actually planned to factor out the JDeb and Spotify support in it's own plugin which is bound to the release cycle of the sbt-native-packager. I will try to upgrade our build infra today

[huntc]

FWIW I think jdeb is useful to support building Debian packages in general, and given that Debian is a popular target I'd leave it in there. Docker should absolutely be standalone though.

Separately, we should probably avoid the Spotify client for Docker given what it pulls in and just integrate at the process API level.

WDYT?

[muuki88]

Keeping jdeb in the core for the first refactoring is fine with me. However we had some issue with jdeb as well, because it was depending on maven2 which introduced a lot of unwanted logging dependencies. So in the long run I would like to factor this out as well.

just integrate at the process API level

What do you mean by that? The native-docker plugin integrates the docker command. The spotify-docker client is like jdeb a java-based abstraction, which allows native-packager to run on platforms that don't have the docker (or dpkg) command available. So this is in general the same thing.

Yesterday I simplified our build, reusing a lot of sbt-plugins out there. My idea would be to separate the build like this

lazy val root = project.aggregate(core, dockerSpotify)

lazy val core = project.in(file("core"))
  .settings(
    name := "sbt-native-packager"
)

lazy val dockerSpotify = project.in(file("docker-spotify"))
  .settings(
     name := "sbt-native-packager-docker-spotify"
  )
  .dependsOn(core % "compile->provided") // not quite sure if this works

So that in the end you write in your plugins.sbt

val nativePackagerVersion = "1.1.0"
addSbtPlugin("com.typesafe.sbt", "sbt-native-packager", nativePackagerVersion)
addSbtPlugin("com.typesafe.sbt", "sbt-native-packager-docker-spotify", nativePackagerVersion)

[muuki88]

Actually, I have a better idea. That it's a lot easier. Marking the dependencies with % "provided".
We can then make Class.forName checks in the plugin using these to output better errors messages and the user just needs to add the specific library in the plugins.sbt

[huntc]

Yeah, I think that could work, although I still think that Docker should be an entirely separate plugin ultimately. :-)

On 22 Dec 2015, at 5:21 AM, Nepomuk Seiler notifications@github.com wrote:

Actually, I have a better idea. That it's a lot easier. Marking the dependencies with % "provided".
We can then make Class.forName checks in the plugin using these to output better errors messages and the user just needs to add the specific library in the plugins.sbt

—
Reply to this email directly or view it on GitHub.

[muuki88]

I think we should keep it. We only should avoid the dependency mess. There is another sbt-docker plugin, which is pretty nice. However you have to configure everything for your application by yourself.

[huntc]

Sounds like a plan. :-)