Eclipse Yoxos Services Downloads Blogs About
Home > Blogs >

Archive for February, 2009

on Feb 27th, 2009Ganymede SR2 and ’23′

I have to admit: 23 is the number that I like most. Some computer scientists and mathematicians prefer 42, but this is not a prime number.20090227 epp ganymede sr2 builds Ganymede SR2 and 23

Why am I starting this blog entry with this odd number? Because my birthday is on a 23rd? While this is true, it is not particular interesting. But if you are going to the EPP project page where you see the EPP package builds for all Ganymede Releases you will find out that every Ganymede build that has been released to the public in the past was in fact build on a 23rd.

Look at the screenshot: Ganymede Release build on June, 23rd – Ganymede ServiceRelease 1 on September, 23rd, and now the Ganymede Service Release 2 build on February, 23rd.

And now I am happy that I can write: The new Ganymede SR2 packages are now available for download. There are still some problems on the different download web pages but I am sure those problems will be fixed by the webmasters soon. I think this is good news at the end of a long week.

BTW: How many Eclipse projects did participate in Ganymede? Yes, exactly 23!

on Feb 27th, 2009Tip: Validation with a MultiValidator

In the last blog entry regarding databinding, we learned how to create a custom observable for a DateTime widget. Starting with Eclipse 3.5 there is a new approach to creating custom observables as described by Matthew Hall in the comments to that post. Which ever way you choose, we will now use the observable to showcase another cool databinding feature: Crossvalidation. Crossvalidation was introduced with Eclipse 3.4 and describes the process of validating one IObservable based on the value or state of another IObservable. A classic example is the input  of a date ranges where the start of the period can not be after the end of the period.

databinding cross validation 300x91 Tip: Validation with a MultiValidator

As we can see on the screenshot above, the status message informs us of a violated validation constrain. So, how is such  kind of crosscutting validation achieved? First of we need some kind of model, to hold the start and end value. Next we need the two DateTime widgets and the corresponding DateTimeObservableValue. The observables can than be tied to the bean model, holding the start and end values. In order to create a crosscutting validation for the dates, we introduce a custom PeriodValidator extending a MultiValidator, which is in fact an implementation of a ValidationStatusProvider.The MultiValidator lets us implement a validate() method, returning an IStatus corresponding to our validation results. Since we are implicitly implementing a ValidationStatusProvider, the state of our validation can be bound to any party interested in the validation result. Here is the implementation of the PeriodValidator, comparing the start and end date (ignore the shortcomings of the Date class):

public class PeriodValidator extends MultiValidator {

private final IObservableValue start;
private final IObservableValue end;

public PeriodValidator(final IObservableValue start, final IObservableValue end) {
this.start = start;
this.end = end;
}

@Override
protected IStatus validate() {
Date startDate = (Date) this.start.getValue();
Date endDate = (Date) this.end.getValue();
IStatus status = ValidationStatus.ok();

if ((this.start != null) && (this.end != null)) {
     if (startDate.after(endDate)) {
          status = ValidationStatus.error(”The start date has to be before the end date.”);
     }
}
return status;
}
}

As we can see, there is not much magic going on in the PeriodValidator. Lets have a look at the broader context, in which this MultiValidator is applied. The following code demonstrates the overall setup of the databinding. Note how the validation status (wrapped in an IObservableValue) is obtained from the PeriodValidator and bound to the status Text widget.

private void createDatabinding() {

DateTimeObservableValue startObservable = new DateTimeObservableValue(this.dateTimeStart);
DateTimeObservableValue endObservable = new DateTimeObservableValue(this.dateTimeEnd);
DataBindingContext context = new DataBindingContext();

// bind start and end
UpdateValueStrategy modelToTarget = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
UpdateValueStrategy targetToModel = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     startObservable,
     BeansObservables.observeValue(this.period,Period.PROP_START), targetToModel, modelToTarget);

context.bindValue(endObservable,
     BeansObservables.observeValue(this.period, Period.PROP_END), targetToModel, modelToTarget);

