Category Archive for: ‘Eclipse’

Eclipse RCP Demo: MP3 Manager Update

13

I have added two new projects for my Eclipse RCP demo application MP3 Manager:

  • com.siemens.ct.mp3m.ui.editors.id3.databinding:
    This editor is very similar compared with the com.siemens.ct.mp3m.ui.editors.id3 editor but uses rudimentary Eclipse data binding. I did not add validation so far but I have planned that for future releases.
  • com.siemens.ct.mp3m.ui.cheatsheets:
    This bundle implements a little cheat sheet and provides help for adding and deleting music folders.

You find the project home page at max-server.myftp.org/trac/mp3m where you get the information for anonymous svn access.

Have Fun

Kai

Advanced RCP Tutorial

I am very happy that my tutorial “Advanced Eclipse RCP” got accepted for EclipseCon 2008!

Eclipse RCP vs NetBeans Platform

7

I am a big fan of Eclipse RCP. But as a software engineer, it is always a good idea to know more than one platform. Since almost one year I am also interested in what’s going on in the NetBeans world and I have to admit, I find it pretty interesting, especially NetBeans Platform 6. Recently I wrote two articles for the German Eclipse Magazin, comparing Eclipse RCP and NetBeans Platform. Unfortunately these articles are only available in German, but if you can read German, part 1 and part 2 are available as PDF.
Here is my conclusion: In the two articles I tried to give a brief comparison of the NetBeans Platform and the Eclipse Rich Client Platform, using my little show case application (MP3 Manager), to compare a few common use cases. I explicitly did not want to make a list of + and -, how a specific issue could be solved better or worse with each platform. My intention was rather to show that many typical uses cases can be implemented using the one or the other platform. Both platforms offer a huge collection of reusable functionality and can help building mature, high quality Java rich client applications. The platforms have some fundamental differences as well as some very similar approaches. When it comes to a platform decision, I think it is very important to get the requirements for the rich client application first. There might be non-functional requirements like scalability, extensibility, reliability, usability and so on as well as functional requirements. After prioritizing the requirements, make the platform choice. Both platforms Eclipse RCP and NetBeans Platform offer a lot and help to build better Java rich client applications.

BTW, I submitted a LongTalk for EclipseCon about this topic. So far I have seen lots of interest in both the Eclipse community as well as the NetBeans community.

Are there any software engineers out there who have experience with both platforms? If so, I would be very interested in sharing experience.

What do you think when comparing both platforms yourself?
Have fun 🙂

Kai

Eclipse RCP Demo: MP3 Manager 3.3.1 available

MP3 Manager is a little project that I use as a playground for Eclipse RCP features. The whole purpose of it is to share information and best practices, how things are done using Eclipse RCP. Please help me improving the code base by trying it out and filing bugs or requests for improvements. It is all Open Source, with anonymous subversion access. You find more information at the project homepage. Here is a (probably incomplete) list of features:

  • Product Branding & Feature Branding
    • Custom Splash Screen
    • Blue and Orange colored demo brandings
    • Images/Icons and About Dialog
  • Internationalization English/German (full Eclipse 3.3 localization still work in progress)
  • New Look & Feel using the Presentation API
  • Loose coupling of views and editors
  • Tree view, tree-table viewsand a virtual tree view
    • Regular Label & Content Provider
    • Using an adapter factory
  • Multi-page editor
  • Use of Commands & Handlers
  • Local help system using the Jetty stack
  • Customized update functionality
  • A Wizard
  • Own Extension Points
  • And much more

Here is a little screenshot:

MP3M

Have Fun 🙂
Kai

OSGi with Eclipse RCP: Import-Package vs. Require-Bundle

I am a big fan of both, OSGi and Eclipse RCP. In terms of flexible modular architecture I prefer to use “Import-Package” rather than “Require-Bundle”. However, probably due to historical reasons, PDE supports “Require-Bundle” much better than “Import-Package”. And, in the current Eclipse 3.3 platform, split packages are used (I guess mostly for compatibility reasons). With my current RCP demo application, I have the following problem with switching to “Import-Package”: After putting my target platform in the list of “Automated Management of Dependencies” (Why is that not the default?, probably I file a feature request) and letting PDE compute the dependencies using “Import-Package”, my application does not run anymore.

