Sunday, December 20, 2009

Contradicting myself with my eclipsecon submissions....

If you look at my EclipseCon 2010 submissions:

  • 1443 Declarative UI sucks? Create your own!
  • 1480 Extensible EMF Switches
  • 1483 Annoyed by all those similar looking interfaces: IMemento, IConfigurationElement, IPreferenceStore, IDialogSettings, ILaunchConfiguration...
  • 1484 JFace/SWT Tables turned upside down

It seems that I am contradicting myself, because in 1443 I propose to create your own (copy) of a declarative UI and in 1483 I whine about all those similar looking interfaces. How does this go together?

Well, in the case of all the different property stores, they all do the same and having 10 different classes/interfaces is indeed annoying. On the other hand. I simply do not believe that there is "the" declarative UI that solves everybody's problems. Whenever you try to create the ultimate declarative UI you are doomed to fail because it is either simple but too restrictive or powerful but too complicated (I'd be very happy if someone could prove me wrong).

The idea of a domains specific language is to be Domain Specific! One could argue that UI is a domain and a (e.g. xml based) declarative UI is a domain specific language for creating UI. But, in reality UI is not UI. It's like creating a domain specific language for programming. You end up creating a Turing complete general purpose language. OTOH, if you want to create a domain specific language for form based UI on top of EMF you have a good chance it becomes a good abstractions. But do not expect this language to be used to create something like JDT or PDE.

I do not believe there is the ultimate declarative UI language. But I believe that saving properties is so universal (and simple) that one 'language' should be sufficient.

Saturday, October 24, 2009

Future of eclipse: The Road Construction Analogy

Frank Gerhardt will host a session at ESE called Symposium on Eclipse Foundation 2.0. Half a year ago I burned my fingers with my "Eclipse Freeloader Award" blog entry. I got lots of negative comments and mails. I also got a few positive reactions. I decided not to continue talking about the future of eclipse.

Today, half a year later I look back and one interesting mail I wrote at that time is an email press interview. I decided to post it as I wrote it and I use it as my position paper for the symposium.

If this blog is to long just read the "The road construction analogy" section. This is the part of the interview I am most proud of....

The last months I have been heavily involved in an internal Wind River project based on eclipse and modeling, especially Xtext and I have not had too much time to work on eclipse except bug reporting and asking stupid questions on the tmf newsgroup.

I have no idea how the community will react on that (very long) post.

Disclaimer: The text below was written half a year ago. It expresses my personal opinion at that time. I have not followed the recent developments and I might change my mind at any time... ;-)

My reply to an e-mail interview on April 18. 2009:

Q: If you were ready to give the freeloader award, who would be the three finalists for the "honor." Why these guys?

A: I had no particular company in mind. However, it is the general mentality of the industry that frustrates me: the attitude to take advantage of something like open source and not give back anything to the system. This is also known as the "Tragedy of the Commons": Scott Lewis pointed out that the bigger a community is the less people participate: "The Logic of Collective Action"

From an architectural perspective, there are things to be done in eclipse that should not been driven by direct interests of some companies but in the common interest of the community. IBM somehow took this role for a while, when they put some of their best people on the core of eclipse. At that time they were interested in the overall success of eclipse. Since some years they started removing quite some developers from eclipse (and put them on the Jazz/RTC project).

I believe there should be an independent group of developers driving eclipse. In my opinion it would be best if they would be paid by the community but act independently in the best interest of eclipse.

Now the questions is: why should companies put money into something that is free? If they put money in the system and their competitors do not, they have a competitive disadvantage. They support the community but they have no direct advantage. And in fact the company I work for (Wind River) just ended their membership (which is a sponsorship of the foundation) just recently.

That is why I was brainstorming about ideas how to stimulate companies to contribute. I am really afraid that eclipse will suffer in the future because the architecture degenerates over time and there is not enough manpower to keep modernize the architecture. Yes, there is e4 (the next generation of eclipse), but I am not 100% convinced that this is the solution.

To stimulate companies to give money/resources to support the commons there has to be a benefit. If there is no positive benefit why would a company do that? So, my idea was to create peer pressure. One way to create peer pressure for companies to make them avoid negative press. A freeloader award would create negative pressure. No company would like to win the freeloader award.

Q: Other people I've spoken to, include Mike M. at Eclipse are much less concerned about the problem. Why do you see it as so serious?

