[eropple]

Fully agreed on a most of this; when Play does something well, it does something really well. I personally just wish the build system wasn't such a mess and so antithetical to good development practices--it's extremely hard to have something like a shared domain library among multiple projects (with hot reloading, i.e. if you need to iterate on it while you develop) without making a fake Play project with a conf directory and all of that. It feels built for independent systems/applications rather than ones that play (ha) nicely with each other.

(Also, using the Flyway module has made life a lot easier. play-evolutions is a bit wonky.)

[saryant]

You don't need to make a fake Play project to create a shared module. Any SBT or Maven project will work just fine.

That's how we do it anyways.

[eropple]

Really! How new is this? I ask because there were some people trying to do this to little effect last time I seriously worked with Play.

[joostdevries]

Play 2.0+ is based on SBT as build system. SBT uses ivy and maven repos as source for dependency lookup. Maven repo's often show the SBT mantra form of a maven dependency. F.i. click on the sbt tab here http://mvnrepository.com/artifact/org.eclipse.mylyn.github/o... If you don't want to add your dependency to a maven repo you can define a sub-project. SBT projects are aggregated recursively of other sbt projects.

My pet peeve is that SBT suffers from ungoogleable scalaz like operators like %% instead of %. And that the Scala IDE doesn't provide any help like code completion, marking compilation errors e.d. in creating your project/Build.scala Those two facts make sbt a big hurdle in adoption I noticed.

[eropple]

Believe me, I've spent enough time with Play to know exactly how the build system does its thing with external dependencies.

The problem I'm referring to is that, for a long time at least (I know pre-2.1, maybe 2.1 as well), there was no way to aggregate non-Play projects--that is, ones that didn't have a conf directory and did have their own pom.xml or whatever--and use the recompiler. So if you were trying to build your project using an external Java/Scala domain object library that could be shared between projects and wanted it to hot-recompile while you're working (because I at least don't write every model class before I get going) you were in for a world of hurt.

[ssmoot]

I must be misunderstanding the question. Aggregation of non-PLAY sbt projects has worked from day one of Play 2.0 AFAIK. (That's when I started using both, and we've had sbt projects as bit submodules compiled as dependencies from the start).

I even did a presentation with examples for my local Scala User Group: http://slid.es/samsmoot/some-sbt

[eropple]

Yeah, maybe we're talking about different things; I may be using the wrong sbt terminology because I generally try to avoid it. =) Here's the original bug where some WTFs were exchanged:

http://play.lighthouseapp.com/projects/82401/tickets/453-nee...

Ben's patch made the workaround less terrible for 2.1, but it's still a really weird hacky thing to me and I never got it working with my Maven projects (my preferred backend uses Dropwizard so using a sbt project wasn't really optimal at the time).

[ssmoot]

This ticket is (justifiably IMO) marked as invalid. It's not a bug, misfeature or anything. It looks like a misunderstanding honestly.

If you approach it with a "Play first" mindset and ignore that any of the Play build-cycle stuff only works because it's built on SBT it's going to be rough going.

An "SBT first" mindset makes it much easier.

Create three console apps in three different folders. Doesn't matter where on your system these live.

Now create a fourth directory, add a project sub-folder and a `Build.scala`. Aggregate the projects together and make Project-C a dependency of Projects A and B. A and B are otherwise completely unrelated.

Now when you drop into the SBT console you can run test, compile, etc. All your standard aggregation tasks. If you wanted to actually run A or B, you can run the `run` task and it'll ask you what main-class to execute.

Here's the only real difference as far as Play is concerned: It doesn't use the standard SBT `run` task. So to get the `run` task from the Play plugin you first need to select your Play sub-project: `project my-play-project`. Now you can run `run` and it'll work like a normal Play application.

I think that extra step is actually resolved in Play 2.2 (it uses the standard `run` task now I've heard).

In this setup your "root project" isn't your Play app. It's a code-less project just defining the build and dependencies between your projects. You could add your common project to the Play app's Build.scala, and use `file()` in the Project declaration for it. The project can live anywhere. It's not at all necessary it be in a sub-path, use symlinks, anything like that.

In SBT 0.13 it's even better since you can do almost everything in .sbt files, which unlike a Build.scala can be built up across several projects. So Play-App-A can read the build.sbt from ../common/build.sbt and use that. Where a Build.scala has to be all-encompasing, so your common project configuration would have to reside in my-play-project-a/project/Build.scala.

SBT really is very nice. :-) I've used Maven, Bundler, Buildr, etc. Written my own JRuby Maven+Rubygems build tool (http://github.com/sam/doubleshot). The docs for SBT are real heavy, but if you set aside a few hours to watch some presentations on Parleys, Youtube, etc, it's pretty easy to get into.

Feel free to ping me if you're interested and could use a hand.

[joostdevries]

btw JS dependencies are available as maven deps now as well. Pretty handy http://www.webjars.org/

[virtualwhys]

This is true, although I'd replace "multiple projects" with "multiple applications" as you can most definitely create highly modular applications using SBT sub projects.

The dirty *nix hack for this is to symlink the shared library; otherwise, converting the lib to a plugin is one way toward creating reusable cross-application libraries.