In a recent post, I wrote about my current research project: a restricted subset of AADL and a translator that converts from this subset to Java. Since AADL has a pretty nice Eclipse plugin in OSATE2, I think it’s pretty natural to build on top of that. Not only does this make for an easy workflow (no leaving your development environment when it’s time to run the translator) but I got a lot of things “for free” — like tokenization, parsing, and AST traversal. Since good engineering practices are pretty strongly encouraged / outright required in my research lab (yesterday’s post discussed testing), that meant I would need to learn how to build an Eclipse plugin automatically, so that everything could be automated using Jenkins (our continuous integration tool).
Integrating Tycho
Other projects in my research lab had used SBT for automated building, so that was where I started out. Unfortunately, there isn’t a lot of SBT support for building Eclipse plugins (there’s this project, but it seems to be abandoned), so after some googling, I ran across Maven’s Tycho plugin. It seemed to support everything I wanted, though with no Maven experience I found the learning curve a bit steep. I then ran across this tutorial, which really got everything rolling. I would find myself coming back to this article every time I wanted to automate another feature, like testing.
The basic idea behind Tycho is that it enables Maven to read build information (dependencies, contents of source and binary builds, etc.) from your plugin’s plugin.xml and manifest.mf files. This greatly simplifies Maven’s build configuration specifications (the pom.xml files), since all you need to do is tell Tycho what kind of a project you’re building, and it takes everything from there. For example, the entirety of my main plugin project’s configuration file is only 14 lines:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<?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> <relativePath>..</relativePath> <groupId>edu.ksu.cis.projects.mdcf</groupId> <artifactId>aadl-translator</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <groupId>edu.ksu.cis.projects.mdcf</groupId> <artifactId>edu.ksu.cis.projects.mdcf.aadl-translator</artifactId> <version>0.1.0-SNAPSHOT</version> <packaging>eclipse-plugin</packaging> </project> |
Note in particular the packaging element (line 13), which specifies the type of artifact — other options I used were eclipse–feature , eclipse–update–site , and eclipse–test–plugin .
Using Maven
I won’t attempt to re-create the Vogella tutorial here, but I do want to mention a couple of general Maven things I learned:
- I found the ability to use Eclipse’s P2 update sites as repositories (from which dependencies can be pulled) really helpful. Since OSATE2 isn’t available from Maven’s main repository, I initially thought I’d have to somehow add (and maintain!) a bazillion .jar files to my build configurations. Instead, I was able to simply use:
123456789101112<repositories><repository><id>kepler</id><url>${kepler-repo.url}</url><layout>p2</layout></repository><repository><id>osate</id><url>${osate-repo.url}</url><layout>p2</layout></repository></repositories> - I put off learning about / using profiles as long as I could. Profiles let you specify how your build should change in different contexts, depending on things like the host OS, command line switches, etc. I probably should have learned about them sooner since they’re so powerful, but I’m glad I worked to generalize the build as much as possible, because they’re definitely a tool that can be overused.
- When it was time to learn about profiles, I mostly used random examples from StackOverflow for the actual code, but I thought this article was particularly good on the philosophy behind profiles, and the “Further Reading” section has a lot of good references.
- The two different profiles I did use were:
- A host-os activated profile to enable a Mac OS X specific option that’s required if the testing needs a UI thread ( <argLine>-XstartOnFirstThread</argLine>).
- A command-line activated switch to trigger uploading (using Maven Wagon‘s ext-ssh provider) of the generated update site and documentation.
- Since my tests relied on some functionality present only in OSATE2, I had to declare the providing plugin’s id as an extra dependency for my tests to run. That meant adding the following to my test project’s pom.xml file:
12345678910111213141516<plugin><groupId>org.eclipse.tycho</groupId><artifactId>target-platform-configuration</artifactId><version>${tycho.version}</version><configuration><dependency-resolution><extraRequirements><requirement><type>eclipse-plugin</type><id>org.osate.xtext.aadl2.ui</id><versionRange>${osate.version}</versionRange></requirement></extraRequirements></dependency-resolution></configuration></plugin>
Ultimately, the build files I ended up with represent the most up-to-date working state of my Maven / Tycho knowledge. They’re all available on github. Let me know if you have any feedback in the comments!
Leave a Reply