I want to introduce you to a new concept called WAR Products. They are similar to Eclipse Products but much more lightweight. All you have to do to export a RAP application is to create a .warproduct based on a working launch configuration and press ‘export’. The exported .war file is ready to deploy. There is a function included that validates your .war file content before you’ve exported it. If you don’t believe me,  watch the screencast below and see for yourself.

You can use the tooling right now, but please keep in mind that we are still polishing. The final goal is to contribute it back to PDE, but there are still a few things to do before we make the contribution.  One of those items is to get your initial feedback so when you use the WAR Products tooling, please be sure submit your feature requests or file bugs and help us to continue to improve the tooling.

Here is what you need to do to use the WAR Products tooling:

1. Install the tooling from this repository into your IDE: http://download.eclipsesource.com/~hstaudacher/warproducts/
2. Set up your target. You need to download these bundles and add them to your target installation. (Don’t forget to refresh the target afterwards.)

Again, comments, bugs and feature requests are appreciated!

At this point I want to thank some people. First of all, Rüdiger Herrmann for great mentoring and the whole RAP team for all the nice evenings in the beer garden. Not to forget Simon Kaegi, Scott Lewis and Chris Aniszczyk and the rest of the Equinox and PDE teams for tuning up the Product concept. Your changes made things much easier.

And, I hope that you will find WAR deployment and creating WAR Products not just easier, but completely pain free!

A worker’s paradise is a consumer’s hell.

With the Eclipse Examples project we wanted to provide a few exemplary projects to show how to use different projects. In theory a nice idea, but practically I don’t see that this effort was very successful. Wayne and me discussed some ideas back in 2008 but without a concrete outcome.  Thinking about this topic after EclipseCon, my current thought was to provide easy ways for our consumers to try out the bits and pieces of all the projects. What I constantly run into though, is that you need to do so many things  before you can get started, like setting up a target platform, making your examples depend on the right bundles, using the right extension points/services/etc, creating launch configurations. Many projects already helped themselves by providing examples using PDE templates. That’s the way I’d like to tell newcomers how to get started and would push this even a little further – the idea is to provide some infrastructure in the Examples project to help others setting up their examples. The projects just provide example bundles, maybe a target definition, a launch configuration and a cheatsheet or something. In the end, the user should be able to try out another Eclipse technology within 2 clicks: New Example > That technology, run!

Basically PDE already provides many of these things but it’s not yet at the point I would love to see it. It’s still too complex for consumers to create target platforms (I know what I’m talking about), create their launch configs and get started with the examples. While there are still some hurdles to jump, I think our users and consumers would thank us for getting them up to speed in seconds. It should even be interesting for non-OSGi related examples as other projects thought about something like this for years. I don’t see a chance to have this ready for Helios, but I’m pretty confident that we could do something like this in the timeframe for the I… release train. Would other projects be interested in such an approach to distribute their examples? Please leave a comment on this bug if you do so to collect ideas, wishes and requirements.

Target Platform Templates

For runtime projects, such as Riena, RAP and Equinox, the first hurdle a developer faces is to set-up the appropriate target platform. A target platform is the collection of bundles that are available during compilation. Obviously if you ship runtime components they must end up in there to be available for compilation.

You can make this much easier for others by contributing a target platform template to the “New Target Definition” wizard. A developer can then select an entry in the “Template” drop-down and will instantly receive a pre-configured target definition. Much easier and less error-prone that recreating the target definition manually from step-by-step instructions.

Since the target definition’s payload can be provisioned over http, the developer only has to click on “Set as Target Platform” and is done. For details refer to the org.eclipse.pde.core.targets extension point.

Project Templates

Another way to help developers with their first steps is to provide a project template. This hooks into the last page of “New Plug-in Project” Wizard and pre-populates a new project with source code, binary content and appropriate plugin.xml and MANIFEST.MF files.

The templating mechanism has a lot of depth as you can manipulate data-models to dynamically craft the MANIFEST.MF and plugin.xml files. You can also define placeholder variables, such as $pluginId$ and use them in source templates. There are mechanisms to tie these variables to UI elements in the wizard pages. The developer documentation on the matter is somewhat superficial. At the moment your best bet is to check out and study the org.eclipse.pde.ui.templates project from the Eclipse CVS (/cvsroot/eclipse/pde/ui/org.eclipse.pde.ui.templates). It contains the templates that ship with the IDE and therefore plenty of examples. Complement this by reading the specification of the org.eclipse.pde.ui.pluginContent extension point and this introductory article on developer works.

The offending lines where here:

and more precisely:

You see, while this may seem fine to all you Java 1.6 developers out there, p2 is set to run on CDC-1.1/Foundation-1.1 and JSE-1.4.  I know in the Java SE space, 1.4 is long past end of life, but in the embedded space, it is still very common.  (Remember, these embedded devices require much smaller VMs, otherwise we complain that our small devices are two slow /sluggish / expensive, etc…) — and p2 is a provisioning platform that operates just fine on embedded devices.

