Besides all the Java code in the RAP project, we also have more than 250 JavaScript files which total up to 75k lines of code. For such an amount of code, you should have some kind of code analysis that detects common coding problems like unintentional global variables. We use the JSEclipse plug-in for JavaScript editing which detects some, but not many JavaScript problems.

A while ago, we’ve tried to use JSLint, a tool written by JavaScript guru Douglas Crockford. Unfortunately, this tools produces several thousand warnings on our code base, many of them were not really problems but debatable coding style issues and there was no way to turn them off. JSLint’s lack of customizability recently lead to a fork named JSHint that is going to provide more flexible configuration options.

Like JSLint, JSHint is written in JavaScript, but can be run on the command line using tools like Rhino or JavaScriptCore. I tried JSHint on our codebase with good results using a shell script that runs it on top of Rhino. Unfortunately, checking all our 250+ *.js files keeps my machine busy for 5 minutes and 40 seconds and effectively turns it into a fan heater. This is not because JSHint itself is so demanding, but because for every file, a JVM has to be started, Rhino has to be loaded, then Rhino has to parse and load the JSHint JavaScript library, and then finally, jshint can parse and validate the source file.

Encouraged by the good results I tried to find a solution that doesn’t have this overhead. And as an Eclipse hacker and user, I certainly wanted to integrate the tool into my daily working environment. The result is a simple, yet efficient JSHint Eclipse integration that validates the same bunch of *.js files in less than 15 seconds.

This speedup could be achieved by exploiting the way Eclipse builds projects: It uses the same builder instance to visit all files of the project recursively. That makes it possible to load and configure the JSHint library only once for the entire project and reuse it for all files being checked. Of course, validating all files of a project is only necessary for a full rebuild. During normal work, single files are being validated instantly when they have changed.

Although the configuration options are still somewhat basic, this integration proved to be very helpful already. I thought that it may be useful for others as well and decided to build and publish a first version. It’s available on the jshint-eclipse page. There’s an update site that let’s you install the plug-in right into your Eclipse IDE. If you find the plug-in useful, have ideas for improvements, find a problem or want to contribute, I’m happy to hear about it. To report problems, please use the github issue tracker.

Tags: eclipse, javascript

In a recent blog post Peter Kriens commented that the OSGi service model is as important as object-orientation. I feel the same – I don’t want to write software without this concept anymore. But for me, the service model only makes sense when it’s used together with the modularity OSGi provides. I think the modularisation layer is the greatest advantage of the OSGi platform and the services are really only there to simplify the communication between modules.

When it comes to developing a REST API with Java, this advantage is missing in most of today’s libraries (e.g. Restlet or Jersey), because the Java language still lacks modularity. But especially for the design of a REST API this concept can be a great benefit, because it overcomes the limitation of only being able to separate REST services by url and Java packages. With modularity the service implementations can be separated into modules which improves the maintainability and the beauty of the whole system a lot.

A few months ago I discovered JAX-RS for developing REST services. (Before that I used Restlet.) I have to say that the JAX-RS API makes it really easy to develop REST services. See this article for a how-to. A reference implementation of this API is Jersey. The cool thing about this implementation is that it plays really well together with the OSGi HttpService and it ships as bundles. In this way we have the option to actively deploy REST services into the HttpService. But is this how we want to publish REST services? To me, it’s not!

In my ideal world I would write my @Path annotated Pojos and publish them as OSGi services. That’s it. The runtime should take care of publishing and service wiring. Sadly, Jersey has no built-in feature for that. This is the reason I wrote a little OSGi-JAX-RS connector. The only thing the connector does is that it publishes OSGi services as REST services using JAX-RS. Of course, there are OSGi remote services, but using them does not allow the use of JAX-RS the way I’d prefer, namely as a lightweight additional bundle.

You can find the connector in GitHub. To make it work simply install it into your OSGi instance by using this jar. (You’ll also find a p2 repository there). That’s it. The only thing you have to take care of is writing the REST services like the one in this example.

@Path( "/osgi-jax-rs" )
public class ExampleService {
 
  @GET
  public String seyHello() {
    return "JAX-RS and OSGi are a lovely couple.";
  }
}

The activator can then look like this:

public class Activator implements BundleActivator {
 
