Tuesday, December 12, 2006

Thursday, October 12, 2006

Design patterns for UI

While reading a post from Grady Booch, I came across the yahoo design pattern library which seems to be a very interesting concept that could be adopted by the user interface best practices working group to publish their results.

Sunday, October 01, 2006

Being rich

No, I'm not commenting about my lifestyle <g>, I'm just talking about RCP, the Really Cool Platform. Lately I've been annoyed by this tendancy to call anything built on top of eclipse, an RCP application. This is just wrong as it creates confusion around a concept not easy to understand, and it does not promote SWT and/or JFace where they are the real "heros".

So what does it take to be rich? To depend on org.eclipse.ui and org.eclipse.core.runtime (see the wiki).

Now remember that and give credit to the right technology even though it may not market as well (sorry azureus is not rich, it is SWeeT).

Monday, July 10, 2006

France 7 - Italy 0

Italy can have all the word cup they want, but they still don't have a committer in the SDK whereas France is strongly represented with 7 active people and 4 retirees :-)
Congrats for the cup Italy.

Friday, July 07, 2006

Setting the Bundle-RequiredExecutionEnvironment

In 3.2, each bundle included in the Eclipse SDK got its "required execution environments" set.
The two main motivations were:
  • Carefully controlling the set of APIs we use from the JRE and reduce our dependencies
  • Express in an API way the fact that some bundles could run on lower configurations than the one recommended by the platform (for example SWT and OSGi can run on foundation)
By doing that we also got some added benefits:
  • At runtime, bundles that do not qualify to run on the VM will not run (for example bundles requiring java 5 will not resolve on a 1.4 VM)
  • At build time, PDE Build will set the compilation flags for you and make use of the proper class library (see PDE Build help).
So if you write your bundle using java 5 feature, want to manage your JRE dependencies or simply want to do it the platform way, set the Bundle-RequiredExecutionEnvironment in your manifest.mf. Check out the wiki for the details.

Friday, June 30, 2006


Earlier today, like a few others I was at the foundation and I actually saw Denis putting the final touch to callisto. That was really cool and exciting since it represented for us 'the' last final step to make our work available to everybody.
Thanks again Denis, Matt and Nathan for bearing with us in your office while we were drinking your beers and watching you work.
By the way next time, get one of those to make the final push more exiting :-).

Wednesday, June 28, 2006

Release party at the foundation?

Rumor has been growing that once Denis will have released the eclipse bytes to an ecstatic crowd all hyped up by the Ian's press releases, the foundation will host a release party where we can all watch the eclipse servers and the committers go red.

Thursday, June 22, 2006

Headless build of products finally automated

For the longest time (two release cycles 3.0 and 3.1), it was a pain to automate the build of your RCP apps. The PDE Build team heard you and now the pain is gone!
Since 3.2, PDE Build provides support to build RCP applications from .product files. For more details, see the help (Plug-in Development Environment Guide > Tasks > Building an RCP Application from a product configuration).

Wednesday, June 21, 2006

Community plan items

As various teams are now planning 3.3 or whatever comes next, I would like to suggest the addition of a new kind of plan item, the community item.

What would it be: A work item bringing value add to eclipse, but where the effort would be driven by the community instead of the eclipse teams themselves. Such items should be relatively self contained (for example: implement a new refactoring, implement a new code formater, better high level doc on RCP, provide an simple build infrastructure, provide login infrastructure, etc.).

How would they work: Like any work item they would first be proposed. Then interested members of the community would form a working group responsible for designing and implementing a solution in adherence with the component vision, solution that would find its way in the release. To this extent, it would get assistance from appropriate committers, but it would also be submitted to the same criteria of quality with respect to stability, scalability or being done on time.

Who would submit those items: The PMC or the community, but it would likely have to be approved by the PMC to ensure the cohesion of the vision and appropriate resource is available to assist where needed (of course this is just a proposal).

Why do we need those? Current plan items read as "the team will do it for sure (committed)", "the team is investigating (proposed)". Therefore if you are willing to help you are left with the not so sexy HELPWANTED bugs. What this does is create a focal point and fosters discussions around a particular topic, that would not have necessarily emerged alone from the community. Also it is clear for companies or people willing to contribute code what things are of interest and what their energy could best used at.

In order to discuss that, I have opened bug 148149.