The simple RCP product build

A question came up the other day on the difference between building small RCP apps pre-3.5 with the delta pack, and what to do in the new p2 world. So I did what everybody wishes they could do ... I cornered Andrew Niefer and asked him a few questions.

I created the standard RCP mail app and then a feature to contain it. The I created a .product file that includes the RCP mail feature and org.eclipse.rcp (a few more plugins than the mail app technically needs, but a good starting point). The .product also had some branding information/splash information in it.

I want to use a product build, as I'm building a product. If you're going to be creating your runnable repo from p2 repos, you don't set baseLocation any more. You care about 2 different properties:

• repoBaseLocation - a directory where you can mirror your p2 repos, or at least the pieces you need.  You can create multiple repo directories under this location
• transformedRepoLocation - PDE Build will take your repoBaseLocation and convert it to a runnable repo (to be consumed by the build)

Out of the regular build properties, this looks like:

buildDirectory=${base}/buildDirectory
repoBaseLocation=${base}/repoBase
transformedRepoLocation=${base}/transformedRepos

You also need to set the location(s) of the repos you will consume, and provide a product file:

eclipsePlatformRepo=http://download.eclipse.org/eclipse/updates/3.6
product=${builder}/rcp_mail.product
runPackager=true
p2.gathering=true

There are other options that need to be filled in the build.properties file, but that's left as an exercise to the reader. The next step is to set up your customTargets.xml. Because I assume the defaults for most everything, I don't have to copy out the template any more. For the p2 part of this exercise, just provide a preProcessRepos target

<project name="RCP Mail customTargets overrides" >
        <import file="${eclipse.pdebuild.templates}/headless-build/customTargets.xml" />

        <target name="preProcessRepos">
                <p2.mirror source="${eclipsePlatformRepo}" destination="${repoBaseLocation}/launchers">
                        <iu id="org.eclipse.equinox.executable.feature.group" version=""/>
                        <iu id="org.eclipse.rcp.feature.group" version="" />
                </p2.mirror>
        </target>

        <target name="postFetch">
                <replace file="${buildDirectory}/pluginVersions.properties" token="HEAD" value="${timestamp}" />
        </target>
</project>

org.eclipse.rcp.feature.group will mirror everthing you need for the org.eclipse.rcp feature, including the different platform fragments. org.eclipse.equinox.executable.feature.group will mirror the features that a product build can use to create your specific executables (rebranded or renamed, etc). PDE build will run the p2.repo2runnable step for you automatically.

Now you just need to run it:

eclipse/eclipse -application org.eclipse.ant.core.antRunner \
 -buildfile eclipse/plugins/org.eclipse.pde.build_3.6.0.v20100603/scripts/productBuild/productBuild.xml \
 -Dbuilder=/opt/local/rcp/builder  \
 -Dbase=/opt/local/rcp/base \
 -Dtimestamp=20100924-1100

This generate 4 zips (the platforms from my configs= property) although the names were a little odd, they were complete product zips for each platform.

Thank you to Andrew for the examples and tips I used to set this up.

Import Projects from a Repository

I've been focused on e4/4.0 lately. A lot. Both on the modeled workbench infrastructure and on building the darn thing (I worship the ground Kim M walks on). But I discovered a feature in 3.6 that I find extremely useful. When importing plugins and fragments from any target platform, you now have the option to import them from (the CVS) repository.

Being able to import the source has always been useful if you want to see how something in JDT or PDE works, or if you want to tweak part of the behaviour of one of your plugins, or for the really brave, you want to see if you can fix a bug :-)

But while useful it has always been a problematic feature. Creating source bundles always lost the shape of the original project and its build information, since the source bundle is a representation of the binary bundle. The more complicated the layout or building of the original bundle, the further away the source bundle is from the actual plugin project.

And so "Import Project from Repository". Just grab the project. You have the option to take the tag that was used to build the bundle (the exact source in your target) or just grab it from HEAD (to get the latest). Fiddle with it. Reset it. Generate a patch for a fix that would actually apply to the bundle source! The committers will love you forever!!

Well, perhaps that's a little over the top, but I think it's a handy feature for plugin developers that need to poke around in someone else's bundles.

Maybe a comment policy

As much as I do enjoy the comments I get from such as "佩GailBohanan1蓉" I've decided to try comment moderation so I don't have to continually delete comments from my posts. So what's my moderation policy:

1) no adult site links
2) keep the language clean
3) stay more or less on topic

#1 is obvious

#2 well, this is a work related/technical blog. While sometimes eclipse might drive us to distraction, those moments can be captured using English (or the Language of your choice)

#3 this has a lot of flexibility (discussions will go wherever they want), but it is mostly in place to keep eclipse blogs from digressing into discussions about Chris Aniszczyk's Armani jorts... :-)

PDE will tell you

We're experimenting with a lot of new technology in e4 and with different development paradigms. It's all good. But development on 3.x and with PDE will continue for many years to come, and PDE has some often overlooked tools that can really help you develop your plugin and find your IDs.

1) Plug-in Selection Spy (ALT+SHIFT+F1) activate a part or dialog page and hit ALT+SHIFT+F1. Plug-in spy will open a popup and describe the contents (at least it will try). It will provide information about what ID and implementation class the focus part has, as well as which plugin contributed it, what are the active identifiers (menu, help, etc) and what type is the selection that part publishes.

2) Plug-in Menu Spy (ALT+SHIFT+F2). Hit ALT+SHIFT+F2 and then pick a menu item. The popup will provide information about where that item lives, action ID, command IDs if available, etc.

3) In the PDE Editor, the Browse... button. Many extensions need IDs provided in another extension. For example a menu contribution (org.eclipse.ui.menus) needs a commandId (org.eclipse.ui.commands). If you are asked to fill in an ID and there is a Browse... button, use it. It will give you a filterable list, and cuts down on cut&paste errors.

These 3 are examples of PDE tools that you probably don't use very often, but when you need them they're *really* helpful.

e4 and "early" compatibility

As the model for the e4 workbench stabilizes we're back working hard on the compatibility layer. Right now it consists of the gutted org.eclipse.ui.workbench plugin. The idea is to support the API we have in org.eclipse.workbench, but based on the e4 workbench model and e4 services, instead of the mass of internal code in parts, perspectives, and presentations.

We're taking a 2 pronged approach. Creating an e4 IDE application and slowly adding useful views and actions, seeing what is needed to bring them up. We want to support a useful number of views (like the Project Explorer and Problems view) sooner rather than later.

We're also running the org.eclipse.ui.tests.api.ApiTestSuite (after cleaning up internal references in the tests themselves with the aid of a tweaklet). ApiTestSuite covers the most common scenarios (opening and closing windows, perspectives, views, and editors), and supporting our API is a good way to help 3.x plugins run on e4 with the compatibility layer.

There's always a lot to do, so if you are interested please check out http://wiki.eclipse.org/E4/Compatibility/Running_the_compatibility_layer. You can also post to the e4-dev mailing list, or join us on irc at irc://freenode.net/#eclipse-e4