I just pushed a template for creating AspectJ applications with Tycho and will give you a quick tour of it here. You’ll find the template on github [1]

The template contains four infrastructure projects. One defines an OSGi command to calculate faculties and another contains an aspect to measure the duration of the calculation.

Let’s take a closer look. com.eclipsesource.weaving.demo.releng contains the Maven parent pom.xml file which defines the modules of the application:

<groupId>com.eclipsesource.sandbox.weaving.demo</groupId>
<artifactId>com.eclipsesource.sandbox.weaving.demo.parent</artifactId>
<version>0.1.0-SNAPSHOT</version>
 
<packaging>pom</packaging>
...
<modules>
 <module>../platform</module>
 
 <module>../weaving.demo.chronometry</module>
 <module>../weaving.demo.faculty</module>
 <module>../weaving.demo.feature</module>
 
 <module>../repository</module>
</modules>

com.eclipsesource.weaving.demo.platform – contains the target definition

com.eclipsesource.weaving.demo.feature – defines the application scope

com.eclipsesource.weaving.demo.repository contains the product definition. One very important VM argument, almost hidden from the debug arguments, registers the framework weaving extension:

-Dosgi.framework.extensions=org.eclipse.equinox.weaving.hook

The weaving service has to be started early.

As well as the four infrastructure projects, the template contains the application code:
com.eclipsesource.weaving.demo.faculty – provides an OSGi console command to calculate faculty.

public class FacultyCommandProvider implements CommandProvider {
 
