Keep track of your Eclipse projects

19. February 2010

If your days are anything like mine – full of different activities in different areas of the software, and involving multiple tasks over the course of the day, you’ve probably wondered how to organize yourself.  I’m a fan of keeping everything in one place, and this place for me is Eclipse. Beside the excellent programming tooling support in the IDE, Eclipse also offers various means to help you keep track of your workspace resources, projects and tasks.

Developing software often goes along with managing a lot of different files and projects in your workspace and development environment. There is the “client”- and “server”-related code, various database- and build-scripts, user documentation, generated resources, tests and test results, – and before you know it you’ve got more than twenty projects in your workspace. But Eclipse can easily help you to manage all these things – the “magic words” are

  • (Window) Working Sets,
  • Linked External Resources,
  • and Tasks

Only a few clicks and you can bring into focus what’s currently important for your work:

(Window) Working Sets

I use Working Sets to categorize the projects within my workspace. Various Views support the usage of Working Sets, like the Package Explorer.  Just select Select Working Set… from the Package Explorer View Menu and define your own categories for a bunch of projects:

Open the Working Set Dialog

You can define as many Working Sets as you want and also assign one project to multiple working sets. As well as assigning whole projects you can also select single resources from within a project to add to a Working Set.

Define Your own Working Set

That’s all it takes to start using Working Sets.

Select Your Working Set

Defining and setting Working Sets this way is view specific – which means that each individual view can be configured as to which Working Set it should use. Most of the time this is not exactly what you need – focusing on a part of your workspace should affect all views at once. For this,  the Window Working Set comes into play. By setting the specific view Working Set to Window Working Set you refer to a central preference for your active Working Set. Unfortunately this central preference is by default not visible – but it’s very simple to change: Just select Window → Customize Perspective → Tab “Command Groups Availability” (in Eclipse ≤ 3.4 it’s “Command”) → then select the command group “Window Working Set”. From now on you have got a new toolbar item in the main toolbar from which you can easily select the Window Working Set you currently want to work with.

Window Working Set Toolbar Item

As well as reducing the amount of visible projects, other advantages of using Window Working Sets, include being able to have more than one active Working Set at a time and the improved performance from the IDE (often a major advantage!).  For example the JDT part of Eclipse also seems to be more focused and quicker when indexing and searching for classes. A minor disadvantage of using Working Sets is the storage of this information – they reside in your workspace metadata directory and are not that easy to share: ž<workspace>/.metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml

Linked External Resouces

Another feature I use every day is the linking of external resources in my workspace. To link a resource, use the Advanced function when creating a new folder in your workspace:

Link to Filesystem

I like using this feature e.g. for taking a quick look at our regression tests which run during the night, because you can use the well known Eclipse Tooling for these linked files like searching, filtering and working with the editing capabilities of Eclipse. The only thing you have to keep in mind is that linking many files into your workspace can easily lead to a poorer performance of your IDE.

Tasks

And last but not least I simply want to mention the integration of Mylyn in combination with bug tracking systems such as Bugzilla or Trac have been improved a lot and it’s real fun working with the Task List- and Task Repositories-Views. Hereyou can find detailed information on how to use Mylyn in your IDE.

Posted by Markus Tiede in Eclipse, Java | 1 Comment »

Eclipse Get-Together at BREDEX / Eclipse Island at CeBIT

17. February 2010

We’ve got a couple of BREDEX/Eclipse events coming up in the next few weeks.

Braunschweig Eclipse Stammtisch
First of all, we’ll be having the first Eclipse “Stammtisch” of the year on the 24th February here at BREDEX.  Ralph Müller will be there and we’ll be hearing from Markus Tiede about a “normal day working with Eclipse” before we go round the corner to “Mephisto” for some food and drink. If you’re interested in coming, or if you want to speak at an upcoming Stammtisch, take a look at the BREDEX website for more details.

CeBIT
The second piece of news is that BREDEX is going to CeBIT! We’re teaming up with other members of the Eclipse Foundation to showcase Eclipse technologies and solutions.  Drop by the Eclipse Island, in the Open Source Park, Hall 2, booth numbers 151-154, to meet representatives from EclipseSource, Actuate, SOPERA, BREDEX and the Eclipse Foundation.  Visit the demo theater and see Eclipse products and projects, including GUIdancer, Yoxos, RAP, BIRT and Swordfish.

Looking forward to seeing you there!

Posted by alex in Eclipse, Events | Comments Off

Pimp my QDox

19. January 2010

QDox is a library which allows you to parse a java source file and extract instance variables, methods and even JavaDoc tags from it. Quite some time ago, I had used QDox for a little tool that generates implementation source code for java beans. When writing java bean sources, you usually have to write the same code template again and again for every single bean property. Each time, the template has to include an instance variable, a getter and a setter method and a constant for the property name.

