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.
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:
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:
In the next step, you must define the constraints with an Annotation on the DataType:
In the properties of the Annotation, the source must be set to “http:///org/eclipse/emf/ecore/util/ExtendedMetaData”:
To define the constraints, a Details Entry must be added to the annotation:
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:
The complete DataType definition looks like this:
You can now use this definition as an attribute type of any EAttribute in the model:
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:
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!
Leave a Comment. Tagged with eclipse, emf, validation, eclipse, emf, validation
August 25, 2014
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 22, 2014
Committer and Contributor Hangout -- Project Code Development Changes When It Becomes an Eclipse ...
If you are a Fedora Eclipse user, then you're probably saddened since the release of Eclipse Luna (4.4) because you are still using Eclipse Kepler (4.3) on Fedora 20.
Well, be saddened no longer because Eclipse Luna is now available for Fedora 20 as a software collection!
A software collection is simply a set of RPMs whose contents are isolated from the rest of your system such that they do not modify, overwrite or otherwise conflict with anything in the main Fedora repositories. This allows you install multiple versions of a software stack side-by-side, without them interfering with one another. More can be read about this mechanism on the software collections website.
Then you can install the whole collection by doing:
$ sudo yum install eclipse-luna
This will install everything you need to run Eclipse Luna (including a bunch of useful plug-ins for Java and C/C++ development) on your Fedora 20 machine. After installation is complete, you may notice Eclipse Luna's shiny new icon appear next to the old one in GNOME.
Alternatively, if you ever need to launch Eclipse from a terminal, you can do so with the following command:
$ scl enable eclipse-luna eclipse
And that will launch the specific version of Eclipse from the Eclipse Luna software collection instead of the default Eclipse that comes with Fedora 20.
August 21, 2014
Eclipse Mars will make access to the structured selection of a StructuredViewer easier. So instead of:
ISelection selection = combo.getSelection();
IStructuredSelection sel = (IStructuredSelection) selection;
You can write
IStructuredSelection sel = combo.getStructuredSelection();
Not a big one, but one of the little annoying things. See the rest of the Eclipse papercut series
1. Display of EMF Model on a TableViewer
I have seen a lot of associates implement their own content and label provider when it comes to a table instead of extending and reusing the EMF Edit code. This is due to the reason that the generated EMF Edit Code doesnt support TableViewer out of the box. Therefore i did think its is definitely useful to document the steps involved in extending the Edit plugin to support TableViewer than rewriting the Content and Label Provider completly.
For Article on Display of EMF Model on Table Viewer : Click Here
For SourceCode for the Article on Display of EMF Model on TableViewer : Click Here
2.Populating the ContextMenu with NewChildDescriptors for creation of new Siblings and Children.
Many a times when we have to contribute Context Menu on existing Model elements to support creation of New Child or Sibling Objects, we miss on the idea of NewChildDescriptors provided by the EMF Edit Plugin out of the box for similar usecases. Therefore this tutorial helps in understanding NewChildDescriptors and their use.
For Article on Populating the ContextMenu with NewChildDescriptors : Click Here
Please like us on marketplace, if you like our contributions to the eclipse world.
Download our srcs from http://github.com/ancit or http://github.com/cmalai