EclipseCon 2011 has come and gone, and I was lucky enough to be there. One of the nice things about going to speak at EclipseCon is the opportunity to see the other projects and technologies congregating around the Eclipse Foundation. I'll blog later about the talks I gave, but one of the things I tried while down there was using Maven and Tycho to build a p2 repo.
I picked one of the Orion features. My efforts can be seen in git://git.eclipse.org/gitroot/e4/org.eclipse.orion.server.git in the mavenExperiment branch.
There are some things maven needs to get started, which I put in a parent pom. A tycho-version property (I needed the 0.11.0-SNAPSHOT so a javax.servlet import package could resolve) and a pluginRepository so I could load that version of tycho. The repositories to build from: 3 p2 repos in my case. Some build plugin configuration I copied from the tycho RCP example, including configuring the qualifier with <format>'v'yyyyMMdd-HHmm</format>
The plugin poms are straight forward, as I want manifest first builds. You just need to make sure the versions and IDs match. Same with feature poms.
To generate the p2 repo you need to specify 2 things. An eclipse-repository pom (relatively straight forward, although I've copied in extra maven plugin statements). And a category.xml that lists the features you want in the repo.
I list all of my modules in my aggregator pom, and then run "mvn clean install".
Ta da: a p2 repo with my 2 features in it.
I'm still encountering some problem either with my configuration or with tycho itself. I open bugs for the $HOME/.m2/repository interfering with a second build: https://issues.sonatype.org/browse/TYCHO-606 and trying to add extra categories to the p2 repo using category.xml results in the generated repo missing things: https://issues.sonatype.org/browse/TYCHO-605
I think there's some work to be done on the Execution Environment side as well, although JIRA appears to be down at the moment.
Once the build has been configured to run with maven, the next person just has to check out the code and "mvn clean install". That looks promising. I'm glad I had the opportunity to try out maven and tycho.
Monday, March 28, 2011
Thursday, March 10, 2011
A working state from a p2 update
In one of our recent build/update cycles we made a change that was source compatible but not binary compatible. In this case (there are no errors anywhere) it's easy to miss that you need to tag the consuming bundle as well.
The build ran fine, but the previous build's consuming bundle was used when creating the update site (since we didn't tag that bundle, the qualifier did not change).
When an unsuspecting co-worker updated to the latest build, his system would no longer start at all with a number of java.lang.NoSuchMethodErrors.
So how do you fix your install, given that you can't even bring up the workbench? As it turns out, p2 can help you. The SDK profile saves its state on each installation change. You can usually find this information in:
Then you just need to pick the last stable version of your installation, and you can revert your install and restart your system.
Obviously you'll need to use a different eclipse install and the necessary -destination arguments if the corrupt bundle is *in* the director part of your install's p2 framework :-)
The director won't run this command without specifying a -repository, but it's not important which one you use so I used the installations own SDKProfile repository.
For more director information see p2 director.
The build ran fine, but the previous build's consuming bundle was used when creating the update site (since we didn't tag that bundle, the qualifier did not change).
When an unsuspecting co-worker updated to the latest build, his system would no longer start at all with a number of java.lang.NoSuchMethodErrors.
So how do you fix your install, given that you can't even bring up the workbench? As it turns out, p2 can help you. The SDK profile saves its state on each installation change. You can usually find this information in:
bash-4.1$ ls eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile 1299467192263.profile.gz 1299499722731.profile.gz 1299761082054.profile.gz 1299467192395.profile.gz 1299499723473.profile.gz 1299761705917.profile.gz 1299467285942.profile.gz 1299499764937.profile.gz state.properties 1299467287251.profile.gz 1299500329056.profile.gz
Then you just need to pick the last stable version of your installation, and you can revert your install and restart your system.
eclipse/eclipse -noSplash \ -application org.eclipse.equinox.p2.director \ -repository file:$(pwd)/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile \ -profile SDKProfile \ -revert 1299499722731
Obviously you'll need to use a different eclipse install and the necessary -destination arguments if the corrupt bundle is *in* the director part of your install's p2 framework :-)
The director won't run this command without specifying a -repository, but it's not important which one you use so I used the installations own SDKProfile repository.
For more director information see p2 director.
Subscribe to:
Posts (Atom)