With the code generation tool, you can just create an abstract template class for the bean that holds a single abstract getter method for each bean property. Here is an example with a bean for an employee:

    public abstract class EmployeeTemplate {
        public abstract SkillTemplate getSkill();
        public abstract String getName();
    }

The template source has all information necessary to generate an implementation source file with the code items mentioned above.

    public abstract class GenBeanEmployee extends EmployeeTemplate {
        public static final String PROPERTY_SKILL = "skill";
        public static final String PROPERTY_NAME = "name";

        private SkillTemplate m_skill;
        private java.lang.String m_name;

        public SkillTemplate getSkill () {
            return m_skill;
        }
        public void setSkill(SkillTemplate skill) {
            m_skill = skill;
        }

        public java.lang.String getName () {
            return m_name;
        }
        public void setName (java.lang.String name) {
            m_name = name;
        }
    }

The tool is still being used today. Recently the project migrated from Java 1.4 to Java 5. Unsurprisingly, it didn’t take long for the first template to become a generic class. Designed for a Java 1.4 environment, the tool was of course not able to handle generic templates.

To fix this, the generated implementation source needs to adopt any generic parameters from the template. A template class header like

    public abstract class EmployeeTemplate<S extends SkillTemplate>

should result in a generated implementation class header like

    public abstract class GenBeanEmployee<S extends SkillTemplate>
        extends EmployeeTemplate<S>

So, the tool needs to extract the generic parameters from the template class. However, the QDox parser does not provide this information by default. This is obviously a missing feature. Luckily, it is not too difficult to modify the sources and upgrade the package.

When I experimented with the output of the parser, it turned out that it actually recognizes the parameters from the class during the parsing process. This is due to the fact that the parser can actually handle type parameters for methods. Any recognized parameter – regardless of whether it originates from a method or a class definition – is stored with the structure used for methods. So, the recognized generic parameters from the class definition are falsely added to the first instance method found.

This can easily be fixed by first storing the recognized items in a separate instance variable within the Parser.java file. Then, the type parameters can be added either for the class definition or a method definition, depending on which is parsed next. In order to be able to store the type parameters with the class definition, an appropriate variable needs to be added in the JavaClass.java and ClassDef.java files. Finally, the parsed class parameters need to be set within the ModelBuilder.java file.

With these small additions, I can continue to use the QDox parser for the code generation tool that now also handles generic classes. I had briefly looked into possible alternatives, but did not find any other library that nearly had all of the features required for the task. Most of the other options did not even provide any support for generics at all. If you are interested, you can download the modified source files here. They are based on QDox version 1.10.1.

Posted by Henning in Java | Comments Off

Eclipse Demo Camp in Braunschweig

27. November 2009

On Wednesday 25th November, Braunschweig had its first Eclipse Demo Camp. We organized the camp jointly with brox IT Solution GmbH and, of course, with the help of the Eclipse Foundation, who also kindly sent us Ralph Müller to talk to us about the Eclipse Ecosystem.

The location in the Stadthalle was perfect: enough space for the 48 participants with room at the back for drinks and snacks in the break.

democamp2

Networking in the break

We were treated to five demos over the course of the evening, starting with Ralph’s contribution – complete with mandatory audience participation! He was followed by Sebastian Voigt from brox, giving a demo of SMILA and Eccenca. Just before the break, we presented our role play of an agile development team working with GUIdancer.

Benjamin Muskalla, who had joined us all the way from Karlsruhe in an elaborate demo-swap between EclipseSource and Bredex (Markus Tiede will be heading to the Karlsruhe demo camp on December 3rd), welcomed us back from the break with his demo of the Eclipse  Memory Analyzer and RAP. We even saw some spontaneous community spirit when Frank Fauth from IT-Region 38 lent Benny a power cable for his slowly dying computer. The final demo of the evening was from Prof. Dr. Kreyssig from Ostfalia, who showed us how he uses Eclipse to program embedded systems. The demo culminated with the words “Eclipse Demo Camp” being shown on an LED display.

Eclipse Demo Camp

Eclipse Demo Camp

After the camp we were grateful for Ralph’s invitation to have a drink in a local restaurant and for the chance to get to know some of the participants a little better.

I think that the success of this demo camp shows us that we have the makings of a strong Eclipse community here in the Niedersachsen area. I hope that you all enjoyed it as much as we at Bredex did, and I look forward to seeing you at the next Stammtisch or Demo Camp!

Slides for all the demos are available on the Bredex website.

Posted by alex in Eclipse, Events | Comments Off

Hello World

26. November 2009

Hello and welcome to our shiny new blog.

Soon we’ll be posting our thoughts and experiences about development, testing and usability, as well as other interesting things we come across.

Posted by alex in General | Comments Off