Managing preference pages with Eclipse 4

Preference pages and Eclipse 4

If you have made preference pages with Eclipse 3 you probably used the org.eclipse.ui.preferencePages extension point which describes your pages displayed in the preference dialog.

In a pure Eclipse 4 application, this extension point is no more available because it stands in ‘org.eclipse.ui’ and the IPreferenceStore implementation, which is usually used, is not available (the ScopedPreferenceStore is defined in the org.eclipse.ui.preferences which depends on org.eclipse.ui once again…).

Also remind that PreferenceDialog is provided by JFace and needs a PreferenceManager to be initialized.

As the Eclipse platform does not provide  a pure E4 solution to define this preference pages, I developed a dedicated plugin to manage them.

This plugin is available on github and also on the  OPCoach P2 repository

It provides the following issues :

• an extension point com.opcoach.e4.preferences.e4PreferencePages which is like the Eclipse 3 extension point but it expects a class extending the FieldEditorPreferencePage
• a handler which reads all these extensions and displays the preference dialog. This handler is used by the (com.opcoach.e4.preferences.mainmenu) plugin which adds the command automatically in a pure E4 application.
• The compatibility with legacy Eclipse 3 preference pages (if in compatibility mode you still use Eclipse 3 pages they will be displayed together).
• an automatic binding with the PreferenceStore belonging to the plugin where this page is defined
• a copy of the ScopedPreferenceStore class from the E3 org.eclipse.ui.preferences package
• an extension point com.opcoach.e4.preferences.e4PreferenceStoreProvider, to manage your own PreferenceStore policy if the default behavior does not match your needs

This solution can help you to write easily your preference pages without having a dependency to org.eclipse.ui.

Of course, you can use the injection in your preference page code, if you need it.

To get the preference value you can still use the @Preference annotation.

To use this plugin in your project, you should :

• add the e4 preferences feature in your target platform  (see the link on the GitHub home page) or this Target Platform file (look at the end where OPCoach repository is used)
• make your plugin depend on com.opcoach.e4.preferences
• extend the com.opcoach.e4.preferences.e4PreferencePages extension point to add your pages
• If you are running a pure E4 application, add, in the plugin that contains your application model, a dependency to the com.opcoach.e4.preferences.mainmenu plugin that will add, for free, the command to open the preference dialog.
• If you are running the compatibility mode (E3 + E4), add nothing else. The E3 and E4 pages will be displayed together automaically. 
• optionally write a com.opcoach.e4.preferences.e4PreferenceStoreProvider extension to override the default PreferenceStore policy

This example projet shows how to use it. 

Feel free to comment this post if you have any remark.

E4 tools and Spies for Eclipse Mars

E4 Tools and Spies for Eclipse Mars

E4 tools is a set ot tools to help in developping application using Eclipse 4. They are not absolutely necessary to create a new E4 pure project because it is now possible for creating a new Eclipse 4 project using the ‘new plugin project’ wizard, and then by choosing ‘Rich Client Application’ and the ‘Eclipse 4 RCP Application’ template :

But installing E4 tools spies makes the E4 development easier and helps to understand the new E4 concepts.

In Eclipse Mars version, E4 tools is composed of the following spies : model, context, event, css, preference, bundle. They can be opened using the shortcuts Alt Shift F5 to Alt Shift F10

The E4 tools Eclipse update site is today out of date but it should be fixed in a few time (see bug 471308).

If you need the latest E4 tools version, I built it locally and pusblished the zipped update site here :

org.eclipse.e4.core.tools.update-0.17.0-SNAPSHOT-OPCoach_090915.zip

If you prefer to build it locally, it is very easy to do using the following 3 commands :

git clone https://git.eclipse.org/r/e4/org.eclipse.e4.tools
cd org.eclipse.e4.tools
mvn clean install

You will get the zip file in the following directory : org.eclipse.e4.tools/build/org.eclipse.e4.core.tools.update/target

Feel free to ask me any questions if you can not install them.

Hackathon prerequisites

Here is the contents of the mail sent to hackathon attendees :

Hi,

You are registered to attend the Eclipse Con France Hackathon.

To prepare the talk you need to bring you own laptop and check the following prerequisites :

Administration :

There are some registration that should be done to fix bugs :

• you should have an account on www.eclipse.org  -> on the top of the page
• be sure to have signed the CLA. To sign it go on this page : https://projects.eclipse.org and click on CLA on the top of the page
• that would be fine to have a public ssh key installed on your computer (search for ‘generated public keys’  on google).

Software :

We need 2 software to fix the bugs : eclipse and optionally git  :

