How to avoid the specific feature versions in eclipse target definitions

Question

I have an osgi project that is split into 3 repositories. Each repository has its own build into p2 repository with Tycho:

Repo1 -> P2 repo 1
Repo2 -> P2 repo 2
Repo3 -> P2 repo 3

Also each repository has a target definition file that includes the bundles from third party p2 repositories and from another project repositories (P2 repo1, P2 repo 2 or P2 repo 3 above). Repo2 contains a dependency to Repo1 bundles, Repo3 has dependencies to the Repo1 and Repo2 bundles:

Repo1 Target Definition -> Eclipse Orbit P2
Repo2 Target Definition -> Eclipse Orbit P2, P2 repo1
Repo3 Target Definition -> Eclipse Orbit P2, P2 repo1, P2 repo2

Now I have the following problem. After building the first repository, the P2 repo1 repository updated and contains the feature with the new snapshot versions. The target definitions of Repo2 and Repo3 depend on the previous snapshot version of Repo1 bundles and building these repositories is impossible without updating the appropriate target definitions (In Eclipse there are Update button in Target Editor).

<location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
<unit id="com.myproduct.feature.api.game.feature.group" version="1.0.0.201509251400"/>
<unit id="com.myproduct.feature.impl.game.feature.group" version="1.0.0.201509251400"/>
<repository location="http:............../target/repository/"/>
</location>

So it is impossible automatically build all 3 repos, so the build process becomes too complicated:

• Commit the changes in the first repo and build it with Jenkins
• Update the target definition of repo2 to point it to the new version of repo 1 feature
• Commit this update in repo2 and build it with Jenkins

etc....

I am thinking now to use git submodules for integrating these 3 repos to avoid the p2 repositories or move all in one repository.

Chlamydospore

I had the same problem recently and stayed with manually updating the target platforms because there was only one upstream p2 repo which doidn't cahnge often. Did you consider a pre-build step that updates the target platofrm to the latest snapshot (not sure if that would really work out though)? – Hospitality

Answer 1

Set version to 0.0.0

I don't know how to edit the .target file with the Target Editor to achieve this, but you can enter a version number of 0.0.0 in the target file by editing in XML or Text Editor, like this:

<location includeMode="planner" includeAllPlatforms="false" includeSource="true" includeConfigurePhase="false" type="InstallableUnit">
  <unit id="com.example.feature.group" version="0.0.0"/>
  <repository id="my_repo" location="http://my/repo/path"/>
</location>

By specifying a version number of 0.0.0 in the target file you should pick up the latest version of the unit from the p2 repository.

That said, there are serious disadvantages of using this lazy (more about name below) way of specifying versions. It makes it very difficult to go back and rebuild older versions of your project because the older version will pull in the latest version of the dependency from the p2 repository instead of the correct version.

Use Target Platform Definition DSL and Generator

Instead of editing with the target editor, use the excellent "Target Platform Definition DSL and Generator" instead. It allows you to edit the target files more sensibly. In the above case, you can use the lazy version keyword to specify you want 0.0.0 as the version number. It would look like this:

location "http://my/repo/path" my_repo {
    com.example.feature.group lazy
}

Best of Both Worlds

The generator can be invoked at the command line (e.g. from pom.xml), this should allow you to leave off the version number in the .tpd file. With no version number in the .tpd file, the generated .target file will have the resolved version number to the latest version. If you preserve the generated .target file as part of your build artefacts, you will be able to rebuild older versions of your software against the correct dependencies.

Emelina