June 30, 2015
Java™ 9 support has not yet landed in our standard download packages. But you can add an early access preview to your existing Eclipse Mars install.
The Eclipse Java™ 9 Support (BETA) contains the following:
- ability to add JRE and JDK 9 as installed JRE;
- support for JavaSE-1.9 execution environment; and
- ability to create Java and Plug-in projects that use a JRE or JDK 9.
At the moment Eclipse must be run with Java™ 9 if you want to use Java™ 9 in your workspace. You can download from http://www.oracle.com/technetwork/articles/java/ea-jsp-142245.html.
This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP.
Install the Java 9 Beta via the Eclipse Marketplace:
June 29, 2015
It is now official. A posting from the official Android Developer’s blog has confirmed what many of us already knew, that the days of the original Android Developer Tools based on Eclipse was numbered. Honestly, I think this is not a bad thing. It does free up the resources that Google has to fully concentrate on the Android Studio tooling, and continue to improve and advance their chosen strategy going forward.
However, all is not lost, as the Andmore project is here to continue to provide Android tooling for the Eclipse community. However, progress right now is pretty slow, and that is because my own time has been limited. With this said, we do have integrated support with Maven and the android-maven-plugin through the m2e-android project’s support. The Buildship project can import an existing Android gradle project, and even run some tests, but it still has problems in setting up the project natures and make things work with Andmore. There is a feature request opened to have some sort of project configuration extension so that Andmore can help configure such projects to better work with the tooling.
The state of Android development with Andmore and how well it keeps up with the yearly and quarterly updates coming from the Android Open Source Platform is going to greatly depend on contributions from the community. We need your help, as one person definitely can not maintain the project alone. So please do take a look at the bug/feature backlog, feel free to fork the project on GitHub, roll up your sleeves and get a bit dirty, submit pull requests and file new bugs. Andmore is going to be what the community makes it. We wished for years that ADT had been open more to contributions from the community, now is the time for us to follow through on that wish.
We are happy to announce that together with Mars we have released EMF Forms and EMF Client Platform 1.6.0! We want to thank all committers and all contributors for their work as well as the active ecosystem of users and adopters for the feedback and support!
EMF Forms is a framework focused on the creation of form-based UIs. EMF Client Platform is designed to support the development of applications based on an EMF data model. If you are not yet familiar with EMF Forms, please refer to this tutorial for a introduction of EMF Forms.
Both frameworks are part of Eclipse Modeling Tools Mars (version 1.6.0), however, we have already released a service release (1.6.1) fixing a Bug with the double control, so if you use EMF Forms or want to get started, we recommend to update to 1.6.1, available from our download page.:
Please have a look at our migration guide, e.g. if you have used the service provider interface in a previous version.
Since February 2015 and with the 1.6.x release, we have closed 111 Feature Requests and Bug Reports.
It is amazing to see, that the number of active contributors is still growing and how much effort was spent so far. OpenHub shows some impressive numbers:
We will describe the most notable new features in a small blog post series starting next week. We hope you enjoy the new release and provide us with feedback!
Leave a Comment. Tagged with eclipse, emf, emfforms, mars, eclipse, emf, emfforms, mars
Never ending fight on IDE related meta-files included in code source found an alternative: Eclipse Smart Importer rocks!
Should the meta files related to an IDE be committed?
There is a never-ending fight over this question. I'm sure that most of the advanced Eclipse users will answer yes but unfortunately in a team you might get some Eclipse haters (and sometimes even IDE haters, who I also call last-century coders). This second and third categories will answer no.
When the answer is no, setting up your preferred IDE might become cumbersome. There is missing meta-information, for instance contained in .project files, which can lead a developer to import projects with the wrong nature into the IDE. Hopefully, here comes the Smart Importer! It enables Eclipse to guess the most appropriate nature when importing a project.
For instance, with the Bonita BPM engine project, you just have to specify the git clone repository that you want to import and all the correct natures for every projects are detected automagically.
The project is not integrated in the Eclipse Mars Release train but is available from a dedicated update sites. It will enable you to test and contribute - ideas and code - for Neon, the next version.
June 27, 2015
We at ANCIT are planning to organise a list of Eclipse based Public Training Courses. As part of that we are planning to organise a Public Classroom for Eclipse PDE & RCP. Course Content of the training is attached to the email.
Workshop Title : Eclipse 3x PDE/RCP - 2 Day Workshop
Trainer Profile : Annamalai Chockalingam
[Linked In Profile : https://www.linkedin.com/in/annamalaichockalingam]
Date of Workshop : 9th & 10th July 2015
Time of Workshop : 10.00am to 5.00pm
Venue : ANCIT Consulting Office [Apponix Technologies], Rajaji Nagar, Bangalore
Location on Google Map : https://www.google.co.in/maps/place/Apponix+Technologies
Cost of the Workshop : Rs.7500/participant + ST.
If you have more than 3 nominations you will get a discount of 10%.
If you register before 1st July 2015 you will get 20% discount on the above mentioned price.
For more information write to firstname.lastname@example.org
Eclipse is landed on Mars, and now Platform UI team (as well as SWT and EGit teams) start to receive new bug reports from our end users. That's OK, business as usual after each release. Not OK is that we could get much less bug reports, especially from our Linux users. Why?
Eclipse Mars on Linux uses first time GTK3 toolkit by default (all versions before 4.5 were on GTK2), and that is the major driver for new bugs from Linux users. I'm writing this on Linux, and know what I'm talking about. Eclipse SWT team crafted the SWT GTK3 port with tremendous effort, but unfortunately GTK3 exists an a bunch of (partly incompatible) versions with different API behavior, and developing a widget toolkit on top of it is a pain, not a pleasure (IMHO).
The major issue with GTK3 is that if SWT is broken, it affects each and every Eclipse UI plugin, at most unexpected places! Anyway, now this is default toolkit and we must know how to work with it (or workaround it).
So if you are on Linux and see a new UI regression on Eclipse Mars, please be aware that if this a GTK3 issue, there is easy way to fix it - switch to back to the GTK2 version (which is still supported by Eclipse 4.5). But before switching the toolkit - try to help Eclipse and report the issue you observe, so that the next release has a bug fix for it!
1. Search for similar bugs
Before reporting, please search for bugs! All properly reported GTK related bugs contain [GTK], [GTK2] or [GTK3] keywords in the summary. If your bug is already reported, do not report another one, but just add extra details you want to mention.
2. Check if the GTK3 to blame?
Try to check if your issue is GTK3 related: switch to GTK2. Either export SWT_GTK3=0 in the shell before starting Eclipse or add this two lines to your eclipse.ini:
which has exact the same effect. If this helps, we will know that the problem is most likely GTK3 related.
3. Check if the GTK+ theme to blame?
Not always the GTK itself is a problem, but the current GTK theme (widget style).
GTK applications can be "styled" - they can look and feel differently on same GTK version due the currently selected "style" or "theme". There are various GTK themes available, and some are better for use with Eclipse as others.
Beware of oxygen-gtk theme on GTK3! This pair is known to be extremely buggy!
Unfortunately, many distributions set the default KDE GTK theme to oxygen-gtk. It worked well in the past with the old GTK2, but on GTK3 this can be a source of multiple issues. If you are using KDE desktop, the first thing you should do is to check if you are using oxygen-gtk. If so, switch to another theme (Adwaita or Clearlooks-Phenix). Later one is my favorite, and I even forked it to make it working on GTK2 in the way I like it :-).
Please note, that after switching GTK theme it is highly recommended to restart Eclipse to avoid unexpected side effects of half-zombied theme artifacts. If the problem do not disappear after restart we know it is independent from the theme.
4. Report the bug
If your bug is not on the list, prepare the information we need to triage it properly! First and foremost we want know exact Eclipse and GTK version used. Eclipse version is shown in the "About" dialog, GTK version is not that easy to retrieve. If you are on Eclipse 4.5, you can see GTK version used by SWT in the "Help -> About -> Installation Details -> Configuration" dialog - search for the "org.eclipse.swt.internal.gtk.version" property, it looks like:
But of course on Linux we want use command line tools :-)
For the rpm - based distributions (Fedora, RHEL, CentOS) it's easy: just call
rpm -q gtk2; rpm -q gtk3
and you will see something like:
For the debian based distributions (Ubuntu & Co) I know about two commands:
apt list | grep installed | grep libgtk2.; apt list | grep installed | grep libgtk-3.
dpkg -l | grep libgtk2.; dpkg -l | grep libgtk-3.
but both of them aren't that concise as rpm and print lot of unneeded information. Please also note inconsistent naming schema: libgtk2 but libgtk-3. Nice and makes lot of sense, isn't?
Now we know the installed GTK version we can go and submit bug report against Platform/SWT.
NB: please also add your operating system details, desktop environment (Unity/Gnome/KDE) and GTK+ theme used.
From my personal point of view SWT GTK3 port is still not on par with GTK2 and ideally shouldn't be made default for 4.5 - it wastes lot of space and introduces multiple regressions. But the decision was made and only way to fix it now is to contribute to Eclipse.
Max Domeika discusses the relative strengths and weaknesses of the current Eclipse IDE for IoT development, and tooling support for Sensor emulation, Power Analysis, and Cloud.By Max Domeika
June 26, 2015
At the recent Eclipse Foundation board meeting this week in Toulouse as part of EclipseCon France, the committer representatives helped move forward a code of conduct for the Eclipse community. As for a bit of background, the request for this initially came from bugzilla and also the LocationTech working group which was looking for a code of conduct for its community. The board opted for a simple code of conduct based on the Contributor Convenant, see this email from Mike Milinkovich:
I am very pleased to announce that the Eclipse Foundation Board of Directors approved a Community Code of Conduct at their meeting earlier this week at EclipseCon France. This brings the Eclipse community in line with the best practices for open source communities around the world.
Our community already has a strong culture of respect and professionalism. Neither I nor the Board expect anyone’s behaviour to change as a result of this. This is simply codifying the high expectations we already meet in terms of professionalism, respect, and simply courtesy.
I agree with Mike and couldn’t have said it better, we have a great community and this simply codifies our high expectations.
Today is a great day: with the announcement of Eclipse Mars, many great projects are released, and Sirius 3.0 is part of this release train.
When I have a look at the status of the Sirius project today, one soundtrack immediately comes to mind: Harder, Better, Faster, Stronger
Work on it harder
One first fact, looking at the project’s statistics, is that the Sirius team worked hard on this release to deliver some new cool features and improve the existing ones:
|Version||Date||Total Closed||Feature Requests|
This release is the first one on which the team worked at full speed, so for the future you can expect the same amount of work done.
Make it better
Their goal was to provide a better tooling for the end users by improving the diagram user experience. This work started with Sirius 2.0 and some of the following features are there since then.
Resizing a container
|Snap To Shape enabled by default for new diagrams|
|Snap To Grid now used when an element is created|
|Resize no longer change ports or children’s location|
|Actions to distribute shapes|
|Action to reset the diagram origin|
The editor was also improved to provide:
- Anchor on borders: Now the edges are linked closely to the images, you just need to define images with an transparent background.
- Underlined and strike through style for labels
- Compartments: There are two new values available for a container mapping
Horizontal Stack. This means that the defined container will show its children as a vertical/horizontal stack of compartments. Thanks to this new feature, you are able to define a dynamic number of compartments.
Compartments are just a specific setting of a full blown container mapping making it easy to create any artificial level of compartments independently from the metamodel structure.
Have a look at the Sirius compartments documentation for more details.
Do it faster
The goal was to get a runtime which react well with 1 million elements. Why one million? Because it is a beautiful number… but also because we noted that the modeling projects are fastly growing to 200K elements and 500K in case of in-depth analysis. Usually when you are over 500K, it means it’s time to re-think the process as you will likely need to decouple models with a clear and defined life-cycle. That is why we aim Sirius to work with 1 millions, then it will be really smoothly with the more usual 500K use case.
Sirius performances are in constant improvements, and this version comes with significant enhancements on heap consumption and time execution.
|Time (sec)||Heap (Mb)||Time Variation||Heap Variation|
|Open Huge Project||80||276||-31,00%||-20,00%|
|Open Big Class Diagram||11||24||-54,00%||+20,00%|
|Refresh Big Class Diagram||0,731||0||-18,00%||0,00%|
|Save After Diagram Change||26||0||-23,00%||0,00%|
On big operations, the model footprint is reduced by 20%. To do so, major work was done on:
- using MinimalEObject
- Transforming Colors from full-blown EObject into Immutable DataType
- Detecting and fixing leaks
- Reducing the usage of adapters.
Then the save strategy was reviewed as well as the diagram refresh and the image cache.
Another big task was to reduce the latency. First, on the UI runtime:
- model element selection dialogs must be used for big models.
- the right-click in the explorer was optimized.
- and the property views made with EEF are better integrated.
And then to reduce the latency on tables, SWT refreshes are now done in batch and the team also improved the table model refresh.
Performance is also your matter! It really depends on your .odesign specification. You should focus on queries which will have a complexity depending on the size of the model: measure, improve and repeat! Think about using the Sirius embedded profiler:
Make us stronger
The Sirius team also worked to polish the specifier editor. They improved many different small things which will really enhance the specifier work as it will guarantee a better odesign validation and an efficient navigation.
- Workspace class loading is BACK: With Sirius 3 you can define Java services and then try them directly in your current development environment, you do not need anymore to launch another runtime just to test your services!
- Image path validation and selection wizard: Now, there is a selection wizard to choose an image and then validation exists on image path. You will never get a not found image.
- Quick Outline: An awesome improvement: it allows to quickly find any element in a odesign! Just call
Ctrl+Oand a wizard shows up to help you searching through the viewpoint specification.
- Prioritized sub menus: Another great thing, the menus have been reordered and now the most used elements are available at the top.
If you are used to work with Sirius, you already know that writing queries can turn to a severe headache due to the lack of detailed type information.
Actually, there are in Sirius 5 different interpreters to write your queries:
- and the legacy one:
.odesign specification is as flexible as possible, tools can be reused among mappings, mappings can be reused by other mappings, but that means one variable definition can actually have several types depending on the
.odesign structure. If we have a look at the following query: What is the type of var:source?
Regarding our example, source can be a Man or a Woman but it could be Woman or Package. Then the source variable can be of multiple types and those types may have no common ancestor other than
Type analysis within the action language requires a stronger type information from interpreters. It is implemented in
var:. We made some improvements in
[/] and there is simply no support in legacy
ocl:. What we want is a good reference support.
The Acceleo Query Language also known as AQL comes to our rescue. The implementation of AQL is specifically tailored for the Sirius use case. We have many variables for a given expression and null values are common. The usage is really interactive and so the context is constantly changing. I can hear you “Hoooo no, not yet another language…”. Don’t be afraid! You know OCL ? Then you know AQL.
The most important things to know is that:
- You will find the classic operations like
- And some convenient ones as:
- There is no implicit variable:
[name/] is invalid becomes self.name
[self.eContents()->select(name.startsWith('A'))/] is invalid and becomes self.eContents()->select(i | i.name.startsWith('A')
self.referenceWithNoValue.someOtherAttribute has no evaluation error, returns "Nothing"
AQL is not strictly compatible with MTL but a subset of MTL works for both.
We did some benchmarks with the different queries engines available in Sirius:
There is no good reason not to use it considering the overhead vs the flexibility and strong validation. In Sirius 3.0, it is delivered as an experimental feature but it will be available officially for the next 3.1 release.
So consider using it from now on if you are still using Acceleo 2 expressions (
<%%>). Otherwise, if you are using MTL (
[/]), you can prepare your queries to make the migration easier.
Even if Sirius 3.0 is major version, don’t be afraid! The models are automatically migrated by Sirius, the API changes are well documented in the release notes and some projects such as EcoreTools or UML Designer could upgrade just by changing the version range in the plugin, no impact on the code.
The 3.1 version is planned for November and the next topics of work will be: more flexibility for diagram UX, compartments feature complete, bullet-proof AQL and again more performance and scalability improvements… and your priority is our priority for the future. So don’t be shy, report what you need and want on the bugzilla and remember you can sponsor us to get it done quickly!
Let’s have Daft Punk conclude this post:
More than ever
Our work is
Eclipse Mars has arrived, and with it comes a brand new Docker tooling for it.
|This blog is a cross-post from Eclipse Newsletter: Landed On MARS where you can read about more things included in recent released Eclipse Mars.|
We wanted to have a way to easily start/stop and deploy Docker containers directly from Eclipse.
We wanted something that would run on all three major platforms: Windows, Linux and OS X.
We wanted something that would work together with existing Docker command line tools, but also utilized provide better overview and easier/faster access to common operations, from a visual perspective.
We wanted it to be released with Eclipse Mars.
…and that is what we got now.
This article runs through how to get it installed, the main features and what the future plans are.
With Eclipse Mars released, you can get it from the Eclipse Mars
updatesite, the feature is named
If you want to try the latest greatest builds you can use
project nightly builds update site at
To use the plugins, it is assumed that Docker is already installed. You can see Docker’s Installation guide on how to do this on various platforms.
Once you have installed the Docker tooling, you will get access to three new views:
- Docker Explorer
a tree view listing all connected Docker instances, with image and containers.
- Docker Containers
a table view listing containers for selected Docker connection
- Docker Images
a table view listing images available in the selected Docker connection
The easiest way to get to see these are by opening the Docker Tooling perspective.
In the screen above, the Docker tooling are connected to a locally running Docker deamon named
To configure this you click the
Add Connection… button in the
Docker Explorer view.
This will start a wizard that will try to detect your default Docker connection setup, dependent on your operating system.
In Linux it will use standard unix sockets and if on Windows or OSX, it will look for the following
If neither of these are detectable, you can click
Use custom connection settings and provide the connection info.
When you have the connection working you can get started using Docker images.
To run the image, the easiest way is to right-click on the image in the Docker Explorer.
Here, I’ve initially filtered the list to just show images matching
wildfly and then using right-click to choose the
Run Image… action.
From within this dialog you can also search in Docker Hub for other images by clicking
In this example, I’m only going to focus on running using the defaults, but in the Run Image wizard you can also configure ports, links, volumes, environment variables etc.
By default, we enable interactive and tty mode to allow you to interact with the docker container in the console (i.e. if the image asks for input).
When you click
Finish, the container will start and show output in a Console and the Docker Containers view will show which ports are used.
In here, the port at 8080 (the web server) is mapped to 32768 on the docker daemon.
To show this I just need to goto http://dockerhost:32768 to access it.
dockerhost is the IP of the docker daemon.
If you have a
Dockerfile you can build it via the
hammer icon on the Image view. This will start the Build wizard.
Once built, the image will show up and be possible to use for running.
You can view properties for all the various parts: connection, image and container, including getting a tree view of what
docker inspect would show.
For Eclipse Mars we added all of the above base features and you can use it in your day-to-day work with Docker.
For Eclipse Mars SR1, we will work on getting some of the rough edges fixed, like &aposRun&apos and &aposBuild&apos should be available in the context menu and not only in the views menu.
Work also started in Eclipse CDT to support using Docker images to build binaries for an OS other than the one you are running on. The vision for this would allow running on Windows or Mac, but target native deployment on multiple various Linux architectures.
Furthermore in JBoss Tools we are working on better integrating Docker with Eclipse server adapters, to ease deployment of your web applications to a Docker container. You can see how server deployment works with the current Docker tooling by leveraging docker volumes and remote deployment support.
If you have suggestions or find bugs, please open these in the Linux Tools project under Docker.
Max Rydahl Andersen
We are on Mars now!
On June, 24, we've released Mars-based version of RCP Testing Tool as participants of Simultaneous Mars Release.
So RCPTT IDE has migrated from Indigo to Mars to allow users to install it into their developer Eclipse installations.
The review information is available here and the latest version can be downloaded from Downloads page.
You can also install RCPTT as an eclipse plugin from an Update Site or from Eclipse Marketplace.
Test Runner is now free and Open Source.
This is the first release of Open Source RCPTT Runner.Now RCPTT project consists of two tools providing the whole process of automated regression testing of Eclipse-based applications:
- Modern Development Environment supporting debugging and refactoring.
- Test Runner allowing to run your tests locally and in integration with Jenkins, Hudson, or other CI tools.
RCPTT Test Runner tests Eclipse-based applications by executing RCPTT tests unattended, on a regular basis.
It provides a command line interface and a Maven plugin and establishes seamless integration of your GUI tests with your favourite toolchain.
Runner is required to manage test bases greater than a dozen of tests for projects that care for development speed.
- Completely automated testing
- Command line interface
- Maven plugin
- Works with Jenkins, Hudson, Bamboo, etc.
- Human readable HTML report
- JUnit or custom reports
- Every commit can be verified by functional tests before reaching development branch
- Handles application hangups, logs errors, stores every test step and its result
RCPTT becoming mature
We are happy to celebrate RCPTT project graduation from incubation to mature!
P.S.: Will miss the egg. It was cute, though.
June 25, 2015
This week, the third major version of RAP, the Eclipse Remote Application Platform, has been released. As a major release, RAP 3.0 cleaned up deprecated API, allowing us to change and to optimize internals. I’m happy to report that we achieved a significant performance boost compared to 2.3. Before I go into details, let’s look at some results.
To evaluate the performance of RAP 3.0, we created a new load test setup. We deployed a test application with more than 300 widgets on an average cloud server (4 CPUs @2.80GHz and 8GB of memory). On another machine, we ramped up 1000 parallel user sessions, each issuing requests at a rate of one per second. The requests themselves are small, containing an event and some updated properties. Here’s the results of a test run with RAP 2.3.2:
Shortly before reaching 1000 requests per second the system started to degrade in response times, but stabilized at a level of ~60 ms. The server CPU utilization during this time was ~90%.
Running the exact same scenario with RAP 3.0, we saw an average server load of ~65% and the response times have dropped significantly:
With an average response time below 10 ms and 99% of all requests finishing in less than 100 ms, this is a result we are very happy with.
We used Gatling, a powerful load test tool that creates nice and meaningful reports. I’ve aligned the scales of both graphs to make them easier to compare. The test application and test scenarios are all public, allowing you to reproduce and to adapt the tests to your needs.
The application ran on the latest Oracle Java 8 VM using the G1 garbage collector (
Background: Change Detection
Various changes contributed to the performance boost in RAP 3.0. For example, the synchronization in the RWT servlet has been reworked. Initial GET requests don’t create a separate UISession anymore. However, the biggest performance gain was achieved by a number of improvements to the change detection. This mechanism preserves the current UI state before processing a request and then compares it with the state afterwards in order to detect and render changes.
Due to the remote processing model of RAP, clients can send requests to the server at a high rate, for example, when typing in a text field with a server-side listener for validation or data binding. Many of these requests have only little effect on the UI. However, since the change detection has the same amount of work to do for every request, it contributes significantly to the server load in these cases.
To speed up this process, most standard Control properties such as bounds or font, are now preserved in dedicated fields in a new, optimized data structure instead of HashMap entries. For example, information about all attached listeners are now kept as a bitmask in a single long value. We also reduced the number of short living objects created during the change detection in order to reduce GC load.
During this work, some more ideas came up and I’m looking forward to further improving the performance of RAP. Big thanks go out to the nice guys at MIC, who contributed their insights and sponsored the performance work in RAP 3.0.
Leave a Comment. Tagged with eclipse, mars, new and noteworthy, performance, rap, eclipse, mars, new and noteworthy, performance, rap
It is with great pleasure that I announce the on-time availability of the Handly 0.3 release, symbolically coinciding with Eclipse Mars. This release includes major new features, such as an outline framework, integration with text editors (in addition to preexisting integration with Xtext editor), a real-world exemplary implementation (a simplified Java model), and a number of API enhacements. This release is primarily focused on bringing more value to early adopters while further evaluating the Handly core framework.
Handly is a relatively new project at Eclipse started with an initial contribution from 1C. In brief, it can be described as a framework for handle-based models — with an emphasis on code models that render Eclipse workspace from a programming language angle.
Because the rest of the IDE usually depends on the code model, the quality of the design and implementation of that model is of the utmost importance. Traditionally, such models were built either entirely from scratch or by forking and modifying preexisting models. The traditional process required much effort, was tedious and error-prone. The resulting models were effectively silos with a completely isolated API, which prevented a possibility of developing reusable IDE components, although the models did seem to have certain traits in common.
The Handly project begs to differ with the traditional approach. It provides a set of flexible building blocks that help developers create handle-based models similar in design principles to the JDT Java model. The framework imposes almost no restrictions on the shape of the models or on the languages modeled. The uniform API makes it possible to develop generic IDE components dealing with such models — some common UI components are already provided by Handly. The intent is to come up with a really nice design in this problem area through an open and transparent development process primarily driven by community feedback. For more information, please visit the project’s website.
Despite the “incubating technology” status of Handly, there already are three known major adopters (in chronological order): 1C:Enterprise Development Tools, erlide (in yet-to-be-released version 0.30), and Codasip Studio — two commercial products and an esteemed open-source IDE. We are very grateful for their vote of confidence to the project, active participation and valuable feedback. With this release, we hope to encourage further adoption and receive broader feedback.
Some design discussions with early adopters are already taking place on the project’s forum, but also (as it stands, chiefly) on the handly-dev mailing list, with potentially even more interesting discussions soon to follow.
So if you are interested in this project and would like to have a say in it, I encourage you to engage as early as possible by playing around with this release and giving feedback.
June 24, 2015
Remote Services Tooling - A new Remote Services perspective with views to help design, test, discover, and debug Remote Services
OSGi R6 - Full support for OSGi R6 Remote Services/Remote Service Admin specifications. Full spec compliance via the OSGi compatibility test suite
New Providers - Support added for websockets and MQTT-based distribution providers, and etcd-based discovery
Apache Karaf - ECF Remote Services can now be easily installed into Apache Karaf
New Tutorials, Examples, and Documentation
More on the New and Noteworthy. Download here or via repository included in Eclipse Mars.
It's finally done. With today's Mars release we are able to celebrate the first release of the new GEF4 components, on which we have been intensively working for the last five years. A good opportunity for a small retrospective about our "Mission to Mars" and for some sightseeing "at the landing zone".
Countdown and Liftoff! - The Story behind GEF4The renewal of the GEF API had already been a vision back in 2010, when development of Zest 2.x was started with the goal to revise the Zest 1.x API, which had been kept backwards compatible since 2007. Draw2d and JFace were still unquestioned as underlying rendering technologies, but several refactorings and additions were incorporated (e.g. some new layout algorithms), all in a separate repository and thus in parallel to the maintenance of Zest 1.x. Two completely new features were added in this context as well: support for rendering of tag clouds (Cloudio) as well as Graphviz DOT-support in terms of an Xtext-based editor and a Zest-based viewer (Dot4Zest).
Inspired by how Fabian Steeg, Zoltán Ujhelyi, and Stephan Schwiebert were bringing Zest 2.x forward, I initiated a comparable renewal of Draw2d and GEF (MVC) 3.x, whose API had been kept stable since 2004, in early 2011. As the GEF project team strictly separated between Draw2d/GEF (MVC) and Zest component responsibility at that time, Matthias Wienand and I started with developing a new double-based geometry API pretty much in parallel to the Zest 2.x efforts. Nevertheless, as we finalized the geometry API in 2012, it soon became clear that the next generation GEF API had to be developed in a unified effort. In accordance to the usage of "e4" to depict the 4th generation of the Eclipse platform, we chose the term "GEF4" to refer to that unified effort.
The major goal we identified for this unified approach was to have a self-contained GEF4 with no dependencies on Draw2d, GEF (MVC), or Zest, which could thus be developed in parallel to maintaining the old production components, not affecting any of our adopters directly. One of the first steps we performed conjointly in terms of GEF4 was the migration of the Zest 2.x codebase to the GEF4 namespace, the unification of the related Git repositories and Hudson build jobs, and the adoption of the just finalized GEF4 Geometry component by the migrated Zest 2.x code base.
Having finalized this initial Zest 2.x migration, we now initiated work on a replacement API for Draw2d and GEF (MVC) 3.x, using JavaFX instead of SWT as underlying rendering technology. This lead to two new GEF4 components: GEF4 FX and GEF4 MVC. To already decouple as much of the migrated Zest 2.x code base from Draw2d 3.x as possible, we extracted all newly introduced features, namely Cloudio and Dot4Zest, as well as all rendering-independent parts into new GEF4 components, namely GEF4 Cloudio, GEF4 DOT (the Zest-based DOT-viewer was not extracted at that time, because of dependencies to Zest), GEF4 Graph, and GEF4 Layout.
Mission to Mars: Accomplished!The major goal for the Mars release timeframe - our Mission to Mars - was to finalize GEF4 FX and GEF4 MVC, so that a comparable functionality to that of Draw2d and GEF (MVC) is offered, and to completely rewrite the initially migrated Zest 2.x code base into a GEF4 Zest component that is internally based on GEF4 MVC, GEF4 Graph, and GEF4 Layout, and which uses JavaFX and GEF4 FX for rendering purposes. In other terms, we wanted to achieve that GEF4 is fully self-contained and provides at least the functionality offered by Draw2d, GEF (MVC), and Zest.
And while all GEF4 components are still provided with provisional API, and a little functional gap still remains compared to the current production components (on the other hand several new features are provided in exchange), a fully self-contained GEF4 has been initially released today as part of the GEF 3.10.0 (Mars) release. Mission accomplished!
Sightseeing Mars - What does the first release provide?The spectrum of what is provided with Mars reaches from libraries that may also be used apart from graphical applications (GEF4 Common, GEF4 Geometry) via dedicated graphical application development frameworks (GEF4 FX, GEF4 MVC, GEF4 Graph, GEF4 Layout, GEF4 Zest) to graphical end-user tools (GEF4 DOT, GEF4 Cloudio) that as well include framework parts.
All components (features) are broken down into one or more modules (plug-ins), to clearly separate parts that are rendering-toolkit (i.e. JavaFX) dependent from independent ones, as well as parts that rely on SWT, JFace, or the Eclipse Workbench UI from others. We consistently use the suffix ".FX" to indicate that a module depends on JavaFX technology, and ".UI" to indicate that it depends on SWT, JFace, or the Eclipse Workbench UI. The following are provided with Mars (modules are given in brackets, where appropriate):