A: Well, I probably have a different perspective than Mike. Mike sees the eco system and the new companies joining eclipse. My focus is more on the architecture of eclipse. So, the irony is that although eclipse is widely successful the underlying architecture ages and dissolves slowly. Partly because eclipse is stretched into so many different directions. It is never good for an architecture to go into too many directions at the same time. When eclipse started it was a platform for IDE like applications. It was later retro fitted to be the basis for rich client applications. The people ported eclipse to embedded systems. Then the it was used for the web and for servers.... All this is good for the short term success but I am afraid that the long term impact on the architecture could be disastrous. The architecture council is not really focusing on architecture. Partly because the members have never been the ones that created and drove the original architecture. And partly because architecture by committee is doomed to fail.

The road construction analogy

One analogy for the general eclipse community problem I have been thinking about recently is road infrastructure in a country. Suppose a big company (=IBM) created a basic road infrastructure and decided to make this available to the public for free (=original eclipse).

In the beginning, the big company somehow drove the journey and continued building the free infrastructure. They also had some interest in this infrastructure because they wanted to have a well accepted public road system to deliver their products. But over time they gave the roads to the public and let the other companies continue building the roads. The hope is that the market is self regulating and it would continue maintaining the road infrastructure and new roads would be build by other companies.

In the beginning the companies understood the plan of the big company and continued building in that spirit. But some companies realized that it is not in their interest to build roads for their competitors. And it makes no sense for them to maintain the highways in general. They might build junctions to their private road network but hope that others maintain the net of highways created by the big company long ago. Sure they would fix some obvious holes on the roads. One could argue that roads build like that really reflect the needs of the community. But some of companies make sure the competitors do not get access to their key roads. What happens is: many private roads are be build in parallel, instead of some new highways. Companies would build "public roads" that connect their private roads. If the companies would understand that they all would benefit form good public roads, then they could come together and hire an independent road building organization and give them money (a kind of tax) to build the roads that are in the interest of the entire eco system. But at the moment there is no authority to enforce the tax payment. Lots of the roads are public and some companies donate "public roads" to the system. Who could blame those companies? They give something free to the community but also act in their own interest. They are much better than companies that use the public roads without contributing back. But something is wrong here. The nicely designed infrastructure degenerates over time. Can we blame the ones who contribute for that? That is the key to the problem: companies are contributing, but the contributions are not really in the best interest of the eco system.

How to solve the problem? How to make sure that roads are build that are in the common interest? Would it make sense to have a "tax paid" independent organization build and maintain the infra structure? How can we motivate the community to pay the taxes? Can we blame the companies that fix the roads and add now ones?

Q: Any suggestions, besides public disgrace, to ease the problem?

A: The questions boils down to: how can we motivate companies to maintain and enhance the common infra structure?

Positive motivation: all participants understand that they have to invest into the system beyond direct interests. But do all participants understand that? And how to deal with community members that do not want to pay their taxes? If someone can get away not paying the taxes the others who pay the taxes are the stupid ones. So, positive motivation works if all participants understand that they depend on the system. It essentially requires a certain level of moral. The bigger the community (and the more anonymous) the easier it is to get away without paying the tax. And in a capitalist world companies act in their own interest. Who can blame them for doing so? How else can they survive?

Negative motivation: have a police, a pillory, public opinion (press), a freeloader award. Something that puts pressure on members that do not want to pay their "taxes"...

Q: I always prefer to quote people by name, but if you like, I can withhold yours.

A: You can quote me. Those who know me know that I can change my mind very quickly. Partly because I simply forget what I say and partly because I like to look at problems from very different angles. Therefore, I could never ever become a politician because you could find lots of statements where I contradict myself.

If I look into the eclipse world, I see that the number of people warning about the future problems is underrepresented. That is why I raised my voice. If everybody would scream and warn about the future of eclipse, I would certainly find a lot of good arguments why eclipse has a bright future and why the current eclipse eco system works so exceptionally well and why eclipse is a great example of a successful open source project.

But at the moment I think there is not enough awareness of the problems of the tragedy of the commons. And that companies think they act in their own interest, but in the long term and from an higher level, they do not act in their own interest because they "ultimately destroy a shared limited resource".

[sorry for the long reply, but this is a topic that upsets me at the moment because I can see the disaster coming]

Thursday, September 17, 2009

Never put things above a user specified path

