blog of itemis l.e.

Developing OSGi bundles or eclipse plugins, features, updateSites, products or fragments within eclipse and the PDE is excellent. Headless build automation and dependency management for java based projects is also excellent with maven from Apache.

But the combination of maven based builds and eclipse development was till recently awful.

Since some days ago the brand new maven 3 alpha 4 and the new tycho 0.5.0 are available for download.

With these two new versions it’s more easier to enable headless eclipse or OSGi bundle builds based on maven. Included is also, e.g. target platform management and P2 integration.

Thanks to the people from sonatype for this great work.

I will describe in some more posts, the steps on migrating existing eclipse builds to maven.

Creating a new Xtext project by default creates src and src-gen folders. However, sometimes one may wish for a more maven-like structure using src/main/java and src/generated/java. I want to briefly describe how to refactor an existing Xtext project (such that regenerating from the grammar file still works afterwards). Using these steps it should easily be possible to adapt new Xtext projects before the first generation of the Xtext artifacts, as well.

There are two main steps involved:
1) replacing the source folders src and src-gen by src/main/java and src/generated/java
2) making these changes known to the workflow file, so that these folders are used instead

Apply steps a)-c) to all three Xtext projects (they are essential only for the grammar and the ui one, though).

a) Remove <classpathentry kind="src" path="src"/> and <classpathentry kind="src" path="src-gen"/> from the .classpath files. And while you are at it, change the output entry from “bin” to “target/classes”.

b) Use the “New Src Folder”-Wizard to create src/main/java and src/generated/java. This adds them automatically to the .classpath file. But you still have to adapt the source..-entry in the build.properties. Use the quick fix (in the textual representation of the file) to add the new folders and remove src and src-gen manually.

c) Move the previous contents of src to the source folder src/main/java (don’t move the subfolders main or generated). Move the previous contents of src-gen to src/generated/java.

d) In the workflow file, point the directory cleaner components the the new folders, replacing src-gen by src/generated/java.

e) Also add the following properties to the Generator component in order to let it know the new folders:
<srcPath value="/src/main/java"/> and
<srcGenPath value="/src/generated/java"/>

Xtext sample project after maven structure refactoring

f) You may want to delete the src-gen- and the bin-folders in all the projects. The generator project may call for a different folder structure. Feel free to choose your own. I also recommend to use package names more unique than templates, model and workflow, in particular if you have several Xtext projects in the same environment. Don’t forget to modify the generator-project’s workflow file (targetDir, template path etc.), template and extension file(s) accordingly.

P.S.: Of course it would be nice if the New Xtext Project wizard had a tick box “use Maven folder structure”

Wer ein neues modellbasiertes Projekt anfängt, steht u.a. vor folgenden Aufgaben:

1. Referenzimplementierung inkl. Systemarchitektur realisieren
2. Modellierungssprache ausdenken
3. Codeschablone schreiben
4. manuellen Code ergänzen

Wer das öfters macht kommt schnell auf die Idee, vielleicht aus dem letzten Projekt die Modellierungssprache oder Teile der Codeschablone o.ä. wiederzuverwenden. Konsequent weitergedacht macht es so natürlich Sinn, vielleicht genau für die Wiederverwendung auf Werkzeugebene ein eigenes Framework aufzubauen. Dieses hätte den Vorteil eine erprobte Systemarchitektur zu generieren und jede Menge geteste Codeschablonen zu beinhalten.

Und genau das ist die Fornax Plattform. Dort gibt es verschiedene Cartridges, u.a. auch Sculptor. Just von diesem wurde Anfang dieser Woche die Version 1.5.0 veröffentlicht.

Konkret benutzen wir Sculptor momentan in einem Projekt, in dem wir das JEE-Backend, ablaufend im JBoss, zu großen Teilen generieren. Das Frontend basiert auf eclipse RAP und läuft im OSGi-Container equinox. Dort haben wir die Infrastruktur generiert und die UI noch teilweise per Hand ergänzt. Die Kommunikation zwischen beiden Containern wurde auf Basis Spring Dynamic Modules und JEE Stateless Session Beans generiert. Automatisch gebaut wird das Ganze natürlich mit Apache Maven.

Wer also gern mal das typische Helloworld Projekt modellbasiert realisieren möchte, ist eingeladen einfach Sculptor auszuprobieren. Das gesamte Framework ist Open Source und lebt natürlich vom Mitmachen.

/Steffen…

Viele Entwickler fühlten sich bisher bei der Nutzung von Maven 2 in die Vergangenheit zurück versetzt. Immer wieder neue Terminals oder Shells zum Ausführen der Maven Goals. Selbst mit dem WickedShell Plugin keine echte Freude für Eclipse Anwender. Während die ANT Untersützung automatisch in jeder Eclipse Distribution enthalten ist, wurde Maven – in meinen Augen zu Unrecht – etwas stiefmütterlich behandelt. Zwar gab es erste Ansätze wie m2eclipse und q4e. Allerdings waren diese Plugins lange Zeit in grossen Projekten nicht sinnvoll einsetzbar, weil elementare Eigenschaften fehlten.

Umso erfreuter war ich, als ich im Zuge der Einführung von Nexus gesehen habe, dass m2eclipse einen grossen Schritt in der Entwicklung getan hat. Das Erstellen neuer Projekte mit bestimmten Maven Archetypes sowie das Ausführen der gewünschten Goals aus der IDE heraus sehe ich schon als must have Kriterium eines solchen Plugins an. Ob man den grafischen POM Editor wirklich benötigt, mag jeder Entwickler für sich selbst entscheiden. Dependency Hierarchy View und Dependency Graph sind aber sehr nützlich, um den Überblick über die vielen Maven Artefakte zu behalten.

Einen Vorteil kann m2eclipse dann ausspielen, wenn es um die Suche nach Artefakten geht. Dazu bindet m2eclipse Indizes von anderen Maven Repositories ein. Das sind standardmäßig der aktuelle Workspace, das lokale Repository im Heimatverzeichnis des Nutzers und das central Repository. Bindet man statt central den internen Nexus Repository Manager ein, kann man in Eclipse automatisch alle Maven Repository Proxies nach Artefakten durchsuchen.

Die Suche geht sogar noch einen Schritt weiter. Nicht nur Artefakte können gesucht werden, sondern sogar Klassen innerhalb der Java Archive. Somit behält man selbst in großen Maven Projekten leicht den Überblick über Artefakte, Versionen und deren Abhängigkeiten. Hier hat sich in den letzten Monaten also einiges am Plugin getan und gerade in Kombination mit Nexus wird die Entwicklung von Maven Projekten in Eclipse mit m2eclipse nun vielfach angenehmer.