September 02, 2014
I got the chance to see a preview of Vaadin 7.3 some days ago and I am really really impressed about the new features it brings.
Until now, I have worked with the Vaadin Reindeer theme and tried to customize it. But since I am a Java developer, I do not have particularly deep knowledge about CSS3 and had a hard time with it. That’s why I am really looking forward to Vaadin 7.3 and going to upgrade my customer projects in the next days. The new Valo-Theme is exactly what I have been trying to do myself: a responsive and highly customizable theme. There are many different styles and most of them meet my objectives without having to change anything in the CSS.
And the best thing about Vaadin 7.3 is that it comes with a high-end Sass compiler. In the last days I was reading a lot about Sass and it is a perfect match for Java developers. Using this very intuitive styling language, Vaadin 7.3 will compile that information into proper CSS3. Really crazy… For me Sass is something like a DSL for CSS3. Thus, I do not have to schedule my CSS training anymore — I just have to use Sass :D
OSGi and Vaaclipse
During the next days, I will “Run a first Vaadin 7.3 OSGi application”. And I am sure right now: it is a perfect match.
Running a Vaadin 7.3 OSGi application is the base for migrating the Vaaclipse-Project to Valo too. The Vaaclipse-Project is a rendering layer to render the e4-workspace with Vaadin. See http://semanticsoft.github.io/vaaclipse/.
For details about Vaadin 7.3 just click here.
I also added two screenshots about the new theme:
Going to keep you informed…
September 01, 2014
In our recent milestone releases of JBoss Tools 4.2 we’ve started gathering additional data from those who are have agreed sending back anonymous usage data to us (Thank you!).
Reminder: As always, this is my personal interpretation of the data and again it is early days for the data collection. These numbers are just for the last month of beta testers thus do take these absolute numbers with a grain of salt!
In any case I find the numbers interesting and thought I would share since there are some lessons to be learned.
One of the data points are which JBoss servers users create.
Mind you we don’t collect the exact version of the server installed, just which server adapter users are using - i.e. EAP 6.1 also covers EAP 6.2 and 6.3, WildFly 8 covers 8.0 and 8.1 etc.
The numbers above shows the last two weeks of server creation by our beta users. Not surprisingly majority of users are using the community version of the latest JBoss servers (AS 7.1 and WildFly 8), and it’s great to see the third most used server is the free for development/enterprise supported EAP 6.1/6.2/6.3.
What I find funny is that there are still users using the latest/greatest development tools, but who runs JBoss AS 3.2 - this was last released back in 2006! Talk about dedication :)
What the list shows to me is the importance of development tools need to support multiple versions because even though most are using latest/greatest runtime there are still a great bunch of users that will be using older versions of runtimes. Many developers tend to forget or blissfully ignore this.
I’m convinced as users move to our release that gathers these data we will start see even higher numbers of "older" runtime usage.
What is a bit disconcerting is how few seem to know about our Deploy only server (in this list noted as
This server allows you to use Eclipse’s support for incremental deployments to any directory locally or remotely available.
Really useful for deploying to a non-JBoss server, a remote PHP or just a plain html app.
You should try it out!
Combine this with our LiveReload support and you get a great and fast workflow!
Another data item we have insight to is the uptake of Eclipse versions.
The graph above is our recorded startups of Eclipse Java EE installs since January pr. week. Be aware the versions listed are the EPP versions, not Eclipse release train versions - I’ll do the mapping for you below.
Two things to note: the "Drop" at the end is just the effect of the numbers ending middle of the month, the "Dip" in mid April I’m not sure what is but we see it across all our Google analytics thus I expect it was an Google Analytics anomoly. The numbers have since stabilized, that said…lets interpret!
This graph shows how Eclipse Kepler SR1 release (2.0.1) usage is dropping as users upgrade to Kepler SR2 release (2.0.2) - this are most likely the effect of users using Eclipse built-in update mechanism to upgrade.
What also can be seen is that the latest stable release (4.4.0) uptake is gaining faster than total Eclipse version usage (the faint lines are even older eclipse versions). Meaning total usage of JBoss Tools is up/stable. Eclipse isn’t dead yet :)
I wish Google Analytics had a way to show this graph cumulative instead of per line…anyone up for a data extraction and visualization project ? I’ll give you access to the data to play with.
Finally, my personal main interest was to see what the uptake of Eclipse Luna is.
You can see what effect a GA release of Eclipse has. The red line is Eclipse Luna going from a couple of hundreds starts to now 7.000 starts pr. week since its release - but do notice that there is no corresponding drop (yet) in Kepler. Looks like most are installing Luna next to their Kepler installs (my theory at least ;)
This mimicks previous years uptake patterns and once everyone gets back from vacation and Luna SR1 release comes out it should be close to the level of Eclipse Kepler installs. Good to see users continue to picking up latest greatest features and bugfixes!
I’ll go look at the numbers again in a few months to see if the trend continues.
If there is some additonal data you are interested or questions about the above let me know in comments and I’ll try include/answer it!
Max Rydahl Andersen
Even back when the first line of code was dropped for Hybrid Mobile tooling, making the tools as part of the Eclipse foundation was a goal. When starting, we looked at the available tools for developing Cordova applications. We found out that there were no open source solutions that we could contribute and use as part of our tools. Furthermore, interoperability among what very little existed was poor. Of course, our main goal is creating good tools for Apache Cordova development, but while doing that we always keep an eye on interoperability and extendibility.
It is only natural that we are moving the development of our tools for Cordova based application development and forming the Eclipse THyM project. We hope that, as a vendor neutral non-profit organization, Eclipse foundation will encourage contributions and be the base for interoperable Cordova tooling.
Everything related to Cordova based development including the project management, plugin discovery, and support for iOS and Android excluding the Cordova simulator is contributed to Eclipse.org. We have excluded CordovaSim for now because of its complex set of dependencies
The development will continue to happen on GitHub but on a repository owned by Eclipse foundation. The contributed code is already renamed, cleaned and on the new repository. If you are a contributor, or want to be one, please use https://github.com/eclipse/thym
JBoss tools will continue to have support for Cordova development. We will consume Thym project and extend them with more capabilities and integrate with other parts of the tools and technologies coming from projects such as Aerogear.
And of course our wish to create good tools for Apache Cordova development continues with a hope for better collaboration with other individuals and companies.
The Maven Integration for Eclipse plugin, a.k.a. m2e, released version 1.5.0 a few weeks ago, as part of the annual Eclipse release train, this year known as Luna. 77 Bugs were fixed as part of that release, compatible with both Eclipse Kepler and Luna. I believe it’s a pretty solid one, with numerous interesting fixes and usability improvements that deserve a blog post. So here goes, in no particular order:
Selecting Maven projects to import used to take an inordinate amount of time, due to a suboptimal - I love that word :-) - Maven Lifecycle Mapping Analysis (LMA). LMA is used to determine whether the projects would require further configuration to operate properly in Eclipse. That LMA is now only run after projects are imported, making selection of projects to import much, much faster (< couple seconds vs 1-2 min for the wildfly 8.0 codebase and its 130 projects, for instance)
After import, lifecycle mapping error markers are collected on imported projects and the discovery service is invoked to find proposals to fix those errors.
Another improvement to this workflow is the ability to easily import multi-module projects to an Eclipse Working Set. The default name is inferred from the root project but can be overridden manually:
Before m2e 1.5, by default, Nexus indexes were downloaded on new workspace startup, then subsequently once a week. Depending on your internet connection, that whole process could take 15 minutes or more, heavily pegging the CPU. Once the indexes were updated, the size of the workspace would increase by approximately 500 MB. Even though space is relatively cheap these days, those with many workspaces (eg., for testing) or large workspaces, this extra disk usage can add up quickly.
m2e 1.5.0 now has this feature disabled by default. You can still enable it in. One major downside of having this feature disabled by default though, is Archetype and Artifact/Plugin searches are now much less efficient, as they rely on this indexed content.
See bug 404417
The JBoss Tools team contributed its Maven Profile management interface to m2e 1.5.0. This new interface eases switching between profiles.
Rather than right-clicking on a project, going to the Ctrl+Alt+P to open the new Maven Profile selection interface.page, then manually (mis)typing a list of active or disabled profiles, you can now just use
The new interface is also accessible from the Maven context menu: Right-click project
The list of available profiles is inferred from profiles defined in:
the project pom.xml
the project’s parent hierarchy
user and global maven settings.xml
When several projects are selected, only the common available profiles are displayed for selection. Common profiles are profiles defined in settings.xml or profiles having the same id in different pom.xml.
You can learn more about that feature from the original JBoss Tools blog
See bug 428094
The Update Maven Project dialog (launched via Right-click projector via Alt-F5), now shows a dirty overlay on projects which need updating.
Additionally, an "Add out-of-date" button adds all out-of-date (OOD) projects to the current selection. If an OOD project has not been selected, a warning is shown underneath the selection table with a link equivalent to "Add out-of-date". Warning text and "Add out-of-date" button tooltip show a count of unselected OOD projects.
See it in action: http://screencast.com/t/27S0qeca
See bug 422667
There’s a very popular question on StackOverflow about an
m2e bug that plagued many users of the maven-eclipse-plugin: m2e would throw
Unsupported IClasspathEntry kind=4 exceptions on classpath entries generated by the maven-eclipse-plugin
(one of the reasons why you should never mix maven-eclipse-plugin and m2e).
m2e 1.5.0 no longer complains about these unsupported classpath entries, but unexpected classpath issues may still arise, should you mix duplicate jars from m2e and those added by the maven-dependency-plugin.
See bug https://bugs.eclipse.org/394042
Ever connected to a network with limited Internet access or simply stayed at a hotel where you needed to get past a for-pay-firewall, resulting in HTML pages being downloaded instead of jars? There’s nothing better to pollute your local Maven repository. Maven CLI builds can use these flags:
-C- fail build if checksums do not match
-c- warn if checksums do not match
m2e now has a global Checksum Policy available in, that will help you keep your sanity, and yor local repository clean:
While m2e actually won’t create any Warning markers on projects when "Warn" is selected, it will override existing checksum policies set on repositories.
See bug https://bugs.eclipse.org/418674
m2e has been known for generating specific errors that have puzzled more than one user in the past:
Project Configuration is not up-to-date- a change in pom.xml might require a full project configuration update.
Plugin execution not covered by lifecycle- m2e doe not know if it is safe to execute a maven plugin as part of the Eclipse build
With the new
Warning, or even be ignored entirely.
A few changes have been made with regards to the Maven runtime(s):
The embedded Maven runtime has been updated to maven 3.2.1.
The Netty/AsynHttpClient transport layer as been replaced with OkHttp 1.5.4. OkHttp is now the default HTTP client on the Android platform. It brings HTTP 2.0 and SPDY support to artifact downloads. Please note though, NTLM authentication is not supported.
Maven runtime installations can now be customized with a name, and additional libraries can be added. Maven Launch configurations now reference the Maven runtime by name, instead of using a hard-coded location so the configuration is more portable.
In order to lower the contribution barrier and increase contributor diversity, the m2e project now accepts changes contributed via the Gerrit review system. Head over the wiki that explains how to use it. Does it work? Hell yeah! After several significant contributions, Anton Tanasenko has joined the m2e team as commiter!
See bug 374665
With new blood on the m2e team, numerous fixed bugs and some big new features & improvements, m2e 1.5.0 is a pretty exciting release. Hope you guys appreciate this year’s release, before an even better version next time.
So if you haven’t installed m2e 1.5.0 yet, head over to https://www.eclipse.org/m2e/download/ and have at it.
It’s been a while since the Eclipse Foundation decided to stop the Usage Data Collector. The main reason for stopping this service was that, although thousands of users shared data, neither plug-in providers nor researchers took significant advantage of the data collected at that time. Since its shutdown, however, a new demand for collecting usage data evolved. But compared to the data collected by the UDC, today’s demands are different and vary quite a lot from project to project.
We started with our first Sharky talk in Germany Darmstadt one year ago. Now after furthermore 9 talks we decided to stop the project. We showed our Sharky in many different cities like Darmstadt, Vienna, San Francisco, Ludwigsburg, Mainz, Zurich and Munich.
Now we are on the way to find new ideas for projects, hopefully as good as the sharky project was.
In this video you can see our last Sharky presentation at IoT-Meetup in Vienna. (the Video is in german)
See you soon,
- Installation of Edapt,
- Use of Edapt
- Tracking your Model Changes [History → Operations]
- Versioning your Model [URI Updation]
- Migrate your Model Instance [Automatic Migration of Model Instance]
August 31, 2014
1. strip existing old license headers (if needed), as the automated tool requires a particular format
2. automatically apply new standard header to all files
3. ensure that new files added in the future which don't include the new standard header fail your build
4. using your source control tool to compare before/after, and manually fix-up any lost names etc.
For some probably historical reason there appear to be two very similar Maven plug-in for this, namely the Mycila Maven License Plug-in and the Codehouse Mojo License Maven Plugin (confusingly both named "license-maven-plugin", but with a different groupId). We'll be using Mycila's for the stripping (as Codehouse' doesn't seem to include that feature), and Codehouse for the re-adding and future enforcement.
So to strip existing old license headers, add this to your (parent) pom.xml:
$ mvn com.mycila:license-maven-plugin:remove
Doing e.g. a git diff now will show you that existing license headers have been removed. As this was a one-time operation, you can now remove the com.mycila:license-maven-plugin from your pom.xml again, and add this instead:
$ mvn license:update-file-header
and do e.g. a git diff now to see that you that new license headers, in the format suitable for automate tooling. If you've previously removed old license headers, then at this point you might want to do a before/after comparison, and manually fix-up any lost names etc.
Note how the pom.xml configuration above binds mvn license:check-file-header to the Maven lifecycle validate phase. This means that your build (incl. e.g. your TravisCI or Jenkins-based GitHub pull request) now automatically enforces presence of these headers. A new file added missing them will cause any future mvn verify / test / package etc. to fail with:
[INFO] BUILD FAILURE
[ERROR] Failed to execute goal org.codehaus.mojo:license-maven-plugin:1.7:check-file-header (default-cli) on project org.eclipse.emf.eson: There are .. file(s) with no header :
If your build is using Gradle instead of Maven, something very similar can be done using the license-gradle-plugin from nl.javadude.gradle.plugins; you can see how to configure it e.g. in the build.gradle of the open source microfinance platform Mifos X.
These models have of course a graph structure, but when taking a closer look, they are actually more than just that. The higher expressive power of metamodeling languages like EMF or MOF in comparison to simple graphs has some severe implications when trying to apply formal (mathematical) methods known from the graph transformation research community.
Let's take a look at a concrete example of a Henshin transformation. The following rule is a variation of the Bank Accounts example:
This rule collects all accounts which do not belong to any client and adds them to a designated bank for "orphaned" accounts. The graph transformation semantics of this rule does exactly what is shown: it creates zero or more edges between a bank and a number of account objects. In contrast, the EMF-semantics actually has a twist which is not directly visible here: any of the orphaned accounts which before belonged to a different bank object are removed from their original bank. Thus, this rule can actually also delete edges.
This is because in EMF, adding an object to a container also means that it is removed from its old container. Implicit deletion of edges can also occur for edges with multiplicity 1. Another semantical difference to graph transformations exists for the handling of bidirectional references (eOpposite-references). In this case, EMF automatically maintains the opposite references in a consistent state which can have the effect that EMF removes or creates edges. It can actually get more complicated when you have a combination of containment and multiplicity constraints, and opposite edges.
EcoreUtil.equals(eObject, EcoreUtil.copy(eObject))does not always return true. This is because the copy mechanism in EMF won't make any changes which would alter the original model (e.g. bend an opposite reference).
The lesson learned is that models are more than graphs, and model transformations are more complicated than graph transformations.
August 30, 2014
In the wild the Infocenter is used for instance by Tasktop without modification except an additional header…
… or by bada Developers:
I like the red style of Wolfram. Even the icons have been adapted:
ARM has made functional changes to the Infocenter. With the menu to the left of the search box you can select where to search, e. g. within the title only or in the whole document. Interestingly, some icons have been removed: there is no Print/Search Topic (and its Subtopics) icon and no Link with Contents icon in the Contents toolbar; no Group by Categories and no number of matches in Search Results.
Sybase also made some search modifications. The drop-down menu right of the search field makes it easier to switch between search scopes that have been created. The flashlight symbol of the search icon to search a topic (and its subtopics) has been replaced with a magnifying glass.
The Infocenter of VMware is hardly recognizable as such. The tabs are shown at the top instead of at the bottom. Maybe because today common web browsers do not have a status line and show the target of a link while hovering it in the left bottom corner which hides bottom tabs.
IBM, the company which has done most of the development work for Eclipse’s Infocenter, added a Collaboration tab to show hot topics and – if logged in – the user’s own comments. There is also a frame below the topic frame for topic-specific comments.
IBM has begun to replace this and other Infocenter instances with its new Knowledge Center. I guess but I don’t know that it is still based on Eclipse Infocenter. It does not use HTML framesets but an iframe for the topic. The search field is wider and the search scope follows automatically the selected book which covers a product.
Most of the modifications described above are about searching. Please drop a comment if you have come across an Infocenter with other modifications. If you like a modification then report it to Eclipse, or even better, implement it and contribute it to Eclipse and watch them reintroduce it into the wild.
August 29, 2014
August 28, 2014
I am thrilled to announce the Eclipse Board of Directors has formally approved the creation of the Eclipse IoT top-level project. This is an important milestone for our vision of creating an open source community that is creating the technology to power the Internet of Things (IoT).
Less than two years ago we created the IoT Working Group to start a collaboration between vendors that saw a need for a vendor neutral open source community. Companies like IBM, Sierra Wireless and Eurotech were instrumental in setting the vision. In those two years the community has grown to 15 different open source projects. We have developed a vibrant, innovative community that is delivering technology today. Due to this success, it was time to formally create a top-level project that would help guide and mentor the IoT projects. The creation of the IoT top-level project will allow us to grow and scale the IoT community to address the needs of the IoT industry.
The Eclipse IoT top-level project will be led by Jens Reimann (Eclipse SCADA project leader) and Kai Kreuzer (Eclipse SmartHome project leader). Both Jens and Kai have been great leaders in our IoT community and it is awesome to have them lead the PMC. If you would like to follow the working of the PMC please subscribe to their mailing list.
Moving forward, the new IoT top-level project will work very closely with the IoT working group. We are well on our way to fulfilling our vision of being the open source community for IoT.
August 27, 2014
We are happy to announce that EclipseSource is going to Austria! Effective today, there is an EclipseSource division in Austria with an office in Vienna. Philip (Langer) is leading our office in Vienna and is bringing solid Eclipse Modeling Framework experience to our team with a focus on software modeling as well as model collaboration, versioning and simulation. Furthermore, he will drive innovation in modeling with his tight links to Vienna University of Technology.
With our expansion to Vienna, we can now accommodate our customers in Austria even better and enhance our team with more modeling experts.
Contact us with your projects in Austria. We are looking forward to it.
Leave a Comment. Tagged with Austria, eclipse, EclipseSource, emf, Austria, eclipse, EclipseSource, emf
The major change in this release is that the minimap is enabled by default (for PyDev and LiClipse editors). With this change, the scrollbars are now also hidden by default. It's still possible to revert to the old style in the minimap preferences (but for me the current style is much better -- especially when using dark themes).
Below is a snapshot showing a 2.000 lines file in the editor... unfortunately I wasn't able to remove the scrollbars in the tree (believe me, I've tried), but without the scrollbars in the editor, it's already much nicer!
Besides that, StringTemplate and YAML are now also supported.
And at last, it's possible to debug Django Templates by adding breakpoints (in the LiClipse HTML or Django Templates editors).
August 26, 2014
EMF Forms is a component of the EMF Client Platform project that provides a form-based User Interface to display and edit your data, a.k.a. the entities of your application. The UI is rendered based on a view model at runtime and provides an out-of-the-box experience while being highly customizable. If you are not familiar with EMF Forms yet, please read this tutorial.
We have just updated the documentation with more information how rendering in EMF Forms works in the 1.3 release with details on prioritization, styling and layouts and how they can be influenced and customized. The new documentation can be found here.
Leave a Comment. Tagged with eclipse, emf, EMF Client Platform, emfforms, Rendering, eclipse, emf, EMF Client Platform, emfforms, Rendering
What I really like with MQTT and CoAP is that they both are very simple protocols. When dealing with MQTT, the client itself has almost no state to maintain (at least when you stick to QoS 0 communications) and granted that you have an MQTT packet serializer/unserializer, it’s very simple to stuff such MQTT packets into TCP sockets using the networking APIs that your IoT microcontroller is providing.
The tutorial below, split into two parts (publishing and subscribing), gives a complete overview on how you can very easily port MQTT to the CC3200 and should probably be useful if you’re targeting another kind of platform, as it walks you through the process of tying in with the networking API of the underlying platform (TI SimpleLink™ in CC3200′s case)
No matter with what graphics technology you choose to implement a diagram for your Xtext-based language, there are a few things you should know in order to connect the diagram view/editor to the rest of the infrastructure.
Let us first have a look how to implement a context menu action for the Xtext editor to show the element at the current cursor position in the diagram. In Eclipse, you have to implement a handler for such an action. Xtext offers a bunch of classes making your life easier. EditorUtils detects the Xtext editor for the handler’s action and EObjectAtOffsetHelper finds the semantic model element at a given text offset.
As the document – and thereby the model parsed from it – is subject to editing, you have to make sure nobody is changing it while you traverse it to derive your diagram. You can execute code in a read transaction on the XtextDocument by wrapping it in an IUnitOfWork that you pass to the XtextDocument#readOnly method.
The following snipped shows an example handler written in Xtend.
Note that the @Inject annotation in the example requires you to use your language's executable extension factory when you register the handler class it in the plugin.xml of your language's UI plug-in. See the Xtext documentation for details.
To navigate from a diagram element back to it’s element definition in the text, you need to store some back reference. The model element itself is not suitable, as its lifecycle is bound to the one of the editor, and the parser is even free to expunge model elements whenever the document is re-parsed. As Xtext is based on EMF, each model element has a unique URI. You should always use these URIs to store references to model elements beyond the boundaries of a read/write transaction. An element’s URI is provided by EMF's EcoreUtil#getURI method.
Having the URI, the navigation to the respective model element’s definition is easiest to implement using Xtext’s IURIEditorOpener. If your diagram view supports selection listeners, the respective Xtend code could look like this:
Diagrams are superior to code when it comes to high-level views. But while programmers can easily cope with files that contain several hundred lines of code, the same amount of information usually blows a diagram and destroys all its suggestiveness. Diagrams with just a few nodes and edges showing on a certain aspect of the models only are best fit for human readers. Such aspects are often spread across various model files. So in order to add the best value for the language users on top of an Xtext infrastructure, we need to allow them to create multiple diagrams, each highlighting just a subset of model information, picked from multiple model files. In other words, diagrams that have a completely different structure than their associated textual models.
Traditional graphical editing frameworks focus on editing the underling model through the diagram.
But synchronizing the model changes from textual and diagram editors is very hard if their content's structures differ. In most cases, the integration will lead to major usability quirks like unexpected editor behavior, forced save operations, blocked editors or even data loss.
So rather than working around the hard challenges of integrating graphical and textual model editing, we can leave model modification to Xtext. For the graphical stuff we can concentrate on diagram editing and leave the underlying model read-only. This way we can spend our energy on the things that really matter to the user, like easy and useful ways to populate diagrams or best visual appearance.
In Eclipse, one could build such graphical views using Zest or GEF. If model and diagram do not differ too much in structure, a small code generator targeting GraphViz is a very simple solution with high quality output.
The general integration with Xtext is covered in a follow up post.
The following screencast shows another solution for an Xtext-based domain model language. The graphical editor is using FXDiagram, a diagram framework based on JavaFX. FXDiagram offers a very smooth user experience, excellent rendering, support for touch-pad gestures, animated undo/redo, diagram persistence, export to scalable vector graphics and much more. If you are interested in learning more, feel free to contact me.