If you tell a program to use a path to store something you normally expect that the program puts its data inside that path and not into the parent. Sounds simple, but in the last 24 hours I ran two times into violations of this basic principle.

1. For the next release of our Wind River Workbench product we will use p2. We have thought our customers to use the -configuration option to redirect the place where eclipse puts its "stuff" if they use a shared installation. If they have different installations or different versions installed, that worked nicely (before p2): for version 3.0 they would use -configuration /someplace/wrwb3.0 and for version 3.1 they would use -configuration /someplace/wrwb3.1. Unfortunately since version 3.4 eclipse violates the principle "never put things above a user specified path" (bug 230384) and puts things like artifacts.xml and the p2 directory above the directory specified. If customers mix different versions of our product the old way, then they get a mess because two configurations that are supposed to live side by side suddenly share the potentially incompatible information in the parent. We are thinking to change the behavior of -configuration to add implicitly one more directory (to turn a user specified -configuration /someplace/wrwb3.0 into -configuration /someplace/wrwb3.0/configuration) so that the two configurations -configuration /someplace/wrwb3.0 and -configuration /someplace/wrwb3.1 do not infer with each other.

2. I am really excited about Xtext! Yesterday I created a new Xtext language project (let's call it gr.scharf.mylanguage). The wizard suggests to call my language gr.scharf.MyLanguage. Sounds good, but it puts its files into the package gr.scharf which is not such a good idea, because it pollutes the parent name space (see bug 289780) and therefore violates the principle "never put things above a user specified path".

Conclusion: if the user gives you a path put things underneath the path and do not touch the parent!

...think twice to make sure not to violate this simple principle....

Saturday, June 13, 2009

Every pixel counts! The new eclipse fullscreen plugin...

A few days ago Kevin McGuire blogged with the title Every pixel is sacred (not any more!) and a follow up Eclipse UI Real Estate Wasters!. I still believe that every pixel counts and I often wanted to have eclipse in full screen mode to save a few pixel. I use full screen mode in the browser and with pdf files a lot and I really love it. I remembered that there is a new Shell.setFullScreen method in SWT. During a boring meeting, I decided to create a small plugin that would add a toolbar button and a menu entry to toggle eclipse in to fullscreen. I started with the "New Plugin wizard" and choose the Hello, World Command example and replace the handleCommand line with one line:

I changed the labels in the plugin.xml and I was done, in less than 10 munites.....

I should know that even "simple" things can be quite complicated.
I wanted to make the plugin nice and share it but that was the start of a nightmare..... but that is another story.


You can use this site as update site or download the plugin from here:


The plugin has been written for eclipse 3.5 but it works also for eclipse 3.4 although there are some problems with the handling of the toggle state of the commands...

The plugin adds a Fullscreen command to the Windows menu and a Keybinding M3+F11 which translates on windows to Alt+F11:

When fullscreen mode is active all (main) windows are in full screen mode:

There is also a Toolbar button that can be enabled. Because the plugin uses the Commands Framework there are some unfortunate restrictions (bug 280033):

  • When you go to Window->Customize Perspective->Tool Bar Visibility, you will not find the Fullscreen tool bar unless you have enabled it in Window->Customize Perspective->Command Groups Availability

  • The Toolbar details are empty, although the toolbar contains a command:

Once you have succeeded enabling the toolbar button, it will look like this:


I decided to hide the button by default, because in most cases the shortcut and the windows menu command should be enough.

Tuesday, May 12, 2009

Why is RCP, EMF, p2, databinding... so hard to learn?

There are some interesting discussions on my recent blog entry on "How to explain EMF?". The debate is between those who find it hard to learn EMF and those who have a hard time seeing the difficulty. I think there is a general pattern behind this debate. The same arguments could be made for almost any non trivial technology/framework inside and outside eclipse (EMF, RCP, p2, databinding, [your "favorite" hard to learn technology],...).

Why do many people really suffer form the steep learning curve and others master the same technology easily?

I think we have to step back for a moment from any concrete technology and we should to look at how the technology gets created and how learning and applying of the technology works.

The creators of the technology/framework have a deep knowledge in the particular domain the framework solves. They have created several software systems where they saw some reoccurring patterns. They realize by putting the common parts into a framework they can dramatically increase their productivity, because the work is then reduced to assemble the pieces and write some "glue code" (in some sense they create a kind of domain specific language for that problem). As long as the creator(s) of the abstraction are the only users of the system, there is no real problem and they can show dramatic increase of productivity, because they can focus on the business relevant part of the system.

Now comes the next phase, where others adopt the technology. Those early adopters are usually people with a similar experience background as the original authors of the framework. They have typically written such systems by hand or created their own framework and they see the value of the technology. For them, learning the system is almost effortless because they understand the underlying problems and the solution provided by the cool technology. Good candidates of successful adopters are typically consultants using the technology in multiple projects. They report impressive increase of productivity. Let's call them expert users.

Now another category of users, the normal users wants to use the technology. They see the impressive results created by the expert users. The expert users tell them how effortless this is and how quickly you can create solutions.This is where the problem starts! The expert users understood the problem before they started, they understand the solution in depth and they reapply the technology to many projects. The normal users typically have a single project where they want to apply the technology. They might have a vague understanding that the new technology fits to their problem. The "documentation" build from expert users for expert users make no sense, because there is a lot of background knowledge and experience missing. Normal users have to put a lot of effort into learning and understanding a complicated system just to apply it once.

If the normal user manages to use the technology to solve his problem, his solution is often "suboptimal", because he might be happy to have found just one solution. The expert would see that it is by far not the best possible solution, because he has a much deeper understanding of the solution space. OTOH, the normal user might have a much better understanding of his specific problem domain and the expert might propose a bad solution, because his limited understanding of the problem domain.

Let me give you an analogy: Some weeks ago, my mother told me that she has a serious problem, because her old typewriter broke. She explained me how they do their tax-declaration: my father hand-writes tables with income and expenses and my mother types them with the typewriter. Well, they have a computer (which they use to read email and browsing). The solution is clear: a spreadsheet is all the technology they need to optimize the process. Me "the expert", could just tell them that they can be much more productive by using this "new and cool" technology. All, they'd have to do is to enter the numbers directly into a spreadsheet and with a few more mouse-clicks and a bit of excel programming he would even get some cool graphics and analysis.... Do you think I did that? No way. They are in their mid 70ies, they have done it "their way" all their life. How steep would their learning curve be? Does that mean they are stupid? My father is extremely good with his hand written tables, he uses colors and creates cool graphs by hand. He has an extremely good understanding of the money flow. He even knows exactly how much money they spend on me and my brothers from our birth to now. I wish I would have 10% of his knowledge on where my money flows.

In this example we see very well the difference between "expert users" and "normal users" of the technology. This technology would work really well for me and would not work at all for my parents. And even if I would try to teach them, I would have to use a very different language to explain it to them than I would use it explaining it to you. I would have to explain them what a spreadsheet is and so on. Then I could ask them if they prefer open-office or Microsoft office. Because they have absolutely no idea, even this simple this choice would stress them a lot.... Once they would start with an empty spreadsheet, there would be so much choices and decisions to make that they would be totally paralyzed. Would examples or documentation help? Well somehow, if an example does exactly what they want to do, but then it is almost the solution. Does that mean that spreadsheets are complicated technology? Well, it depends on your background. I think it would be more efficient for me to help them doing their tax declaration and prepare a spreadsheet and every time they do it, sit with them and help them. But I think the way they do it is OK for them, all I need to do is to fix my mothers typewriter.... If they were young and they had a lot of numbers for their tax declaration, it would make sense for them to learn the technology....

OK, I stressed this example enough... What does this mean for the "complicated" technologies around eclipse?

  • There is a big danger that a great technology gets a "bad reputation", just because "normal users" want to apply it and they find it the technology incredibly hard to learn and to apply.
  • As expert user, you can cause a lot of damage it you tell some unexperienced users to use a technology without guiding them. And in some cases it might be better to tell them not to use the technology if they are not "ready". For you it might be the right choice, for them it would cause disasters at all levels.
  • Learning "complicated" technologies might not be worth the effort if you want to apply it once.
  • Ask yourself if it is more efficient to hire an expert than to learn the technology. Especially if you want to apply the technology only once in a relatively simple way. In this case the expert can be 10-100 times more efficient than you.
  • If you are a normal user and you still want to learn the technology, be prepared that is takes time and it is a painful process. In order to make educated decisions you have to become at least "Competent" (see the Dreyfus model of skill acquisition) or needs "Conscious competence" (see Four stages of competence).
  • Maybe expert user and normal user should team up to write documentation and create example. For experts it is often very difficult to understand the problems of normal users and for normal users it is impossible to come up with good examples and documentation.

This post is a bit longer than my normal posts and I kept is as draft for a while but I decided to post it. It is a bit like with complicated technology: you can't explain it in two sentences ;-)....

Thursday, April 23, 2009

How to explain EMF?

Have you ever tried to explain EMF to nonbelievers? I find it difficult to explain what EMF is and why it makes sense to use it. I had this a few times in my career:

  • In the mid 80ies when I started with object oriented programming. For procedural programmers (modula2/pascal/C/Fortran) it sounded like a lot of buzzwords and seemed to add no real value...
  • End of 80ies and in the beginning of the 90ies (before the GOF book was out), patterns seemed to be quite fuzzy and it was hard to explain what the value of describing "patterns" is.
  • Around the same time I discovered scripting languages (starting with (g)awk->TCL->perl and ending with python, which I used for a decade). It was hard to motivate why those "slow" languages are in any way useful.
  • Aspect oriented programming is still in the "hard to explain/motivate" phase.

The common pattern with those "hard to explain" new technologies is that they are incremental changes to existing stuff but once you understand and use them, they change the way you are thinking. If you adopt the "new technology" you feel a boost in productivity and you see better ways to solve old problems. The level of abstraction raises and you can focus more on the problem instead of dealing with low level implementation details (or reinventing the wheel). And then comes the time when you think all problems can be solved with the new "hammer"....

It is similar to converting to a new religion. For the believers it changes their life. It changes the way they see, experience and interact with the world. For the nonbelievers it looks like a stupid set of paradigms that make no sense. They learn how to block the arguments of missioners of the new religion and the more missionary the believers are the more skeptical the nonbelievers get.

So, how do you explain the benefit of EMF?
What is the best strategy to evangelize nonbelievers?
What is the best way to get the converts over the initial pain of change?

What are the typical questions and problems with EMF?
Here is a list of things I hear often:
Why to use EMF for my DSLs instead of some hand-written well tuned Java?
It generates lots of code and bloats my project.
EMF is so complicated, it takes a long time to learn -- in that time I have solved my problem twice without EMF.

What are scenarios where EMF increases productivity and where is it the wrong tool?

I have seen Peter Frieses talk at eclipsecon. I really liked it but I am not sure it helps nonbelievers to understand what EMF (and modeling in general) is. I think what is needed is a hands-on way with some real examples that show step by step how modeling and EMF can be applied to real problems.

I will post some of my experience with EMF in this blog in the next weeks and months.

Tuesday, April 07, 2009

The Eclipse Freeloader Award

The future of eclipse in in danger: The problem is that there is no real pressure for companies to contribute back to the community and it is easy to use the eclipse "for free" for the own products. There are some interesting blogs on this topic by Doug Schaefer on the future of eclipse and Bjorn on life at Eclipse in the new world.

According to wikipedia, this is called free loading: "choosing not to do work and letting others do it".

Eclipse is open source and companies can take advantage of the open source work. There is nothing legally that can prevent them from doing so. But the eclipse community should create peer pressure to prevent the freeloaders and parasites from getting away without punishment.

A few ideas to increase the pressure for freeloaders:
  • Create an eclipse freeloader award
  • Have an "eclipse supporter" logo
  • Have a list of of freeloaders prominently on the eclipse page
  • Create an eclipse pillroy

Is this too harsh? Well, it is less harsh than to take advantage of the work of others and letting eclipse die. It seems that positive stimulus is not enough. I want eclipse to succeed in the future. But if everybody is only thinking about his own agenda the entire system will die. Eclipse has to defend itself. The eclipse foundation is to polite to upset some companies. That has to change. It has to be an honor being part of eclipse, and is has to be crystal clear that eclipse is not for free!

Disclaimer (not sure if this helps, but it seems common to add a disclaimer to anything that could potentially upset an employer): This is my personal opinion and not the opinion of my employer.

Good versus evil diversity - why the foundation must hire developers

In German we have two contradiction proverbs: "Gleich und Gleich gesellt sich gern" ("birds of a feather flock together" *) and "Gegensätze ziehen sich an" ("opposites attract" *).

When applied to couples, I think both are true but for different aspects: for social status, education, religion etc, coming form similar background makes things easy. But when it comes to character, being of different kind is good because my partner might have something I don't have and together we are more "complete".

Diversity in open source is similar. There are areas where diversity is absolutely vital and other areas where diversity has a very negative impact.

Bjorn criticized the "lack of diversity" in the eclipse community because most projects are "mono-vendor". He is right, we need more diversity here!

But there is another kind of diversity that is bad: if there are many ways of doing the same thing. Excellent system are not designed by committee, but by a few people (often a single person) with strong ideas about architecture, design and the "right way of doing things" (Frederick Brooks calls this "Conceptual Integrity"). This leads to excellent systems. From my experience I learned that it does not matter much, which set of rules are applied, as long as the rules are consistent and everybody in the team believes in them and follows them.

Startup companies often get this kind of consistency "for free", because they grow form a small set of people and they hire only new people that fit into the "mind set" of the team. Open source projects, created by some enthusiasts, get it, because they attract people who believe in the system. The (original) eclipse platform is an example of such a consistent system.

I am afraid that the future of eclipse is in danger if this wrong type of diversity (I call it chaos) increases. (I wish the architecture council could help to defeat this kind of diversity, but I am afraid that the council is already way too diverse when it comes to "architecture")

It would help a lot if there would be a set of developers paid by the foundation coming form different backgrounds but with a common mind set when it comes to technology. If the foundation would hire people, I am sure we could find a great team of people that would be able make eclipse ready for the future.

Having a "vendor neutral" team of developers dedicated to the future of eclipse would give eclipse a boost. Else, I am afraid, eclipse is "auf dem absteigenden Ast" ("heading south" *)

Friday, March 20, 2009

New Book: Eclipse für C/C++-Programmierer

I just got a copy of Eclipse für C/C++-Programmierer by Sebastian Bauer, the first German CDT book. The first impression is very good. This book is ideal for C/C++ developers who are new to eclipse and new to CDT, but it also has a few gems for more experienced users. It covers a wide range of topics (see the table of contents), it is well written and takes a very good route to get started with CDT. Although it has a lot of screen shots, I don't have the impression there are too many, because they complement the written text in a very good way. It has a very good balance between practical tips and explaining the concepts and ideas behind CDT.

This book is the missing manual for CDT! It should be delivered with each copy of CDT. I wish it would be available in English because it deserves a wide audience.

Sunday, March 15, 2009

eclipse 3.5M6: linked extension locations now require a .eclipseextenison file

UPDATE: the problems have been solved/explained (see below)

There is a hot debate between the community and the p2 team on supporting extension locations. A few weeks ago I described a simple procedure to use and maintain extension locations with p2.

In eclipse 3.5M6 links file do not work anymore, unless you add a .eclipseextension marker file next to the plugins and features directories of the extensions location (see bug 268673).

This marker file was required by the classical update manager in order to be able to add a directory as product extension from the UI. Until 3.5M6 link files just worked when pointing to a directory containing a plugins directory (or a eclipse directory containing a plugins directory). No .eclipseextension file was needed.

Ironically, the classical update manager in M6 cannot be used to add extension locations anymore. (To enable the classical update manager: Preferences...->General->Capabilities->Classical Update)

Is this a sign that the p2 team wants to discourage extension locations and link files? Or am I believing in a stupid conspiracy theory?

Update! Both problems have been solved
1. bug 268673: p2 tries to be clever: when it detects a artifacts.xml in the extension location it needs a .eclipseextension marker file to believe that this is really an extension location. Normal extension locations are not affected by this bug.

2. bug 268674: This happens only if you never have started eclipse from the installation location (and always start with the -configuration option.

==> no conspiracy :-)

Friday, February 20, 2009

p2: how I install plugins in extension locations...

The following procedure explains how I install plugins into different extension locations and share those extension locations between different eclipse installations using the p2 update manager and link files. For a lengthly discussion see bug bug 224145

I keep a set of different extensions locations in C:\eclipse\extensions (each extension location is in a subdirectory of that directory). Suppose I want to install foo into the new extension location C:\eclipse\extensions\foo.

  1. I start eclipse with:
    -configuration C:\eclipse\extensions\foo\eclipse\configuration

  2. I install foo using the update manager.

  3. Now I can use the extension by creating a file inside the links directory of an eclipse installation (you might have to create the links directory) containing:

That's it :-)

Note: You have to the forward slashes on windows in the links file.

Note: This procedure works for eclipse 3.4 and 3.5.

Note: You don't have to create any directory specified by the -configuration parameter. Eclipse will do that for you.

Note: It is important to follow the pattern EXTENSION_NAME/eclipse/configuration for the -configuration parameter because p2 will put the plugins one directory above the configuration directory and link files require that the directory that contains the plugins is called eclipse.

Note: With this structure I can update plugins into the extension locations by running eclipse with the -configuration and then do the update.

Advanced use: If I want to install bar based on my foo extension, I create a link file to foo in the bar extension location links directory:
and follow my standard procedure described above (the links directory can be populated before the first run of eclipse)...

Note for eclipse 3.4: If you are using eclipse 3.4 and you want to use the eclipse default update sites, you have to run eclipse without -configuration and export them (Help->Software Updates->Available Software (tab)->Manage Sites->Export), so you can import them into the -configuration eclipse.

Note for eclipse 3.5M6: You have to add an (empty) .eclipseextension file next to the plugins and features directory of the extension location.

Tuesday, February 03, 2009

When the runtime Application uses the wrong plugins...

Today I run into a problem that can cause a lot of frustration: a runtime eclipse launch that runs with he wrong plugins. The frustration comes form the fact that your application behaves strangely and it is hard to guess that this is caused by loading some worng plugins. Those plugins might even be closed or deleted from your workspace!

Here is what happens: PDE (eclipse 3.4) does some hidden magic when you run an eclipse application (lets call the launch configuration foo): it creates a directory in .metadata/.plugins/org.eclipse.pde.core/foo. This directory is used with the -configuration flag when running the application to store the runtime configuration of your application. But, there can be cases when this directory is not updated correctly, like when you switch between "launch with all enabled and workspace plug-ins" and "plug-ins selected below". It can happen that the runtime application still uses all plugins although you have selected to run with some specific plugins. I have not tested the exact conditions when this happens, but it happened several times to me in the last months.

Unfortunately the "Clear workspace" flag does not help, because it clears the workspace but not the configuration area! It took me several hours to figure that out....

As Chris points out in the first comment, here is the solution: On the "Configuration" tab of the launch configuration check the option "Clear configuration area before launching".

Chris also recommends to use -clean -consoleLog -debug -console as arguments for plugin development launch configurations. In this case, the -clean option takes care of cleaning the configuration area.

Tip: you can set -clean -consoleLog -debug -console as default in Preferences->Plug-In Development->Target Platform->Launching Arguments->Program Arguments

I hope this tip saves someone some wasted time...


Thursday, January 22, 2009

Finally, I found a good book on JavaScript!

For some years I have been looking for a book on JavaScript that would explain the language to someone who already knows programming. But all I have seen until recently are books for beginners or books that talk a lot about web programming, web browsers, DOM, XML, HTML etc, or books that explain all the different versions of JavaScript implemented in different browsers (many of these books have 1000 pages or more).

The book I read is a 180 page book called JavaScript: The Good Parts by Douglas Crockford. The idea of the book is: JavaScript is a messy language but here is a subset and some best practices how to use JavaScript in a manageable way. And that is done on 100 pages (the rest are interesting appendices). I read it last week on a flight and it was a kind of eye opener for me.

I finally understood that the object system of JavaScript is not class based like in C++/Java/Python/Ruby but it is prototype based like in Self/Perl/Lua. This prototype based approach is not supported by a special syntax. There are many ways of creating and dealing with objects. But be book makes some suggestions and explains some best practices for creating objects.

The other eye opener was how closures can be used to build objects with private information.

An interesting design decision of JavaScript is that there is essentially one data structure, called Object, with string keys and any object as value. It can be used as hash map, array or object. Even functions are objects and you can associate information with them or add methods to one or all functions.

If an object is used as array, the index is converted to a string key -- I find this very strange -- but it seems to work. The array.lenght attribute is defined as the "largest integer property name plus one", which means it looks for string keys that look like positive integers and takes biggest one, provided it is less than 4294967295.

If you want to learn JavaScript as a language I would highly suggest to read JavaScript: The Good Parts. After you finished the book, you might not be able to read any bad JavaScript programm, but you might be able to write your own "clean" scripts. I really like that approach.

If you are interested in E4, knowing JavaScript might be useful, because E4 will be scriptable with JavaScript.