// bind status
PeriodValidator periodValidator = new PeriodValidator(startObservable, endObservable);
modelToTarget = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
modelToTarget.setConverter(new Converter(IStatus.class, String.class) {

public Object convert(final Object arg) {

if (arg instanceof IStatus) {
     IStatus status = (IStatus) arg;
     return status.getMessage();
}

return null;
}
});

targetToModel = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     SWTObservables.observeText(this.status),
     periodValidator.getValidationStatus(), targetToModel, modelToTarget);
}

The validation status of the period validator is updated everytime any of the DateTime widgets is changed. In turn the validation message is updated to reflect the validation state.

You can download the the entire project containing the sample snippets here.

Also note that you will need to adjust the elements on the classpath. See the .project file for the required libs.

I hope you found these hints valuable and am looking forward to your comments and suggestions.

on Feb 27th, 2009Safari 4.0 – or closing the gap to RCP

Apple has released a beta of the next major release of the Safari web browser. Beside having a couple of cool new features like a preview of your top sites on the start page and coverflow for bookmarks/history it introduces the new JavaScript engine “Nitro”. Nitro makes a difference, it makes JavaScript apps much more responsive.
cas pia overview Safari 4.0   or closing the gap to RCP

cas pia contacts Safari 4.0   or closing the gap to RCP

A very brief benchmark showed the following results for the RAP based CRM system we are using:

Startup time (initial loading of the app):

FF3: 4sec
Safari4: 2sec

It seems like Safari is very fast when having to deal with a bulk of JavaScript, approx. 120 KB of compressed JavaScript for building the inital UI. Outperforming Firefox 3 by a factor of 2.

Switching between Overview and Contacts perspective a couple of times and calculating the average leeds to the following results:

FF3: 1s
Safari4: 0.8s

The difference may seem insignificant, but it feels like the difference between a slightly sluggish and a very responsive system. Now, switching between the resources perspective and the plugin development perspective in my Eclipse IDE takes approx. 0.5 seconds on my system. The gap is getting smaller.

Not to mention startup times ….

With the new RAP 1.1 service release which is part of Ganymede SR2 we are now also supporting key navigation in table and tree for Safari – version 3 and 4.

on Feb 26th, 2009Tip: Adding Bundles to Java Search

Awhile ago, I blogged about adding bundles to your Java search scope. As an exercise born out of frustration while on a plane, I made this a bit easier to do in the upcoming Eclipse 3.5M6 release:

javasearch 300x98 Tip: Adding Bundles to Java Search

There’s a command now to add all the bundles in your target to the Java search scope. Enjoy.

on Feb 26th, 2009Wayne Beaton in Victoria

Wayne Beaton, our beloved Eclipse Evangelist and all-round good guy, will be visiting Victoria next week.  I am very happy to say that Wayne will be spending some time with the Chisel Group, the UVic research team whom I worked with throughout my PhD.  As well, I just found out that Wayne will be speaking at the Vancouver Island Java User Group about Mylyn and task-focused programming on Thrusday March 5th.  If you are in Victoria, and can make it, why not join the fun.

If you are not able to make the JUG, but would still like to get together to chat about Eclipse in Victoria, drop me a line.  I am always happy to talk about Eclipse over a few frosty beverages.

on Feb 25th, 2009You gotta have friends

Its at times like these that you gotta have Friends.  Of Eclipse that is.  Friends of Eclipse.  While I congratulate the entire Eclipse team for releasing 3.4.2 and I applaud the community for its fast uptake.  But really. All this downloading is getting in the way of other people.

Until today I was a lapsed friend.  But then I decided I needed yesterday’s integration build. Being no longer blessed with living inside the IBM firewall and having access to “fullmoon”, I had to go to the main eclipse.org server for the file.  Well, me and 110% of all the other people in the world apparently.  Just getting a 20MB file was going to take 30min. I had several downloads fail.  Frustrating. But wait, a lifeline is at hand.

The Friends of Eclipse program allows the community to both show their support for Eclipse and get a bit extra.  The extra in this case is special Friends QoS rules for download.eclipse.org. What’s that mean? For me it meant the difference between 9kb/s and 688kb/s. Or, for the temporally inclined, 37 minutes to download my file vs. 37 seconds. As Denis puts it, “thats 35 bucks well spent”.

Are you a…

friendslogo You gotta have friends

