Deploying simple scala app(non-webapp) managed with maven - maven-2

I am new to the java/scala stack in general. So far I have a relatively simple scala application (not a webapp) setup and built build with maven2, and I'd like to be able to deploy the output to one or more production server (ubuntu on EC2, but that shouldn't matter I assume)?
My main questions are:
1) What's the best way to get all the dependent (third-party) jars installed on the production server? maven takes care of installing them on my development box, how does that work in prod?
2) I can run my app with mvn scala:run, but what's the right way to start the app in production?
3) How do I deal with subsequent deployments?
Any pointers/resources will be appreiated! Thanks a bunch in advance for helping a noob! :)

I tend to use the Maven App Assembler plugin to package dependencies, my own code, and create startup scripts. Basic use is described in the excellent Maven book from Sonatype.
For the most flexibility, it can generate Java Service Wrapper scripts, which allow the application to be run either as a command line application, a Windows Service, or a Unix Daemon.
This approach is not specific to Scala applications. You just need to know the main class of your application, e.g. sample.Main$ in the code below.
package sample
object Main {
def main(args: Array[String]) = println("hello world")
}

retronym's answer looks like the best solution but if you just want something really simple you can use the Maven assembly plugin. All you do is add it as a plugin to you pom.xml then do mvn assembly:assembly and it will build you a jar with all your dependencies (including scala lib) unjared into it. So you can then just run your application with java -cp my.jar MyMainClass.

Related

intellij hybris class recompile not working

I installed hybris plugin.
Imported project with it.
Have done ant clean all.
Then, if I try to build->recompile class it's not working. Seems like idea doesn't see classes generated by ant.
If I do build->rebuild project and then build->recompile class it's working fine, but it's not convenient at all. I believe there is fix to this, but I couldn't find it.
This is usual error I've got(packages are different for different cases):
this is essentially the expected behaviour. You can't mix "ant" build
and "native IDEA" build. Those are two separate build systems.
This is an explanation of hybris plugin developer (hybris-integration.atlassian.net/browse/IIPS-120)
And he suggests a solution for that:
before you try to import the project you need to do ant clean all (you will not need to use ant afterwards)
import the project using hybris plugin.
Press Build->Recompile project
Then you can create or modify your test run configuration if needed.
Recompile your classes and so on directly in Idea.
Also, he mentioned deal with JRebel here (hybris-integration.atlassian.net/browse/IIPS-47)
we support both compilation modes. Ant targets and idea internal. They
shouldn't be mixed as idea has it's own compilation model/cache. If
you use idea compilation then you can use JRebel or hotswap.
You cant hotswap classes in hybris without the help of a hotswap agent.There is a tool available in the market called JRebel. It is a good commercial tool if one can afford. However, if you are an open-sourcist, there is a promising alternative to JRebel, which is DCEVM (Dynamic Code Evolution Virtual Machine) along with HotswapAgent.
I don't know if this help,
you can start another cmd console, and run
setantenv and ant build to hotswap class in runtime.

Can't produce an executable jar from Spring Boot, Gradle, and IntelliJ-Idea

I have created a Spring Boot Microservice using IntelliJ-Idea and Gradle as the build engine. I have made no changes to the initial Spring Boot configuration. I also have made no modifications to the build.gradle file provided. I built the application using starter.spring.io through IntelliJ-Idea and have the following dependencies:
compile('org.springframework.boot:spring-boot-starter-data-jpa')
compile('org.springframework.boot:spring-boot-devtools')
compile('org.springframework.boot:spring-boot-starter-web')
runtime('org.postgresql:postgresql')
testCompile('org.springframework.boot:spring-boot-starter-test')
The application currently contains 12 classes and 2 interfaces and is a Web Service provider. It runs fine on my system but when I build with Gradle, the Manifest.MF contains no Main-Class entry.
I created a very simple Hello World app and tried several combinations of IDE’s and build tools(Gradle and Maven)
and got the following results:
 
 
Interestingly, I was able to produce executable jars in Eclipse which has a separate Runnable JAR Export process.
I'm fairly new to IntelliJ and Gradle. Has anyone see this behavior before? Any ideas what I might be doing wrong in IntelliJ? I have my Hello World project zipped up if anyone needs it.
I took the advise of M. Denium and I did the Gradle build from the Command Line. The jars created were formatted correctly to be executable. Everything worked like a charm. In fact the Main-Class is a Spring Boot class called org.springframework.boot.loader.JarLauncher and the main class for my app was in a property called Start-Class. The IDE totally misses this.
Looks like you will need to include spring boot plugin for gradle - org.springframework.boot:spring-boot-gradle-plugin
More details in the gradle section of the getting started guide

OSGI aware IDE at development time

