Chris Aniszczyk's (zx) diatribe

I’m happy to announce that we have a first release of eclipse-maven-signing-plugin. If your project needs to sign your bundles as part of the Eclipse Indigo release, please give the plug-in a try. To get started with the plug-in, please add the proper maven.eclipse.org repository to your pom.xml…

  <pluginRepositories>
    <pluginRepository>
      <id>maven.eclipse.org</id>
      <url>http://maven.eclipse.org/nexus/content/repositories/milestone-indigo</url>
    </pluginRepository>
  </pluginRepositories>

After that, in the module that you generate your p2 repository, add this profile…

   <profiles>
    <profile>
     <id>build-server</id>
     <build>
       <plugins>
         <plugin>
           <groupId>org.eclipse.dash.maven</groupId>
           <artifactId>eclipse-maven-signing-plugin</artifactId>
           <version>1.0.0</version>
           <executions>
             <execution>
               <id>pack</id>
               <configuration>
                 <inputFile>${project.build.directory}/github-updatesite.zip</inputFile>
               </configuration>
               <phase>package</phase>
               <goals>
                 <goal>pack</goal>
               </goals>
             </execution>
             <execution>
               <id>sign</id>
               <configuration>
                 <inputFile>${project.build.directory}/github-updatesite.zip</inputFile>
                 <signerInputDirectory>/home/data/httpd/download-staging.priv/egit-github</signerInputDirectory>
               </configuration>
               <phase>package</phase>
               <goals>
                 <goal>sign</goal>
               </goals>
             </execution>
             <execution>
               <id>repack</id>
               <configuration>
                 <inputFile>${project.build.directory}/signed/site_assembly.zip</inputFile>
               </configuration>
               <phase>package</phase>
               <goals>
                 <goal>pack</goal>
               </goals>
             </execution>
             <execution>
               <id>fixCheckSums</id>
               <phase>package</phase>
               <goals>
                 <goal>fixCheckSums</goal>
               </goals>
             </execution>
           </executions>
         </plugin>
         <plugin>
             <artifactId>maven-antrun-plugin</artifactId>
             <executions>
               <execution>
                 <id>deploy</id>
                 <phase>install</phase>
                 <goals>
                   <goal>run</goal>
                 </goals>
                 <configuration>
                   <tasks>
                     <delete includeemptydirs="false">
                       <fileset
                         dir="/home/data/httpd/download.eclipse.org/egit/github/updates-nightly">
                         <include name="**" />
                       </fileset>
                     </delete>
                     <copy includeemptydirs="false"
                       todir="/home/data/httpd/download.eclipse.org/egit/github/updates-nightly">
                       <fileset dir="target/checksumFix">
                         <include name="**" />
                       </fileset>
                     </copy>
                   </tasks>
                 </configuration>
               </execution>
             </executions>
           </plugin>
    </plugins>
  </build>
  </profile>
  </profiles>

Then all you need to do is run your maven build with ‘-P build-server’ as an added goal.

There are a couple things you need to watch for in regards to paths. The first is to ensure that you have a directory on the build server where signing can happen, in the example above, it was /home/data/httpd/download-staging.priv/egit-github. If you don’t have the proper permissions to create a directory under /home/data/httpd/download-staging.priv, please open a bug against the webmaster. You also need to ensure that you point to the archived p2 repository that is generated as part of the maven build. In the case of our example above, it’s ${project.build.directory}/github-updatesite.zip. The second part of the profile publishes the results on download.eclipse.org so you need to ensure that the directory there (e.g., /home/data/httpd/download.eclipse.org/egit/github/updates-nightly) is writable by Hudson (e.g., chmod 777).

I hope that gets you started. I plan on updating the Minerva example by next week to include all of this information and have it migrated to the eclipse.org Dash project where everyone can use it. A special thanks goes to David Carver and Jesse McConnell in helping get this in place in time for the Eclipse Indigo release.

I’ve helped setup quite a few Maven Tycho builds for people as of late, with more requests coming in. Personally, I’ve had quite a bit of experience working with Tycho-based builds as being one of the first early adopters with the EGit and JGit projects at Eclipse. At that time, Tycho was pretty rough around the edges but I’m pleased to report I believe now Tycho to be one of the best, if not the best option for building Eclipse/OSGi related artifacts. Sure, it’s not perfect but it’s pretty damn good now. Furthermore, there are even large projects like Mylyn at eclipse.org that have moved to Tycho to manage their whole build if you need further proof.

