Even though I’ve been involved in the Eclipse community for around 5 years, I’m still amazed by the projects that are hosted under the Eclipse umbrella. As an “insider”, I have a pretty good overview of many projects and at least a rough picture of all the other cool stuff. While I love working with EclipseRT technologies like Equinox, RAP, EclipseLink, ECF or <insert your project here>, I always find myself in the same situation.  This stuff is awesome but do users really get the point of what’s possible? Learning a new technology is always hard, but if you want to develop enterprise-ready, scalable and vibrant platforms using Eclipse components, there are so many obstacles to overcome. You need to have at least a clue about OSGi/Equinox, Extensions and their corresponding Extension points (for each for your consumed modules) and many other things. I don’t want to say that Eclipse is too complicated (which is a topic for another post anyway), but what I would really like to see is a better way to get our future consumers up to speed. As Esther Dyson once said:

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.

Tags: consumers, eclipseRT, equinox, examples, OSGi, p2, pde, rap

A nice thing about Eclipse PDE is that it has mechanisms to make it very easy for developers to get started consuming your frameworks. Here are two of them.

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.

Tags: pde, tips

Lately I have been working on (and committing) a repository analyzer tool for p2.  It is meant to help you validate your repository against known problems and common mistakes (missing version numbers, two IUs with the same ID/Version, etc…).  After cleaning up the code I finally committed it.  Within a few minutes of committing it, Andrew starting pinging me to let me know I introduced a compile error. (Thanks Andrew).

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.

Tags: OSGi, pde, tips

Whenever I’m working on UI stuff, something always goes terribly wrong Sometimes it’s only a margin or padding, other times it a composite that crosses my path. I was pretty happy that Chris Aniszczyk and Simon Archer hacked together Picasso, which helps you to identify some of these layout issues. As you may know, most of the time I work on the Rich Ajax Platform (RAP) and come across the same issues. As Picasso was originally intended to work for RCP, it’s not a long way to get it working for RAP.

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.

Tags: eclipse rap, layout, pde, picasso, rap, Single Sourcing, tips, ui

If you’re using Eclipse for OSGi development, there’s a neat utility that you can use to help you run your OSGi application on a variety of frameworks. PAX Runner uses the PDE org.eclipse.pde.ui.osgiFrameworks extension point to supply frameworks.

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.

Tags: OSGi, pde

One of the great things about Eclipse is that it evolves, it’s not static. We reinvent ourselves.

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?

Tags: OSGi, pde

Yesterday I spent the day working on examples of how PDE Build can be used to build OSGi bundles.  I was setting up builders, copying files from my workspace to my builder, and running builds.   Early in the morning I was faced with the follow:

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.

Tags: pde, pde build, tips

Recently, a few people have come to me ask how Eclipse maintains its API and versions. The intent of this question was to see what lessons there are to be learned for other OSGi-based applications. If we step back a bit, in essence, Eclipse is a large OSG application. On top of that, Eclipse is a platform where people build their own OSGi applications on… it’s an OSGi party. As a result, there are many people dependent on the API Eclipse produces so the management of this API is important. If breaking API changes were common, people would have less desire to build on the platform. To help with this problem, Eclipse developed PDE API Tools.

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.

Tags: api, galileo, OSGi, pde

As readers of my blog are no doubt aware, I have been counting down the Top 10 Galileo features that I’m most excited about. Galileo is the name of this years “Eclipse Release Train”, the simultaneous release of 33 Eclipse projects. Galileo will available for download on June 24th, but “Friends of Eclipse” get it sooner. Friends of Eclipse is a donation program setup by the Eclipse foundation.

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!

Tags: galileo, pde

Awhile ago, I blogged about PDE API Tools and the usage scans feature. In honor of the Eclipse Galileo release, I decided to run the usage scan tool and generate a report against a good portion of the release to see if anything interesting came up. I was particularly looking at what bundles were accessing internal code. I decided to look at the org.eclipse.compare bundle and noticed that PDT had some internal references:

If we dig deeper and look at a particular set of internal references, we notice org.eclipse.php.ui using various classes:

As an API provider (in this case, org.eclipse.compare) you have a couple questions you can ask yourself based on a report like this. Why are my consumers accessing these particular internal classes? Is there API I can point my consumers too that they can use instead of the internal classes? Should I make these classes API or craft API? And so on…

Does anyone else see interesting internal usage?

Do people want to see this type of report run against Galileo and future release trains?

For those who are interested, here’s the build script that I used to generate the report.

<?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>

Enjoy.

Tags: galileo, pde