Developers, Developers, Developers! Maksim Sorokin IT Blog


Manifest Version — with or without qualifier?

Should MANIFEST.MF contain qualifier or not? That depends on what strategy you use in your development cycle. When you change a plugin a lot during development cycle, it is better to add append a qualifier to the end of the version. In this case, everytime you will build a plugin, it will have a timestamp added to the end of the filename, for example:


If you will not have a qualifier, it will always be the same jar name:


In this case you may have some troubles. For example, when you run FeaturesAndBundlesPublisher with -append option. Since old and new bundle version have the same version (without added timestamp), old version will be preserved. In this case make sure to change the version of your MANIFEST.MF, when you make changes to the project without qualifier.


Tests in Tycho

In Tycho tests expected to have the following name pattern: **/Test*.java, **/* and **/* By default, the following is excluded: **/Abstract***/Abstract* and **/*$*.

If you want to change excluded and included tests, in your test fragment you have to add something like the following:


Keep in mind, that if tycho will not find any tests, it will fail! See discussion on issue tracker.


Tycho “Profile id _SELF_ is not registered”

Are you using eclipse-application as a packaging type? Try eclipse-repository. Here is an example.

Tagged as: , Comments Off

Building with Tycho — Our Eclipse DemoCamp Presentation

Our Tycho presentation for Eclipse DemoCamp Copenhagen 2010.


Having Different Versions of the same Feature in p2 Repository

In one of the posts I talked about creating a p2 repository from plugins and features. In other one I showed how to make Tycho create a deployable feature. You can combine them both in order to have several versions of the same feature in p2 repository.

This works in the following way. First, you build a feature with Tycho. Then you merge it with existing p2 repository (it can also be used to create one) using p2 publisher, about which I talked in previous post. -append option ensures, that you add and not delete rewrite old ones.


Creating a p2 Repository from Features and Plugins

So you have some features and plugins and you want to publish those to the p2 repository. There is a nice page on describing this procedure.

Here is a recepie.

First, you will need to have to create a folder, which be a source folder for p2 repository. Let's
name it src:

-- src

In this src folder create two other folders called features and plugins:

-- src

Copy your features to features folder and plugins to the plugins folder.
And what you do next is just running

$ECLIPSE -debug -consolelog -nosplash -verbose -application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher -metadataRepository file:$DEST -artifactRepository file:$DEST -source %SRC% -compress -append -publishArtifacts

where $ECLIPSE is a path to eclipse executable, $DEST is where p2 repository will be created and $SRC is the path to src folder.

That is it.

If you want your plugins be visible on p2 repository, you would need to run additional step. In this case, you would need to create a category.xml file. This file provides information about the categories of your bundles, so they could be seen. If you do not care about nice naming, you can just have a dummy category.xml with which bundles will have category name the same as bundle name:

<?xml version="1.0" encoding="UTF-8"?>
   <category-def name="all" label="Maven osgi-bundles"/>
      <category name="all"/>
      <query><expression type="match">providedCapabilities.exists(p | p.namespace == 'osgi.bundle')</expression></query>

And then run another command:

$ECLIPSE -debug -consolelog -nosplash -verbose -application org.eclipse.equinox.p2.publisher.CategoryPublisher -metadataRepository file:$DEST -categoryDefinition file:PATH_TO/category.xml

Then you can point your eclipse to location of installed p2 repository. If you want to switch feature/bundle view, toggle "Group items by category"

Eclipse, p2, update site

Deployable Feature with Tycho

When building a feature with Tycho, you can define it to be "deployable":


In this case, when Tycho will build it, it will also create a p2 site for this feature including all the plugins and dependencies.


Checking out PDE as Maven Project in Eclipse

Ealier I though about bringing maven structure to mavenized PDE projects. That it instead of having

- trunk
  # dk.sorokin.maksim.feature
  # dk.sorokin.maksim.plugin
  # dk.sorokin.maksim.parent

where dk.sorokin.maksim.parent is a project containing parent pom.xml, have more standard maven structure:

- trunk
  # dk.sorokin.maksim.parent
    @ dk.sorokin.maksim.feature
    @ dk.sorokin.maksim.plugin

Latter case has more benefits. One could use "Check out as Maven Project...". When a new plugin is added, changes immediately are seen on the parent. There will be no need in providing "relativePath" to the parent in the modules.

However, as far as I see, at the moment it is not possible. The problem is that together with Mavenizing the project, we still want to preserve developers to work with the project the way they worked before. We need to have ".project" and ".classpath" files commited to repository. M2Eclipse Eclipse plugin fucks up ".classpath" file and adds some new settings during "Check out as Maven Project...".
Therefore, currently we will use a plain PDE structure and will not check out projects as Maven ones.


Error – 7 icon(s) not replaced in.. during “eclipse-application” packaging

You may encounter something like:

Error - 7 icon(s) not replaced in C:\...\AppData\Local\Temp\p2.brandingIron9146421972747334437\launcher.exe using C:\...\target\products\...\images\modeler.ico

There is currently a bug in Tycho. However, patch is provided.

Tagged as: , Comments Off

Building RCP Deliverable with Tycho

We managed to build our Eclipse based product deliverable with Eclipse. Yes, it is possible! I suggest looking into the following resources:

Especially, take a look at the last demo link.


Philosophy Differences between Eclipse and Maven in Dependency Management

Title of this post is a bit cumbersome. I want to discuss how Eclipse-OSGi world works with dependencies and compare it with Maven world.

In Eclipse-OSGi world dependencies usually are defined with a range. For example:

Require-Bundle: org.eclipse.ui,

Numbers in build number x.y.z are meant to be

  • x -- changes in API. Downstreamers should expect code breaking. Non-backwards compatible code.
  • y -- changes, which might lead to code breaking.
  • z -- bugfixes

Eclipse-OSGi world basically does not have understanding of "released" product. Built product is always "released" (if exposed to the public). Moreover, build number does not necessarily change. Thefore Eclipse-OSGi guys have problems, if they depend on online repositories. Because at any time new version of dependency with higher minor build number may appear and code may break.
What Eclipse-OSGi do then? Well, it is simple. They do not use online repositories! They used "frozen" version of those, for example by using standalone Eclipse installation as target platform. Usually this "frozen" target platform is being renewed at the beginning of each sprint.

Let's take a look on Eclipse-OSGi dependency management world from Maven perspective. Eclipse-OSGi world guys have SNAPSHOTs, but do not have releases. That is, you always grab the latest available version (of course, in possible range). Obviously, if we look from this perspective, it is very dangerous to depend on latest SNAPSHOT version.
In Maven world released products have to depend on released versions of dependencies. Moreover, when product is released, you are forced to change the build number. So there is no two releases with to numbers. Of course you can cheat and delete released product from maven repository and put another one, but at least you are guarded from doing that.

Ok, now why that matters. Lately more and more companies use Eclipse platform to build their products. And many development departments use maven heavily in the development process. Therefore they want to benefit from having maven to build Eclipse products. Tycho project allows to do that. However, beside many missing features in Tycho, there is a clashes between maven and Eclipse-OSGi world dependency ideology.

We already have some solutions and ideas to solve dependencies situation. However, let's wait with those until next posts..

Thanks to Tony Madsen for clarifications.