With Eclipse, you can set your Execution Environment (EE) and point to a variety of JDKs.  This allows you to “single source” your code so the same code can run on a server with Java 1.6 installed and a small device with a Foundation VM.  However, I don’t have a Foundation VM .

Lucky for us, an EE description for several JDKs is available in the Eclipse CVS repository:

Once you checkout the project, you can add this to your list of known JREs

Now I get all the Java tooling (content assist, compile errors, etc…) for the Foundation 1.1 VMs.

In case you’re struggling with these issues too –  and working on RAP applications, please add your vote to bug 267975 so we can use Picasso on both runtimes.

To install PAX Runner, simply add their repository via software installation wizard.

There’s an important thing to note about PAX Runner. When you’re self-hosting with a PAX Runner based framework, your bundles will be deployed before executed. This may cause launching to take a bit longer than you’re used to depending on the size of your application. This is different from the traditional PDE workflow where we don’t have a deployment step when self hosting because Equinox provides us with some great hooks to skip that process. If you’re curious how this works under the covers, PDE instructs Equinox where to look for classes for the various bundles in your workspace (usually in the bin/ folder). This is known as the development time classpath and as far as I know, Equinox is the only framework to support this type of classpath (I filed a bug against Felix awhile ago).

On the whole, I recommend you give PAX Runner a try.

Also, if you have any ideas on how PDE can better support other frameworks, come talk to us.

From IDE to RCP to Runtime. From Platform to e4 (e.g., the future).

When we evolve, it gives us an opportunity to think about our lexicon.

I recently sent an email to the Eclipse PMC entertaining the idea of deprecating our usage of the word ‘plug-in’:

On last week’s Eclipse Architecture team call, I brought up the ‘plug-in versus bundle’ naming issue. This naming issue also came up at this week’s PDE team call where we had consensus that deprecating the word plug-in would be a good idea. Furthermore, the new components in PDE (e.g., API Tools) have gone out of their way to not call things plug-ins. I also know the Equinox p2 team struggles with naming problems (e.g., calling things software).

…

My proposal is that we adopt “bundle” and deprecate “plug-in” as the official module term.

If you’re interested in this, please comment on this bug. There’s also another bug open that wants to rename RCP if you’re interested in that too.

I would like to hear from the Eclipse and OSGi communities on what they think. Good or bad idea?

Would you welcome the change?

The method disposeImageButtonImages(ImageButton) from the type
ScaledWidgetFactory refers to the missing type ImageButton

Ok, a compile error, no big deal… the better part of a day later I finally had this solved.  Just so nobody ever has to deal with this particular error again, I thought I would post a small debugging tip you can use.  But first, some background on my day (after I saw the error):

1. Ensure export from the UI works… yes!
2. PDE/Build defines a variable called pluginPath that you can use to point at additional plugin locations.  Since the missing type  –ImageButton in my case — was in a pre-compiled bundle that exists in my target, I assumed this variable was set wrong.  I tried different separators, bundle ordering and directory locations (with and without spaces in the name). I even tried putting the bundle in my baseLocation.  No dice.
3. You can debug Ant scripts using PDE/Build.  There are a few things that you must setup first, but after I did this I was able to debug the script and ensure that the “so called ‘missing’” bundle was indeed in my classpath.
4. At this point something hit me — the compile errors is on the method call, not the import statement. That means that the compiler found the type on import, but not when the method was called…. strange!
5. In this particular example we are using Import-Package as opposed to Require-Bundle. Maybe I found a bug… I changed all the code to use Require-Bundle… No Dice.
6. Because build can be finicky, and and a typo can cause all sorts of problems, I started again… Same problem.
7. Read a story to my daughter. (Best part of the day, by far)
8. Back to work… This time, I started making small changes in different bundles, copying them over, and trying again… At one point, IT WORKED!
9. Revert the changes… IT WORKS! — Note: That’s not good
10. Start over, .. IT FAILS… make the same changes I did above.. IT FAILS!
11. Curse
12. Notice something.. when I copy the directories over, I am copying a bin/ directory that may (or may not) have fully built .class files.
13. Delete the bin/ directory .. IT WORKS!

In fact, the problem will happen very infrequently.  It only happened because I was copying bundles from my workspace (not fetching them from CVS), and in some cases, the bundles were not fully built.

So, the lesson: If you get strange compile errors using PDE Build, try deleting the bundles bin/ directory.

Thanks goes out to Andrew Niefer who once again came through with a much better way off structuring my build.

I’ll discuss four main areas around API management that API Tools can help you with.

API Comparisons

I have seen some discussion of people wanting to know what new APIs were part of the Eclipse Galileo release. While it’s pretty easy to see the new and noteworthy items for the latest Eclipse release, it’s difficult to dive into and see what actual classes and methods were modified. To help alleviate this problem, PDE API Tools has the ability to produce API comparison reports to show exactly what has changed. I have mentioned the API Tooling view in a past blog entry for those who are interested.