I'm starting development using OSGi but when one of my concerns is about the lack of support at development time, meaning that commonly IDEs (started using Intellij IDEA) don't use OSGi for class discovery but classpath search IDE managed (I'm in search for one that uses OSGi instead).
The main concern here is to prevent classpath issues at execution time by suing the same OSGi mechanisms at development time.
Does any IDE work this way ?
update: added link to blog post with my experience with IDEA
OSGi is a runtime technology, therefore there is no such thing as an OSGi mechanism at build time. Also bear in mind that ultimately all Java code must be compiled by a Java compiler, usually javac. The javac compiler does not use package dependencies like Import-Package, it always uses JARs or directories on the classpath.
Having said that, Bndtools uses package filtering at build time, based on the exported and private packages of the dependencies. This is a special feature of Eclipse and it does not work when you compile outside of the IDE, e.g. with Ant or Maven. However it may still be useful because if you try to use a non-exported package from another bundle you will get a problem marker with a red X in the Eclipse IDE.

To use ServiceMix my project has to be an OSGi bundle?

I' starting to use ServiceMix and Camel and I've run through many examples.
It seems that the examples that are OSGi can be deployed in ServiceMix via hot deploy or via console, but I don't know how to deploy a project that is not an OSGI. Can it be done?
For example, I'm looking at the example project from Camel 2.10.0 called camel-example-cxf-proxy. I did some alterations and now I wanted to load it in ServiceMix. If I copy/paste to the deploy directory it is loaded but when I try to run it via osgi:start id it fails.
However if I run it from the IDE as a standalone it runs just fine and I can send and receive requests via SoapUI.
When I'm done with the examples I'll want to create my own project in eclipse and do tests in the IDE and in ServiceMix. I don't really understand the advantage of OSGi yet. SO I'm not too compelled to use OSGi for my project.
My main question is: Can I deploy a non-OSGi non-JBI compliant project in servicemix? Something like the camel-example-cxf-proxy. If yes, how can I do it? If no, how can I OSGi-fy the camel-example-cxf-proxy?
Thank you :)
Apache ServiceMix which uses Apache Karaf as its kernel, support pluggable deployment units. Though OSGi is the main unit.
You can deploy JBI artifacts (eg JBI was used as deployment units for Apache ServiceMix 3.x). So we offer that as a migration path to run JBI in SMX 4.x.
A plain WAR file can be deployed as well. You can for example just drop a .war file in the deploy directory. If you deploy from the shell, you need to prefix the deployer with war so it knows to use the war deployer.
There is some documentation about the various pluggable deployers here
http://fusesource.com/docs/esbent/7.0/esb_deploy_osgi/UrlHandlers.html
For example to install an Apache Wicket WAR example using Maven you can do from the shell:
osgi:install war:mvn:org.apache.wicket/wicket-examples/1.4.7/war?Web-ContextPath=wicket
The Apache documentation about deployer is mainly documented at Apache Karaf
http://karaf.apache.org/manual/2.2.9/users-guide/deployer.html
Now to deploy OSGi applications can be a bit of pain to assemble. And that is why FuseSource created FAB to make it much easier. I blogged about this a bit, which references to videos and more material: http://www.davsclaus.com/2012/08/osgi-deployment-made-easy-with-fab.html
With FAB you can just deploy regular Maven projects out of the box without any OSGi pain.
If your project is a maven project, you can try :
mvn install
Then start your servicemix, and in servicemix command line :
install mvn:groupId/artifactId/version
This will prompt a bundle ID. Then, juste start the bundle :
start <bundle_id>
You can check the state of your bundle with command "list"
The project has to be a bundle to be installed in servicemix / karaf. So the steps to make a camel project work in OSGi are the following.
Use the maven bundle plugin in the pom and configure it to import / export the necessary packages if necessary.
Make sure your camel context is defined in a way that OSGi can start. This is either in the activator of the bundle or in a spring config in the right location or with a blueprint config in the right location.
See two of my karaf tutorials for the details:
CXF: http://www.liquid-reality.de/x/EoBk
Camel: http://www.liquid-reality.de/x/G4Bk

Play framework 2.0 continuous integration setup

I am looking for ideas for a Play 2.0 continuous integration setup. It would contain typical jobs like build after a git push, nightly builds with deployment to a test Heroku instance etc. Also code quality and test coverage metrics generation would be handy.
At the moment the stack looks like Play 2.0 with Java but that might change to Scala.
For "traditional" Java web app I would use Hudson/Jenkins. I found a Hudson plugin for Play but it doesn't seem to support Play 2.0. Is Hudson suitable tool here in general or what is your setup for Play 2.0 applications?
Play 2.0's build tool is just a thin wrapper around SBT. You should be able to use Hudson's sbt plugin to execute SBT build commands that are the equivalent of the Play commands you would execute from the console.
We execute the following under Bamboo for our builds:
SBT_OPTS="-Dsbt.log.noformat=true"
sbt clean compile test
(The SBT_OPTS variable turns off the colour formatting, making test output legible in log files.)
I found useful to add JUnit reporting plugin as I couldn't get test results to be displayed otherwise.
https://github.com/bseibel/sbt-simple-junit-xml-reporter-plugin
For PMD and Checkstyle I used this:
https://github.com/ymasory/sbt-code-quality.g8
For test coverage I am using JaCoCo at the moment:
http://ronalleva.com/2012/04/25/jacoco-and-play.html
Scct could be other option for coverage: http://mtkopone.github.com/scct/
With those and PMD, CheckStyle and JaCoCo plugins for Jenkins I have now quite ok setup for a Play 2 Java project.
here Is some detailed tutorial about doing It
http://wiki.cloudbees.com/bin/view/DEV/Playframework
It based on cloudbees but it would work fro any Jenkins Installation
You actually don't even need to use the SBT Plugin. I am running Play 2.1.1 on Jenkins and simply use the Execute Shell. I run something like the following:
cd ./your-play-project-root
play clean compile test stage
exit
This works quite well. "play" is simply just a thin wrapper around sbt.
"stage" will create a runnable in your target/server directory. Then, you can simply shell again to actually start your play application!