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 eclipse.org 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
features
plugins
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"?>
<site>
<category-def name="all" label="Maven osgi-bundles"/>
<iu>
<category name="all"/>
<query><expression type="match">providedCapabilities.exists(p | p.namespace == 'osgi.bundle')</expression></query>
</iu>
</site>
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":
<plugin>
<groupId>org.sonatype.tycho</groupId>
<artifactId>maven-osgi-packaging-plugin</artifactId>
<version>${tycho-version}</version>
<configuration>
<deployableFeature>true</deployableFeature>
</configuration>
</plugin>
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.
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:
- Packaging type eclipse-repository shall support publishing of categories, features and bundles
- Demo RCP Application and P2 Updateable Eclipse Product
- itp04-rcp demo application
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, dk.sorokin.maksim;bundle-version="[2.0.0,3.0.0)",
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.
UTF-8 File Encoding in Eclipse
By default Eclipse interprets files as being not UTF-8. The reason for that is that file encoding is inherited from JVM property file.encoding, which is usual set to something else. That is why you see “Text file encoding” being“ being Cp1252 (or something similar) when you right-click on a file in Eclipse.
To change it, go to Window->Preferences, Choose General->Workspace in the left menu. And change “Text file encoding” from “Default” to “UTF-8”.
Eclipse “Favorites” and JUnit 4 Static Imports Revised
After some time of using static imports workaround for JUnit 4 and EasyMock described earlier I came to the conclusion, that editing import "favorites" is not a good idea.
The problem is that when you include a class with static methods in Eclipse "favorites", then in Content Assistant you see hundred of those static methods. This maybe somewhat inconvenient. Moreover, Content Assistant hangs a bit longer before appearing.
From now on I am directly using class name like Assert.assert.. or EasyMock.expect.. instead of using static imports.
Development With GlassFish v3
GlassFish is becoming new de facto standard in Java applications. Development with new GlassFish v3 server and Eclipse now is really fast and comfortable. Server starts within a second, Java EE 6 is fully supported and hot code replacement works as it should.
Eclipse and JUnit 4 Static Imports
Importing static JUnit 4 annotations in Eclipse is somewhat boring. The thing is that by default Eclipse doesn't import static fields or methods.
The most optimal way is to add junit.framework.Assert to "favorite" static types. Then, assertion methods will be seen in editor.
How to:
- Menu -> Window -> Preferences
- Java -> Editor -> Content Assist -> Favorites
- New Type:
junit.framework.Assert
P.S.: idea taken from http://blog.xebia.com/2008/10/12/eclipse-tip-keep-static-imports-for-junit-4/