'Ignore optional compile problems' is now available with 3.8/4.2 M6

• Have you ever been overwhelmed by thousands of potentially unimportant warnings in your Java project?
  
• Have you ever tried to avoid excessive error reporting from a source folder containing auto-generated code?
  
• Have you ever looked for a specific problem and could not find it because it drowned somewhere in the Problems view?
  

If answer to any of the above questions is 'Yes', then I have good news for you! Finally, after several busy weeks, we have an option to ignore all configurable compile problems just a few clicks away!

It's really simple!

You can turn on the new Ignore optional compile problems option for each source folder available in your Java project. To do that, go to Project properties > Java Build Path > Source and toggle the value of 'Ignore optional compile problems' to Yes. With this option set to 'Yes', JDT compiler will suppress errors and warnings configured in the Preferences > Java > Compiler > Errors/Warnings page.







We wouldn't have the new option without great help from Satyam and Markus who spent a lof of time reviewing patches for bug 220928. Thanks guys!


For other noteworthy things available in 3.8/4.2 M6 see the entire New and Noteworthy.

Time to say goodbye!

I think I should start this writing from stating that this is a guest post, as I am no longer a member of IBM Eclipse Support crew.

It has been almost 5 entire years since my office was formed as a kind of joint venture between Poznan University of Technology and IBM. My main responsibility was to help customers with their Eclipse related problems. As you know, many IBM Rational products are Eclipse based, even those server-side, so I never had enough time to blog or actively participate in Eclipse development - I barely managed to open a number of bugs that could change how corporations perceived Eclipse and Eclipse-based solutions.

I'd say that my experience gathered on the border of open-source and enterprise worlds is a rather unique one. And I would like to share it with you at EclipseCon.

I guess that my 5 years of work for IBM may be summarized with the following xkcd strip - I just started realizing that careers are hard ;-).

Every age: "I'm glad I'm not the clueless person I was five years ago, but now I don't want to get any older."

If you wonder what I will do next, please stay tuned! I will announce that on my newly created blog once it gets added to the planet Eclipse (I have already opened a bug for that).

I would like to publicly say "Thank you" to Daniel Megert for his incredibly reliable work, not only in JDT - and nominate him to Eclipse Community Awards in recognition.

Thank you for reading this post :). I hope that I will have now much more time for writing.

Krzysztof (Chris) Daniel

A very interesting bug report

One image is worth more than a thousand of words.
Just check this real bug report:

New preferences for Eclipse

Hello All!
As you probably have noticed, Eclipse preferences are not perfect. A majority of enterprise companies struggle with enforcing consistent setttings across multiple installations, and so far nobody find a remedy which would be good enough.

Recently a light appeared in the tunnel. Ericcson contributed code for obtaining preferences from a certain URL, something similar to the Workspace Mechanic, which may solve some of the enterprise problems.

On the other hand, two GSoC proposals have been accepted in the area of preferences. I would like to get it done right this time, so any comments/suggestions are welcome.

New preferences for Eclipse

This is just a small update to let you know that Eclipse preferences which I have described in my last post are hosted in Eclipse labs here together with usage description.

New preferences for Eclipse

It has been long time since I recently blogged on Planet Eclipse, but as an Eclipse Support Center we have been incredibly busy during the recent year. Last time I have mentioned preferences issues that are pretty often reported and left without a fix, because of Equinox preference limitations.
We had no other choice to solve customer woes than to start a closer cooperation with Poznan University of Technology, and a group of excellent students, as a part of their thesis, analysed, designed and coded a separate preferences module, which addresses (almost) all issues in "old" preferences that we have been aware off.

Check out their webcast - it is definitely worth it (for some reason the video does not get displayed on Planet Eclipse, you have to refer to the original blog entry or directly to Youtube).

The project was started in Eclipse labs, but we would like to move it to incubator. Could any of full time commiters guide us through the process of code donation? Any help will be deeply appreciated.

The code itself requires further work, like adding proper licensing headers, project naming issues, etc. I expect the code will be ready for reviews and donations before the end of month.

Those excellent students that did that thing are:
Marek Kuzora
Anna Ferster
Filip Wisniewski (responsible for the editor)

Congratulations!

Note: Poznan University of Technology has more excellent students which would like to get experience in commercial environment (and write their thesis, too). So if you have any non-business-critical project (or research project) to realize, please drop me a line (krzysztof.daniel somewhere at pl.ibm.com), and I will contact you with appropriate person.

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 :)