API Compatibility

One thing that’s important is being able to see binary compatibility issues between a build and a baseline. This is currently possible within the Eclipse IDE if you use PDE API Tools in the workspace, however, if you wanted to generate a report via an Ant task you can do that. As a sample, I generated a report against Eclipse 3.4.2 and Eclipse 3.5:

<?xml version="1.0" encoding="UTF-8"?>
<project name="api_analysis_reporting" default="run" basedir=".">
    <property name="baseline" value="/Users/chrisaniszczyk/eclipses/eclipse-SDK-3.4.2/eclipse" />
	<property name="profile" value="/Users/chrisaniszczyk/eclipses/eclipse-SDK-3.5/eclipse" />
	<property name="report_location" value="${baseline}/api" />
	<property name="html_report_location" value="${baseline}/api-html"/>
 
	<target name="run">
	    <apitooling.analysis
	      	baseline="${baseline}"
	    	profile="${profile}"
	      	report="${report_location}"
	      	debug="true"
	     />
	    <apitooling.analysis_reportconversion
	      	htmlfiles="${html_report_location}"
	      	xmlfiles="${report_location}"
	      	debug="true"
	    />
	  </target>
</project>

API Freeze

Another aspect that’s important to Eclipse is the concept of an API Freeze.

Towards the end of the Eclipse release, we implement an API Freeze which means that no new API can be added or modified after this point. Why have an API Freeze? Well, it helps ensure stable APIs for consumers looking to adopt a new version of Eclipse. From a producer point of view, how do you ensure that the API Freeze is actually enforced? Developers are human and make mistakes. Developers can be also be sneaky by modifying API.

To help enforce an API Freeze, PDE API Tools has the ability to produce freeze reports:

<?xml version="1.0" encoding="UTF-8"?>
<project name="api_freeze_reporting" default="run" basedir=".">
    <property name="baseline" value="/Users/chrisaniszczyk/eclipses/eclipse-SDK-3.4.2/eclipse" />
	<property name="profile" value="/Users/chrisaniszczyk/eclipses/eclipse-SDK-3.5/eclipse" />
	<property name="report_location" value="${baseline}/api" />
	<property name="html_report_location" value="${baseline}/api-html"/>
 
	<target name="run">
	    <apitooling.apifreeze
	      	baseline="${baseline}"
	    	profile="${profile}"
	      	report="${report_location}"
	      	debug="true"
	     />
	    <apitooling.apifreeze_reportconversion
	      	htmlfile="${html_report_location}"
	      	xmlfile="${report_location}"
	      	debug="true"
	    />
	  </target>
</project>

As part of the Galileo release, we used freeze reports as a way to ensure API stability as we converged.

API Usage

From the consumer point of view, it’s interesting to see how people are consuming your APIs. To help with this, API Tools has the ability to run usage reports against a set of bundles. Awhile ago, I blogged about this topic and produced a report against most of the bundles included in the Galileo release:

<?xml version="1.0" encoding="UTF-8"?>
<project name="api_use_reporting" default="run" basedir=".">
    <property name="baseline" value="/Users/chrisaniszczyk/eclipses/eclipse-galileo" />
    <property name="report_location" value="${baseline}/api" />
	<property name="html_report_location" value="${baseline}/api-html"/>
 
	<target name="run">
	    <apitooling.apiuse
	      	baseline="${baseline}"
	    	proceedonerror="true"
	      	report="${report_location}"
	      	considerinternal="true"
	      	considerapi="true"
	      	debug="true"
	     />
	    <apitooling.apiuse_reportconversion
	      	htmlfiles="${html_report_location}"
	      	xmlfiles="${report_location}"
	      	debug="true"
	    />
	  </target>
</project>

I hope this helps and allows you to understand and adopt PDE API Tools.

Also, the PDE team is currently in the planning stages for the next release.

Please file any bugs if you have issues or suggestions so the PDE team can act on them.

Support the tools that support you. The best $35.00 you will ever spend.

Number 6 on my Top 10 list is the new Install Into Self option. While many people view the Eclipse SDK as an excellent Java development environment; it’s the extensible nature of this environment that makes it so powerful. Eclipse is assembled from 100′s of plug-ins, and while you may commonly use other peoples plug-ins, the true power of Eclipse comes when you start to develop your own. Before Galileo, the steps for building / testing / deploying / installing your own plug-in were quite cumbersome. This has all changed in Eclipse 3.5.

Using Eclipse 3.5 you can quickly develop your own plug-in (maybe it’s a new static code analysis view or an awesome new twitter client – All the cool kids are building twitter clients these day), and deploy it directly into your running instance. This makes development / testing / deploying much easier and enables all developers to “eat their own dog food”.

I consider this feature a “game changer” as it completely changes the way I work with Eclipse. Kudos for this feature go to Curtis Windatt with help from John Arthorne for p2 side of things. Thanks guys!