Eclipse Xtext’s new umbrella repository

by Karsten Thoms (thoms@itemis.de) at December 02, 2016 07:58 AM

On November 18th the Eclipse Xtext project added a new source repository eclipse/xtext-umbrella. This article describes the reasons for this additional repository and what is developed in there. 

In the past Eclipse Xtext was developed in a single repository, first at eclipse.org and since 2015 at GitHub in the repository eclipse/xtext. After Eclipse Neon and Xtext 2.10 the code was splitted into several separate repositories:

While these repositories contain the majority of the code there is still the need for some code that is related to all sub projects and has to be placed in a central “umbrella” project: release engineering, development tools, documentation, website, etc. This code remained in the eclipse/xtext repository.

So why a new umbrella repository?

When developing on Xtext, committers and contributors should have a similar development environment and all relevant Xtext sources. The Xtext project therefore provides an Oomph setup which is automatically available in Oomph’s Eclipse product catalog. All sources also include the mentioned cross-cutting-concern projects for build, documentation, etc. Checking out the eclipse/xtext repository is easy with Oomph. However, the cloned and checked out repository takes 550MB and also cloning takes a bit. The pain of this large download could be lowered if the repository would be cloned shallow. Unfortunately Oomph is not able to configure the Git Clone Task for that and JGit – which is used in the background – isn’t either (see Bug#475615, Bug#507324).

This would be not a problem if developers could choose this repository optionally like any other sub project in Xtext’s setup:

Eclipse-Xtext-oomph-repository.png

But there is an important requirement for a permanent availability of the umbrella repository.

The Gradle Composite Build

Xtext’s project structure is now due to the repository split a multi-repository multi-project structure. During the development in the IDE it is important that sources from an upstream repository could be changed and seamlessly used by a project in a downstream repository. For example, if a developer debugs code in Xtend (repository eclipse/xtext-xtend) and changes a class in Xbase (repository eclipse/xtext-extras), the change has to be used immediately. This sounds natural, but with Gradle inter-project dependencies can only be resolved within one composite build and the composite is only defined per repository. In order to resolve now cross-repository dependencies, there must be a composite that aggregates the composites of each repository.

The Gradle composite has to be placed in an umbrella repository (xtext-umbrella/releng/gradle-composite). Placing that in the eclipse/xtext repository would require to clone this large repository always although just a very small bit of code is actually needed.

Updated Oomph setup for Xtext

Xtext’s Oomph setup has now been updated. Users that set up a development environment with the Eclipse Installer like described in the Contribution Guide will automatically benefit from the new setup. The setup will now additionally clone the eclipse/xtext-umbrella repository and import the projects from there for any combination of sub projects selected in the Oomph wizard.

During tests of the new setup it becomes apparent that users should pay special attention to the Variables page and therefore the Git clone location rule. The value should be

${workspace.location/.git/}${@id.remoteURI|gitRepository}

if the repositories should be checked out within the workspace. On another machine I recognized that the Git branch was another directory layer, but this would break the composite build right now. It is possible that we will make this even more flexible later.

Update-Oomph-for-XText.png

Conclusion and outlook

The Eclipse Xtext project has now a new repository eclipse/xtext-umbrella, which contains sub project independent sources. A new repository became necessary since a new Gradle composite build was required and must be always checked out. Cloning the old main repository takes too much space and time to be reasonable for these sources.

Contributors can now use the new project structure by setting up their environment with the updated Oomph setup.

The new Gradle composite build became mandatory to resolve cross-repository dependencies in the IDE. In a future blog post I will go into some details on this requirement and how and why we created the composite build.

More details can be found in the related discussions in the following issues and PRs at GitHub:

You want to learn more about the project? Check these blogs:


by Karsten Thoms (thoms@itemis.de) at December 02, 2016 07:58 AM

The Open Source Advent Calendar

by Tracy M at December 01, 2016 10:29 AM

oscalendar

It’s that time of year again. But I don’t really like chocolate. And there’s only so many times you can do a Lego advent calendar. However, I do really love open source software. So for a change, it’s time to spread some open source software magic.

The Open Source Advent calendar works like a normal advent calendar, but instead of the usual countdown, in this case each day has a specific ‘act of open source goodness’. Whether you are an existing open source committer, a contributor or even a lurker looking to get involved, the open source advent calendar will get you right into the spirit of things. It’s like the Kindness Calendar but for open source software.

We’ll be working as a team at Kichwa Coders to step through the calendar, focusing on the projects we love.  We’re using the hashtag #OpenSourceAdventCalendar to share our acts of open source. We invite you to join us, create an open source ripple effect and make a difference to open source projects everywhere this December!

Download the Open Source Advent Calendar here.



by Tracy M at December 01, 2016 10:29 AM

The Eclipse User Profile

by Antoine THOMAS at December 01, 2016 10:22 AM

Following a soft release in October 2016, including several features, the collection of user feedback, related testing and adding improvements, it is officially time to announce the launch of…

The Eclipse User Profile

Story

The aim of the Eclipse User Profile (previously known as the User Dashboard), is to provide user’s with an overview of their community user activity on eclipse.org websites and services (such as Eclipse Marketplace).

The User Profile includes:

  • A simple URL, easy to remember and share, https://eclipse.org/user/ttoine;
    An overview of a user’s activity, retrievable from their account, and also made shareable with a link;
    A way for community users to find other users, and to understand who they are;

Use Case:

  • A young developer is using a plugin in the Eclipse IDE, and submits a bug to ask for an improvement. A top contributor or project lead answers the bug. On Bugzilla, the only information you can see about a specific user is their email address. So how can the young engineer contextualize the value and merit of the answer he or she receives?
  • Instead of only being able to see a public email address, a link to the Eclipse User Profile will appear, helping the young developer understand who the other participants are, and why their input is of value.
  • Users can also share their profile URL in their email signature, on social networks, when applying for a job, as a footprint of their activity and software development work…

Roadmap

Every month we will add new features to the Eclipse User Profile. Below you will find a list of the currently available features, and the features scheduled on the roadmap for the next release.

Released :

  • User presentation, including short presentation, social networks and interests;
  • Eclipse status;
  • Upcoming events;
  • Developer tools, Committer tools;
  • Data management;
  • Applications management;

In Progress:

  • Hudson HIPP control;
  • Activity tab has Gerrit, Marketplace and Forum (more to come);
  • Statistics block has Gerrit, Marketplace and Forum (more to come);

December Release:

  • Adding pagination to the activity tab to improve user experience;
  • Adding an activity tab about Projects involvements;
  • Starting migration of the user preferences and information to the user profile;

If you want to submit a bug on Bugzilla, please open it under ‘Community’, and select the ‘accounts.eclipse.org’ component. You can set it to block bug 493458.

Coming Soon

Other features are planned on the roadmap, such as the  integration with Eclipse Bugzilla and Wiki, listing talks at events and articles on Eclipse Planet. Anything we deem potentially useful for Eclipse users that are active within the Eclipse ecosystem, but who are not necessarily code contributors.

We are also interested in displaying Github activity, as it affects Eclipse end users. Although it is outside of our infrastructure, it would be very interesting to display Github activity and user information. If you know Github’s API well, your help is welcome in order to assist us in planning the best way to display information like the number of commits a user has per year in the statistic block, and user’s recent activity (e.g: like for the forum, last activity in contributing repositories).

F.A.Q

Can I add my project to the Eclipse User Profile?

The User Profile is open to integration with Eclipse projects.

This can be done to:

  • Display information on the activity tab;
  • Store application data on the user profile;
  • Manage access rights with OpenID connect;
  • If you are interested, please, do not hesitate to contact us with your feedback and input.

How do we retrieve user data?

To fetch data from our API and to display it on the user profile, we are using a jQuery library. For some of the services we use their REST API. And for other services, we gather data before on api.eclipse.org. This architecture is very flexible, and allows the User Profile to in theory retrieve data from all of the eclipse.org sites. You can find our work on Github: https://github.com/EclipseFdn/jquery-eclipsefdn-api

Is the data public?

We only display information that is already publicly available on your user profile, coming from the Eclipse’s websites. We may display public information from Github in near future if we proceed with the integration.

How do I find a user?

This is a very good question, and we are working on this capability. The specification should be done before the end of December 2016, in order to start the development of this functionality at the beginning of next year. The general idea is to have a simple search for first-name/name, nickname, or email, with some filtering options. An advanced search form could be made possible, with more fields retrieved from public data, like location, organisation, social networks accounts, projects involvement.

Feedback is welcome

The feedback we have received from early adopters has been positive and instrumental in allowing us to improve the Eclipse User Profile. It is clear that Eclipse end users and contributors don’t have the same needs. That is why your feedback is important and needed to help us distinguish functionality.

If you have ideas, if you want to help, or if you want to share your experience, please:

Thank you!


by Antoine THOMAS at December 01, 2016 10:22 AM

TypeFox

by Sven Efftinge (noreply@blogger.com) at November 30, 2016 08:04 AM

As many of you already noticed, we had to find a company name without 'Xtext' in it. Longer story short, we finally decided for TypeFox (it still has an 'x', ey? ;-)).  We are still all about Xtext and Xtend, of course.

