In this approach, migrations and application are separated in two sbt sub projects. We don't really need an sbt plugin to run the migration commands -- we just need to run the other sub project, and we can easily define an alias for that. We don't really need to change much code in this approach.
This approach reduces sbt dependency significantly (comparing with #2 ). Changes in migration sub projects do not require an sbt reload, either.
In this approach, migrations and application are separated in two sbt sub projects. We don't really need an sbt plugin to run the migration commands -- we just need to run the other sub project, and we can easily define an alias for that. We don't really need to change much code in this approach.
This approach reduces sbt dependency significantly (comparing with #2 ). Changes in migration sub projects do not require an sbt reload, either.