Eclipse Yoxos Services Downloads Blogs About
Home > Blogs >

Archive for November, 2009

on Nov 9th, 2009EclipseRT Days and DemoCamps

Autumn is in the air (wouldn’t know it here.  17C!) so it must be time for the Fall line up of “Eclipse days” and demo camps. This year I’ll be at two Eclipse Days and three demo camps!

First we have the EclipseRT days in Austin and Toronto. Are you in the area? Come on by and tell people about your use of Eclipse in runtime scenarios or find out how others are getting the power of Eclipse modularity and all that good stuff in their clients, servers and embedded devices. There are talks from the projects, talks from the community. Fun for kids of all ages.

Due to a happy coincidence of travel and cosmic forces I’ll also be at the DemoCamps in Toronto, Vienna and Ottawa. Should be very cool.  I’m particularly excited to see one of these fabled European DemoCamps in action.

Its going to be a busy few weeks. Hope to see you at one or more of these events.

on Nov 7th, 2009Tips for Successful PDE Product Builds

Recently I had the pleasure of updating the way Yoxos is built.  Like a lot of Eclipse based applications, the Yoxos build was feature based and we naturally use the normal headless PDE/Build scripts to do this.  To make things a little easier to extend, I decide to use the new product based builds (new is relative, as product builds have been around since about Eclipse 3.2).

There are a number of subtle points that I think are worth mentioning.

1. PDE/Build does not checkout the .product file

As you may know, when you specify a product build, you use the following build.property setting:

product=/some_bundle_or_featre/your.product

However, PDE/Build does not fetch that bundle or feature from your SCM system (See Bug: bug 159128)

To get around this problem, you can use a post setup custom target like this:

 <ant antfile="${genericTargets}" target="fetchElement">
    <property name="type" value="feature">
    <property name="id" value="org.feature.containing.product.file">
 </ant>

2. Platform specific products require platform filters

When I converted to product builds, I decided to build platform specific products (with platform launchers, etc…).  If any of your features contain platform specific fragments, make sure you set the conditions under which the fragment can be installed.

fragments1 Tips for Successful PDE Product Builds

If you don’t set these, and the bundle or fragment has set platform filters, then at build time the fragment won’t be included, however, the feature will still require it.

3. Make sure your delta pack matches your platform

If you are building a product that targets a number of different architectures, then you are likely familiar with the delta pack.  It’s very important that you use the delta pack that matches your platform version (i.e. don’t use the Eclipse 3.5.1 delta pack with Eclipse 3.5.0). At build time, the executable features (found in the delta pack) has a requirement on the org.eclipse.equinox.launcher bundle.  This bundle comes with the platform and the versions must match.

4. Make sure all your bundles are contained in a feature

If your product is feature based, make sure all the bundles that constitute your product are listed in a feature.  This is one of those errors that manifest itself as it worked when I ran it from Eclipse, why doesn’t it work on the build machine. The reason for this is you likely had all your bundles in your workspace when you launched from Eclipse, so PDE was able to track down these dependencies for you.  When you build on the server, only things that are explicitly included are fetched for building.

5. Check your javacSource setting

If you are using newer java constructs like generics (again, new is relative as these constructs have been around for over 4 years), make sure your java settings reflect this. However, changing your compiler settings in your workbench will have little effect on a server 1/2 a world away.  To influence the compiler settings during build, you can set the following properties in your build.properties file:

# Default value for the version of the source code.
# This value is used when compiling plug-ins that do not set the
# Bundle-RequiredExecutionEnvironment or set javacSource in build.properties
javacSource=1.5

# Default value for the version of the byte code targeted.
# This value is used when compiling plug-ins that do not set the
# Bundle-RequiredExecutionEnvironment or set javacTarget in build.properties.
javacTarget=1.5

Happy building!

on Nov 3rd, 2009An Introduction to OSGi in Victoria

Have you heard about OSGi but are not sure about the details?  Are you wondering what this brand new Java technology is all about?  Are you concerned that its footprint is too large for your specific application?  Are you not sure if OSGi solves a problem you have? Is OSGi a no go for you because you don’t use the Standard Widget Toolkit (SWT) or any other Eclipse technology?

If you considered answering yes to any of these questions, or are just curious about OSGi… please join us at the Vancouver Island Java User Group (VIJUG) on November 26th in Victoria, BC where I will be giving a introduction to OSGi. You might be surprised to learn that:

  • The OSGi specification is over 10 years old
  • OSGi was originally designed for embedded devices (and it’s small footprint reflects this)
  • OSGi is a framework that enables highly modular systems and a consistent programming model whether you are developing for the server, client or mobile devices
  • While Eclipse does make use of OSGi, there is no requirement on any Eclipse technologies when using OSGi.  There are even several implementations of OSGi specification to choose from

For more information, please see the announcement page.

on Nov 3rd, 2009Git Mirrors at Eclipse.org

Good news everyone, Git mirrors are going live at Eclipse.org

gitmirrors 300x93 Git Mirrors at Eclipse.org

Please give them a whirl.

If you find any issues, please state them on this bug.

on Nov 2nd, 2009Extending Google Wave

A few days ago i gave Google Wave a spin. I was already quite familiar with the conversation features and thought it was time to extend the wave by some custom functionality. I therefore created a robot extension to enrich a wave conversation with some additional functionality. The idea was to fetch details about an eclipse bugzilla bug when a bug is referenced in a wave conversation. To see how that works check out the screencast below (click the image).

buggy Extending Google Wave

The development of the robot was rather straight forward. The robot itself is deployed on the google appengine and communicates with the wave via HTTP REST calls and uses JSON as its language dialect. The communication was encapsulated in a client library which did have some bugs though. Working with the app engine was a joy i must add. Deployment and management of the application was quite cool. Fetching the bugzilla data was also easy as it is able to spill out bug details in XML format.

All in all i am very excited to see how easy it is to provide additional wave capabilities and am hopping that the wave will make its way into every days life. Also the appengine gets a thumbs up from me (at least for such simple tasks as this wave robot). You can fetch the source of the robot project here.

on Nov 2nd, 2009Eclipse 3.6 M3 (Helios) available for download

Milestone #3 for Eclipse 3.6 is now available for download.

Here are the noteworthy changes up this milestone:

My favorite change is the new support for software installation while running & debugging. This should be a huge time-saver for all developers who are adding p2 support to their RCP apps. It permits to do install operations in a launched application. Previously this was only possible after regularly deploying the RCP application via the export wizard.

launch config Eclipse 3.6 M3 (Helios) available for download

    © EclipseSource 2008 - 2011