The website is online now and reveals some additional details about what we do. Also we are having a blog there, which will be updated with useful content around Xtext and Xtend and more general about language engineering, code generators and so on on a regular basis. If you want to get notified about the content, there is a monthly newsletter. It will contain information about the latest blog post, upcoming Xtext and Xtend releases and upcoming events. The sign-up form is on the blog page.

Also Jan joined this month as a co-founder and there will be five more friends (Xtext committers) joining TypeFox in the coming weeks.

Finally I wanted to say thank you, for all the good wishes and the trust of our partners who already do business with us. It starts all very well and I am very thankful for that.

How do you like our logo?






by Sven Efftinge (noreply@blogger.com) at November 30, 2016 08:04 AM

YAKINDU Statechart Tools 2.9 – New and noteworthy

by Andreas Mülder (andreas.muelder@itemis.de) at November 29, 2016 02:56 PM

The YAKINDU team is happy to announce the new YAKINDU Statechart Tools 2.9.0 release! Only 6 weeks after our last release we are proud to present you the new version with some long-expected features and several bug fixes and improvements.

The product bundle of SCT is shipped with Eclipse Neon.1 as underlying platform. However, SCT does not require Neon to be installed. You can still update the SCT plugins with a Mars based IDE or the previous SCT bundle. You can download the current version of YAKINDU Statechart Tools from our download page where you also find the links to our update sites.

