How do I build an Eclipse RCP app so that its features can be updated automatically?

Question

I am building an RCP application that will be made up of several Features.

My RCP application is configured to check for updates each time it starts. My current problem is that I need one of my Features to be 'Installed' at build time so that it will get updated during this automatic check for updates without forcing the user to manually install it. I need this feature to update independently from the other features in the system.

So, to recap, I'm just looking for a nice automated way to have a Feature installed in an RCP app in such a way that it updates independently from other features, and doesn't require the user of the RCP app to install it manually.

Answer 1

After a long search, I have found the answer. It's kind of a kludge, but I'm willing to do anything at this point. My solution is dependent upon the fact that my built RCP application includes p2 application org.eclipse.equinox.p2.director. I guess if your RCP app doesn't contain this application, you can refer to another Eclipse install in order to launch the Director. I just did it this way to avoid having an instance of Eclipse sitting on my build machine.

I used the p2-dev mailing list, and Paul Webster answered my question. (Thanks Paul)

He suggested using ant to launch the p2 director application to install the IU into my built RCP application.

Here's his answer on the p2-dev mailing list http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04735.html

Here's the ant target I came up with.

<target name="install_IU">
  <path id="launcher.paths">
    <fileset
       dir="${app.dir}"
       includes="plugins/org.eclipse.equinox.launcher_*" />
  </path>
  <property
      name="launcherPath"
      refid="launcher.paths" />
  <echo>-installIU ${iu.id} </echo>
  <java 
      jar="${launcherPath}"
      failonerror="false"
      dir="${app.dir}"
      timeout="900000"
      fork="true"
      output="${basedir}/director.log"
      resultproperty="directorcode">
      <arg line="-application org.eclipse.equinox.p2.director" />
      <arg line="-noSplash" />
      <arg line="-installIUs ${iu.id}" />
      <arg line="-repository ${iu.repo}" />
      <arg line="-destination ${app.dir}" />
      <arg line="-bundlepool ${app.dir}" />
  </java>

  <zip destfile="${app.zip}"
    basedir="${app.dir}"/>
</target>

I put this in an ant file in the same project that produces my Eclipse RCP application via Tycho. Tycho produces my build artifacts in a directory called "target" so my parameters to the ant target above look like this...

<target name="modify_x86">
  <antcall target="install_IU">
    <param name="iu.id" value="com.mydomain.the.feature.i.want.to.install.feature.feature.group"/>
    <param name="iu.repo" value="http://mydomain.com/thep2repository/where/i/deploy/the/feature/to/install"/>
    <param name="app.dir" value="${basedir}/target/products/com.mydomain.myRCPapplication/win32/win32/x86"/>
    <param name="app.zip" value="${basedir}/target/products/com.mydomain.myRCPapplication-win32.win32.x86.zip"/>
  </antcall>
</target>

I have a few more of these targets for each platform that my RCP application is built for.

Hope this helps.

UPDATE: May 8th, 2014. Tobias has brought it to my attention that I should change the accepted answer from this one to the one that has the new feature that was added to Tycho 0.20.0 that enables this behavior in a much more simple fashion. So, the new accepted answer is the proper solution for this question now.

Answer 2

In the meanwhile, Tycho has explicit support for this use case. Starting with Tycho 0.20.0, you can make Tycho install features of an RCP separately from the product. In this way, these features can be updated (or even be uninstalled) independently of the product.

To install features independently, just add an attribute installMode="root" to the respective feature tags in the product file. Example:

<features>
   <feature id="org.eclipse.platform"/>
   <feature id="updatable.feature" installMode="root"/>
</features>

For more information, see this documentation page.