Here are my goals:
1. Run my tests in Eclipse and see the pretty green or red bar.
2. Run my tests on the command line with a build tool.
I'm leaning towards specs and sbt, but I can't get them to work. I have no desire to pick up Maven. My question is which one of the follow sets works best?
sbt and scalatest
sbt and specs
ant and scalatest
ant and specs
something else?
A consideration is how much effort do other people need to get the project up and running on a new machine. Bonus points if it can integrate with Hudson.
SBT is definitely the way to go over ant. Ant will not give you congruency with maven project structures and would force you to roll your own dependency management.
Either scalatest or specs will work. The former seems to be a de facto, but I get excellent results with specs.
I am not an Eclipse user, but would be surprised if either test library was not supported.
I'm currently switching the specs project to sbt and fixing a few things with Mark Harrah (check out the sbt mailing list for the details).
Please post any issues you may have with specs and sbt and I'll try to fix them ASAP.
Thanks,
Eric.
Related
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!
I have been looking into Gradle and looks pretty interesting. I think being able to write your scripts in any other language than XML is pretty cool, and it is not clear to me whether polyglot Maven POM files are still a feasible option.
I am working on a project that uses Maven 2.2.1 as build tool. This project:
is multi-module
uses (also our own) plugins
relies on an Artifactory proxy repository
Are there any experiences out there on migrations from Maven to Gradle? Gotchas, pain points, corner cases? Any sort of experience is very welcome.
The migration from Maven to Gradle isn't as easy as from Ant to Maven (at the least at the moment). You can easily reuse Ant scripts and make them first class citizens in your Gradle build. There's a task on the Gradle roadmap for deep import of Maven builds as well.
So far I migrated two enterprise Maven builds to Gradle. Both of them were multi-module projects using standard Maven plugins. I basically rewrote the builds the Gradle way which requires at least some knowledge about Gradle. Based on my experience you can easily get the same build running in Gradle as well. Gradle doesn't really box you in here and is fairly flexible. Along the way you might find yourself having to write a custom plugin that doesn't exist yet depending on what Maven plugins you are using. However, there's already a wide breath of plugins out there. So far I haven't run into a real roadblock yet. Even though the Gradle documentation is pretty good you might find yourself reading a lot of Gradle forum posts to find the solution to one of your problems. Some of the standard Maven features are not supported out-of-the-box e.g. a provided scope or WAR inplace. However, there're easy ways around it. I haven't used Artifactory repositories. The ones I dealt with were Nexus repositories. As far as I know the Gradle guys have good support for Artifactory though. Edit: JFrog provides a Artifactory Gradle plugin.
A good way to start is to use the migration tool Maven2Gradle which let's you generate a Gradle script from your Maven build. Personally, I didn't use it yet. I developed the Gradle build side-by-side with the Maven build which didn't cause any trouble. Maven put its
output under target, Gradle under build. Make sure you prepare your team for the change. Let them try out the Gradle build and get familiar with the tool.
Once you are fully migrated you'll be very happy about the maintainability and extensibility of your build. It's very easy to add custom build logic and you're going to be grateful that you left XML-land. In terms of performance you are not going to make a step back as well. The incremental build feature does its job very well.
You may also want to read through this write-up of my experience porting a maven project to gradle.
In the directory where you have pom.xml just run the below command:
gradle init --type pom
This should convert your maven pom.xml to build.gradle
You can always change the buildDir to be 'target' under gradle if you want the build output to go under 'target' instead of 'build' like maven:
buildDir = 'target'
maven2Gradle seems to have been replaced with being able to run gradle init from the command line (though it's a rather experimental feature). It seems to work ok for doing some basic Gradle setup from a Maven project.
The past week or two I've been studying Maven, and I like it, but there are just a few things that I require Ant tasks for, rather than Maven's complicated and scarcely-documented POM file. However, I believe Maven has a great folder structure going for it, and I like that it natively supports tests, packages the project into a jar by default, and supports a 'resources' folder, from which everything is directly copied into the jar file.
Is there a sample Ant project out there that does the same sort of thing but with an Ant build.xml script? I want the placeholder folders and hello world app and test, just like Maven does when you first create a project from its default archetype:create goal (as demonstrated in the Maven in 5 Minutes page). Or, is there an even better Ant sample project out there that does more or suggests a better folder layout?
If no such thing exists, perhaps someone can help create it in a nice detailed answer? I would be willing to host a permanently-available zip file for anyone who finds this question in the future.
mvn archetype:create
mvn ant:ant
http://maven.apache.org/plugins/maven-ant-plugin/usage.html
... but if there are really "just a few things", you may want to check out the AntRun plugin instead. I'm not trying to sell you on Maven, believe me, but since it's not clear exactly what is stopping you from trying it with your project, I guess I'm suggesting you try to push the issue a little harder.
Refer this: Why you should use the Maven Ant Tasks instead of Maven or Ivy
I also wouldn't recommend Ivy, reasons at the link above.
Quoting the Maven - Frequently Asked Technical Questions and more precisely:
How can I use Maven features in an Ant build?
The Maven Ant Tasks allow many of the
features of Maven, such as dependency
management and repository deployment,
to be used in an Ant build.
Refer to the installation page and the usage page for instructions for installing and using the Maven Ant Tasks respectively. You'll find many links to samples in the usage page and a build.xml showing most of the features in action.
An alternative (direct competitor?) to Maven Ant Tasks would be Apache Ivy.
PS: While it's definitely a good idea to adopt maven standards, even partially, I'd really think about it twice before to drop Maven (but I live in the Maven jungle for a while now - and I like it - so I'm biased).
I am experimenting with Groovy Griffon development and I am wondering what IDE to use.
I am trying to use NetBeans 6.5, and I found this post
https://blogs.oracle.com/geertjan/entry/notes_on_converting_netbeans_grails
essentially it describes forking the NetBeans trunk and hacking the Grails support; I was hoping for something more lightweight.
Are there any simple tools to create eclipse, netbeans or pom.xml's from Griffin Apps?
Or is it best to use a simple text editor?
There is a NetBeans Griffon plugin already available at http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=18664
Griffon apps have some rudimentry hooks already for IDE integration.
First, a .classpath and .project file are generated that mark the expected source and test directories for Eclipse. Both IntelliJ and NetBeans have importers for these eclipse files (and they work, I use them regularly).
Second, Griffon 0.1.1 adds more targets to the parallel build.xml so that more of the common scripts can be used as though they were ant tasks (run-app, compile, debug-app, etc.)
Third, there is some better IDE support in the works form some of the IDE vendors. As mentioned in the article you linked because Griffon is grails derived it is fairly easy to re-purpose existing Grails support. IntelliJ has the only specific tracked feature request I am aware of.
IntelliJ Idea has very good Griffon support.
This question usually comes with a next question:
How to debug Griffon?
Just in case someone still requires a helping hand trying to figure out how to debug Griffon in Eclipse/STS I've written a simple step by step guide to get it done:
http://ivo43.blogspot.com/2012/02/debugging-griffon-in-eclipsests.html
Hope it helps someone someday, :D
PD: I've tried Netbeans and even though it looks great am still with STS, call me a maniac!
My company starts a new project next week. We have planned to develop the application with eclipse rcp. The build process should be fully automated, so we're prepared to set up a continuous integration environment (e.g. Continuum). For the build-automation-part I intended to use maven2, because I want use its dependency management.
I have used maven2 for a small old-style java project, but have never set up maven for using it with eclipse rcp.
What's the best way to do this? Basic concepts? Common traps? Are any tutorials or book's around there? The tutorials and informations I found, seemed outdated or incomplete.
PS: The main project will be divided into sub-project's (plug-in's). But I think this is typical for eclipse rcp projects.
You should take a look at Tycho:
the-future-of-maven-osgi-join-the-tycho-users-mailing-list
the-next-generation-of-build-tools-for-eclipse-plugins-and-rcp-applications
Like most Maven questions, this is solved by a link to a plug-in:
"pde-maven-plugin"
Other advice:
use the assembly plug-in to build
the update site
consider using hudson rather than
Continuum
I've been battling maven2/Eclipse RCP integration for some time. The key is not so much getting your setup right: You can get it to work - eventually - by reverse-engineering Eclipse's build process in maven.
In my experience, the hard part is keeping everything up to date. Every time Eclipse revs their libs, you'll find yourself re-writing a bunch of pom files for that newest RCP widget or SWT lib. Naturally, CI helps with this somewhat. The problem is that Eclipse and maven are very particular about the way they do the business of building, and their approaches are quite different. To make matters worse, PDE dev (and Eclipse dev, more generally) is powered by a lot of wizard code, which is sometimes quite opaque as to what's happening behind the scenes.
The question you really need to ask yourself is if it's worth the effort. In my particular case, I believe it has been. (CI is too good to live without.) But the trade-off is that you may find yourself being the "build guy", which can take valuable time away from actual development, which is probably what you enjoy most.
I've got recently the same problem : build eclipse RCP application through continuous integration.
I haven't applied them yet but I've found some interesting articles :
Here's the documentation for Tycho
Building Eclipse Plugins with Maven 2 on eclipse.org
Build Eclipse RCP products using Maven 2 - how hard can it be? from Immo Hüneke's blog
Here's an article about PDE build automation
Here's a shell script to automate JUnit test launch