Headless Code Generator

The new release provides a headless code generator infrastructure that allows easy integration in continuous build environments. As the state machine code is fully derived from the statechart model, it is best practice to generate it on the fly during a CI-build instead of polluting your version control system with generated artifacts.

And here is the good news: The headless code generator can simply be called from the command line and thus can be integrated with different CI-Tools easily. No matter if you use Gradle, Maven or Make: all you need is a Java runtime on your build machine.

For more information about headless code generation read our documentation.

YAKINDU-statechart-tools-Release-2.9.0.png

Automated Error Reporting (AERI)

To further improve the quality of our code base, we added the well known AERI Feature (Automated Error Reporting) to the latest release. Thanks a lot to the ctrlflow team who provides a great software as a service infrastructure for collecting error reports!

YAKINDU-statechart-tools-Release-2.9.0-Bug-Report.png

In case you run into an error when using SCT, you will be asked to report this to the developers of YAKINDU Statechart Tools. This feature is disabled by default, so if you do not explicitly enable it nothing will be sent to us. Please see our privacy policy for more details. Every bug report helps! We are looking forward to your feedback.

Download Statechart Tools


by Andreas Mülder (andreas.muelder@itemis.de) at November 29, 2016 02:56 PM

Pushing the Limits of Xtext for C/C++ Linker Scripts

by Tracy M at November 28, 2016 02:54 PM

simplemem

Xtext is the popular Eclipse language development framework for domain specific languages. Its sweet spot is JVM-languages and it is excellent for languages where you can define the grammar yourself. But how well can Xtext cope with a non-JVM language that has undergone decades of evolution?

In our case, we want to see if we can take advantage of Xtext to create an editor for C/C++ linker scripts in CDT. Linker scripts are used to specify the memory sections, layouts and how code relates to these sections. Linker scripts consist of the ld command language, and this is what a simple typical script might look like:

MEMORY {
 RAM : ORIGIN = 0x0, LENGTH = 0x2000
 ROM : ORIGIN = 0x80000, LENGTH = 0x10000
}

SECTIONS {
 .text : { *(.text) *(.text.*) } > ROM
 .rodata : { *(.rodata) *(.rodata.*) } > ROM
 .data : { *(.data) *(.data.*) } > RAM
 .bss : { _bss = .; *(.bss) *(.bss.*) *(COMMON) _ebss = .; _end = .; } > RAM
}

Alternatives to Xtext

