I have to say that I’m really impressed with Tycho. Before this experience, Maven was the “bad thing that downloads the internet” to me. Okay, it still downloads the internet but in this case it’s very useful. You can add p2 repositories to resolve dependencies and it automatically downloads the right bundles. You can define the dependencies in your MANIFEST.MF and use the pom.xml to describe what kind of package it is, e.g. a feature or bundle. For building the RAP application, I just had to add the Helios p2 repository to solve all my feature’s dependencies.

Now, you might want to know how to build the application with Tycho yourself. I published the code on github [1]. It’s just the example Mail application and a sample feature that can be built with Tycho. Follow the README instructions to run the build. Here are a few notes you might need if you want to use this configuration as a template for your own build:

1. Edit the feature.xml from com.eclipsesource.maildemo.tycho.feature, adding your dependencies.
2. The build uses a static configuration.ini. As a result, you have to edit the configuration manually and add your own bundles. You will find the configuration.ini in the com.eclipsesource.maildemo.tycho.feature feature in the templates/WEB-INF/eclipse/configuration folder.
3. Create a pom.xml for every bundle you created with the following content:

   <?xml version="1.0" encoding="UTF-8"?>
   <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <modelVersion>4.0.0</modelVersion>
     <parent>
       <artifactId>maildemo</artifactId>
       <groupId>com.eclipsesource</groupId>
       <version>0.0.1-SNAPSHOT</version>
     </parent>
     <groupId>com.eclipsesource</groupId>
     <artifactId>com.eclipsesource.maildemo.tycho</artifactId>
     <version>1.0.0-SNAPSHOT</version>
     <packaging>eclipse-plugin</packaging>
   </project>

4. Change the artifactId from com.eclipsesource.maildemo.tycho to your own Id.  You’ll also need to change the parentId when you use your own Id.
5. Edit the pom.xml in the parent folder and add your modules. To add modules you just need to add the folder names from the different bundles to the file.
6. In the pom.xml of the feature, change the naming of the “maildemo” to create a .war file with the name of your choice.
7. Of course you can use your own groupIds and artifactIds. But, you have to reference the parent pom.xml artifactId in every bundle’s pom.xml

I hope these steps and the example build will help you to create your own Tycho based builds for RAP applications. Maybe you have some experiences or ideas you’d like to share?  Please feel free to post comments.

[1] https://github.com/hstaudacher/org.eclipse.rap.build.examples

Here is the full list of the proposals that got accepted for 2010.
Improve Eclipse Git integration
Student: Dariusz Luksza
Mentor(s): Matthias Sohn

WAR deployment for RAP/Equinox based applications
Student: Holger Staudacher
Mentor(s): Ruediger Herrmann