One of the common complaints from folks within the eclipse.org ecosystem is how difficult it is to setup build. In the past, we had the Athena Common Build project at eclipse.org with some success. Athena helped many projects get off the ground when it comes to building and publishing their artifacts. However, it still suffered the drawbacks of PDE Build based systems when it came to debugging, customizing and extending the build system. For example, if you wanted to integrate with Hudson, add FindBugs to your build or run SWTBot unit tests, you suffered quite a bit. Well, I’m happy to report that Maven Tycho helps quite a bit with these customization issues. To help alleviate some of the pain we’re experiencing with build at eclipse.org, I decided to put up sample Maven Tycho project for people to look at and refine. I’m calling the effort Minerva as I think it plays nicely with what was done in the Athena project (Minerva is the Roman equivalent of Athena and the word Maven is in Minerva!).

The goal of the Minerva project would be to get a well documented sample build for eclipse.org projects. I can even envision a future when a new eclipse.org project comes around and they get a build already generated for them and hooked up to hudson.eclipse.org! I think once you have something working and it’s well documented, it becomes pretty easy to expand as you add new features.

To get started, I’d take a look at what is on the wiki already. If you want to play with code, ensure that Maven 3 is installed and then do a quick clone.

git clone git://github.com/caniszczyk/minerva.git

mvn -Dskip-ui-tests=true clean install

Once you do that, you should notice a p2 repository (update site) generated in the update site project’s target/site folder. To sweeten the deal, if you have Hudson (Jenkins) installed anywhere, you can configure it quickly to build the code base.

Remember how long something like that took before? In reality, Tycho isn’t that complicated to setup.

In Maven, the parent pom.xml serves as the central point on adding things to the build. It’s also generally the most complicated piece of the build as it contains information that is shared by children pom.xml files. The first part of the parent pom.xml contains identifying information:

...
<groupId>org.aniszczyk.minerva</groupId>
<artifactId>minerva-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>

<name>Minvera Parent</name>
...

The second part contains profile information and where to get dependencies.

  <properties>
    <tycho-version>0.10.0</tycho-version>
    <platform-version-name>helios</platform-version-name>
    <eclipse-site>http://download.eclipse.org/releases/${platform-version-name}</eclipse-site>
    <wikitext-site>http://download.eclipse.org/tools/mylyn/update/weekly</wikitext-site>
    <swtbot-site>http://download.eclipse.org/technology/swtbot/${platform-version-name}/dev-build/update-site</swtbot-site>
  </properties>

  <profiles>
    <profile>
      <id>platform-helios</id>
      <activation>
        <property>
          <name>platform-version-name</name>
          <value>helios</value>
        </property>
      </activation>
      <properties>
        <eclipse-site>http://download.eclipse.org/releases/helios</eclipse-site>
        <platform-version>[3.6,3.7)</platform-version>
        <swtbot-site>http://download.eclipse.org/technology/swtbot/helios/dev-build/update-site</swtbot-site>
      </properties>
    </profile>
    <profile>
      <id>platform-indigo</id>
      <activation>
        <property>
          <name>platform-version-name</name>
          <value>indigo</value>
        </property>
      </activation>
      <properties>
        <eclipse-site>http://download.eclipse.org/releases/indigo</eclipse-site>
        <platform-version>[3.7,3.8)</platform-version>
        <swtbot-site>http://download.eclipse.org/technology/swtbot/indigo/dev-build/update-site</swtbot-site>
      </properties>
    </profile>
  </profiles>
...
  <repositories>
    <repository>
      <id>helios</id>
      <layout>p2</layout>
      <url>${eclipse-site}</url>
    </repository>
    <repository>
      <id>swtbot</id>
      <layout>p2</layout>
      <url>${swtbot-site}</url>
    </repository>
    <repository>
      <id>wikitext</id>
      <layout>p2</layout>
      <url>${wikitext-site}</url>
    </repository>
  </repositories>

What’s cool about setting up these repositories and profiles is that we can easily switch the build to run against Helios or Indigo repositories. If you want to run Indigo, simply set -Dplatform-version-name=indigo and you’re good to go. You could even setup multiple hudson jobs that build against various Eclipse releases if you want to ensure everything works properly.

The third part lists the modules (e.g., features, plug-ins) that are part of the build:

  <modules>
    <module>org.aniszczyk.minerva.core</module>
    <module>org.aniszczyk.minerva.ui</module>

    <module>org.aniszczyk.minerva-feature</module>
    <module>org.aniszczyk.minerva.source-feature</module>

    <module>org.aniszczyk.minerva-updatesite</module>

    <module>org.aniszczyk.minerva.tests.core</module>
    <module>org.aniszczyk.minerva.tests.ui</module>
   </modules>

Each of those modules has a simple pom.xml that tells Tycho what type of project it is (think feature or plug-in). You should be able to piece things together by looking at the documentation on the wiki. Let me know if you have any questions and please feel free to add anything. My plan is eventually to get things up to shape so the code could live at eclipse.org and get things up to a point where a Maven archetype could be built and used to generate new projects.

Thoughts? Also, if you’re an eclipse.org project and interested in moving to Tycho, feel free to contact me and look at the example.