Besides using Xtext, its worth considering some of the other options there are for this task:

  • Roll-your-own – the existing C/C++ Editor in CDT does this, gives full control, best error-recovery and supports bidirectionality, recreating source from abstract syntax tree (AST), but it is a last resort as it would be an incredible amount of work that would take a long time to get right.
  • Antlr – write your own antlr grammar, but since antlr is already used in Xtext, may as well use Xtext and get benefits of Eclipse editor integration
  • Reuse linker’s bison grammar – would give perfect parsing, but it is a no-go because i) it’s GPL ii) it generates C code not Java & iii) requirements for editing are much more strenuous than for linking and this for example, would not support bidirectionality (i.e you can’t recreate the linker file from the AST).

Benefits of Xtext

The Xtext framework additionally provides these nice features we are interested in:

  • Parsing, lexing & AST generation
    • serialisation support is particularly important to support bidirectionality and preserve users comments, whitespace etc.
  • Rich Editor Features
    • syntax highlighting
    • content assist
    • validation & error markers
    • code folding & bracket matching
  • Integrated Outline editor
  • Ecore model generation which can be used for integration with UI frameworks such as EMF Forms, Sirius, etc.

Linker Script Parsing Challenges

When we talk about the ld command language being a non-JVM language, here are some specific challenges related to what that means.

  1. Crazy Identifiers! The following are valid identifiers in linker scripts:
    • .text
    • *
    • hello*.o
    • “spaces are ok, just quote the identifier”
    • this+is-another*crazy[example]
  2. Identifier or Number? Things that appear to be identifiers may actually be numbers:
    • a123 – identifier
    • a123x – number
    • 123y – identifier
    • 123h -number
  3. Identifier or Expression?

In the grammar 2+3, for example, depending on context, can either be an identifier or an expression:

SECTIONS {
 .out_name : {
  file*.o(.text.*)
  2+3(*)
  symbol = 2+3;
 }
}

The first 2+3 is a filename, so almost anything that can be a filename is allowed there. The second 2+3 is an expression to be assigned to symbol.

Resolutions

Here’s what we did to support the linker language as far as we could:

  1. Custom Xtext grammar – as extending the XType grammar does not make sense, the main job is to craft the grammar to understand all the linker script identifier and expressions specifics. This involves iterating as we add in more and more language feature support, here’s the work in progress.
  2. Limited Identifier Support – in some cases we opted to not support certain identifiers unless they are escaped (double-quoted). While linker scripts theoretically support such identifiers (e.g. 1234abcd) we have not found a single case yet of an identifier that would actually need escaping. If one did crop up, the user could adjust it to work with the editor (e.g. “1234abcd”).
  3. Context Based Lexing – knowing the difference between an identifier or expression would require context based lexing rules. However this will not work with the antlr lexer. We have the option to replace it with a custom or external lexer. This is an option that can be considered in the future if desirable.

Conclusion

Xtext is a great language development framework. While Xtext may not be able to support every theoretical case of the long-lived linker script command language, it can be used to provide a very high level of support for the common features. Support for context based lexing in the future would enable a higher level of language support. Xtext can be used to provide a rich language editor with syntax colouring, command completion, integrated outline view & more in a relatively short space of time. A powerful linker script editor is another great feature for C/C++ developers that use CDT, the reference C/C++ IDE in the industry.



by Tracy M at November 28, 2016 02:54 PM

Improving Min/Max performance in “e4-on-JavaFX” applications

by Tom Schindl at November 25, 2016 08:00 PM

When it comes to performance in JavaFX one of the biggest problems is that if you detach and reattach a big SceneGraph-Part you run:

  • CSS-Pass
  • Layout-Pass

So in general one should avoid those operations as much as possible but there are situations you can’t get something implemented without doing exactly this kind of thing.

In the current architecture of e(fx)clipse we need to use this reparenting in case of minimizing/maximizing certain areas of your e4-on-JavaFX application which might lead to a very poor user experience if you eg have a MPartStack with many complex substructures (like eg our code editor).

Today we took a closer look for one of our customers to find out if we – the e(fx)clipse – framework can do anything to fix that problem and after some experiments we managed to come up with a solution who allows us to reparent the content of an MPartStack in constant time:

In general I’d say that such optimization should not be required and JavaFX CSS and Layout performance HAS to be improved in general and JavaFX-Components have to get smarter in not running CSS-Passes on SG-Parts who are currently not showing.



by Tom Schindl at November 25, 2016 08:00 PM

New SashLayout container has landed in e(fx)clipse

by Tom Schindl at November 25, 2016 10:24 AM

