0

I'm an open-source Scala developer who wants to minimize the hassle of dependencies when pushing to GitHub and triggering a check with continuous integration (CircleCI). I have two projects where one (A) is dependent on the other (B). B is under development at the same time (as a snapshot). My project A build.sbt file has a dependency on this (snapshot) version of B and of course all works fine on my local machine. When I push to GitHub, it naturally fails as that snapshot file is not available to CircleCI.

I have generally worked around this by putting the jar file into my lib directory (and removing the dependency from build.sbt). I believe this is known as an unmanaged dependency.

My question is this: is there any way of setting up my lib directory so that CircleCI can resolve the (managed) dependency from the lib directory? I have tried putting the ivy structure into lib starting with the top level com.phasmidsoftware, with b_2.13 under that and under that 1.0.4-SNAPSHOT and so on down. That doesn't work. I've attached the build.sbt for project A (called Numeric).

organization := "com.phasmidsoftware"

name := "Number"

version := "1.0.9"

scalaVersion := "2.13.6"

scalacOptions ++= Seq( "-target:jvm-1.8", "-encoding", "UTF-8", "-unchecked", "-deprecation", "-Ywarn-dead-code", "-Ywarn-value-discard", "-Ywarn-unused" )

val scalaTestVersion = "3.2.3"

libraryDependencies += "org.scalatest" %% "scalatest" % scalaTestVersion % "test"

resolvers += "Typesafe Repository" at "https://repo.typesafe.com/typesafe/releases/"

libraryDependencies ++= Seq(
  "com.phasmidsoftware" %% "matchers" % "1.0.4-SNAPSHOT",
  "org.scala-lang.modules" %% "scala-parser-combinators" % "1.2.0-M1",
  "org.apache.commons" % "commons-math3" % "3.6.1",
  "org.slf4j" % "slf4j-api" % "1.7.31",
  "ch.qos.logback" % "logback-classic" % "1.2.3" % "test",
  "org.scalacheck" %% "scalacheck" % "1.14.1" % "test"
)
Phasmid
  • 923
  • 7
  • 19
  • 2
    I wouldn't recommend pushing JARs to Git, that's really not a good practice. – Gaël J Jun 24 '21 at 19:27
  • 1
    Are they unrelated projects? Couldn't they be subprojects in the same Git repository? – Gaël J Jun 24 '21 at 19:30
  • One (B) is general-purpose. A is dependent on B. I don't think subprojects of a common project could really be justified. – Phasmid Jun 25 '21 at 04:00
  • As far as pushing JARs is concerned, I agree. But there is no simple way to get those JARs to Circle-CI (that I know of). Publishing via Maven is possible of course but is the very opposite of simple! – Phasmid Jun 25 '21 at 04:02
  • 1
    If `B` is general purpose and will be used by many other projects then pu pushing to **maven central** is the right thing to do, otherwise join both projects in a single **sbt** multi-module setup. - An intermediate approach would be to clone the other repo and do a `sbt publishLocal` on **Circle** before compiling your code. - There is also a way to add **abt** dependencies from github repo IIRC: https://stackoverflow.com/questions/7550376/how-can-sbt-pull-dependency-artifacts-from-git – Luis Miguel Mejía Suárez Jun 25 '21 at 04:20
  • @LuisMiguelMejíaSuárez that looks like a very useful idea (using the reference you quote at the end, mostly). Thank you. If you were to turn this into an answer, I could upvote it :) – Phasmid Jun 25 '21 at 18:53
  • Well, then it would be just a duplicate of the one I linked. I would be better if you up-vote those and close this one as a duplicate of that one :) – Luis Miguel Mejía Suárez Jun 25 '21 at 19:02

1 Answers1

0

The answer described in How can sbt pull dependency artifacts from git? is indeed the right answer.

I will just add a couple of caveats.

  • Make sure that you use the git protocol in the URI of your git repository (as is shown in the other answer);
  • The mechanism works by cloning the repository (the branch is defined by ...#branch) but, once you've cloned it, sbt won't fetch if appropriate -- you do have to do that explicitly yourself.
  • The other thing to keep in mind is that the clone(s) are placed in ~/.sbt/1.0/staging/... where 1.0 is based on the sbt version number.
  • And, of course, don't forget to remove the reference to the other project if you have it in your libraryDependencies.

Here's the relevant part of my build.sbt file:

lazy val root = (project in file(".")).dependsOn(matchers)
lazy val matchers = RootProject(uri("git://github.com/rchillyard/Matchers#V1_0_5"))
Phasmid
  • 923
  • 7
  • 19