Thanks to OSGi one of the main qualities of Eclipse ecosystem is its modularity.
In a modular architecture, contract between components is fundamental. I called contract not only the features offered by a component but also its limitations. Quite often we tend to concentrate on features and and miss limitations.
To illustrate my point I will take as an example SWT Eclipse component
I recently needed to add printing support to a custom editor. SWT provides some printing API. I first tried an approach which consisted of printing a snapshot of my already drawn widget. I did it using the SWT faq and added quite easily header, footer and fit to page support but it remained a blocking bug. Sometimes, randomly, a white shadow (of the previously opened print dialog) appeared on my printed widget. I tried to hack by calling redraw and update methods on the control but as I am not a graphic guru I gave up and finally have implemented the printing feature with success using the excellent PaperClips library.
During my hack attempt I saw in code that Printer.getDPI() returns always 72X72 in SWT GTK implementation. I don't want to blame anyone neither SWT nor GTK, just remark that on linux print is not completely supported, and this information may be difficult to find until your get the bug or read concerned code.
So quick reminder for developers : think to document your component limitations !