I just pushed a new layout-container who has a similar feature set than the JavaFX built-in SplitPane but ensures that proportions are not corrupted if you shrink the container (just watch the video below to get an idea what I mean).

The layout algorithm is not something I came up myself. I just reworked the one from SWT to be used in JavaFX.



by Tom Schindl at November 25, 2016 10:24 AM

Registration Open | Eclipse Converge

November 25, 2016 07:30 AM

Discover the newest Eclipse Community event. Join us in San Jose alongside Devoxx US.

November 25, 2016 07:30 AM

Chicken and Pig

by Karsten Thoms (thoms@itemis.de) at November 24, 2016 12:00 PM

Question: Concerning a bacon-and-egg breakfast, what's the difference between the role of the chicken and that of the pig?
Answer: The chicken is involved, but the pig is committed!

So what does that have to do with my work on Xtext?

Xtext by now has a history reaching over a whole decade. Since its early beginnings I have been using the framework and developed several DSLs for customers with it. I have given trainings, consulting, and professional support. I wrote articles and blog posts and talked on conferences, demo camps and community events about Xtext and solutions created with it.

Often it was assumed that I was a committer on the Xtext project and people were very confused when I said that I'm not. I was “just” an expert user and active contributor and I was fine with that. I loved working for my customers and was highly dedicated to craft their solutions. Xtext development had a good momentum and I was happy with just applying this wonderful piece of technology.

From feeling involved...

Recently, my perception has changed a little. While Xtext 2.9 brought a big feature boost (e.g. new generator, Web & IDEA support, better Maven & Gradle support etc.), Xtext 2.10 somehow brought no new prominent features and fewer fixes than the community had expected. For the upcoming 2.11 release the main topics are support of the Language Server Protocol and splitting of Xtext’s single source repository into eight smaller ones.

While the main intention behind the repository split is further stabilization, Xtext and Xtend still have more than 1000 bug reports open. So there is plenty to do and I felt that I could help the project best by getting involved in this topic. Also, the bugs document how users actually use Xtext and where they have problems. I would like to focus on the users and their needs.

Therefore I started to contribute to the project more and more actively, hunted and re-tested bugs. Some were not reproducible, some of them I could already fix and others still exist, but at least they are now marked that they have been reproduced currently. For new issues I want to help users to get a more instant feedback and assure that the issues pile does not grow further. For the near future I want to make sure that stabilization does not lead to stagnation and that we do not keep adding technological debt, but will also actively fight against it.

...to being committed

I really feel committed to the project now and I am pleased that itemis grants the necessary time for me and my colleagues to keep improving this interesting piece of technology. Therefore I am happy that my colleagues Holger Schill finally proposed me to become committer on the project and that those who voted for me showed that they appreciate my dedication and work. 

Now I plan to intensify my work on Xtext even more and to use my close relation to users to improve their experience with the framework. I am confident that I can bring a different perspective into the project that is adding value to it.


by Karsten Thoms (thoms@itemis.de) at November 24, 2016 12:00 PM

Eclipse Newsletter | Eclipse Loves Science

November 24, 2016 11:08 AM

Let's science the sh*t out of this month's newsletter!

November 24, 2016 11:08 AM

Open IoT Challenge 3.0 | Extended Deadline

November 24, 2016 06:12 AM

The submission deadline for the Open IoT Challenge 3.0 has been extended to November 30 @ 11:59 PM PT.

November 24, 2016 06:12 AM

Production BRMS and Fuse Tooling for Neon

by pleacu at November 18, 2016 08:20 AM

Try our complete Eclipse-Neon capable, Devstudio 10.1.0 compatible integration tooling.

jbosstools jbdevstudio blog header

JBoss Tools Integration Stack 4.4.0.Final / JBoss Developer Studio Integration Stack 10.0.0.GA

All of the Integratioon Stack components have been verified to work with the same dependencies as JBoss Tools 4.4 and Developer Studio 10.

What’s new for this release?

Fuse Tooling/SwitchYard and BRMS Tooling are released for the Eclipse/Neon platform (Devstudio 10.1.0). The latest Fuse runtime and BRMS runtime are supported. Also - we’re happy to offer the latest Mars-based DataVirtualization bits as Early Access on our Neon platform.

Released Tooling Highlights

JBoss Fuse Development Highlights

Fuse Tooling Highlights

See the Fuse Tooling 9.0.0.Final Resolved Issues Section of the Integration Stack 10.0.0.GA release notes.