Theme editor for RAP
Student: Benjamin Muskalla (IRC: benny`work)
Mentor(s): Ruediger Herrmann

Rich Editor For Wiki Markup
Student: Harshana Eranga Martin
Mentor(s): David Green

index based model compare match engine
Student: Stefan Leopold
Mentor(s): Cedric Brun

Restlet integration with Equinox
Student: Rajeev Sampath
Mentor(s): Bryan Hunt

C++ editor enhancements
Student: Tomasz Wesolowski
Mentor(s): Alena Laskavaia

DNS-SD based wide-area ECF discovery provider
Student: Markus Alexander Kuppe (IRC: lemmy)
Mentor(s): Scott Lewis

Hudson Integration for Mylyn
Student: Markus Knittig
Mentor(s): Steffen Pingel

Google Wave ECF provider
Student: Sebastian Schmidt (IRC: sebs)
Mentor(s): Mustafa Isik

Integrate GMF runtime with Mylyn task focused UI
Student: Yongming Luo
Mentor(s): Mariot Chauvin

Congratulations to all the students and a big kudos to the organizers and mentors for their choice. As every year, it is pretty difficult to dismiss so many other good proposals but there were only 11 slots available this year for Eclipse. Looking forward to a great summer!

What I wanted to with jetty was to create an executable, standalone and self-contained WAR. I first encountered this concept in Hudson. The hudson.war contains an embedded Winstone servlet container, which makes it possible to run the application by executing

java -jar hudson.war

This makes test driving the application really simple. The idea was to do the same with Jetty. Embedding the Jetty runtime in the war proved to be the easy part, as it was just a matter of declaring the jetty dependencies in the maven pom.xml.

The tricky part was telling jetty where to find the war-file to serve. My first try was to hardcode the filename, but that left a foul aftertaste. Finding a solution took quite some time, which is why I am posting this for future reference. This is the Main-Class used to bootstrap Jetty (adapted from the Wicket quickstart archetype):

import org.mortbay.jetty.Connector;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.bio.SocketConnector;
import org.mortbay.jetty.webapp.WebAppContext;
 
public class Start {
 
  public static void main(String[] args) throws Exception {
    Server server = new Server();
    SocketConnector connector = new SocketConnector();
 
    // Set some timeout options to make debugging easier.
    connector.setMaxIdleTime(1000 * 60 * 60);
    connector.setSoLingerTime(-1);
    connector.setPort(8080);
    server.setConnectors(new Connector[] { connector });
 
    WebAppContext context = new WebAppContext();
    context.setServer(server);
    context.setContextPath("/");
 
    ProtectionDomain protectionDomain = Start.class.getProtectionDomain();
    URL location = protectionDomain.getCodeSource().getLocation();
    context.setWar(location.toExternalForm());
 
    server.addHandler(context);
    try {
      server.start();
      System.in.read();
      server.stop();
      server.join();
    } catch (Exception e) {
      e.printStackTrace();
      System.exit(100);
    }
  }
}

The interesting bit is the getProtectionDomain()/getCodeSource() part, which tells us the location of the war-file. That’s all there is to it. Presto, executable web-application powered by Jetty in jar.

Edit: Added the import statements as per Tim’s suggestion.

And lo and behold, there’s not one but two eclipse projects for integrating maven. One is the IAM project (formerly known as Q4E) and the second is m2eclipse. In that regard it’s a bit like subversive/subclipse but hopefully without all that licensing nonsense. But it is usually  good to have some choice – and competition of course. To get a clearer picture I decided to give both plugins a try.

IAM

I started with IAM. Setting up my sample project was a snap, and the maven integration immediately started downloading dependencies and adding them to the project classpath. Maven repositories can also hold source jars, making development and debugging much easier. The pom editor seems to cover all options and is looking quite solid. I was more interested in the core feature set, so I didn’t check out any advanced options.

m2eclipse

Next up I tested m2eclipse, which offers basically the same core feature set. Dependencies are automatically downloaded and added to the project classpath. The pom editor covered the same functionality as IAM’s, but I personally liked the the looks and layout better in m2eclipse. One really nice feature is code completion for dependencies.

Code completion - rocks!

I know I am spoiled eclipse developer, and I expect my IDE to finish my thoughts for me. But it gets even better: There is also a quickfix (Ctrl+1) for unresolved imports. Talk about convenience!

Quickfix to the rescue!

It’s good to see that there at least two very viable options when it comes to developing maven  projects in eclipse. Kudos to both the IAM and the m2eclipse team for the fantastic work.

The Price of Modularity

To me, one of the greatest strengths of the Java Platform has been its rich ecosystem. There are so many java libraries and frameworks out there, that when developing for the Java platform you almost never have to start from scratch. Most of the time it’s finding the right libraries, writing a little adapter code and the core business logic. No need for reinventing wheels. This truly is modular and reusable software development, and one of the main reasons why the Java platform is so competitive.

But this modularity does come at a price known as dependency hell. Any non-trivial project has a dozens of dependencies. Even your basic run-of-the mill webapp requires a web framework, logging, OR mapper, JDBC drivers, etc. Add in all the indirect dependencies and you are looking at quite a lot of libraries. This is why strong dependency management is such a compelling argument for build systems like maven.

But there is another issue apart from painfully assembled builds: Jumpstarting new developers. Especially for open source projects it is quite a turnoff for a potential contributor to look at the long list of requirements and dependencies needed to get to the point where the code even compiles cleanly. This is where strong dependency management comes to the rescue. Sure, maven may download two and a half internets on the first compile, but when its done you have everything ready to start working.

“apt-get for Java”

Due to popularity and pervasiveness of maven, there are plugins for integrating almost all imaginable build tools. For most of projects maven provides everything needed right out of the box: unni testing, coverage, javadoc, pmd, you name it. Combined with hudson this makes it ridiculously easy to get a continuous integration server running literally within minutes.

It is good to see that automatic dependency management is making such inroads in different areas of computing. Apt-get and maven, and even p2 have helped a lot to make the dependency hell a little more bearable.