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

Eclipse Luna for Fedora 20

by Mat Booth at August 22, 2014 12:00 PM

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.

The Eclipse Luna software collection lives in a separate yum repository, which must be configured by clicking on this link to install the release package.

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.

Luna Launcher

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.

Happy hacking!


by Mat Booth at August 22, 2014 12:00 PM

Open IoT hangout #9

by Eclipse Foundation at August 21, 2014 03:35 PM

After a short holiday break, join us to discuss what's new in the IoT space and learn more about Eclipse IoT Working Group member BitReactive!

by Eclipse Foundation at August 21, 2014 03:35 PM

Eclipse Papercut #15 – Simplified access to the structured selection of Viewer

by Lars Vogel at August 21, 2014 01:15 PM

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


by Lars Vogel at August 21, 2014 01:15 PM

CONSUMING an EMF MODEL in UR ECLIPSE UI - PART 5 & 6

by Its_Me_Malai (noreply@blogger.com) at August 21, 2014 01:10 PM

Its been a while I have updated my EMF Document to further enhance my series of Consuming an EMF Model in UR Eclipse UI. I have finally found the time to update the same with the following topics.

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








by Its_Me_Malai (noreply@blogger.com) at August 21, 2014 01:10 PM