SwitchYard Highlights

See the SwitchYard 2.2.0.Final Resolved Issues Section of the Integration Stack 10.0.0.GA release notes.

JBoss Business Process and Rules Development

BPMN2 Modeler Highlights

See the BPMN2 1.3.2.Final Resolved Issues Section of the Integration Stack 10.0.0.GA release notes.

Drools/jBPM6 Highlights

Early Access/ Technical Preview Tooling Highlights

Data Virtualization Highlights

Teiid Designer Highlights

What’s an Integration Stack?

Red Hat JBoss Developer Studio Integration Stack is a set of Eclipse-based development tools. It further enhances the IDE functionality provided by JBoss Developer Studio, with plug-ins specifically for use when developing for other Red Hat JBoss products. It’s where the Fuse Tooling, DataVirt Tooling and BRMS tooling is aggregated. The following frameworks are supported:

JBoss Fuse Development

  • Fuse Tooling - JBoss Fuse Development provides tooling for Red Hat JBoss Fuse. It features the latest versions of the Fuse Data Transformation tooling, SwitchYard and access to the Fuse SAP Tool Suite.

  • SwitchYard - A lightweight service delivery framework providing full lifecycle support for developing, deploying, and managing service-oriented applications.

JBoss Business Process and Rules Development

JBoss Business Process and Rules Development plug-ins provide design, debug and testing tooling for developing business processes for Red Hat JBoss BRMS and Red Hat JBoss BPM Suite.

  • BPEL Designer - Orchestrating your business processes.

  • BPMN2 Modeler - A graphical modeling tool which allows creation and editing of Business Process Modeling Notation diagrams using graphiti.

  • Drools - A Business Logic integration Platform which provides a unified and integrated platform for Rules, Workflow and Event Processing including KIE.

  • jBPM6 - A flexible Business Process Management (BPM) suite.

JBoss Data Virtualization Development

JBoss Data Virtualization Development plug-ins provide a graphical interface to manage various aspects of Red Hat JBoss Data Virtualization instances, including the ability to design virtual databases and interact with associated governance repositories.

  • Teiid Designer - A visual tool that enables rapid, model-driven definition, integration, management and testing of data services without programming using the Teiid runtime framework.

JBoss Integration and SOA Development

JBoss Integration and SOA Development plug-ins provide tooling for developing, configuring and deploying BRMS, SwitchYard and Fuse applications to Red Hat JBoss Fuse and Fuse Fabric containers, Apache ServiceMix, and Apache Karaf instances.

  • All of the Business Process and Rules Development plugins, plus…​

  • Fuse Apache Camel Tooling - A graphical tool for integrating software components that works with Apache ServiceMix, Apache ActiveMQ, Apache Camel and the FuseSource distributions.

  • SwitchYard - A lightweight service delivery framework providing full lifecycle support for developing, deploying, and managing service-oriented applications.

The JBoss Tools website features tab

Don’t miss the Features tab for up to date information on your favorite Integration Stack components.

Installation

The easiest way to install the Integration Stack components is through the stand-alone installer.

For a complete set of Integration Stack installation instructions, see Integration Stack Installation Instructions

Give it a try!

Paul Leacu.


by pleacu at November 18, 2016 08:20 AM

Eclipse Che 5.0 Brings Docker Compose Support, Workspace Agents, and More

by Sergio De Simone at November 16, 2016 10:00 PM

At the first CheConf16, a virtual user conference dedicated to Eclipse Che, a containerized portable development workspace, Codenvy CEO and Che project leader Tyler Jewell announced Eclipse Che 5.0. Expected to be released before the end of the year, it will introduce support for Docker Compose, Workspace Agents, and more.

By Sergio De Simone

by Sergio De Simone at November 16, 2016 10:00 PM

Papyrus-RT v 0.8.0

by tevirselrahc at November 16, 2016 09:00 AM

Good news!

A new version of Me for Real Time is now available!

Papyrus-RT 0.8.0 (on Neon no less) is now available for download!

There are many ways for you to enjoy the goodness of this new release, and all can be accessed on the Papyrus-RT Download page.

Have the multiple installation option made your head spin?  Are you wondering which installation approach is best for you? Don’t worry, we have a page on our wiki that explains the various installation methods to help you make an informed choice!

Wondering what’s in the release? Just consult the 0.8.0 release notes!

As for what’s coming, you can see that in the next release’s definition!

Enjoy!


