I am trying to deploy a dropwizard app on heroku which fails to launch.
Its works fine locally using "gradle run server config.yml"
I am using gradle for build and when I push to heroku the build is successful.
My gradle stage task dependsOn clean and jar(fat jar creation)
My Procfile has:
web: java $JAVA_OPTS -jar dropwizard-app/build/libs/dropwizard-app.jar server dropwizard-app/config.yml
The above fails with "Unable to access jarfile dropwizard-app/build/libs/dropwizard-app.jar"
I have tried unsuccessfully with
web: java $JAVA_OPTS -jar build/libs/dropwizard-app.jar server config.yml
I have also tried to execute using gradle command
web: gradle run server config.yml
This gives an error
bash: gradle command not found
My gradle tasks are as follows:
task stage(dependsOn: ['clean', 'jar'])
run {
args 'server', 'config.yml'
}
jar {
manifest {
attributes 'Title': 'dropwizard-app', 'Version': version,'Main-Class': mainClassName
}
archiveName 'dropwizard-app'
dependsOn configurations.runtime
from {
configurations.compile.collect {it.isDirectory()? it: zipTree(it)}
}
}
Am I missing out something here?
How do I launch my dropwizard application?
Got it working.
As mentioned above I was trying to execute dropwizard-app.jar
but the jar created on heroku was not of mentioned name, it took the default archive name
starting with build-'some autogenerated value'.jar
So I added a settings.gradle to my project:
rootProject.name = 'dropwizard-app'
Now the jar created was dropwizard-app-1.0.jar
as I have set the version attribute to 1.0 in build.gradle
I used heroku run bash
to check the files on heroku
I wrote a Maven-based deployment guide describing how to deploy a Dropwizard to Heroku which may offer some help. While it doesn't cover gradle, it does point out some common gotchas with the Heroku environment.
For example, your Procfile should look like this:
web java $JAVA_OPTS -Ddw.http.port=$PORT -Ddw.http.adminPort=$PORT -jar path/to/dw/module/target/example-develop-SNAPSHOT.jar server path/to/dw/module/config-heroku.yml
Related
I am trying to deploy a Gradle Java app to Heroku using GitHub. The repo name is "v-m-test". This is the Procfile I'm currently using: web: java -jar target/v-m-test.jar. Is this the wrong Procfile?
make sure the jar is the right path, so in your github you have a jar in this path:
target/v-m-test.jar
I am reading Full Stack Development with JHipster book.
I created a Microservice gateway with 'gateway' app name.
By following the book when I run
./gradlew bootRepackage -Pprod buildDocker
in the terminal, it says
Task 'bootRepackage' not found in root project 'gateway'
and then stop running.
My Jhipster version is 5.0.0
In JHipster v5.0.0+, the goal bootRepackage doesn't exist. It has changed to bootWar, so you need to use:
./gradlew bootWar -Pprod buildDocker
I have similar issue for Spring Boot 2.X. And solved it by changing to bootJar.
gradlew clean && gradlew bootJar
As mentioned here as well as here it should be possible - and a must-have for the docker-container - to be able to build a WAR-file of the whole application with ./gradlew -Pprod bootWar or make the application ready for a deployment via docker-container with ./gradlew bootWar -Pprod buildDocker.
But Intellij IDEA tells me, that there is no task bootWar. And ./gradlew -Pprod bootRundoesn't generate a *.war-file in build/libs/.
I also tried publishing directly to heroku, triggered by pushes to my github-repository controlled by a local jenkins2 docker-container. Maybe even the 404-Site after successful builds at heroku comes from this. The manual way documented in the jhipster.tech-documentation with ./gradlew -Pprod bootWar -x test and heroku deploy:jar --jar build/libs/*war can't work without the *.war.
So how can I export my monolithic jhipster-application into a *.war-file?
AFAIK you can generate a war with gradle by typing the following command
./gradlew -P prod build and/or ./gradlew -P prod build bootRepackage
I’m using Gradle 2.3. When building my mule 3.7 zip artifact, assuming all the tests pass and assembly of the war is successful, I’d like to copy my ZIP to my local $MULE_HOME/apps directory. So I have defined this in my build.gradle script:
task deploylocal() << {
println "Copy from ${buildDir} into $System.env.MULE_HOME/apps"
copy{
from "${buildDir}"
into "$System.env.MULE_HOME/apps"
include '*.zip'
}
}
Then, execute the gradle command:
gradle build deploylocal
You can achieve this by using mule-gradle-plugin. Refer "Special Features" section.
The build can be configured to deploy the resulting artifact on a mule
standalone server:
mule.installPath = '/path/to/mule/home'
Alternatively it can be configured through the MULE_HOME environment variable.
Finally to deploy:
$ gradle deployLocally
More details can be found at mule-gradle-plugin documentation
Hope this helps.
I am trying to accomplish something fairly simple. I have a project that builds a war.
I am using the Gretty Plugin to deploy the war and run it on Jetty.
What I want to do is basically:
Start the Jetty server
Deploy the war
Run the tests
Stop the Jetty server
The gretty configuration supports 'integrationTestTask' that seems to do the following:
Start the Jetty server
Run the tests
Stop the Jetty server
I can't figure out how to ensure the war is deployed before the tests are run.
When I do ./gradlew appStartWar - I can see my war is getting deployed and I am able to test it via curl/etc - but when I try run my automation tests there doesn't seem to be a way to do that...
I think I am missing something basic - but I am not sure what...any help will be greatly appreciated.
I don't think this is supported in Gretty at the moment. Gretty starts the servlet container against the compiled classes, not against the war file. It does not execute the war task. Have a look at the "Uses WAR" column here:
http://akhikhl.github.io/gretty-doc/Gretty-tasks.html
If you can make your application run by executing ./gradlew appStart then the integrationTest task should work as expected too. You might need to put web.xml in src/main/webapp/WEB-INF or figure out how to configure its location outside the war {} configuration.