lundi 9 mars 2015

When building multiple sub-projects with SBT, how do I exclude common dependencies from creating wars?

I'm trying to migrate an existing Java / Scala Ant project to SBT and I'm just getting acquainted with all these tools and Scala. I'm having trouble figuring out the best way to package everything up - especially to match our existing build for easier migration.

Example

Let's say I have the following projects:

common (a dependency of both a and b)

Ultimately, I want to deploy projects a and b to Tomcat as WAR files, but I want the built common jar and all its dependencies to be copied to a shared/lib folder in Tomcat.

I'm planning on using xsbt-web-plugin to package war files (but other suggestions are welcome).

I have a centralized list of dependencies in project/Dependencies.scala. Let's say that looks like:


import sbt._

object Dependencies {
  val foo = ...
  val bar = ...

  val aDeps = Seq(foo)
  val bDeps = Seq(bar)
  val commonDeps = Seq(foo)
}

Goals

What's the best way to package up a.war, b.war, common.jar, and the common dependencies for deployment?

Simple: all dependencies together

I'd be fine with figuring out how to grab all dependencies between all 3 projects and putting those jars in a single folder during packaging. This is basically what our build does now.

Ideal: exclude common dependencies from each war

For the above example, how do I create a folder with common.jar and all its dependencies, then create wars for a and b that exclude common and any of its dependencies? a.war would contain no dependencies because foo is required by common, b.war would contain the dependency bar because it's not in common, and I'd end up with another target folder with common.jar and its dependencies: foo.jar.

It seems like I could do this by looping through aDeps and bDeps and marking anything that appears in commonDeps as provided, but I wasn't sure how to do that.

Rationale

I understand there may be many negatives of doing this such as having to sync up dependencies between A, B and common, but my goal is to replicate the current setup with sbt before making any changes. The reason behind doing this was that many GB of models are loaded into memory in common, so putting it in a shared folder prevents it from being loaded twice.

java