I get the error:
java.lang.NoClassDefFoundError: org/eclipse/ui/progress/IProgressService.

Who has an advice or a best practice how generally to proceed here?

Eclipse RCP 3.3.1 and I18N

3

The last piece to complete my demo application’s port to RCP 3.3 would be the localization using different language packs. After one hour I gave up to make the 3.2.1 language packs work with my application. I filed a feature request (Bug id 205732) for that and hope that the new language packs will be available soon.

Eclipse RCP 3.3 update issue

5

I have updated my Eclipse RCP demo application using Eclipse 3.3. I ran into problems with the update mechanism, getting errors with regards to the feature org.eclipse.rcp. I already filed a bug (204075).

Steps To Reproduce:
1. Create an RCP-based application with update functionality
2. Include the feature org.eclipse.rcp in your own feature
3. Deploy your application to the local file system
4. Create a new version of your feature
5. Update your update site
6. Try to update your previously deployed application

You cannot update it, because you get an error with regards to org.eclipse.rcp 3.3.0 v>xxxx>.jar: [Invalid signature file digest for Manifest main attributes]

Workaround (only tested on Windows):
1. Browse your Eclipse 3.3 distribution’s feature directory
2. Jar the org.eclipse.rcp feature again (to zip it and then rename it to .jar works just fine)
3. Copy the new feature to your update site (override the original org.eclipse.rcp feature)

Then your update works fine again.

Including the Eclipse 3.3 help system in RCP applications

19

I just updated the help system for one of my tutorial RCP applications to Eclipse 3.3. I wanted to use the Jetty stack instead of Tomcat, like the Eclipse 3.3 SDK does. Since the help on “RCP help” is still a bit outdated, it took me a while to collect all necessary plug-ins. Here is the list of plug-ins you need to deploy with your Eclipse 3.3 RCP based application if you want to use the Jetty stack (in alphabetical order):

  • javax.servlet
  • javax.servlet.jsp
  • org.apache.commons.el
  • org.apache.commons.logging
  • org.apache.jasper
  • org.apache.lucene
  • org.apache.lucene.analysis
  • org.eclipse.core.variables
  • org.eclipse.equinox.http.jetty
  • org.eclipse.equinox.http.registry
  • org.eclipse.equinox.http.servlet
  • org.eclipse.equinox.jsp.jasper
  • org.eclipse.equinox.jsp.jasper.registry
  • org.eclipse.help.appserver
  • org.eclipse.help.base
  • org.eclipse.help.ui
  • org.eclipse.help.webapp
  • org.eclipse.osgi.services
  • org.motbay.jetty

Inconsistencies in Eclipse Project Wizards

2

Recently I implemented a customer-specific project wizard. Since I didn’t want to reinvent the wheel, I took a look at the existing Eclipse project wizards. When comparing them I noticed a few (little) inconsistencies. As an example compare the screen shots of the Java project wizard and the Plug-in project wizard. First, the plug-in project wizard:
http://www.toedter.com/blog/images/plug-in_project_wizard.png

Then the Java project wizard:

java_project_wizard.png

The plug-in project wizard is actually reusing the general new project wizard while the Java project wizard does not reuse it. I personally like the UI design of the plug-in wizard better because it is smaller, makes better use of space and has a more intuitive semantics. Consider the following situation: An Eclipse newbie wants to create a NEW Java project but not create the project in the workspace. How would he do that? As an experienced Eclipse user he would know that he just selects “Create project from existing source” and then browse to an empty or even non-existing directory. But that is not what the radio button’s text suggests.

Personally I found it very curious that I use Eclipse for years now and never noticed that :). This example is of course not a big deal, but wouldn’t it be a good time now to take a look at the existing Eclipse UI from a new user’s point of view and improve the usability and the consistency a bit?
If you agree, vote for bug 199147.

My EclipseCon Presentation

I am pretty exited that my EclipseCon Presentation about Eclipse RCP is received well at parleys.com. If you haven’t watched it yet, it is still there…

Page 10 of 10« First...«678910