We use a form of option 2 in the Kiama project (
http://kiama.googlecode.com). Our view is that the extended examples are part of our test suite. Thus, they are in the main Kiama project and we have the project configured so that the example files are seen to be tests by sbt.
You can find the full sbt configuration on the Kiama google code site, but the most relevant details follow. Note that we don't use the default Maven-style directory layout. All of our sources are under "src" and the tests are located in the directory hierarchy with the code that they test.
scalaSource <<= baseDirectory { _ / "src" }
unmanagedSources in Test <<= scalaSource map { s => {
val egs = s / "org" / "kiama" / "example" ** "*.scala"
((s ** "*Tests.scala") +++ egs).get
}}
unmanagedSources in Compile <<= (scalaSource, unmanagedSources in Test) map { (s, tests) =>
((s ** "*.scala") --- tests).get
}
The effect of this configuration is that a .scala file is regarded as a test source if it is in the src/org/kiama/example directory or if it is elsewhere and its filename ends with Tests.scala. All other .scala files are part of the library proper.
Thus the main Kiama jar just includes the library stuff and the test jar includes all tests, including the examples. We don't need any new processing phases since the normal sbt test commands will do the trick. E.g., test runs all of the tests including those in the examples. test:package makes the test jar. Similarly, normal sbt publishing will publish the test jar alongside the library jar.
Overall, this setup seems to work pretty well for us and I think is simpler to deal with than having a separate project for the examples.
cheers,
Tony