Building Woolsey with Maven and Tycho
Building Woolsey with Maven and Tycho
Join the DZone community and get the full member experience.Join For Free
Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!
Probably the hardest thing about using Maven and Tycho to build my Eclipse project was getting my brain around how easy it is. I’m completely new to Maven. I’ve known about it for years. I’ve read some of the high-level documentation, but until last week had never actually used it myself.
The first thing that I had to learn was that you don’t actually have to install Tycho. All you need to get started building Eclipse plug-ins is Maven 3. With that little bit of background out of the way, here’s what I did to create a build for the Woolsey project.
Install Maven This requires downloading and unzipping it. Tycho requires Maven 3, so I downloaded the 3.0 beta 3.
Generate POM files POM files drive Maven: they tell Maven what to do. Tycho POM files are actually relatively short and sweet, but–since I started off with absolutely no knowledge of how to build one–I was delighted to learn that Maven can generate default ones for you, using the following command:
mvn org.sonatype.tycho:maven-tycho-plugin:generate-poms -DgroupId=org.eclipse.woolsey -Dtycho.targetPlatform=/home/wayne/Eclipse/eclipse-rcp-helios-linux-gtk/eclipse
The groupid is an organizational name for the artifacts generated by the build. I used my project name (which seemed reasonable to me at the time). Tycho also requires that you provide a target platform (which I interpret to mean “target” in the same manner that PDE defines it).
I ran this command from the parent directory; that is, the directory that contains separate folders for each of Woolsey’s Eclipse projects. Maven generated a POM file in each directory, including the parent.
Reorganize I decided that I didn’t like the POM file in the parent directory. I preferred to have a separate “releng” project that I could manage from within Eclipse. I created such a project and moved the parent POM file into the corresponding project directory. I updated the “module” paths in the file to account for the new location.
Run Maven I invoked Maven from within the “Releng” project’s directory with the following command:
mvn clean install -Dtycho.targetPlatform=/home/wayne/Eclipse/eclipse-rcp-helios-linux-gtk/eclipse
Maven went to work, but ultimately reported a failure. It seems that my tests don’t run (I’m pretty sure that this is because I haven’t actually created any JUnit tests yet). I need to sort that out, but in the meantime, I removed the “module” reference to the test project’s POM from the Releng POM file and re-ran. It worked like a charm, creating a “target” directory in each Eclipse project directory containing the built bundle in JAR form. Sweet.
It was at this point that I realized that I’d made a mistake. I actually need to have a feature and p2 repository if I want to actually install and test this stuff.
Create a Feature and Update Site I created the required Feature and Update Site Eclipse projects. I then used the “generate POMs” command on the directories for each of these projects and updated the “Releng” POM to include module references to these new directories.
When I reran Maven and watched it build the feature and update site (complete with p2 repository data). Sweet.
Housekeeping The final thing I decided to do was to make sure that Git doesn’t grab the build artifacts. I created a .gitignore file containing a single entry: “target/” to instruct Git (and JGit) to ignore any directory named “target”.
That’s it. Done. Elapsed time: 20 minutes. Sweet.
The best part: I still don’t have a friggin’ clue how to use Maven, but I got the job done.
Next step: automated builds with Hudson.
Opinions expressed by DZone contributors are their own.