  public void _faculty(CommandInterpreter ci) {
    String argument = ci.nextArgument();
    int argumentAsInteger = Integer.valueOf(argument).intValue();
    System.out.println("Faculty of " + argumentAsInteger + " is "
          + recur(argumentAsInteger));
  }
...

com.eclipsesource.weaving.demo.chronometry – contains the Aspect to measure the faculty execution time.

public aspect CommandProviderChronometer {
  void around(CommandInterpreter ci):
        execution(void CommandProvider+._faculty(CommandInterpreter))
          && args(ci) {
    long start = System.nanoTime();
    proceed(ci);
    long duration = System.nanoTime() - start;
    System.out.println("Result calculated in " + (duration / 1000) + " micro seconds");
  }
}

The following snippet from the project’s pom.xml file tells Tycho to use the aspectj compiler:

...
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>aspectj-maven-plugin</artifactId>
      <version>1.3.1</version>
      <configuration>
        <verbose>true</verbose>
        <complianceLevel>1.5</complianceLevel>
     </configuration>
     <executions>
       <execution>
        <goals>
          <goal>compile</goal>
        </goals>
      </execution>
    </executions>
 </plugin>
 </plugins>
</build>
...

We build the application the Tycho way, from the command line with Maven 3.x:

> cd releng
> mvn package
...
[INFO] --- tycho-p2-director-plugin:0.12.0:archive-products (archive-products) @ com.eclipsesource.sandbox.weaving.demo.repository ---
[INFO] Building zip: .../weaving.demo_...-macosx.cocoa.x86_64.zip
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] com.es..weaving.demo.parent ..... SUCCESS [0.002s]
[INFO] com.es..weaving.demo.platform ... SUCCESS [0.269s]
[INFO] com.es..weaving.demo.faculty .... SUCCESS [1.995s]
[INFO] com.es..weaving.demo.chronometry  SUCCESS [0.482s]
[INFO] com.es..weaving.demo.feature .... SUCCESS [0.533s]
[INFO] com.es..weaving.demo.repository . SUCCESS [7.262s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

We can now unzip the artifact and launch the application:

> unzip weaving.demo_selfcontained-macosx.cocoa.x86_64.zip
> Eclipse.app/Contents/MacOS/eclipse

The following output shows that weaving was successful:

osgi> [org.eclipse.equinox.weaving.aspectj] info Starting AspectJ weaving service ...
...
[com.eclipsesource.weaving.demo.faculty] info register aspect com.es..CommandProviderChronometer
[org.eclipse.equinox.weaving.aspectj] info weaving bundle 'com.eclipsesource.weaving.demo.faculty'
[com.eclipsesource.weaving.demo.faculty] weaveinfo Join point 'method-execution(void com.es..FacultyCommandProvider._faculty(org.eclipse..CommandInterpreter))'
in Type 'com.es..FacultyCommandProvider' (FacultyCommandProvider.java:9)
advised by around advice from 'com.es..CommandProviderChronometer' (CommandProviderChronometer.aj:8)

Running the OSGi console command shows the measurement in action:

osgi> faculty 23
Faculty of 23 is 862453760
Result calculated in 1165 micro seconds

[1] https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo

Tags: aspectj, OSGi, tycho

When you face the task of building a Server-Side Equinox or a RAP application (which is just a Server-Side Equinox application) you need to choose a build system from a fairly diverse palette. This choice is never easy because every build system has its pros and cons. In the end it comes down to which one you and others, love or hate.

To make this task a little easier we created a small github project called “RAP build examples”. It provides examples of how to build a RAP application with different build systems. Currently the following systems are covered:

PDE Build:

The goal of PDE Build is to facilitate the automation of plug-in build processes. Essentially, PDE Build produces Ant scripts based on development-time information provided by, for example, the plugin.xml and build.properties files. The generated Ant scripts, can fetch the relevant projects from a CVS repository, build jars, Javadoc, source zips, put everything together in a format ready to ship and send it out to a remote location (e.g., a local network or a downloads server). read more…

Tycho:

Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles. Tycho is a set of Maven plugins and extensions for building Eclipse plugins and OSGi bundles with Maven. Eclipse plugins and OSGi bundles have their own metadata for expressing dependencies, source folder locations, etc. that are normally found in a Maven POM. Tycho uses native metadata for Eclipse plugins and OSGi bundles and uses the POM to configure and drive the build. read more…

WAR Products Tooling:

The WAR Products are similar to Eclipse Products but much more lightweight. All you have to do to export a RAP application is to create a .warproduct based on a working launch configuration and press ‘export’. The exported .war file is ready to deploy. There is a function included that validates your .war file content before you’ve exported it. read more…

All the examples in the git repository follow the same pattern. They provide a simple RAP Application (the famous mail demo) and the files you need for the build. You can read the instructions on how to run each build in the README file which is provided for every example. For those of you who are not using git we’ve also created a zip file which contains the whole repository. You can download it here.

We plan to extend the examples in the future. A Buckminster example is on its way shortly. If you have experience with other systems please feel free to leave a comment and we can create an example together.

Tags: equinox, libra, pde build, rap, server, tycho, WAR Products

Recently I played around a little with Tycho because we evaluated it for the use in the RTP project. As a test case, I decided to try to build a RAP application with Tycho. With building I mean compiling and packaging the artifacts into a WAR file in order to deploy them on a Tomcat or another Servlet Container.

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

Tags: build, eclipse, hudson, indigo, jenkins, rap, tycho

November is over now and last week I attended the last DemoCamp for the year. In this year’s November DemoCamp series I spoke at three events and with this post I’d like to present you with some impressions.

Bonn, November 16th: The beginning…

It was the first DemoCamp that was located in Bonn ever. So, as a result of this the audience was not very big, although at least 40 people found their way to the demos. I was already familiar with most of the talks.  I’d seen both Marcel Bruch’s talk on the Code Recommenders project and Mathias Sohn’s talk about EGit before, but they are still interesting. Besides these talks, one highlight was the talk about Xtext from Karsten Thoms which I hadn’t seen before in this form. He demonstrated how easy it is to create a DSL with Xtext. It’s fantastic what people can do with Eclipse technology.

Afterwards we all met at the Stammtisch. The bad thing was that Ralph Müller had to leave the talks early because he wasn’t feeling well. (Just a note here that he left before the RAP talk, so it wasn’t the talk that made him sick)

München, November 23rd: Party time…

For me it was the first time speaking at the annual DemoCamp in Munich. The organizers are well known Eclipse folks: Jonas Helming, Maximilian Koegel and Ekke. The cool thing was that these guys were so good at publicizing the camp that 100 people decided to spend an evening watching the demos. One thing that I missed was the talk by Marcel Bruch. Marcel where were you? Despite Marcel being missing, there were some really good talks. Two examples are the e4 talk by Tom Schindl and the Mylyn talk by Benjamin Muskalla. Of course both talks have been given before but I still recommend listening to them. They’re great speakers. Of course the RAP talk was another highlight

To put it all in a nutshell Munich was one of the best DemoCamps ever.  It had a very friendly atmosphere with beer service during the talks (thanks Jonas) and a great Stammtisch afterwards. But once more Ralph missed it so I had to pay for my own.

Karlsruhe, December 9th: The return of Ralph…

The last DemoCamp I visited in this series was the Karlsruhe DemoCamp last week. And guess what?  Marcel Bruch was speaking there. Why was I not surprised ? In addition to his talk, there was a world premiere in the form of Markus Tiede from Bredex presenting Jubula, one of the most recently created Eclipse projects. It was really fun to watch the IDE program by itself. Some other good talks were given by Benjamin Muskalla and Karsten Thoms. I saw Karsten in Bonn and the good thing was, that he presented two different talks. Its really nice to see that some people invest the time to provide fresh talks to the audience. I think I need to create a new talk too

The same as with the other camps, there was a Stammtisch afterwards. And surprisingly Ralph Müller was there too. So, the first round was on the Eclipse Foundation. Thanks Eclipse Foundation! I’m sure he came because he wanted to give his 6 democamps tour a nice finish. Hope to see you on more Stammtisch’s next year, Ralph.

To sum up, it was a great month with a lot of traveling. I met a lot of nice people that are all involved in Eclipse in their own way:  some as IDE users, some as contributors, some Foundation folks and a few committers – the ecosystem in its pure form. So, I hope to see some of you again at EclipseCon next year where I hope I’ll also be able to show you Eclipse RTP.

Tags: democamp, e4, eclipse, jubula, rap, redview, tycho, xtext

Eclipse has earned a reputation of being one of the best IDEs in existence. While it has become a lot more than that in many ways, its roots and its focus have always been the user facing aspects. That is probably the reasons why certain other aspects like the PDE build have been a bit neglected for quite a while. Between the ugly map files, the dependence on a target platform and its disability to run JUnit 4 tests it feels like there is quite some room for improvement.
I appreciate all the effort that went into the current state of the PDE Build, and there is quite a lot that it offers: Checking of OSGI access rules, validation of extension and extensions points, multi-platform builds, generation of p2 metadata for update sites among other things. I want to take a look at some of the recent and ongoing developments that build upon that legacy.

b3

The b3 project is currently in incubation at eclipse.org. Its goal is basically to be to the PDE build what p2 was to the update manager: A revised, more powerful version of one of the main components of the Eclipse Platform. But while p2 was more or less a complete rewrite, the key with b3 idea is to build upon the exisiting technologies like the PDE build core, Buckminster, EMF and P2. Important key aspects are extensibility and customizability. as well as interoperability with other build tools such as ant and maven.

It is refreshing to see the build process getting more attention as of late, and that the Eclipse community itself is stepping up to the task of making sure that Eclipse based applications are built in a simple, repeatable and reproducible manner.

Tycho

While Eclipse is certainly one of the defacto industry standards, another one is maven. Just as Eclipse is more than an IDE, maven is more than a build tool. The Tycho project is the maven implementation for building Eclipse plugins. While there are currently maven plugins out there capable of building “plain” OSGi bundles, Eclipse plugins are quite a lot more involved. Since both the maven pom.xml and the OSGi manifest include dependency information, there is a bit of redundancy here. The idea is here to have one of these be the “master” version, and then synthesize the other one from that. This means that projects can either be “pom-first” or “manifest-first” depending on the sepcific requirements and project setup.

There a certainly some roadblocks in the way. For example, both OSGi and maven have a concept of versions that is important for resolving dependencies. And while their format is superficially the same, their notion of version ordering is subtly but definitely incompatible. This can lead to all kinds of havoc.

Hopefully issues like these will be resolved sooner rather than later. Eclipse is not an island. Many applications based on Eclipse RCP are actual rich clients, which means they are connected to a server. These server components are usually more traditional “read: non-OSGI” Java applications, and thus tend to be built by a maven setup. In cases like these it would be desirable to have client and server share the same build infrastructure. This would be a huge boon to many real-life projects out there.

Better builds

Both these projects show an encouraging amount of progress, and I am convinced that these efforts will go a long way in making the Eclipse and the Java Platform an even better combination. While I think friendly competition is a good thing, competitive cooperation can be even better. Maybe these two projects have slightly different goals and will fill slightly different niches in the future. But I believe there is a lot of common ground, and I hope there is some healthy cross-pollination between these two projects, if not more. Both teams have a quite a background in their respective areas, and thus could bring a lot to the table.

I for one am looking forward to see these two project bear fruit, making the Eclipse build process a lot less painful and a lot more powerful.

Tags: b3, build, maven, pde build, tycho