• install the latest Mars Eclipse for committers. You can download it here : 
  • http://www.eclipse.org/downloads/packages/eclipse-ide-eclipse-committers-450-rc3/marsrc3

• if you want to use git in a shell, you can install a recent git version, but it is only a nice to have
  • To install git, go on this page : https://git-scm.com/downloads

Bugs :

You should select some bugs you would like to fix. There are several ways to find bugs :

• search for bugs with the day keyword in bugzilla :    Click here to run the query
• search for bugs on a specific project :  search with bugzilla
• search for bugs using sonar : https://dev.eclipse.org/sonar/  -> then select a project and click on ‘major’ or ‘critical’ at the top of the page.

Note that we are not experts in every single Eclipse technology, but will do our best to help you !

Code :

To avoid bottlenecks with the WIFI, it would be great to clone the projects on which you want to fix bugs. You can have the list of projects on this page : http://git.eclipse.org , and download it using a git clone command as described in the page of the project.

Of course you will not download all the Eclipse code, but it would be cool if you can download at least these ones, using these commands if you have a git install :

• git clone http://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git
• git clone http://git.eclipse.org/gitroot/platform/eclipse.platform.git

For egit specific bugs :

• git clone https://git.eclipse.org/r/egit/egit
• git clone https://git.eclipse.org/r/jgit/jgit

 
Or by pasting the git repository URL in the git repository view directly in Eclipse.

Eclipse Installation :

Try your Eclipse mars on your laptop, and prepare a workspace. You can also add the local git repositories you have downloaded (git perspective, git repository view).

To avoid compilation errors with some projects (like egit) you should also install the ‘Execution Environment’ feature. Check this page to have information :  http://wiki.eclipse.org/Execution_Environment#Installing_Execution_Environment_Descriptions

With all this preparation tasks, we should be operational to start the hackathon and to avoid potential WIFI problems.

See you on Wednesday.
Olivier, Wayne and Mikael.
 

Eclipse 3 to Eclipse 4 Migration Course

Eclipse 3 to Eclipse 4 Migration Course

This course will enable you to master the migration of an Eclipse 3 development to an Eclipse 4 one.
It encompasses the right methods and steps you will need to apply in order to implement such migration.

For detailed information go to this page

E4 Spies and other Tools tools

During the Eclipse Con Europe 2014 in Ludwigsburg I had a talk :

How to use E4 spies and other Tools

The pdf of the talk is available here :

ECE2014_OPCoach_E4Spies.pdf

Video of the talk is also available here.

Eclipse 4 workshop

The Eclipse 4 workshop is available in pdf version, github, etc…

Go to this page to have all information : http://www.opcoach.com/en/eclipse-4-workshop/

10 essential tips for team work with Eclipse

You’re working with Eclipse and you may be having a hard time managing all your developers’ positions. Setting up a new position takes time. You may have questions about work organization. What can you do to improve things?

Here are 10 essential tips to help you standardize your developers’ work.

1. Installation of Eclipse

In order to develop properly, you must use the most up-to-date version of Eclipse. This version can be downloaded from the Eclipse website: http://www.eclipse.org/downloads/

If the downloaded version is not sufficient (for example an eclipse modeling does not contain the webtools or svns), you will need to manage the added tools. There are several ways to do this:

• list the complementary tools’ site updates to install in a wiki and send the information
• install the complements in a newly downloaded Eclipse and have this version installed (management of the different platforms if there are developers on windows/linux, etc…)
• suggest an internal site update that groups together all the tools to install

In any case, it is key to ensure that all developers work with the same tool versions.

2. Workspace management

Eclipse manages projects in a workspace to which some parameters, called preferences, are associated.

As every project has different client-specific characteristics, one workspace per project is required.

If you are developing on maintenance branches, a dedicated workspace for this branch is also required.

You can switch from one workspace to the other by using the command ‘File->Switch Workspace…’.

You can copy a workspace’s preferences to another when you create a new workspace, or import preferences stored in a file once the workspace is created.

3. Java settings

In a multi-developer environment, machines and configurations are often different. In order to avoid configuration problems, it is important to set certain parameters right from the start.

In a Java environment, you can make a Java version (J2SE-1.5 for example) correspond to a JRE or a JDK installed on your machine. These environments are stored in the current workspace. This is actually one of the very few manual settings needed for every workstation as the others can be shared by saving the preferences (Cf §5):

In subsequent Java projects (for the plugins, we can only choose environments) only Java environments can be used and referenced. The current JRE or an alternative JRE must no longer be used:

So if a developer brings up a project through configuration management and JDK 1.5 is set as default, his project will fail and he will have to set the preferences correctly.

4. Code formatting