  private ServiceRegistration<?> registration;
 
  @Override
  public void start( BundleContext context ) throws Exception {
    ExampleService exampleService = new ExampleService();
    registration = context.registerService( ExampleService.class.getName(), exampleService, null );
  }
 
  @Override
  public void stop( BundleContext context ) throws Exception {
    registration.unregister();
  }
}

Further instructions can be found in the README of the git repository. It also contains two examples for using this connector with and without declarative services. In the second part of this blog series I will show you how to configure the services using the OSGi Configuration Admin Service and publish services on different ports within the same OSGi instance. I hope you enjoy this connector as much as I do.

Tags: jax-rs, jersey, OSGi, rest, restlet

As you might know from previous posts, most of my work time has something to do with the development of REST based systems. The systems we develop are mostly written in Java. To ensure that a system works, we have a step in our continuous integration process that executes integration tests before automated deployment is launched. With this short post I’d like to show you our setup for these integration tests because when I searched a few months ago the results were rare.

We write integration tests for REST systems with JUnit and restfuse. Check this post for a how-to on restfuse. Thanks to the Maven surefire plugin we can simply execute these tests in our maven build. Here is the build and dependency section of the test module’s pom.

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.9</version>
      <executions>
        <execution>
          <id>test</id>
          <phase>test</phase>
          <configuration>
            <testClassesDirectory>${project.build.outputDirectory}</testClassesDirectory>
          </configuration>
          <goals>
            <goal>test</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
</build>
 
<dependencies>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.1</version>
    <scope>test</scope>
  </dependency>  
  <dependency>
    <groupId>com.restfuse</groupId>
    <artifactId>com.eclipsesource.restfuse</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

Most of our Java-REST applications ship as war files.  So, at this stage the question becomes, “How can I test the war file I just built?” One answer is to hot deploy the war file and run the tests against it. But, for a hot deployment we need a server running tomcat (or another servlet container), right? Actually, we don’t . We can simply embed a Jetty plugin into our maven build, start it and deploy our war file using the Maven Jetty plugin. The related section in the pom looks like this:

<build>
  <plugins>
    ...
    <plugin>
      <groupId>org.mortbay.jetty</groupId>
      <artifactId>maven-jetty-plugin</artifactId>
      <version>${jetty-version}</version>
      <configuration>
        <scanIntervalSeconds>10</scanIntervalSeconds>
        <stopKey>foo</stopKey>
        <stopPort>9090</stopPort>
        <contextPath>/</contextPath>
        <tmpDirectory>/tmp/work/</tmpDirectory>
        <webApp>/tmp/test.war</webApp>
        <daemon>true</daemon>
        <reload>manual</reload>
      </configuration>
      <executions>
        <execution>
          <id>start-jetty</id>
          <phase>test-compile</phase>
          <goals>
            <goal>deploy-war</goal>
          </goals>
        </execution>
        <execution>
          <id>stop-jetty</id>
          <phase>verify</phase>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>  
    ...    
  </plugins>
</build>

It is important that we deploy the war file before the actual test phase, in our example, during test-compile. To make this work we need to copy the new war file into the configured directory before we run the maven build. This can be accomplished with a simple shell script.  The following snippet shows how it looked for our jenkins job:

rm -rf /tmp/work
mkdir /tmp/work
cp $WORKSPACE/../job/**/*.war /tmp/test.war

A few last points.  In our setup we split the integration test build from the main build but you can merge them together as well. And, when using restfuse an important thing to keep in mind is that you need to configure the port to be the same as the one jetty uses to run the tests.

That’s it – short but efficient. Maybe you have a similar approach to share in a comment with us?

Tags: continuous integration, jetty, maven, rest, restfuse

Ed and I are organizing the Modeling Symposium for EclipseCon North America. It is scheduled for the first day of the conference, i.e., Monday, March 23rd at 1pm. The symposium aims to provide a forum for community members to present a brief overview of their work. We offer 10 minute lightning slots (including questions) to facilitate a broad range of speakers. The primary goal is to introduce interesting, new technological features. This targets mainly projects which are otherwise not represented at the conference. Additionally we offer a number of 1 minute “teaser slots” (no slides, no questions) for advertising other conference sessions.

