Heroku is runnign lein uberjar to build my Clojure app, but I need it to run lein ring uberjar. Can this be configured without forking the buildpack?
I've tried setting the web process to just use lein ring server-headless to start, instead of the standalone jar, but then I get boot timeouts while dependencies are installing.
As described here there is the LEIN_BUILD_TASK configuration variable which you can set.
I'm assuming that setting it's value to ring uberjar should work for you.
If you check the source code of the buildpack, the process fallbacks to uberjar when the LEIN_BUILD_TASK variable is not specified.
Related
So I have a Maven project and I'd like to deploy it on Heroku via Github. To be more precise I want to use automatic deployments where when I push to my master branch only then is it deployed. The only thing I found for Maven is that I add a dependency and it would deploy to Heroku from my machine (which I essentially don't want).
I really don't know what else to say as I had 0 progress. For now I am just pushing my target as well and then just running the target jar file. But I'd like to just send over my source code and for Heroku to build the project.
Alright, so I found my solution.
I saw an example (I can't find it now, no luck) for Heroku that build the project with a thing called mvnw script which is a Maven wrapper when it's not installed on the system. I added it and the .mvn directory but it didn't start by itself like how it is written on Heroku (it should run it when it's detected), no problem really.
I then edited my Procfile and instead of:
web: java -jar target/my-file.jar
I am using:
web: ./mvnw clean package; java -jar target/my-file.jar
And everything works well!
You only need to integrate your GitHub repository on Heroku, and define the automated deployment of the master branch (each push will trigger a deployment).
Heroku will build the JAR and take care of the deployment, you need though to define the Java version in a system.properties and create an Uber-Jar (ie including all dependencies).
Essentially, the Jenkins CI job runs mvn spring-boot:run .... in a productions cluster as the only way to run the application. With this build step, in effect, we are running the springboot app only via maven and this has led to a very unstable jvm behavior. Also, I am unable to configure all the possible tweaks to the jvm e.g, turning on gc logging or changing to G1GC etc.. etc..
I just wanted to know if running my java springboot app should indeed be packaged into a fat jar and run with standard jvm flags, rather than from maven.
Please let me know your thoughts
Spring boot maven plugin has jvmArguments in order to set jvm settings.
......
<configuration>
<jvmArguments>-Xdebug</jvmArguments>
</configuration>
.......
The second option is to create a self-executable jar/war and use a standard way to run app - java -jar app.jar <jvm properties>
Our teams have been running fat jars similar to how others have stated with the simple java -jar ****.jar commands. However, once in production, you can utilize a container clustering system to construct the many microservices that make up your app. Seems like running maven and deploying source code, rather than artifacts seems dangerous. Hopefully this helps!
I decided to build an application on top of OSGI and Karaf - I really like this stuff. However, I'm struggling a bit with a daily deployment on my local, development machine. I mean.. I make a change and then I would like to test it on my local Karaf instance. And it can happen like couple times per hour.
The way I'm doing it now is a maven build that creates a JAR bundle and then it's copied into the Karaf's deploy directory. I think that it isn't elegant at all.
I was trying to find a way around (google). I read about Karaf's features but it seems that despite the fact that it is a nice mechanism for deploying whole app, it doesn't solve my problem. As I understand it right, it does not check whether new version of my SNAPSHOT jar appeared in my local maven repo, right?
The key to make the update mechanism of karaf work is to deploy from maven instead of using the deploy folder.
Install you bundle like this:
install -s mvn:groupid/artifactID/version
or
install -s mvn:groupid/artifactID/version/typeOfMavenArtifact
Second one is useful for installing for example war/wab artifacts. Full maven protocol specification can be found here.
Then Karaf knows where the bundle came from. You can also check this using la -u. This makes karaf show the update location which now should be a maven uri. You will not that all karaf bundles have an update location like this.
When you now create a new build of your project using maven it will end up in you local maven repository.
Then simply run
update <bundleid>
This makes karaf check the update location (in your case you local maven repo) and reload the bundle from there.
You can even further automate this by using
dev:watch
or for karaf 3+
bundle:watch
This will make karaf check you maven repo for changes in SNAPSHOT bundles it has deployed and automatically redeploy these.
This also works very well together with the remote debugging. Use
export KARAF_DEBUG=true
before starting karaf. It then will listen for a debugger on port 5005.
You can then start a remote debug eclipse session on the same port and nicely debug your application in karaf. This works very well even if you change your bundle using one of the approaches above. So you can debug, find your problem, change the code, build and continue debugging with the changed version.
I also use this frequently when I work at the karaf code base itself as this also works for most of karaf's own bundles.
I am using the tomcat plugin to start Tomcat server using a war file i have built using the war plugin.
Before the app starts i need to set some environment variables.
Is there a way to do that?
From what I can see in the Gradle Tomcat plugin docs, the plugin runs Tomcat in the Gradle process. Environment variables for that process can only be set from outside Gradle, in a manner appropriate for your environment/OS. Alternatively, you might want to look into the Gradle Cargo and Gradle Arquillian plugins, which can also run containers in an external process.
PS: Please don't double-post here and on http://forums.gradle.org.
I'm having troubles updating my bundle from the gogo shell.
I have a gogo shell running on terminal. My bundles are active in there.
Now when I make changes to the code, what steps are necessary to forward these changes into the running OSGi framework?
I ran update <bundleId> but nothing happens. It still runs the same version which was compiled when I started the framework.
Before the update command I opened another terminal and ran mvn clean install (I'm using maven-bundle-plugin along with pax-construct).
When working with Maven, my workflow for checking updated code involves two terminals.
After updating the code, I run mvn install from the project which will build the actual bundle. Keep track of the absolute location on your system where the target bundle is built.
In the running framework, I update the bundle, giving it a URL; something like update 25 file:///Users/you/project/bundle/target/bundle.jar
If you're free not to use Maven and Pax Runner, you can also take a look at bndtools, which is an Eclipse plugin. You can then still take the bundles that bndtools builds for you, and run them with Pax Runner.
Another try is via OBR local repo as follows:
- assume artifact is called test-api, then
a)g! deploy test-api deployed under id: 25
after further changes made to the code and mvn clean install do:
1)g! update 252)g! refreshif no result then before step 1) try g! repos refresh file:///c:/Users/.m2/repository.xml to refresh local OBR repo