Another important setting: code formatting rules, which need to be shared between all developers. If these are not set from the start and the files are subsequently delivered in configuration management, they can create problems when making comparisons with previous versions.
For Java the configuration is done in the preference pages, ideally by importing a shared preference file, specific to the project and shared on the network (the first time it is obtained by doing an ‘export all’):

For example, the default line size – currently set at 80 columns and no longer adapted because of new screen sizes! — can be modified.

5. Sharing workspace preferences

By exporting workspace preferences (Menu Export → Preferences), a project’s common preferences can be shared easily. The epf file created can then be imported again into other workstations.

6. Committing Eclipse management files

In the project directory, Eclipse stores some configuration files that are necessary for it to work. They include:

• the file .project which contains the data on the project
• le .classpath if the project is of Java nature
• le .cproject if the project is in C/C++
• the directory .settings which contains the proprieties of the resources.

These files must be committed to the configuration management database in order to find them on every development workstation.
 

7. Sharing launch configurations

Whatever the type of project, the launch parameters of a ‘launch configuration’ can be stored in a file. You get to this from the ‘Common’ tab in every launch configuration. A ‘.launch’ file must be stored in a project and can be committed to the configuration management database. By selecting the Run and Debug menus, the other developers will be able to access it directly from the menus.

8. Target platform management

When developing an RCP application, you must configure the workspace’s target platform.

The best way to do this is to create a target file (New Wizard → target Definition), in the main application plugin. Of course, this file will be stored in the configuration management database (cvs, svn…).

In order to allow the shared use of target files, the files should not be referenced locally but rather referenced directly on Eclipse sites, or possibly in a shared and accessible directory.

The target platform preference screen then references all the .target files in the workspace:

9. Use of the ‘working sets’

The workspace may quickly contain several projects, even dozens. ‘Working sets’ enable you to organize the workspace by creating groups and putting projects together. A project may belong to several ‘working sets’ simultaneously.

The working set mode is set in the view package Explorer menu:

This menu contains the commands used to fill the working set with projects.

10. Exporting and sharing a workspace

Finally, once the workspace is organized properly using working sets, its content can be exported to a ‘Team Project Set’ file. This file contains all the URL for accessing the configuration management tool (cvs, svn, …), and all the defined ‘working sets’.

It is enough with one person defining the reference workspace, containing all the projects, organized by working set and exporting this workspace in a stored file on a shared disk:

 
A new developer can then install a new workstation in 3 steps:

• install an Eclipse with its tools
• import shared preferences
• import the project’s team project set file

Dependencies to use for Eclipse 4

Dependencies to use for Eclipse 4

When you develop with Eclipse 4, you need to use a lot of new classes and annotations that are defined in several plugins. It is a little tricky to know these dependencies without any documentation.

Here is a table to summarize the dependency that must be used for each class or annotation.

You can also find more information in the Eclipse wiki

How to properly override the generated EMF code?

How to properly override the generated EMF code?

EMF allows generating code from the model. By parameterizing the .genmodel file, we can generate 3 sources of code: model, edit and editor, which contain the java sources that let exploit the defined model.
In order to override the generated code, the traditional method consists in directly modifying the generated code by adding a ‘NOT’ behind the @generated tags. Additionally, the ‘mint’ plugin (in emftool) allows distinguishing the overridden methods (in red) from the added methods (in black) and the generated methods (in blue):

The overridden code with @generated

This method is acceptable if little code is modified, however, in the event of projects in which a lot of generated job code has to be added, then it is recommended to:

• clearly separate the generated code from manual code
• automatically generate the code when starting the build process
• take out the generated code from the configuration version system (cvs, svn, git, …) and generate it again when the delivery is made

EMF and Eclipse offer simple solutions to answer this need.
 

1. Separating the src-gen and the src

In order to work properly, it is important to take ‘sealing’ measures, by clearly separating the generated code from the overriddden code. To do this, parameterize the model using the following instructions:

Parameterizing of the genmodel

This operation can be repeated for the edit layer and editor layer.
Then, create a src directory (folder source), dedicated to override the project:

src directory for the override

This new source directory will contain a new EMF factory for creating the instances of the overridden classes. This factory comes from the generated factory and permits object creation with the new interfaces:

New factory that creates the new instances

We will complete the methods of this factory as we override the classes of the generated model.

So, the implementation of the factory is simple:

Implementation of the overridden factory

Then, you just need to link the new factory to EMF by using the extension point factory_override:

extension point override_factory

This new factory will automatically be used by EMF during the object creation by a call to RentalFactory.eInstance.

Then, the modeled classes only need to be overridden with EMF. In this way, helper methods (add, remove) can be added in the interfaces … :

Adding access methods in the interface

… and the modelized operations can be overridden in the implementation:

