Making the Text Editor to be the Default One for All Unknown Files in Eclipse

NOTE. The functionality of the Default Text Editor plugin has been implemented in the Eclipse Platform with the Neon release. Check the release notes for details.

Eclipse users usually work with many different file types. Some of the file types may be opened by default in an external editor instead of in the Eclipse workbench. This happens if Eclipse has no editor available to handle that particular file type, but there is one installed in the operating system. In such case Eclipse assumes that it is better for the user to have the file opened in the external system editor.

Lots of users are quite annoyed by this behavior, especially when it comes to text-based files. They would prefer to have the file opened in the plain text editor of Eclipse instead of switching the context to the external program. Unfortunately, there is no easy way to change this in the preference settings. It's possible to associate a specific file extension with the plain text editor, but this must be done separately for every file extensions. There is no way to say "all text files of unknown type should open in the text editor".

Here comes the Default Text Editor plugin. It takes advantage of the Editor Association Override extension point introduced in Eclipse 3.8. When the plugin is installed it will change the default behavior of Eclipse and will opened all text files of unknown type in the plain text editor. Binary files like images may still be opened in an external system editor. As simple as that.

The plugin is available on the Eclipse Marketplace. It can also be installed through an update site. More info is available on the GitHub project.

$150 Bug Bounty for Fixing a Dark Theme Issue

Zend Studio is an IDE based on the Eclipse Platform. The dark theme is an important feature and is very popular among PHP developers. The most annoying issue with the dark theme, we have at the moment, is that the expand/collapse toggle in trees is almost invisible on Windows, because it seems to be unaffected by the dark theme coloring. See Eclipse bug 434201 for details.

We decided to put some money on the table with the hope that someone will step in and fix this bug. This will benefit not only Zend Studio users, but all Windows users in the Eclipse ecosystem who want to use the dark theme.

We created a $150 bug bounty on the FreedomSponsors crowd-funding platform. Follow this link to open the sponsored issue. Since this is a crowd-funding platform, anyone else who is ready to give some money for resolving this issue is welcome to do it, so the offer becomes more attractive.

UPDATE. The bug has been fixed within days and it will be delivered with the Mars M7 milestone. Thanks to Fabio Zadrozny for his great work. Kudos to Lars Vogel for adding $100 more to the bounty.

Eclipse UI Tips now come on time

The first version of the Eclipse UI Tips for Android reached the astonishing adoption of 18 installations. 13 of which are still active. I am happy that there are people who find this app interesting and useful. Special thanks go to Lothar who submitted the only review in Google Play. I really appreciate it! And I really do care for the feedback that reaches me. 

A few days ago I published an update of the application. As requested, the time for the tip of the day is now configurable. It is not fixed to 8:30 am anymore and you can set it to whatever time you like.

Another improvement is that the welcome screen now includes a link to the User Interface Guidelines wiki page. This is a short term response to the request that it should be possible to browse all of the guidelines without waiting for the tip of the day to come. I will work on a more integrated solution later.

The new version includes also some minor improvements in the layout and a couple of bug fixes.

That's for now, folks! If you want to share any feedback, you are warmly welcome to write a review in Google Play or submit an issue in github.

Eclipse UI Tips for Android

As an Eclipse plug-in developer I am always looking for guidelines how to design my UI for the best user experience. Although not updated for quite a long time, the User Interface Guidelines wiki page is the best source of information I am familiar with. It's quite a lot of reading (big thanks to the contributors), but the time spent on reading really worth.

Recently, I counted that there are exactly 144 guidelines described. Quite a lot, isn't it? Of course, there is a short list of the most important 18 guidelines, but this doesn't mean that I should neglect the other 126. Therefore, I was looking for an easy way to remember them all.

It's quite modern now-a-days to use a smartphone for making one's life easier. I created a simple Android app that fires a status bar notification every morning with a randomly selected Eclipse UI guideline. This would remind me one of these guidelines every day. Since they are 144 total, this should keep me busy for nearly half a year and then for sure I would need to do another round :)

