Support sbt-style scala-versioned dependencies

[cdegroot]

(Not sure it's the correct name for the groupId %% artifactId % version construct...)

It'd be nice if JitPack would support this construct, selecting the scala version on the fly. When you use the double-percent construct, sbt looks for (sample pulled from one of my own JitPack tests):

https://jitpack.io/com/github/cdegroot/hardcoded_2.10/1.0.0/hardcoded_2.10-1.0.0.pom

Underscores are of course allowed in repository names, but I think that if you combine the heuristic "underscore in repo name followed by [0-9\.]+" with "sbt project", it's probably pretty simple to add one and one and conclude someone used the double-percent-sign and wants that version of Scala. Would save sbt library maintainers the hassle of making multiple release tags (one per Scala version).

[jitpack-io]

Hi @cdegroot

Looks like a good idea. Just to clarify, do you mean JitPack should build with a different Scala version depending on which one is requested?

[cdegroot]

That indeed.

[jitpack-io]

Got it. But isn't the scala version specified already in the build file? Not sure how we would specify or override it. Not a sbt expert, sorry:)

[cdegroot]

Well, you can specify multiple versions in the sbt build description. Scala 2.10 and 2.11 (and probably 2.12 as well) aren't binary compatible, hence the convention to put the version number in the library name. Sbt allows for cross-compilation, so an sbt release would upload multiple artifacts, for the versions you specify. So it makes sense for JitPack to do the same but then just-in-time, building against a Scala version when a build for that version is requested. I'd need to dig into how one could best implement it (sbt doesn't have a ton of command line arguments documented, but I guess it should be possible).

[update] I just tested two small libraries I created; one has sbt cross-building support, one doesn't. In both cases, sbt does what you want when invoking it with "+ package", the plus indicating cross-compilation (http://www.scala-sbt.org/0.13/docs/Cross-Build.html). See the output at https://gist.github.com/cdegroot/5c156329b56f2a71ede3 to see what happens.

It would probably be easiest if this feature is supported by convention - invoke sbt in cross-building mode, if it spits out multiple versions then JitPack can support these versions. Least amount of magic involved and puts cross-scala-version support control in the hand of the authors.

[jitpack-io]

That's awesome! Will have a look how to implement on JitPack side

[FRosner]

👍

[jitpack-io]

Just launched this feature in beta mode. Basically jitpack will run: sbt ++2.XX.X publishM2 if Scala version is specified on the url.
Seems to work on your example https://jitpack.io/com/github/cdegroot/hardcoded_2.11/1.0.0/build.log but will keep an eye out for issues. All feedback appreciated!

[cdegroot]

Great work. I'll give it a spin :)

[cdegroot]

👍 and sorry for the reference-spam above, I was force pushing a bit while testing :)

(a quick how-to in https://gist.github.com/cdegroot/5864f4b4a4d759f42158)

[Darkyenus]

Thanks for implementing!

I might have found a small bug with it. When I request for example ResourcePacker_2.10 it builds correctly, but jitpack.io UI does not show the build logs for that version. They seem to be available when manually changing the log URL to https://jitpack.io/com/github/Darkyenus/ResourcePacker_2.10/1.4/build.log , adding the _2.10 postfix manually.

[jitpack-io]

@Darkyenus Good point! The UI doesn't pick it up yet. Opening an issue #269