Eclipse preferences

As you may remember from my earlier postings, on of conditions on which you can get your degree at Poznan University of Technology is taking part in so call Software Development Studio course. Participating students learn how it is like to write a software in real project, where are deadlines, quite a big team, changing requirements, real communication problems, etc. It is the first real experience of students with business world.

Google has recently created their workspace mechanic, which addresses the most common problem that big adopters of Eclipse has - preferences management in corporate environments. I am very happy that someone has finally noticed this problem.

However, I am not happy with installing 3rd party software to manage all the preferences. More, I do not believe it is a correct way. Eclipse, as a great platform, should offer such a functionality without the need of installing non-Eclipse plugins.

That's why I am supervising the project called 'Extended Preferences'. It is at very early stage, we are not sure if it will be welcome by Eclipse Foundation, but if you have some specific requirement which you think we should implement, just let us know.

For now, we would like to satisfy following requirements:

• ability to define during the development, which preferences can be exported
• ability to define import strategy (override, merge or reset)
• ability to create a set of preferences to distribute them amongst developers
• ability to promote project preferences to workspace preferences
• support preferences which can be shared across workspaces
• help developers to use preferences correctly (implement change listeners!)
• create migration tool

We are not sure if we will succeed, the project is at very early stage, but we are going to try hard.

I will keep you informed :)

Dropins diagnosis

This post is P2 related but I could not find the appropriate words to start it. Actually I would not know what to say about P2 even if I could write this in my native language. P2 was definitely a pain at some point, but I still have no clue about the real root cause - was it P2 or just the change of general approach to plugin management.

While there are certainly areas for improvement, the P2 team does a great job in fixing bugs. They are preparing API, which in my opinion will speed up P2 adoption because you all will be able to wrap existing functionality into your UI, so there will be much more testing and much more bug reports :-).

I wanted to let you know that one, in my opinion very important, bug has been fixed:
Bug 264924 - [reconciler] No diagnosis of dropin problems.

If you add right now to your .options file following lines

org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true

P2 will inform you what bundles were found in dropins/ folder, what request was generated, and what is the plan of installation. Maybe it is not detailed explanation of what actually happened, and what went wrong, but it should give you strong information about where to start - was your bundle in the plan? Was it installation problem (P2 fault) or maybe it is just not optimal to include your feature?

This is not a lot and a lot at the same time ;-).