I published the application to Google Play, so you can try it yourself if you find this idea useful. The code is available as open source under EPL on github.



Please, note that I have designed the application to fit my own needs. It's very likely that you have a different style of learning. I am open for feedback, request for improvements and patches. You are welcome to fork the project and submit your requests in the issue tracking system of github.

Call for screenshots

I have mentioned earlier that the Eclipse WTP project is taking steps on improving the default layout of the Java EE perspective. We made an UI walkthrough in the Eclipse UI Best Practices group and reached consensus for some small, but valuable, things to improve. We have scheduled this small step for Galileo M3.

Before we continue the discussions on the topic, we would like to look inside the development environment of WTP users. We have some statistics from the Usage Data Collector, but it is invaluable to see how Java EE developers compose the different views in an effective and convenient perspective. We are sure that everybody has its own favourite layout depending on the screen resolution and the working style.

We will be happy if you take some minutes to submit a screenshot of your IDE on the designated wiki page.

Plans for changes in the Java EE perspective

The Java EE perspective hasn't changed much in the last years. There were only minor tweaks that surely make the things better, but nothing special yet.

Recently a discussion started on how to update the default layout in the Java EE perspective. The first suggestions came from Mik Kersten. They are related about better integration with the Mylyn project. This includes:

• adding the Task List view


• replacing the old Problems and Tasks views with the brand new Markers view

This started tickle my mind. I have an old usability problem with server management in the Java EE perspective. When I use an application server that produces logs in the standard output (like all open source servers), whenever I execute a start, stop or deploy operation, the Console view suddenly pops up and pours tons of logs on the screen. It nice to have a view on the logs, but this hides the Servers view where I can see what's happening at a glance. In such situation I always decide to change the docking location for either the Servers view or the Console view.

So, why don't we just change the default docking location of the Servers view? I find it very comfortable on the left-bottom side - under the Project Explorer view. This way I can see both the server status and the console output without any tab switching. Another benefit is that both views, which deal with projects, are on one and the same side and I can easierly drag-and-drop a project on a server instance.

Here is how the new Java EE perspective layout would look like:


Other thoughts that cross my mind are:

• why do we have the Data Source Explorer view by default?


• isn't it better to have the Snippets view docked on the right next to the Outline view rather than at the bottom?

If you have any wishes that the Java EE perspective should meet, feel free to comment in the Eclipse Bugzilla where the discussion currently happens. The community feedback is the best guarantee that we will come to great ideas!

An easy way to unit test your EJBs

Unit testing is essential part of software development. Testing POJOs with JUnit is de facto standard. But when it comes to execute unit tests on Java EE artifacts like servlets and EJB beans, a problem arises. Java EE artifacts live in a Java EE container rather than in a pure Java Virtual Machine. How do we execute our JUnits for servlets and EJBs in the environment of the Java EE container?

The Apache Cactus project tries to solve this problem for years and, indeed, it makes more and more steps towards reaching the goal. The main problem with Cactus is that you need to run your entire application server just for the sake of unit testing your EJBs. In many cases the application server could be a monster that could eat a lot of resources of your developer system.

In this post I will uncover you a little secret on how to test your EJBs in much simpler and resource efficient way. You may have already known about the Apache OpenEJB project and the lightweight and embeddable EJB container it provides. If you still miss that, then it is a good idea to take a look at my previous blog post where you will learn how to integrate it with your Eclipse IDE.

Lightweight EJB container in Eclipse

Looking for an easy and lightweight environment for developing Enterprise JavaBeans? The Eclipse IDE for Java EE Developers gives you a great tooling to develop your EJBs, while Apache OpenEJB project provides an embeddable and lightweight EJB 3.0 runtime to execute them. The glue that sticks the Eclipse's and Apache's perls together is the OpenEJB Eclipse plug-in, developed by Jonathan Gallimore. In this post I will give you some kick-off hints about installing this plug-in that integrates the OpenEJB runtime with Eclipse.