Edapt - A EMF Model Migration Framework

by Its_Me_Malai (noreply@blogger.com) at September 01, 2014 01:15 PM

CHANGE is the most common term we would hear when it comes to requirements. And that’s common to our Model also as it is what the requirements are finally represented as in our Software World. Modelling is always an iterative stuff.

As usual Google let us step into Edapt, which is a promising framework for Model Migration and also auto Instance Migration. It promises to be a lot more easier than M2M Tools.

In this article, we are going to explain the following
  1. Installation of Edapt,
  2. Use of Edapt
Now normally in any application, we will design the Model and get into the conceptualization of the model on the UI. Once in production, it is very common that we get request to change the model varying from renaming a variable to throw out a complete class.

Changing the Model is an easy job, get the request, do the needful in Ecore and generate the Src for Model, Edit and Editor using the GenModel. But what happens to the data or instances of the model that have been already created.

Migration is a BIG Headache.

Edapt's intention is to address such migration issues for EMF Models. Edapt address these issues thru the following steps.
  1. Tracking your Model Changes [History → Operations]
  2. Versioning your Model [URI Updation]
  3. Migrate your Model Instance [Automatic Migration of Model Instance]
To read the Article on how to setup and use edapt : Click Here

Edapt is hosted on eclipse.org under the URL : http://www.eclipse.org/edapt/

by Its_Me_Malai (noreply@blogger.com) at September 01, 2014 01:15 PM

Fun stats about WildFly and Luna

by maxandersen at September 01, 2014 12:50 PM

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.

JBoss Server Usage

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.

server creation stats

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.

Oldie but goodie

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 :)

Importance of Multiple runtime support

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.

Deploy Only Server

What is a bit disconcerting is how few seem to know about our Deploy only server (in this list noted as systemCopyServer ). 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!

File ▸ New ▸ Server ▸ Basic ▸ Deploy Only

Combine this with our LiveReload support and you get a great and fast workflow!

Uptake of Eclipse versions

Another data item we have insight to is the uptake of Eclipse versions.

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.

Uptake of Eclipse Luna

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!

Have fun!

Max Rydahl Andersen
@maxandersen


by maxandersen at September 01, 2014 12:50 PM

Development of Hybrid Mobile Tools has moved to Eclipse Foundation

by gercan at September 01, 2014 12:50 PM

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.

What is contributed

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

What is changing

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

We will use bugzilla, and thym-dev mailing list from now on as provided by Eclipse foundation. As expected project documentation is at the wiki. The builds will be running on eclipse.org build server instance.

What is NOT changing

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.


by gercan at September 01, 2014 12:50 PM

m2e 1.5.0 improvements

by fbricon at September 01, 2014 12:50 PM

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:

Improved project import workflow

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:

m2e-workingset-import

More performance improvements during import itself are to be expected to be included in m2e 1.6.0.

See bugs 409732, 408042 and 417466.

Improved memory consumption

Maven project instance caching strategy has been revisited to reduce memory consumption. For a workspace with 300+ projects for instance, heap memory used went from 2.5GB down to well under 1GB without any noticeable side effects.

Nexus index download disabled by default

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 Preferences ▸ Maven ▸ Download repository index updates on startup. 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

New Maven Profile management UI

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 Properties ▸ Maven page, then manually (mis)typing a list of active or disabled profiles, you can now just use Ctrl+Alt+P to open the new Maven Profile selection interface.

m2e-profile-selection

The new interface is also accessible from the Maven context menu: Right-click project Maven ▸ Select Maven Profiles…​

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

Easily update outdated projects