Filed under: Papyrus-RT, UML-RT, Uncategorized Tagged: modeling, New, release

by tevirselrahc at November 16, 2016 09:00 AM

Naming Maven repositories

by Zoltán Ujhelyi at November 15, 2016 10:14 PM

Motto:

Caches are bugs waiting to happen. Rob Pike

The last two days I was hunting an issue in the Maven/Tycho based build of VIATRA: some artifacts from Maven Central were not found anymore, seemingly without any related change. A more detailed analysis has shown that the issue is specific to the build server at the Eclipse Foundation: in all other cases the builds run successfully.

When looking at the debug output of the build (the -X switch for mvn is truly a killer feature…) it was interesting that the build did not try to download the dependency from Maven Central nor from the mirror set up for builds at the Hudson instance at eclipse. Given that the first twenty-two modules compiled (with dependencies to Maven Central) this made no sense.

After managing the sanity loss and calling for help (thanks Ábel and Balázs) we have managed to identify that the settings.xml used on Hudson caused the problem. After calling for more help (thanks for the quick help from webmaster) I have finally managed to find out the root cause of the issue: repository identifier clash caused by the maven central mirror and a dependency issue.

For performance and network utilization reasons a mirror for maven central was set up about a month ago using the following fragment:

<mirrors>
    <mirror>
      <id>repo.eclipse.org</id>
      <name>Eclipse Central Proxy</name>
      <url>https://repo.eclipse.org/content/repositories/maven_central/</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
</mirrors>

Our problematic bundle had a repository declaration as follows:

<repositories>
    <repository>
        <id>repo.eclipse.org</id>
        <url>https://repo.eclipse.org/content/groups/releases/</url>
    </repository>
</repositories>

What happened here is that we declared some repositories with the same identifier as the proxy repository declared by webmaster, and Maven got confused, and thought that everything from Central is reachable from our declared dependency repository. Changing the identifier to avoid the name clash solved this issue nicely.

Now only one question remains: why was this issue not found earlier. The answer is trivial: the plugins were available in the local repository, effectively hiding the unresolvable dependencies. A completely unrelated cleanup of the local repository however has brought forth this issue, causing much headache to find.


The main lesson we learned here: DO NOT reuse the same repository identifier for multiple repositories. It can cause very subtle, hard to debug issues in the long run. However, there are a few other aspects you have to keep in mind:

  • All repositories and plugin repositories defined in your parent project are also inherited, so their name should also be unique.
  • Identifier clash might not be a problem in case of deployment repositories, but have not tested this aspect yet.
  • A more specific lesson for Eclipse projects building on Foundation Servers: DO NOT use the identifier “repo.eclipse.org” for your repositories. Maybe it is worth checking whether the identifier is used (e.g. use following the github search link to check projects developed or mirrored to the Eclipse Github organization), and update accordingly. Update: the mirror repository id was updated to “eclipse.maven.central.mirror” that should not clash with manual repository names.

by Zoltán Ujhelyi at November 15, 2016 10:14 PM

Java 8 Features Supported by Spring 4

by support-swapna at November 15, 2016 07:17 PM

Spring Framework 4 supports Java 8 language and API features. In this article, we will focus on the new Java 8 features which are supported in Spring 4. The most important ones are lambda expressions, method references, JSR-310 Date and Time, and Repeatable annotations.Lambda ExpressionsSpring code base uses a lot of functional interfaces and with […]

The post Java 8 Features Supported by Spring 4 appeared first on Genuitec.


by support-swapna at November 15, 2016 07:17 PM

Running EMF Client Platform + EMFStore as RAP application on Tomcat

by Maximilian Koegel and Jonas Helming at November 15, 2016 10:48 AM

Building an application to view and edit data is really simple using the EMF Client Platform. This includes form-based editors based on EMF Forms. Add EMFStore to the mix and you get collaborative editing and versioning. All of this is merely a matter of defining an EMF model for your data.

If you want to run all this as a web application, you can use the Remote Application Framework (RAP). EMF Client Platform, EMF Forms, and EMFStore support running on RAP without modifications.

Recently Neil made another very useful contribution – a tutorial on how to deploy and run a RAP application based on EMF Client Platform, EMF Forms and EMFStore on an Apache Tomcat server.

Sounds interesting to you? Have a look at the brand new tutorial available here.

And again, thank you very much, Neil, for all your great contributions!

 

