consider adding an option to build a war
x12a1f opened this issue · comments
Hi,
I want to run the shimmer under an existing tomcat server so I would like to have the shimmer available as a war.
I found this: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/html/build-tool-plugins-gradle-plugin.html#build-tool-plugins-gradle-packaging and http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-create-a-deployable-war-file
I have no experience with spring, but it sounds like it should be possible to create a war containing the shimmer and also have the jar with the embedded jetty.
What do you think?
Hi Ralph,
That should be straightforward enough. There's a release around the corner, I'll see if I can squeeze it in.
Thanks for the suggestion,
Emerson
That would be great!
I've been trying to tinker with the build files using the information from those pages and I've got it working as a war under tomcat. However, with the changes I made, it does not run standalone anymore and I'm not sure what is wrong.
This is what I did: https://github.com/MEDvision/shimmer/commit/9266c3f5e55e83fb38b579bc8669ed131a345033
It works for creating a war but it breaks the jar with embedded jetty. (It compiles but jetty fails to start with an error)
We're aiming to get this released next week, was just too tight today.
The build now creates a WAR, which can be run both on the command line and in an application server. This feature branch will get released in the coming days.
If you don't need to use the console or will run it separately, you can just run ./gradlew build and copy the WAR file out of shim-server/build/libs directory. You can use whatever context path you want for the WAR.
If you do need the console and want it deployed inside the same WAR, run the ./run-natively.sh script. The WAR will then have the console resources inside it. You must then deploy the WAR with a root context path, i.e. /, i.e. call the WAR ROOT.war. This is a temporary restriction. The console is getting overhauled and we'll sort this out properly as part of that effort.
This has been fixed in release 0.4.2.
cool, thanks!