如何在子项目example/build.sbt中引用父目录build.sbt内的scala-forklift-slick项目定义以替换Maven依赖？

Yes, you have two clean, concise options to avoid merging all build files into one. Let's break them down:

Option 1: Use ProjectRef to Link the Local Project Directly #

This is the "one-line" style solution you're looking for, keeping your /example/build.sbt intact while pointing it to your local scala-forklift-slick project.

In your /example/build.sbt, replace the Maven dependency line (like libraryDependencies += "com.liyaos" %% "scala-forklift-slick" % "x.y.z") with a dependency on the local project using ProjectRef:

// In /example/build.sbt
lazy val example = (project in file("."))
  .dependsOn(ProjectRef(file(".."), "scala-forklift-slick"))
  // keep your existing example settings here

How this works: #

• ProjectRef(file(".."), "scala-forklift-slick") tells sbt to look for the project named scala-forklift-slick in the parent directory (file("..")).
• You don't need to move any of your existing example build configuration into the parent build.sbt—everything stays isolated in /example/build.sbt.
• Any changes you make to scala-forklift-slick will be picked up immediately when you build the example project (no need to re-publish).

Option 2: Publish Locally to Ivy Repository #

If you prefer to keep the dependency structure similar to the original Maven setup (but using local builds), you can publish scala-forklift-slick to your local Ivy repository:

1. Run this command in the parent directory:

sbt slickMigrationProject/publishLocal

2. In /example/build.sbt, update the dependency version to match the version in your parent build.sbt (make sure it's not a remote snapshot that sbt will try to download):

// In /example/build.sbt
libraryDependencies += "com.liyaos" %% "scala-forklift-slick" % "your-local-version"

When to choose this: #

• You want to test the exact same dependency setup as your production environment (just using a local build instead of a remote Maven repo).
• You have multiple projects that need to use your modified scala-forklift-slick (not just this single example).

Which Option is Better for Your Use Case? #

• Go with Option 1 if you're actively modifying scala-forklift-slick and want instant feedback in the example project—no extra publish steps required, and you keep build configurations separate.
• Go with Option 2 if you want to simulate the full dependency workflow (e.g., testing if your changes work when the library is published) or share the modified library across multiple local projects.

内容的提问来源于stack exchange，提问作者Daniel