Foto
Guest Blog Post
Guest Author: Neil Mackenzie


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with ecp, emf, emf forms, EMFStore, rap, rcp, tomcat, ecp, emf, emf forms, EMFStore, rap, rcp, tomcat


by Maximilian Koegel and Jonas Helming at November 15, 2016 10:48 AM

EclipseConverge 2017 Submissions are open

November 15, 2016 09:45 AM

The call for papers for EclipseConverge 2017 is open. It is the first step toward what ought to be another great Eclipse event. For those who may not know, Eclipse Converge is a new event for the Eclipse community. It is a one-day summit dedicated exclusively to Eclipse technologies, with the goal of allowing our North American developer community to meet and share ideas. 

As you may know, I am leading the program committee this year as program chair. We worked hard to make the best call for papers we possibly could. We designed the tracks carefully so that anyone near or far from the core Eclipse community will feel welcome to submit a speaking proposal about all the inspiring, innovative and interesting stuff they are doing in or with Eclipse. By the way, you can see us on the PC page and contact us anytime via email.

This year, we will have four tracks:

  • Eclipse Platforms & Runtimes. Eclipse is an IDE and also a host for a lot of great open-source runtime technologies such as Equinox, RAP, RCP, and the Eclipse 4 Application Platform. New technologies from the vibrant Eclipse ecosystem as well as state-of-the-union talks go here.
  • Languages & Tools. There are countless plugins and tools based on Eclipse to support developers in their daily work. Tell us about the best ones built on Eclipse, how you have built them, and/or what technologies they 
  • Web & Cloud. If you are implementing Web / JEE applications or want to share your experience with modern web frameworks such as AngularJS, Vaadin, or JSON Forms, your talk goes here. This is also the track for talks about cloud development and operation tools at Eclipse such as Orion, Che, Flux, Dirigible, or other ways to move tooling to the cloud, such as browser-based UIs for developer tools and next-generation 
  • Other Cool Stuff. Not everything will fit easily into one of these tracks. If your talk is one that’s hard to categorize, submit it here!

The submission deadline is December 12, 2016, at 11:59 PM PST. There’s no time for procrastination! Go ahead and submit yours now.


November 15, 2016 09:45 AM

Eclipse LSP4J Is Here!

by Sven Efftinge at November 12, 2016 06:38 PM

This week the LSP4J repository finally got created and filled with the initial contributions. LSP4J is a Java binding of Microsoft’s Language Server Protocol (LSP) with a Java implementation of the extended JSON RPC v2.0 the LSP is based on. The project aims at simplifying implementation of a LanguageClient (an editor) or a LanguageServer (e.g. a modern compiler) in Java. Here is a short introduction of how to use it.

Implement Your Language Server (or Client)

The first thing you should do is to implement your language server. To do so just implement the interface org.eclipse.lsp4j.LanguageServer. If you are implementing a client (e.g. an editor) you would need to implement org.eclipse.lsp4j.LanguageClient instead.

Launch and Connect with the Other End

Now that you have an actual implementation you can connect it with a remote client. Let’s assume you have an Inputstream and an Outputstream, over which you want to communicate with a language client.

The utility class LSPLauncher does most of the wiring for you. Here is the code needed.

LanguageServer server = ... ;
Launcher<LanguageClient> launcher = LSPLauncher.createServerLauncher(
                                                        server,
                                                        inputstream, 
                                                        outputstream);

With this we have a Launcher object on which we can obtain the remote proxy (of type LanguageClient in this case). Usually a language server should also implement LanguageClientAware, which defines a single method connect(LanguageClient) over which you can pass the remote proxy to the language server.

if (server instanceof LanguageClientAware) {
   LanguageClient client = launcher.getRemoteProxy();
   ((LanguageClientAware)server).connect(client);
}

Now your language server is not only able to receive messages from the other side, but can send messages back as well.

The final thing you need to to do in order to start listening on the given input stream, is calling

launcher.startListening();

This will start the listening process in a new thread.

Underlying Concepts

As mentioned in the beginning LSP4J is based on JSON RPC. The implementation is completely independent of the LSP, so can be used for other protocols. Also we made sure that it is easy to extend the LSP with new messages. This is important to bridge the last non-standard 20% and to prototype possible extensions for the LSP. We are for instance currently experimenting with support for semantic coloring and will submit an enhancement request once we are happy with it.

Please refer to the documentation to learn more about the JSON RPC layer.


by Sven Efftinge at November 12, 2016 06:38 PM