Change project setup to a multi-module build #14
Conversation
This is done to prepare for adding a benchmark module. It is done as a separate PR to avoid merge problems, as it involves a lot of renames. - The main build.sbt defines a root project, core sangria and shared settings - The sangria source has been moved to modules/core - The modules/core/build.sbt file defines sangria specific settings
There was a problem hiding this comment.
Thanks for doing this! I definitely think it's a good idea.
One minor point: I have a slight preference for including the core config in the core definition in the root build.sbt, rather than in core/build.sbt, for a couple of reasons:
- It makes sharing version numbers and other config across modules more convenient.
- It feels a little more idiomatic, or at least it seems to be the more common choice for projects with multi-module sbt builds.
This will make sharing of settings and versions easier, as noted in the code review.
|
@travisbrown Thanks for the review. I incorporated your suggestion and moved all config into the main build.sbt. What do you think about the factoring of |
|
@SimonAdameit That looks reasonable to me! |
|
Curious if we could go further with this. I had another issue I n the old repo to split the project further into more specific modules. The reasoning being that often consumers of sangria like client projects don’t need all of the other capabilities and might only need the AST. |
This is done to prepare for adding a benchmark module.
It is done as a separate PR to avoid merge problems,
as it involves a lot of renames.