The Update Maven Project dialog (launched via Right-click project Maven ▸ Update Project…​ or 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.

m2e-select-ood-projects

See bug 422667

No more Unsupported IClasspathEntry kind=4

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.

New checksum settings

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 Preferences ▸ Maven, that will help you keep your sanity, and yor local repository clean:

m2e-checksum-policy-flag

While m2e actually won’t create any Warning markers on projects when "Warn" is selected, it will override existing checksum policies set on repositories.

Improved settings for Errors/Warnings preferences

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 Preferences ▸ Errors/Warnings page, users can now decide according to their own needs whether these errors should be downgraded to Warning, or even be ignored entirely.

m2e-warnerrors-prefs

See bugs 433776, 434053

Maven runtime changes

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.

See bugs 427932, 418263, 432436

Accept contributions from Gerrit

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!

Welcome Anton!

See bug 374665

Conclusion

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.

We’d love to hear your feedback on the mailing list, or whether you report bugs or enhancement requests.

Fred Bricon
@fbricon


by fbricon at September 01, 2014 12:50 PM

How-to clean up and enforce open-source license headers in Maven-based build

by Michael Vorburger (noreply@blogger.com) at August 31, 2014 01:26 PM

The other day I had to make sure that an open source project had clean and proper copyright and license headers in all its files. For Apache Maven-based builds, here is a quick write up illustrating how you can automate doing this. The main steps are:

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:

<plugin>
   <groupId>com.mycila</groupId>
   <artifactId>license-maven-plugin</artifactId>
   <version>2.6</version>
   <configuration>
       <header>com/mycila/maven/plugin/license/templates/APACHE-2.txt</header>
   </configuration>
   <executions>
       <execution>
           <goals>
               <goal>check</goal>
           </goals>
       </execution>
   </executions>
</plugin>

Then run this:

$ 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:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>license-maven-plugin</artifactId>
<version>1.7</version>
                <configuration>
                    <licenseName>apache_v2</licenseName>
                   <addJavaLicenseAfterPackage>false</addJavaLicenseAfterPackage>
                    <failOnMissingHeader>true</failOnMissingHeader>
                    <failOnNotUptodateHeader>true</failOnNotUptodateHeader>
                    <roots>
                        <root>src/main/java</root>
                        <root>src/test/java</root>
                    </roots>
                </configuration>
<executions>
   <execution>
       <phase>validate</phase>
       <goals>
           <goal>check-file-header</goal>
       </goals>
   </execution>
</executions>
</plugin>

You can change the licenseName to any of those listed by mvn license:license-list. Now run:

$ 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
[INFO] ------------------------------------------------------------------------
[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 :
[ERROR] /home/vorburger/dev/ngMUI/com.temenos.ds.op/SUBS/eson/org.eclipse.emf.eson/src/org/eclipse/emf/eson/EFactoryRuntimeModule.java

If using Eclipse, you may also would like to set up  menu Project > Properties (or Window > Preferences) > Java > Code Style > Code Templates, Comments > Files for new Java files to get your header by default.

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.

by Michael Vorburger (noreply@blogger.com) at August 31, 2014 01:26 PM

Why Model Transformations != Graph Transformations

by Christian Krause (noreply@blogger.com) at August 31, 2014 11:48 AM

Model transformations are probably the most important application of (the formal theory of) graph transformations. This includes classical source-to-target model transformations, bidirectional transformations and synchronizations, as well as in-place rewriting, e.g., for refactoring. All these applications have in common that the underlying graphs to be transformed are actually EMF- or MOF-based structural data models.

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.

These phenomena can be considered as side effects of rules -- they are actions performed by EMF even if they are not explicitly specified in the transformation rules. Henshin does not prevent these side effects (that is actually not possible), but it will print warning messages when such side effects occur during the execution.

From the EMF / MOF perspective, the described effects are intended and desirable. What is problematic though is to assume that model transformations per se have graph transformation semantics and (what is more dangerous) to apply formal verification methods from the graph transformation domain without taking into account these possible side effects of rules.

There are also other related, partly surprising, phenomena when dealing with EMF models. For example, copying an object does not necessarily yield an identical object, i.e., the expression:
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.

by Christian Krause (noreply@blogger.com) at August 31, 2014 11:48 AM

Eclipse Infocenters in the Wild

by howlger at August 30, 2014 02:56 PM

Apart from help.eclipse.org for Luna and previous simultaneous releases Eclipse offers its Infocenter for Orion:
Eclipse Orion Help

In the wild the Infocenter is used for instance by Tasktop without modification except an additional header…
Tasktop User Guide

… or by bada Developers:
bada Documentation - bada Developers

I like the red style of Wolfram. Even the icons have been adapted:
Wolfram Workbench Documentation

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.
ARM Information Center

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.
SyBooks Online

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.
VMware vCenter Site Recovery Manager 5.1 Documentation Library

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 Content Analytics Information Center

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.
IBM Knowledge Center

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.

Flattr this



by howlger at August 30, 2014 02:56 PM

Is Docker Eating Java's Lunch?

by Peter Kriens (noreply@blogger.com) at August 29, 2014 09:32 AM

The reason I've put up with Java's deficiencies so long (ok, now with Lambda's it is finally starting to become a real language) is that I truly believe in the 'Write once, run anywhere' mantra. I've never understood why you want to write software that is not reusable and thus portable. Java achieved its portability by creating an abstract API for the interaction with the host Operating System (

by Peter Kriens (noreply@blogger.com) at August 29, 2014 09:32 AM

Welcome to the new Eclipse IoT Top-level Project

by Ian Skerrett at August 28, 2014 07:06 PM

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.

 

 



by Ian Skerrett at August 28, 2014 07:06 PM

Eclipse Newsletter - Creating your own language with Xtext

August 28, 2014 02:53 PM

This month we're all about Xtext, a framework for creating your own programming language and domain-specific language.

August 28, 2014 02:53 PM

How to easy customize Gerrit Submit rules

by Dariusz Łuksza at August 27, 2014 09:33 PM

Gerrit submit rule is a set of conditions that needs to be fulfilled before change can be submitter (read merged) to given branch. By default there are only two simple conditions: Verified +1 (V+1) Code Review +2 (CR+2) First one means that change don’t break the build (or project integrity). This step can (and it […]

by Dariusz Łuksza at August 27, 2014 09:33 PM

EclipseSource goes Austrian!

by Maximilian Koegel at August 27, 2014 11:15 AM

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.

 EclipseSource goes Austrian!

Photo by John Menard, Licensed under CC on flickr.


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with Austria, eclipse, EclipseSource, emf, Austria, eclipse, EclipseSource, emf


by Maximilian Koegel at August 27, 2014 11:15 AM

LiClipse 1.1.1: Minimap default, YAML and StringTemplate supported

by Fabio Zadrozny (noreply@blogger.com) at August 27, 2014 12:48 AM

LiClipse 1.1.1 has just been released.

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).

by Fabio Zadrozny (noreply@blogger.com) at August 27, 2014 12:48 AM

EMF Forms Rendering

by Maximilian Koegel at August 26, 2014 04:16 PM

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.

 26 08 2014 18 16 17 EMF Forms Rendering


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with eclipse, emf, EMF Client Platform, emfforms, Rendering, eclipse, emf, EMF Client Platform, emfforms, Rendering


by Maximilian Koegel at August 26, 2014 04:16 PM

MQTT on the TI CC3200 LaunchPad thanks to Paho embedded client

by Benjamin Cabé at August 26, 2014 10:33 AM

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.

I’ve had the opportunity to play with the TI CC3200 LaunchPad platform recently, and thought it would be a good candidate to try out the Paho embedded C Client.

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)


by Benjamin Cabé at August 26, 2014 10:33 AM

Graphical Views for Xtext ctd.

by Jan Köhnlein (noreply@blogger.com) at August 26, 2014 09:14 AM

(Read my previous post for a rationale on graphical views)

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:


by Jan Köhnlein (noreply@blogger.com) at August 26, 2014 09:14 AM

Graphical Views for Xtext

by Jan Köhnlein (noreply@blogger.com) at August 26, 2014 09:14 AM

Xtext provides you with a powerful IDE and a rich featured text editor for your domain-specific language with little effort. But sometimes, a picture says more than a thousand words: You want to have some additional graphical representation of your models, a set of diagrams.

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.




by Jan Köhnlein (noreply@blogger.com) at August 26, 2014 09:14 AM

EMF Validation for Datatype constraints

by Maximilian Koegel at August 26, 2014 08:16 AM

After defining a model, it is a common next step to define validation rules. Often there is a requirement to have attributes with a restricted length or attributes with values in a specific range. Furthermore, it can be the case, that there are multiple attributes with the same restriction in different places of the model. To solve such a requirement EMF offers a simple solution: EDataTypes with Annotations.

This is a step-by-step guide how to define your own restricted DataType.

First, you need to define a DataType:

  EMF Validation for Datatype constraints

Then the properties of the DataType must be set, this includes the actual Type (the Instance Type Name) and the new Name of the custom DataType:

 EMF Validation for Datatype constraints

In the next step, you must define the constraints with an Annotation on the DataType:

  EMF Validation for Datatype constraints

In the properties of the Annotation, the source must be set to “http:///org/eclipse/emf/ecore/util/ExtendedMetaData”:

 EMF Validation for Datatype constraints

 To define the constraints, a Details Entry must be added to the annotation:

 EMF Validation for Datatype constraints

You can add multiple Details Entries, if multiple constraints must be set e.g. the lower and upper bounds of a range restriction.

The key of the Details Entry corresponds to the constraint type and the value corresponds to the constraint value:

  EMF Validation for Datatype constraints The complete DataType definition looks like this:

 EMF Validation for Datatype constraints

 You can now use this definition as an attribute type of any EAttribute in the model:

 EMF Validation for Datatype constraints

An attribute with such an AttributeType will automatically provide validation results, e.g. via the Diagnostician. Therefore, frameworks like EMF Forms will automatically evaluate and display them:

 EMF Validation for Datatype constraints

You can find the complete list of possible keys here. Just search for “Facet” and look at the “details key”.

For your convenience, the most important ones are:

  • pattern: allows to define a regular expression which must be met

  • totalDigits: allows to define the maximal number of digits of a number

  • minLength: allows to define the minimal length of a value

  • maxLength: allows to define the maximal length of a value

  • minExclusive: allows to define a minimal value which is still invalid

  • maxExclusive: allows to define a maximal value which is already invalid

  • minInclusive: allows to define a minimal value which is already valid

  • maxInclusive: allows to define a maximal value which is still valid

Have fun defining your DataTypes with custom restrictions!


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with eclipse, emf, validation, eclipse, emf, validation


by Maximilian Koegel at August 26, 2014 08:16 AM

Mastering Eclipse Plug-in Development published

August 25, 2014 08:00 AM

This week saw the publication of my second book, Mastering Eclipse Plug-in Development. Hopefully this explains why this blog hasn't seen updates in a while; after some 360 pages and some 75k words, spare writing time has been a bit of a luxury.

The book is aimed at developers who are familiar with the basics of plug-in development, such as covered in my first book, Eclipse 4 Plug-in Development by Example: Beginner's Guide.

It covers subjects that are not normally found in Eclipse plug-in development books, such as how to consume and publish OSGi services, how to use native code inside bundles and how to take advantage of event-based publishing in Eclipse applications. There's also sections on how to provide user assistance (help) in Eclipse as well as some of the mechanisms for using P2 to manage repositories and to affect installations. The full table of contents is:

  • Chapter 1: Plugging in to JFace and the Common Navigator Framework
  • Chapter 2: Extending Eclipse with Custom Extension Points
  • Chapter 3: Using OSGi Services to dynamically wire applications
  • Chapter 4: Defining commands for the Gogo shell
  • Chapter 5: Native Code and Fragment Bundles
  • Chapter 6: Understanding Service Loaders and Class Loaders
  • Chapter 7: Designing Modular Applications
  • Chapter 8: Event Driven Applications with EventAdmin
  • Chapter 9: Deploying and Updating with P2
  • Chapter 10: User Assistance in Eclipse

As with the previous book, the code samples are all available as a GitHub project along with a series of tags associated with each chapter, and commit messages for each section in the book. When you clone this repository (or download the sample code from the Packt website) into Eclipse, you can use the built-in EGit support to switch between different chapters and compare the code with a before/after look at the changes.

I'd especially like to thank those in the Eclipse community who gave feedback on earlier drafts, especially Lars Vogel and Ian Bull; and of course Ann Ford, Carla Guillen, Jeff MAURY, Peter Rice and Dennis John who spent significant amounts of time and effort going through the code samples to verify that they work as expected. Any remaining errors are my own.

The book has been tested against both Eclipse Kepler and Eclipse Luna, and has been updated for OSGi R6.


August 25, 2014 08:00 AM

Committer and Contributor Hangout -- Project Code Development Changes When It Becomes an Eclipse ...

by Eclipse Foundation at August 22, 2014 02:56 PM

Richard Burcher from the Eclipse Foundation will talking about changes your project may have to make to keep developing when it comes to the Eclipse Foundation as a project. We'll discuss what they are:) Links: Talking notes with links embedded: https://wiki.eclipse.org/Committer_Contributor_Hangouts/august_22#Discussion_Script

by Eclipse Foundation at August 22, 2014 02:56 PM