on Feb 24th, 2009Target Platform Changes

I sent an email out to eclipse-dev today detailing some of the changes the PDE team has made to the target platform story:

targetplatform 300x224 Target Platform Changes

Dear Eclipse Plug-in Developers,

In 3.5M5, the PDE team added a new experimental preference page supporting managing and editing of multiple target platforms: Plug-in Development > Target Platform (Experimental). In the latest i-build (20090224-0800), this page has become the default way of managing target platforms and the old page was removed. The page displays all targets defined in the workspace. You can change the target platform used to build workspace plug-ins by checking it in the table. A wizard allows you to add and edit target platform definitions. You can seed a target platform from existing templates (for example, an RCP application), default settings, current target platform settings or start from scratch. Target definitions created from the preference page, by default, are stored locally in your workspace metadata. You can add plug-ins to a target definition from various sources: a directory, an installation (this looks at the list of INSTALLED bundles), a feature, or a repository (update site). You can also scope which plug-ins or features make up a target definition. Also, you can create a target definition from the New -> File -> Plug-in Development -> Target Definition wizard and share it with your friends (use variables if you want a target definition to be shareable).

Please note that this is a change to how people worked with target platforms before. In the past, you just pointed to a directory and magic happened. This was a very brittle way of working with targets and wasn’t conducive to sharing with teammates. In the future, look for PDE to support target platform materialization from p2 repositories and the much requested feature of multiple targets per workspace.

If you find any issues with the new target platform story, issues with the new target workflow or have suggestions, please file a bug against PDE with a starting summary of “[target] xxx”

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=PDE

This is really exciting stuff as your target platform can be crafted now and easily shared with teammates. We are also looking at supporting target platform materialization from places like p2 repositories… OBR and other places where bundles may be stored. In the end, the PDE team hopes that you’ll enjoying crafting your target platforms in the near future icon smile Target Platform Changes

on Feb 21st, 2009The RAP book finally arrived

This is an exciting moment for me – the first book about Eclipse RAP has now finally arrived in print.

“Eclipse Rich Ajax Platform – Bringing Rich Clients to the Web” by Fabian Lange

A book is always a great endorsement for a technology. Having an author with no affiliation to the producers of the technology is even better. Nevertheless, when I read Fabians message that the book was now in print – and it had not worked out that one of the RAP committers acted as a reviewer – I felt a little bit uneasy. After the book finally arrived and having a look at it I must admit for no good reason icon wink The RAP book finally arrived . I stumbled upon the usage of the word component in a way that seems rather uncommon, but it all makes sense if you take it as “ui component”. I have not followed the examples, but I am sure that Fabian did a great job there too.

rapbookcover1 243x300 The RAP book finally arrived

The RAP book at Amazon

The book touches all relevant aspects of RAP, and provides a concise guide for getting started with RAP. It includes a section on single sourcing RCP and RAP applications with some really valuable tips. It also touches on styling RAP applications and finishes with the deployment on application servers. With its volume of 150 pages it can’t provide a lot of depth, but it is really a great book to get started with RAP. RCP Developers with requirements to make their apps available in browsers and developers interested in evaluating RAP going beyond “Hello World” will get a really good bang for the buck. And the book is pretty much up to date with the current 1.2 developments.

Just in case anybody is interested in complementing Fabians book with an “Advanced development with Eclipse RAP” or “The Eclipse RAP compendium” – you should feel encouraged and we might be able to help. How about you Fabian?

on Feb 21st, 2009RFC 119 and ECF – part 2

Some time ago, I blogged about RFC 119 and ECF part 1, so now it’s time for part 2…

ECF now has a set of plugins that serve as a bridge between the RFC 119 spec (see part 1) and ECF’s discovery and remote services API (note:  all the following plugins begin with ‘org.eclipse.ecf’ and can be found in /cvsroot/rt/org.eclipse.ecf/framework/bundles at dev.eclipse.org):

  1. osgi.services
  2. osgi.services.discovery
  3. osgi.services.distribution

