Put jdeb back in provided scope

[ches]

Expected behaviour

Adding the plugin with no configuration at all does not break the build when using Coursier.

Actual behaviour

#1053 happens out of the box with sbt-native-packager 1.3.2 and Coursier 1.0.

Information

• sbt-native-packager 1.3.2
• sbt version 1.1.0
• sbt-coursier 1.0.0

jdeb is in provided scope for sbt 0.13, but that is currently disabled with a comment that something was broken about it in sbt 1.0 milestones (build used RC3 at the time the comment was added).

I've created this issue to track following up on that—presumably if jdeb is back in provided scope for sbt 1.x, a user won't have the bad experience of hitting #1053 and having to go discover the coursier/coursier#450 workaround as soon as they enable sbt-native-packager on their project, when they are not even using JDebPackaging.

This is a poor out-of-the-box experience, so I feel an issue should be kept open for it.

I don't know what the problem with provided was, but I can try to see if it still persists with later sbt 1.x.

[muuki88]

Sorry for the late reply. I tried fix this while upgrading to sbt 1.x, but wasn't able to
set the provided scope as AutoPlugins seem to be initialized eagerly now.

This requires some more refactoring on the JDebPackagingPlugin.

[muuki88]

A possible solution would be to create a separate class which contains all the jdeb specific implementation, so all these imports could be removed

import org.vafer.jdeb.{DataProducer, DebMaker}
import org.vafer.jdeb.mapping._
import org.vafer.jdeb.producers._

The class is only instantiated when the packageBin task is executed. This could solve this issue.

[ches]

Thanks for fixing this!

If I can make time I'll try to do similar for Spotify docker-client, it brings quite a bit of junk (hello, Guava) into your build's dependencies that are not welcome if not using DockerPlugin or preferring the Docker CLI support.

[muuki88]

That would be fantastic 😍