If you are interested in giving a talk, please send a short description (a few sentences) to jhelming@eclipsesource.com. Depending on the number, we might have to select among the submissions. Please adhere to the following guidelines:

• Topics presented in other sessions during the conference should only be proposed as teasers.
• Please provide sufficient context. Talks should start with a concise overview of what the presenter plans to demonstrate, or what a certain framework offers.  Even more important, explain how and why this is relevant.
• Do not bore us! Get to the point quickly.  You do not have to use all your allocation. An interesting 3 minute talk will have a bigger impact than a boring 10 minute talk. We encourage you to plan for a 5 minute talk, leaving room for 5 minutes of discussion.
• Keep it short and sweet, focus on the most important aspects. A conference offers the major advantage of getting in contact with people who are interested in your work. So consider the talk more as a teaser to prompt follow-up conversations than a forum to demonstrate or discuss technical details in depth.
• A demo is worth a thousand slides. We prefer to see how your stuff works rather than be told about how it works with illustrative slides.  Please restrict the slides to  summarize your introduction or conclusion.

Looking forward to your submissions!
Jonas

Many Eclipse committers have been hard at work on the Eclipse Juno (2012) release. There are already many new features including a whole new workbench model.  While this is obviously an exciting time in the history of Eclipse, many of the long time IBM committers have been focusing on future — Eclipse Orion.  Eclipse Orion is a web-based tooling platform. While I’m personally not involved in this project for my day-to-day work, I’ve been exploring the possibilities it exposes. To help you get started with Orion, I thought I would share my experiences.  In this article I’ll show you how to use Orion to develop a simple web application. In future articles I’ll explain how to create both client and server side plugins, as well as how to host your own Orion server.

Why Orion?

Before we can answer this, let’s look back 10 years.  A decade ago Eclipse had just shipped 1.0.  While many people saw Eclipse as a great Java IDE (which it is), Eclipse was also a universal tool platform.  Eventually Eclipse became a platform for Everything and Nothing In Particular, but in December 2001 it was a general purpose platform for development environments with Java Development as one such exemplary tool (C/C++ development was added shortly afterwards).  Many people attributed the success and quality of Eclipse to the fact that the developers used Eclipse for their day-to-day work, a concept known as eating your own dogfood. This model ensured that the quality of Eclipse remained high since any regressions would immediately be seen.

Fast-forward 10 years and we are starting to see many software tools moving to the web. Services such as GitHub, CloudBees, Cloudant, YouTrack, etc… reduce your IT overhead by moving many of your tools to 3rd party service providers, accessible via the web. Also, many of our applications are exposing web-based front ends and developers are relying on tools such as FireBug and other browser extensions.  Since most ‘coding’ still takes place on the desktop using tools like Eclipse or TextPad, developers are no longer using the tools they develop.

Eclipse Orion intends to change this.  Eclipse Orion is positioning itself as a Tooling Platform for the Web, on the Web.  If you’re currently building Web-Based software, then Orion will be of interest to you.

Is Orion Replacing Eclipse?

The aim of Orion is not to replace Eclipse.  Orion provides another tooling platform — this time for the web.  Not everyone is doing web development and not everyone wants their tools on the web.  However, if you are spending more of your time in a browser, Orion might be of interest.

Also, Orion is an entirely new code-base. This is not Eclipse running in a browser.

Getting Started