The osgi.service bundle only contains the classes that are included in the OSGi 4.2 compendium, i.e. interfaces such as DiscoveryProvider, DiscoveredServiceTracker, and DistributionProvider.  These interfaces are defined by the OSGi Enterprise Experts group, and are part of the RFC 119 specification.  The implementation is from the OSGi Alliance, as are other parts of OSGi that are implemented in Equinox.

RFC 119 is divided into two parts:  1) service discovery; 2) service distribution.  Service discovery is optional, and service distribution is required.

The osgi.services.discovery bundle implements the RFC 119 discovery and uses ECF’s discovery API to implement protocol independent network service discovery.   There are two existing provider implementations of the ECF discovery API right now:  zeroconf/bonjour and SLP…so users will be able to publish their services automatically over both SLP and zeroconf discovery mechanisms with a single service publication.

Similarly the osgi.services.distribution bundle implements RFC 119 distribution using ECF’s remote services API.   When this is complete, it will mean that without any additional coding, remote services will run immediately on the following transports:

  1. r-OSGi/http
  2. TCP/ECF generic
  3. XMPP/XMPPS
  4. Skype
  5. JMS – ActiveMQ, Weblogic JMS
  6. Others under active development:  EMF/CDO, http-with-rest

Further,  the ECF remote services API also allows non-transparent access to remote services, in order to support asynchronous remote method invocation, one-ways, futures, explicit failure handling, and other features not part of RFC 119 at this point.

Note also that other providers that implement the ECF remote services API will automatically be RFC 119 compliant…i.e. they have to do no work to be compliant with RFC 119 for transparent remote procedure call.  Further, with ECF remote services, if clients wish to use non-transparent remoting…in combination with or in exclusion to transparent remoting…that is also available.

We’re closing in as rapidly as we can on having this all ready and working…and EclipseCon 2009 is coming up fast…so stay tuned.

on Feb 20th, 2009e4 and RAP

For those of you who don’t know, RAP (the Rich Ajax Platform) provides the ability to run your Eclipse application on a server and have the UI served up in the browser using Ajax techniques. e4 is the next generation Eclipse platform that is targeting, amongst other things, the ability to do web UIs. Hmm, seems like there should be something in common.

Indeed! Yesterday the RAP team spent the afternoon looking at e4. First task was to check out the relevant code and setup the e4 photo demo. With that running it was time to switch out the target platform to use the RAP target platform.  Basically RAP provides alternate implementations of things like SWT and JFace. These maintain all the UI object structures on the server but with widgets that render in the browser. So putting in the RAP target substitutes these new implementations.

Moving to the RAP target resulted in quite a few compile errors but most were actually the same error in many places. For the most part alternates were substituted and in some cases, for the purposes of getting running, bits of the demo were hacked out. One of the major bits that had to be removed was the Nebula widgets–these just don’t have RAP equivalents yet. Of course, the photos in the photo demo are being displayed using these now missing widgets but that’s a different story.

So with that done, the app comes up. e4 on RAP or RAP on e4. However you like to say it.

In the end it was relatively easy once the details of how e4 starts up and works were  were understood. The result is actually too ugly to show here as the CSS styling has not been mapped onto the cool new RAP styling work. That’s a topic for another afternoon.

The goal of this afternoon adventure was to explore the space and see what the further topics of investigation might be. In that, it was a great success. Here is a short list of topics:

CSS styling — Much of the the property setting and basic styling will be easy to integrate but there appear to be some places where a graphic context is used. This will be harder. Perhaps there are some abstractions that can be done there…

RAP IEntryPoint and e4 Product/Application — Since a RAP system can have many concurrent sessions, there will be many concurrent applications.  IEntryPoint is the RAP abstraction for this. It would be good to investigate the use of the OSGi application model.

Nebula integration–This is harder.  Nebula widgets do all manner of stuff.  There has been work to do Draw2d but more is needed. In any event, that is not a critical element of e4.

Session support–Look at contributing RAP’s session support code to the parts of Eclipse that make up e4. This is likely to go a number of places but would be a very useful thing to have.

Internationalization–The extension registry and other parts of the system expect there to be just one locale. With the web there are users all over the place and they expect to see their content in their language.

Other cool stuff.  Stay tuned to this channel and post a comment if you are interested in RAP and e4 as another way of bringing your apps to the web.

© EclipseSource 2008 - 2011