Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Split HAPI service from server #57

Open
lindholc opened this issue Oct 10, 2018 · 5 comments
Open

Split HAPI service from server #57

lindholc opened this issue Oct 10, 2018 · 5 comments
Assignees
@lindholc

Comments

@lindholc
Copy link
Member

Ideally the HAPI service will be its own artifact that can be added to a LaTiS 3 instance.
@lindholc lindholc self-assigned this Nov 6, 2018
@lindholc
Copy link
Member Author

lindholc commented Nov 8, 2018

I've done the split in a branch.

I'm having difficulty figuring out how to get sbt-assembly to produce a single JAR that is the standalone server. I have sbt-revolver and sbt-docker working correctly.

lindholc added a commit that referenced this issue Nov 8, 2018
@lindholc
Split server and service into separate projects
ac33ebd 
The major difficulty with this split was making sure that
sbt-revolver, sbt-docker, and sbt-assembly still did what we wanted
them to.

I needed to disable sbt-revolver on the root project and the service
project because they have nothing to run.

I needed to enable sbt-docker on the server project, because that's
the one we want to build the Docker image for.

Dealing with sbt-assembly was a little trickier. By default it will
build a JAR for each project. By making the root project depend on the
others and disabling aggregation for the assembly task, I was able to
convince it to produce a single JAR that pulls in everything from the
server and service projects.

I have no idea if this is the best way of doing this, but it appears
to work for our needs at the moment.

See #57.
@lindholc
Copy link
Member Author

lindholc commented Nov 8, 2018

I believe I have it working, but I'll need to think on it a little bit. It feels wrong. I haven't seen a good example of an SBT build for an application that includes a reusable library.

We may want to move latis.properties from the server project to the service project, because anyone wanting to use the service backed by LaTiS 2 will need that file. (If they want to use processing instructions in TSML.)

@lindholc
Copy link
Member Author

HapiServerApp is now something that clients may wish to pull in (#64).

It exists somewhere between the HAPI service and the HAPI server application:

  • The HAPI server application is an standalone, executable thing for end users.
  • The HAPI service is useful if you have an http4s application you want to add a HAPI service to, like LaTiS 3.
  • HapiServerApp is useful if you want to run your own HAPI server with a different interpreter.

@lindholc
Copy link
Member Author

Perhaps the LaTiS 2 stuff should be in a third module.

@lindholc
Copy link
Member Author

lindholc commented Jan 4, 2019

See the http4s build for inspiration. In particular, look at http4sProject, libraryProject, and exampleProject. Perhaps there's a way to hide some of the complexity and duplication this way.

They also use sbt-revolver for a subset of their projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lindholc lindholc

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lindholc