Implementation of the job methods in the interface

2. Generating the code in Eclipse during the build

If we totally separate the generated code from the overridden code, it can be useful to automate the code generation from the model.

EMF offers us an ant task (emf.Ecore2Java) that allows generating code from a genmodel. Writing the ant file is straightforward:

Ant file to generate EMF code

To execute it, it is important to use the JRE from the workspace (parameter of the build launch, in the JRE tab).

This ant file can then be integrated to the project builder by putting it in the first position in order to ensure that that the generated code is present for the compilation:

3. Generating the code during the build, outside Eclipse

In the build headless process, without having and Eclipse IDE launched, we can generate code both ways,

• using the application org.eclipse.ant.core.antRunner which calls the generation ant which can contain the following tasks
• using the application org.eclipse.emf.codegen.ecore.Generator which only does generation

In both cases, the launch environment has to be set up:

• cd {Installation directory of Eclipse Modeling}
• export LAUNCHER=plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar

Generating with the antRunner :

Launch of the build with the antRunner :
java -jar $LAUNCHER -application org.eclipse.ant.core.antRunner -nosplash -buildfile {pathToAntFile}/ecore2java.xml

This method is useful if the ant file does a bit more than that of the code generation.

Generating with the ecore.Generator

This method is useful if there is only code to generate from the model:

The parameters of the application are: java -jar $LAUNCHER -application org.eclipse.emf.codegen.ecore.Generator
Usage arguments: [-projects ]
[-dynamicTemplates] [-forceOverwrite | -diff]
[-generateSchema] [-nonNLSMarkers]
[-codeFormatting { default | } ]
[-model] [-edit] [-editor] [-tests]
[-autoBuild true | false ]
genmodel-file [ target-root-directory ]

Example:

• export PROJECT_HOME={path to your project}
• java -jar $LAUNCHER -application org.eclipse.emf.codegen.ecore.Generator -projects $PROJECT_HOME -model -nosplash $PROJECT_HOME/model/rental.genmodel $PROJECT_HOME

In order to go deeper in these notions, I advise you to read this general article on the matter, presented atinfoq and written by Sven Efftinge (XText project manager)

Feel free to comment this article if you have remarks !

Eclipse 4 Context Explorer

Eclipse 4 context explorer

For the presentation that I have given at Eclipse Con in Boston, I had to develop a small tool to help  the understanding of my slides.

This tool happens to be very practical, so I have decided to publish it on github (under EPL license). Since its first release, it has evolved a lot and I use it for each Eclipse 4 training.

Overall, it’s a E4 ‘Part’ containing a  TreeViewer and a synchronized TableViewer that display all the available contexts and which allows to see all available objects for each context.  The root elements in the tree are all the E4 contexts created for each bundle (the default one is the context for org.eclipse.e4.ui.workbench).

Here’s the result:

You have also a search box to find all the keys or classes containing the string (the nodes of the tree are also colored in blue if the associated context contains the string).

In order to use it, import the github project in your workspace, add a dependency (optional or not) on this plugin, then reference the part to where you need it in your application model by using the following URL:

bundleclass://com.opcoach.e4.contextExplorer/com.opcoach.e4.contextExplorer.parts.ContextExplorerPart

So for example we get:

This is useful during the development phase. I also heard that there is an equivalent in E4 tools, but nobody really knows where exactly!

I am inviting you to look  at the code. Perhaps, this will help you understand a bit better how injection works.

EclipseCon in Boston

Like every year, OPCoach participates in the EclipseCon North America held in Boston in March.

The presentation I proposed about injection into Eclipse 4 was accepted by the selection committee, so I will be a speaker again this year.
 

 
The Foundation has also made a real effort on registration fees. I invite you to sign up to ‘advance’ before 14th February. After this date, it will cost you 20% more.

Eclipse 4 talk during Eclipse Day 2012 In Toulouse

• Eclipse 4 talk (french) 
• Eclipse 4 talk (english)

I propose to comment this post if you have any idea or remark on Eclipse 4. Indeed, I have had feedback during informal discussions, but it would be nice to open a discussion here !

So feel free to add your comment(s)  to this post!

Eclipse Day in Toulouse on 24 may 2012

Happy new Year !

OPCoach whishes you an happy new year !

Lots of technologies to be used this year : Xtext, Xtend, Eclipse 4…

Eclipse Con Europe 2011

OPCoach will participate in Eclipse Con Europe 2011.

Paris EMF Training – 7th, 8th & 9th March 2011

• Eclipse
• Modeling
• EMF / Ecore
• Editeurs de modèles
• Générateurs de code
• Model to Text (M2T)
• Editeurs graphiques (GMF)
• EuGEnia