The easiest way to get started with Orion is to look at OrionHub.  OrionHub (http://orionhub.org) is a public beta server of Orion.  Anyone can request an account, but keep in mind that the workspaces are cleaned occasionally so there is no  guarantee that your data will be persisted.

1. Request an Account

Go to http://eclipse.org/orion to request an account.

2. Login to OrionHub

Go to http://orionhub.org and login. Once you’ve logged in, you can access you profile and associate other accounts if you wish.

3. Create your first project

There are a few helpful links across the top of the page. To create you first project, select the navigator and choose New Folder. You can also clone a project from a remote git repository if you choose.

4. Upload an existing project

Initializr allows you to create a bare-bones HTML 5 site, and download it as a zip file. This means you can get started on a new fancy web project without all the boilerplate setup.  I decided to download a bare-bone site from JavaScript InfoVis Toolkit for my example since I was interested in creating a graph based visualization. Using Orion, you can upload this zip file and start working immediately.

This this is on the web, you can review my code as I work:

http://orionhub.org/edit/edit.html#/file/ST/Jit/Examples/ForceDirected/example1.html

5. Launch a site

To test / debug your web application as you develop it, Orion allows you to launch a site containing the newly developed project. You can develop in one browser tab, and test (and debug) in another one. This paradigm means that all your tools are in one place.  To launch a site, choose the ‘Sites‘ link and Create Site.

You can map your project to this site.  In my case, I created a site called irbullvisualization. Feel free to access it at:
http://irbullvisualization.orionhub.org:8080/Jit/Examples/ForceDirected/example1.html

6. Share your project

By default, a Git repository is created for all projects on OrionHub.  Of course, this is just a local git repository (local to OrionHub), but you can easily add new remote references and push your projects around. You can commit changes using the Git Status Page:

And push your changes to remote hosts using the Repositories View:

Conclusion

The Eclipse Orion project is still in its infancy. Unlike the Eclipse project — which was opened sourced at the same time as its 1.0 release, the Orion project is still in its pre 1.0 stage. However, you can get involved with the project, tryout the beta at OrionHub.org or download your own Orion Server.

In my next article I’ll talk about Orion Plug-ins.

Tags: orion

In the RAP framework, the widgets in a website are remotely controlled by the web server. The server does this by sending messages to the client in response to Ajax requests. Until now, those messages used to contain proprietary JavaScript that has been evaluated by the browser. Apart from the drawbacks of using eval to process server responses, this tightly couples RAP to its default browser client. The messages were so specific that only this client could understand them.

One of our goals for RAP 1.5 is to open the framework for alternative client implementations. After all, the messages from the server contain precise rendering commands that are not at all specific to JavaScript. Commands like “create a button with text ‘Ok‘, set its size to 190x25px, and place it at pos (23,42)” or “change the text color of the label with id ‘w47‘ to ‘#ff0000‘” can be rendered by any client that is able to create and manipulate widgets. It doesn’t have to be a JavaScript client, also clients written in other languages like Java or Objective C can implement it. Clients can render widgets with any UI technology, be it SVG or even a mobile device’s native widget set.

To allow for those cases, we exchanged the communication format with a simple predefined format based on JSON. With the M4 build published today, all responses from a RAP server are now plain JSON. This also makes the debugging much easier, since developer tools like Firebug display the structure of a message.

When designing the protocol, we took great care not to limit the exchange format to widgets. Instead, we created a generic synchronization protocol for any kind of objects. Objects are identified with a unique id, and every operation is related to a target object that is referenced by its unique id. There are different types of operations: one to create an object, one to destroy it, one to change some properties on an object, etc. Every message from the server contains a list of operations, besides some meta information.

You’ve guessed that we already have some prototypes for alternative RAP clients in progress. We’ll write about them soon…

Tags: eclipse, juno, new and noteworthy, protocol, rap

There have been a discussion about build naming conventions lately.  SNAPSHOTS, nightly, milestone, GA, maintenance, integration, stable, etc…

In both Nick’s and Mickael’s posts, I noticed a theme: all builds are the same. Of course when they are built, or the process by which the built artifacts are vetted may change, but the build process is the same for all build types: namely, take what’s in HEAD/Master/Trunk/Tip/Top/Main Branch, tag it and build it.

This isn’t the case for the Eclipse project. The Nightly builds are actually done differently from the integration, milestone, stable, and maintenance builds.

The build processes that Nick and Michael mentioned, assume that once something is in Master/Head, it’s ready to be released and the only other variable is release date.  The Eclipse process doesn’t assume this.  In fact, I can release a wad of changes the night before Juno ships and likely none of them will be in build.  This is because Eclipse requires explicit tagging of what you want built.

Here is how it works:

1. Development teams continually release stuff to master.  Each night master is built to ensure that nobody has introduced compile errors (or broke unit tests). This is not bleeding edge! This is not intended for anyone.  This is not similar to maven SNAPSHOTS.
2. When teams are happy with their work, they tag the bundle.
3. Integration builds happen weekly, and only what’s tagged will be built. Integration builds are similar to SNAPSHOTS, and can be consumed (if you want the most bleeding edge stuff).
4. This has recently changed, so instead of tagging each week, we merge (from master into ‘integration’). This means, what’s in master won’t necessarily be in a build each week.

I’m pretty sure I can hear the GitClub screaming feature branch, feature branch, feature branch. Why don’t you just use feature branches?

Please keep in mind:

1. Eclipse is over 10 years old, and predates Git.  Would you really do feature branches with CVS? (maybe)
2. The Eclipse build takes a while to complete:

• Let’s assume it takes 6 hours to build and run the tests (1/4 of a day).
• Let’s assume there are 10 teams (SWT, Debug, Workbench, PDE, JDT, UA, etc…)
• Let’s assume each team has 2 features on the go at all times: 20 feature branches
• Right now (for better or worse) a full Eclipse build, plus platform tests must run on the Eclipse build infrastructure
• So, if we had 20 feature branches that we had to build in sequence, it would take 5 days to build todays nightly
• Tomorrow’s nightly would start once that’s done!

Yes I realize some of those assumptions might be rather simplifying — maybe we could run the builds in parallel and off-load the costs to the hardware, but having a central build of 20 feature branches is still not feasible.  Also, some teams would likely want to combined builds (now build the SWT + Workbench feature branch together).

I know some people will head down the path of build restructuring (completely refactor the Eclipse build so developers can run them locally, thus removing the necessity for a centralized builds). We’ve heard this before many times.  Instead of suggesting this, sponsoring the effort (with money + people power) would be more helpful.  Also remember that Eclipse has successfully shipped on-time for the pat 10 years.  So, if you really want the team to change their process to the development flavour of the week, be prepared to show some evidence that process XYZ is better.

This was not meant to start a development war, but rather explain a bit about how the Eclipse build process works.  For better or worse, it’s what we have.

BTW, what do others do? Does everyone use feature branches and assume what’s in Master is ready? What did you do before Git (did you use branches for development in CVS/SVN)?

Happy Holiday’s Everyone!

As many of us start to get into the Holiday spirit, the Eclipse and Equinox teams have an early gift for you, Eclipse Juno Milestone 4.

Eclipse now supports Annotation based Null Analysis. (See Deepak and Ayushman’s posts for more information).

There are also enhancements to SWT (Tree Cursor)

And Equinox now supports Jetty 8 and Servlet 3.0

Checkout the  completely New and Noteworthy

or Download the Milestone and try it out yourself.

Eclipse Indigo is out and Eclipse Juno development is in full swing. That means it’s time to start thinking about the Eclipse release in 2013 (Only 18 months away). While development plans are still a far ways off, we’ve already started to collect ideas for the name.

Historically Eclipse has chosen names in Alphabetical order (Helios, Indigo, Juno), which brings us to the letter ‘K’. Since some alphabets don’t have the letter ‘C’, we could explore names like Kanada or Kookie Monster.

Of course, we can also go with villains from Star Trek like Klingon or Khan

I’m sure you’ll be much more creative than me.  If you’re interested in following this discussion, feel free to CC yourself on this bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=365965

Does TDD actually improve software quality?  Are good software developers an order of magnitude better than poor ones?  Do multiple code reviews reduce the number of bugs in the software?  Does your choice of language improve productivity? Do distributed version control systems increase the number of contributions?

Many software developers (myself included) have strong beliefs about many of these questions.  In fact, order a round of beers at EclipseCon and bring up any one of these topics and see what happens. Unfortunately, many of us base our arguments on our own experiences or anecdotes.  Occasionally we will quote some self proclaimed expert in the field and assume our argument is ‘proven’.  Is this evidence?

As tool developers — building the Best Integrated Development Environment — we need to hold ourselves to higher standards. We cannot be designing future IDEs based solely on what works well for me. If you have a few minutes, please watch the following video by Greg Wilson on Software Carpentry: Software Engineering Empirical Results. http://software-carpentry.org/4_0/softeng/ebse. I had the good fortune of meeting Greg a few years ago through the Canadian Consortium for Software Engineering. A much longer version of the talk is available (embedded below): http://vimeo.com/9270320.

Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True from CUSEC on Vimeo.

I prefer the longer one as I think he makes a much stronger point about questioning beliefs.