Theia  –  May 2018 Update

by Sven Efftinge at May 24, 2018 12:38 PM

It has been a while since I last shared an update about Theia. A lot has happened since then.

Eclipse Theia

That’s right, Theia is moving to the Eclipse Foundation. The project has already been created and we are now in the process of getting approval from all the committers to relicense the code base. So far, Theia was licensed under Apache 2 but will now be relicensed to a dual license of EPL2 and a secondary GPL. The GPL bit is only interesting if you intend to use Theia in a GPL context, as EPL2 is not compatible. In most scenarios, especially for use in commercial products, the EPL2 license will apply.

Eclipse Che Uses Theia

Another great news for the community is that the Che team has started to open up the Che workspace server to run Theia instead of the current GWT-based Che IDE. The plan is to completely switch over to Theia eventually. For that, we need to catch up and add some features that are available in today’s Che but not yet in Theia.

RedHat

Together with Ericsson and TypeFox, RedHat has started to actively contribute to Theia. Besides several smaller issues, the team has started working on a visual debugger supporting the Debug Adapter Protocol, as well as a plug-in system that allows running plug-ins in a sandboxed environment similar to how VS Code does it.

The new more restricted plug-in system will be optional and developed in addition to the existing extension model of Theia as they address two different use cases: Plug-ins are meant to be used for smaller and simple features, while with extensions you can build anything you want including fully white-labeled products.

The plug-in API is designed with the current VS Code API in mind. The goal is to eventually fully support VS Code extensions through that.

Lots Of New Features

Finally, we have added many new features in the last four months. Without going into too much detail, here’s a list of the new & noteworthy things that have been done in 2018 so far:

The workbench shell has been rewritten and now supports drag & drop between all panels. We have added a bottom panel in addition to the side panels. For more details, read Miro’s blog post.

The Git integration now comes with commit staging, Git diff, and Git history. Git changes are signaled through annotations in the navigator as well as in editors.

The navigator supports drag & drop, quick search and auto reveal with regards to the active editor. You can even upload files by simply dragging them from your desktop onto the file navigator. Furthermore, the navigator supports annotations. For instance, error markers and git changes are now shown in the navigator.

The new search support allows searching for text occurrences in the workspace. Regular expression, glob patterns, and search & replace are supported, as well as some other options.

There is much more like the call hierarchy or the neat markdown support that are worth to check out.

Summary

The strong support from different vendors and the move to Eclipse Foundation are a promising basis for the future of Theia. After one year of development, we are truly happy (and proud) to see our baby starting to fly.

It is now ripe to be used as the foundation for new cloud and desktop IDE-like tools. If you want to learn how, you can either attend the tutorial on Theia during next month’s EclipseCon France, send me a mail, or simply chime in on GitHub or our Gitter channel.

P.S.: I was often asked whether I use Theia to develop Theia. I can finally say, yes. And I enjoy it. 🙂


by Sven Efftinge at May 24, 2018 12:38 PM

Jakarta EE Progress to Date

by Mike Milinkovich at May 24, 2018 11:07 AM

Last September Oracle announced, with the support of IBM and Red Hat, that Java EE was going to move to the Eclipse Foundation. Since then Fujitsu, Payara and Tomitribe have all joined the initiative with strategic-level commitments. The scale of this migration is huge, and if you’re interested in understanding the complexity of the undertaking, I highly recommend you read On Complexity and Good Intentions.

Roughly eight months later, let’s see how we are doing compared to the goals set out in Oracle’s original announcement.

  • Relicense Oracle-led Java EE technologies, and related GlassFish technologies, to the Foundation. This would include RIs, TCKs, and associated project documentation.

This has been the major accomplishment to date. The Eclipse Enterprise for Java (EE4J) top-level project has been created, and thirty-nine projects established. We don’t yet have all of the source code moved over, but you can follow the steady progress on the project status page. All of the projects are using the same license: Eclipse Public License 2.0 plus (Secondary) GNU General Public License, version 2 with the GNU Classpath Exception.

  • Demonstrate the ability to build a compatible implementation, using Foundation sources, that passes existing Java EE 8 TCKs.

This is what the project community is working towards next, and it is going to be a Very Big Deal. Keep in mind that to accomplish this goal, we are going to have to complete the creation of 39 projects, get them building on eclipse.org infrastructure, run the Java EE 8 CTS on those builds, and then get all of the projects together to ship on the same day. There is an enormous amount of work and learning to be done before this release becomes a reality.
 

  • Define a branding strategy for the platform within the Foundation, including a new name for Java EE to be determined. We intend to enable use of existing javax package names and component specification names for existing JSRs to provide continuity.

In the first quarter of 2018, the Eclipse Foundation worked with the community to establish a new name and a logo for the future of this technology. So Jakarta EE was born, and we’re very excited about the new name and the logo. Folks who have been around the Java world for a long time will recognize the name “Jakarta,” as the Apache Software Foundation’s had a long-lived incubator under that name. With their kind permission what was old is new again. We’re really excited about once again seeing Java innovation happening under the Jakarta banner.

jakartaee_logo

  • Define a process by which existing specifications can evolve, and new specifications can be included in the platform.

The first step in creating this process was to establish the Jakarta EE Working Group, which will be the governing body for this community moving forward. This was completed back in March, and the various committees are hard at work.

Discussions to create the new Jakarta EE Specification Process are underway, and early results are promising. This is going to be a very large job, but one which is essential to the future of this technology.

  • Recruit and enable developers and other community members, as well as vendors, to sponsor platform technologies, and bring the platform forward within the foundation. This would include potential incorporation of Eclipse MicroProfile technologies into the platform.

So far so good. Since the original announcement with Oracle, IBM and Red Hat back in September, here is the list of companies that have joined the initiative:

Strategic Members: Fujitsu, Payara, and Tomitribe

Participating Members: DocDuko, Genuitec, IncQueryLabs, Lightbend, London Java Community, Microsoft, Pivotal, RCPVision, SAP, UseOpen, Vaadin, and Webtide.

More importantly, we’ve seen a lot of developers from the Java EE community jump in and participate in the new projects as they’ve been set up. It has been great to welcome so many new people to the Eclipse community.

Eclipse MicroProfile has not joined the Jakarta EE initiative. But those conversations cannot even really start until the new specification process is available for that community to review.

  • Begin doing the above as soon as possible after completion of Java EE 8 to facilitate a rapid transition.

We’ve all been busy! It’s hard to say if the transition has been rapid enough, but everyone involved has been working hard and making progress. The process has not been and will not be perfect. With so many moving parts, people, and technologies, perfection is the enemy of good. But we’ve been very excited by the process we’re making. In particular, we have been excited by the passion and energy of the Java EE community as they have embraced the future with Jakarta EE.


by Mike Milinkovich at May 24, 2018 11:07 AM

Xtext 2.14 released!

by Xtext-Team (xtext@itemis.com) at May 23, 2018 02:18 PM

The Xtext team proudly announces the availability of the 2.14 release. While the previous releases have focused on performance and internal improvements this release comes with a bunch of new features that will ease your life and make your DSLs even more valuable. We encourage to update to this release. Xtext 2.14 will also be part of the upcoming Eclipse Photon release scheduled for June 27.

Update-handwritten


Of course 2.14 provides full compatibility with the recent Java 9 and 10 releases. Quite a lot of effort went into this support as Xtext is not the only part that needed adoption. We heavily rely on JDT, Gradle, Maven and Maven Tycho which all had to be compatible before.

The new version is fully compatible with your existing languages. To best employ the new features after the upgrade, we recommend to use the Xtext Project Wizard to create new projects with an up-to-date configuration and compare the setup with your existing language. For example, for Java 10 support, we had to upgrade the ASM library to version 6.1.1 and so do you.

The brand new Code Mining API from Eclipse Photon is supported by Xtext 2.14, too. To give it a try, you’ll need Eclipse Photon. You should use the latest Eclipse 4.8 Integration Build. The Domain-Model Example DSL contains a sample implementation for Code Minings and serves as a blueprint if you plan to implement your own. This is how it looks like in action:

Code-Mining-API-Eclipse-Photon-Xtext


As the Code Mining implementation in Eclipse is still under development, its inventor
Angelo Zerr is happy to get your feedback, too. Fame and fortune is to come if you report bugs to the Platform Text component in time so they can be fixed for the Photon release.

We also updated the testing infrastructure. The JUnit support has been extended so you can execute tests written with JUnit 5. The Xtext Project Wizard allows you now to select JUnit 5 for testing support and will produce a sample parser test and add the required dependencies.

Xtext-New-Project-Wizard


Creating project and file wizards for your DSL has always been a pain point. There already exists a non-well known generator fragment for an Eclipse New Project Wizard that produced a wizard which was not easily customizable. Now we have a new API and generator fragment that allows to produce
new project and new file wizards.

Xtext-New-Template-Wizard


The Xtext Grammar language now supports additional annotations for parser rules:

  • @Deprecated: This annotation marks a rule to be deprecated. Issue markers with are produced where a deprecated rule is used.
  • @Final: A rule marked as final cannot be overridden.
  • @Exported: With @Exported it can be customized on grammar level, which element types are exported to the index. The customization takes effect when at least one rule in a grammar is annotated with @Exported. By doing that you can easily manage visibility of elements and safe memory.

To enable your DSLs to run out of the box on as many editors as possible the support of the language server protocol was updated to 3.7 with VS code debug protocol 1.25.

Xtend 2.14 is released together with Xtext and of course also supports Java 9 and 10. In addition a few more enhancements are included. One nice thing to mention is the detection of unnecessary modifiers.

And of course we have worked on performance improvements and have closed bugs to improve overall behaviour while adding new features.

Xtext 2.14 is now available on the release update site.

If you have feedback please leave a comment. Suggestions for improvements, bug reports or code contributions are warmly welcome on GitHub. And if you are interested in news about Xtext in general follow us on Twitter. See you there!


by Xtext-Team (xtext@itemis.com) at May 23, 2018 02:18 PM

New File Wizard – easy to generate with Xtext 2.14

by Arne Deutsch (adeutsch@itemis.de) at May 23, 2018 09:26 AM

We have already shown on our blog how to generate a new project wizard with Xtext 2.14. Now it's also possible to create a comparable wizard, also based on templates, for creating DSL files in existing projects.

This wizard will appear with Eclipse Photon in June 2018, but here is a quick preview.

Generating the wizard

The wizard for new files is created in much the same way as the wizard for new projects. The following section must be inserted in the mwe2 file, which defines what is generated:

language = StandardLanguage {
   name = "org.xtext.example.mydsl.MyDsl"
   fileExtensions = "mydsl"
   serializer = {
       generateStub = false
   }
   fileWizard = {
       generate = true
   }
}


Invoking Run As -> MWE2 Workflow now generates the wizard and an example template.

A package wizard is generated in the UI project of the language. This contains a file MyDslFileTemplateProvider.xtend, where the actual name of the file depends on the name of the language. This file defines the contents of the wizard: other configurations are usually not necessary.

If only a single template is generated for a language, the wizard will have only one page. All the parameters of the template are specified on this page next to the directory and a name.

Xtext-214-new-file-wizard


If there are several templates, a combo box for selecting a template will be displayed on the first page. The parameters are then configured on the optional second page.

Defining your own templates

To adapt the "Hello World" example to your own language, or to add further templates, you need to adapt the TemplateProvider class, which implements IFileTemplateProvider. This returns a list of all available templates for the language via the getFileTemplates method. By default, the implementation looks like this:

class MyDslFileTemplateProvider implements IFileTemplateProvider {
   override getFileTemplates() {
       #[new HelloWorldFile]
   }
}


Adding another template therefore consists of adding a new instance to this list. The new template must be a subclass of AbstractFileTemplate. The easiest way to do this is by using the active annotatio
n  File Template. This annotation allows you to specify a name, an icon and some descriptive text for the template. These specify the presentation of the template in the list of available templates in the wizard.

So you would start something like this:

@FileTemplate(label="Test", icon="file_template.png",
   description="This creates a new hello world file.")
final class HelloWorldFile {
}


As a minimum you need to implement the generateFile (IFileGenerator) method here. The passed IFileGenerator contains a single method, generate (CharSequence, CharSequence), which you can call any number of times to create files when you close the wizard.

For example, a call to create a simple "Hello World"  file might look like this:

override generateFiles(IFileGenerator generator) {
generator.generate('''«folder»/«name».mydsl''', '''
Hello «helloName»!
    ''')
}


Additional calls to generate generate additional files. The parameters for the templates are defined with the same API as the project templates. The complete "Hello World" example looks like this:

class MyDslFileTemplateProvider implements IFileTemplateProvider {
override getFileTemplates() {
#[new HelloWorldFile]
}
}

@FileTemplate(label="Hello World", icon="file_template.png",
description="Create a hello world for MyDsl.")
final class HelloWorldFile {
val helloName = combo("Hello Name:",
#["Xtext", "World", "Foo", "Bar"],
"The name to say 'Hello' to")

override generateFiles(IFileGenerator generator) {
generator.generate('''«folder»/«name».mydsl''', '''
Hello «helloName»!
''')
}
}


Adding more templates works analogously to the project templates via an extension point, in this case via "org.eclipse.xtext.ui.fileTemplate”.

The release of Eclipse Photon is still a few days away, but here is the link to the nightly update site:

http://download.eclipse.org/modeling/tmf/xtext/updates/composite/latest/


by Arne Deutsch (adeutsch@itemis.de) at May 23, 2018 09:26 AM

Interview: Building streamed iOS and Android apps with one Java code

by Anonymous at May 22, 2018 02:14 PM

Learn more about Christopher Mindus and his talk on the iizi platform “Building streamed iOS and Android mobile and web apps with one Java code”.

..The iizi platform is a Java and app streaming platform that enables developers to build a cross-platform app for Android and iOS mobile devices and a browser-based web app, using a single code base. It includes tools for WYSIWYG UI design, real-time prototyping, debugging and testing as well as for setting up a production server.


by Anonymous at May 22, 2018 02:14 PM

Generating a new project wizard with Xtext 2.14

by Arne Deutsch (adeutsch@itemis.de) at May 22, 2018 02:07 PM

Anyone who implements DSLs with Eclipse Xtext benefits from the fact that the necessary infrastructure is generated automatically from the grammar. This gives you an environment in which everything is provided for developing your own DSL with minimum effort. A mere grammar and two buttons later, you can start Eclipse, full of anticipation. It first asks what kind of project you want to create. Xtext has not answered this question yet, so you have a choice.

Once you have created a project, many questions arise as to how your brand-new DSL can be used… What is the file name extension? Is it a text file? Is there a wizard? An example would help, but where can I find one? Who isn’t familiar with this sort of situation?

Previously, creating a wizard involved tedious and repetitive manual work. The requirements for wizards are not rocket science, nor is their implementation. What you want is a wizard that clearly shows how to create a special project for your DSL, ideally already containing examples. Can this be generated? Certainly it can: in Xtext 2.14 we can do exactly this.

Although this version will not be released until June 2018, together with Eclipse Photon, here is a preview.

Generating the wizard

Immediately after creating a new Xtext project, the project contains a mwe2 file that defines what is generated. This contains the following section of code:

language = StandardLanguage {
   name = "org.xtext.example.mydsl.MyDsl"
   fileExtensions = "mydsl"
   serializer = {
       generateStub = false
   }
   validator = {
       // composedCheck = "org.eclipse.xtext.validation.NamesAreUniqueValidator"
   }
}


To generate the wizard, this is expanded to include a
TemplateProjectWizard fragment for the wizard.

language = StandardLanguage {
   name = "org.xtext.example.mydsl.MyDsl"
   fileExtensions = "mydsl"
   serializer = {
       generateStub = false
   }
   validator = {
       // composedCheck = "org.eclipse.xtext.validation.NamesAreUniqueValidator"
   }
   projectWizard = {
       generate = true
   }
}


If the generation is triggered as normal, using a Run As -> MWE2 workflow, then not only are the editor, the auto-completion and so on generated, but also all the necessary extensions for the wizard.

A wizard package is generated in the UI project for the language, which mainly contains a file MyDslProjectTemplateProvider.xtend, where the name of the file depends on the name of the language. This file defines the content of the wizard: other configurations are usually not necessary.

If you open the runtime workspace directly after generation, it is possible to create new projects by opening the new wizard, for example via the main menu command File -> New -> Project. There will be a category MyDsl with a MyDsl project, again dependent on the name of the language. If the generated names are inappropriate you can of course change them using standard Eclipse means via the plugin.xml plug-in. If you want to incorporate the wizard in an existing language and are short of new entries in plugin.xml, here is a tip. Xtext normally generates content in the file plugin.xml, which can be edited manually. However, Xtext does not overwrite this file for further generations, but instead generates another file, plugin.xml_gen. You can then manually merge the contents of the plugin.xml_gen file into the existing plugin.xml.

OpenNewProjectWizard

As usual, you can define a project name and location on the first page.

NewProjectWizardSeite1


The second page offers you a selection from the defined templates. By default only a "Hello World" template is provided.

NewProjectWizardTemplateSelection


The following optional page offers options to configure the template. The "Hello World" application is only an example for parameterization; it does not make much sense to parameterize it.

NewProjectWizardTemplateConfiguration


If the wizard ends with ‘Finish’, a project is created, to which the Xtext-Nature has already been assigned that contains a "Hello World" of the generated DSL.

GeneratedProject-1

Defining your own templates

To adapt the "Hello World" example for your own language, or to add further templates, you must adapt the TemplateProvider, the class that implements IProjectTemplateProvider. This returns a list of all available templates for the language with the method getProjectTemplates. By default the implementation looks like this:

class MyDslProjectTemplateProvider implements IProjectTemplateProvider {
   override getProjectTemplates() {
       #[new HelloWorldProject]
   }
}


Adding another template therefore consists of adding a new instance to this list.

class MyDslProjectTemplateProvider implements IProjectTemplateProvider {
   override getProjectTemplates() {
       #[new HelloWorldProject, new TestProject]
   }
}


The new project must be a subclass of 
AbstractProjectTemplate. The easiest way to do this is to use the active annotation provided by ProjectTemplate. This annotation allows you to specify a name, an icon and a descriptive text for the template. These control the presentation of the template in the list of available templates provided by the wizard. 

@ProjectTemplate(label="Test", icon="project_template.png",
   description="<p><b>Test</b></p><p>This is a test project.</p>")
final class HelloWorldProject {
} 


As a minimum, you must implement the 
generateProjects (IProjectGenerator) method. The transferred IProjectGenerator contains a single method, generate (ProjectFactory) that you can call any number of times to create projects when exiting the Eclipse wizard. Xtext already provides various implementations of ProjectFactory to create Java, plug-in or feature projects: you can of course add your own implementations here.

A call to create a simple plug-in project with a file might therefore look like this:

 generator.generate(new PluginProjectFactory => [
   projectName = projectInfo.projectName
   location = projectInfo.locationPath
   projectNatures += #[JavaCore.NATURE_ID,
                       "org.eclipse.pde.PluginNature",
                       XtextProjectHelper.NATURE_ID]
   builderIds += JavaCore.BUILDER_ID
   folders += "src"
   addFile('''src/Model.mydsl''', '''
       Hello World!
   ''')
])


Additional calls to
generate create additional projects, while additional calls to addFile create additional files in the projects.

UI parameterization

To avoid merely static templates you can also use the API to define a simple UI. This will then be presented to users to allow them to provide parameters for the template.

By default the API allows you to define checkboxes, text fields and combo boxes. You can group these using group elements to provide an overview. The AbstractProjectTemplate class provides corresponding methods for defining the interface. A checkbox is generated by calling check. When assigned to an instance variable it can be used in the generateProjects method to determine a user-selected value. For example, you could generate a checkbox with the following code, which suppresses the generation of a project after the user’s selection:

@ProjectTemplate(label="Test", icon="project_template.png",
   description="<p><b>Test</b></p><p>This is a test project.</p>")
final class TestProject {
   val generateHello = check("Generate Hello", true)

   override generateProjects(IProjectGenerator generator) {
       if (generateHello.value) {
           generator.generate(new PluginProjectFactory => [
               projectName = projectInfo.projectName
               location = projectInfo.locationPath
               projectNatures += #[JavaCore.NATURE_ID,
                                   "org.eclipse.pde.PluginNature",
                                   XtextProjectHelper.NATURE_ID]
               builderIds += JavaCore.BUILDER_ID
               folders += "src"
               addFile('''src/Model.mydsl''', '''
                   Hello World!
               ''')
           ])
       }
   }
}


You can create text fields and combo boxes and use them analogously with the text and combo methods. If you need a more sophisticated wizard, you can overwrite the
updateVariables and validate methods, as in the "Hello World" example. These are called after every user interaction with the UI.

updateVariables can be used to manipulate widgets, for example to enable or disable specific items when the user changes a value in the wizard. validate can return a status value to allow reporting of user input errors in the wizard as error messages.

Contribute templates via the plug-in

Project templates are registered via an extension point. You do not get much benefit from this as a DSL developer: things only become interesting when your plug-in is extended by a third party, who can easily contribute further implementations of IProjectTemplateProvider.

It is necessary to reference the implementing class and specify the name of the grammar to which you want to contribute. This name is used to decide in which wizard the templates are displayed. The example generated by Xtext looks like this in plugin.xml.

<extension point="org.eclipse.xtext.ui.projectTemplate">
    <projectTemplateProvider
            class="org.xtext.example.mydsl.ui.wizard.MyDslProjectTemplateProvider"
            grammarName="org.xtext.example.mydsl.MyDsl">
    </projectTemplateProvider>
</extension>


For anyone who cannot wait for Eclipse Photon, check out the nightly updates at
http://download.eclipse.org/modeling/tmf/xtext/updates/composite/latest/. Just install the latest and hottest Xtext to get started.


by Arne Deutsch (adeutsch@itemis.de) at May 22, 2018 02:07 PM

Eclipse Collections 9.2 Released

by Donald Raab at May 21, 2018 05:59 AM

New features, more symmetric sympathy and community contributions.

Good symmetry at St. Paul’s
Eclipse Collections is a collections framework for Java. It has optimized List, Set and Map implementations with a rich and fluent API. The library provides additional data structures not found in the JDK like Bags, Multimaps and BiMaps. The framework also provides primitive versions of Lists, Sets, Bags, Stacks and Maps with a rich and fluent API. There is support for both Mutable and Immutable versions of all containers in the library.

There were nine developers who contributed to the Eclipse Collections 9.2.0 release. I want to thank everyone who made a contribution. If this was your first contribution to an open source project and/or Eclipse Collections, congratulations and welcome!

The release notes for Eclipse Collections 9.2.0 are here:

https://github.com/eclipse/eclipse-collections/releases/tag/9.2.0

Features, Features, Features!

We all love new features in a framework, especially one we use on a daily basis. Since we started compiling with Java 8 in Eclipse Collections 8.0, we have been enjoying new flexibility for adding new APIs in minor releases by using default methods. Here are some of the new API additions that were added in Eclipse Collections 9.2.

Welcome: flatCollectWith

The first story of symmetry improvements arrives in form of flatCollectWith on RichIterable. We have had flatCollect since version 1.0 of the framework. We have also had collect and collectWith. Now we have improved symmetry having both flatCollect and flatCollectWith. Here’s an example of code using flatCollectWith.

@Test
public void flatCollectWith()
{
MutableList<Integer> list =
Lists.mutable.with(5, 4, 3, 2, 1);
MutableList<Integer> result =
list.flatCollectWith(Interval::fromTo, 1);

MutableList<Integer> expected = mList(
5, 4, 3, 2, 1,
4, 3, 2, 1,
3, 2, 1,
2, 1,
1);
Assert.assertEquals(expected, result);
}

Welcome: toSortedMapBy

Our second story of symmetry arrives in the form of toSortedMapBy on RichIterable. We have had toSortedBagBy since 6.0. We have had to toSortedListBy and toSortedSetBy since 1.0.

@Test
public void toSortedMapBy()
{
MutableList<Integer> list =
Lists.mutable.with(4, 3, 2, 1);
MutableSortedMap<Integer, Integer> map =
list.toSortedMapBy(i -> i % 2, k -> k, v -> v);
Assert.assertEquals(
SortedMaps.mutable.with(
Comparators.byFunction(i -> i % 2),
4, 2, 3, 1),
map);
}

Welcome: Bag.selectDuplicates

We’ve had selectByOccurrences on Bag since 3.0. Now we have a short-cut for selecting all occurrences greater than one.

@Test
public void selectDuplicates()
{
MutableBag<Integer> bag =
Bags.mutable.with(1, 2, 2, 3, 3, 3);
MutableBag<Integer> duplicates =
bag.selectDuplicates();

Assert.assertEquals(
Bags.mutable.with(2, 2, 3, 3, 3),
duplicates);
}

Welcome: Bag.selectUnique

The symmetric method to selectDuplicates is selectUnique. Unlike selectDuplicates which returns a Bag, selectUnique returns a Set.

@Test
public void selectUnique()
{
MutableBag<Integer> bag =
Bags.mutable.with(1, 2, 2, 3, 3, 3);
MutableSet<Integer> unique =
bag.selectUnique();

Assert.assertEquals(
Sets.mutable.with(1),
unique);
}

Welcome: chunk (for primitive collections)

The symmetry is strong in this one. We have had chunk for object collections since version 1.0.

@Test
public void chunk()
{
IntList list = IntInterval.oneTo(10);
RichIterable<IntIterable> chunks = list.chunk(2);

Verify.assertSize(5, chunks);
String string = chunks.makeString("/");
Assert.assertEquals(
"[1, 2]/[3, 4]/[5, 6]/[7, 8]/[9, 10]",
string);
}

Welcome: newEmpty (for primitive collections)

We’ve had newEmpty for our object collections since 1.0. The method newEmpty gives you an empty version of the same collection type. Now we have the same method for primitive collections.

@Test
public void newEmpty()
{
MutableIntList empty1 = IntLists.mutable.empty();
MutableIntList empty2 = empty1.newEmpty();

Assert.assertEquals(empty1, empty2);
Assert.assertNotSame(empty1, empty2);
}

Welcome: OrderedMapAdapter

This is missing symmetry of a sort. We have had adapters for List, Set, SortedSet, Collection, Map since 1.0. While there is no OrderedMap interface in Java, there is an OrderedMap implementation, which is called LinkedHashMap. You could always adapt a LinkedHashMap as a MutableMap. Now you can adapt it and get back an OrderedMap or a MutableOrderedMap. Of course, the next thing we will eventually want on RichIterable is toOrderedMap.

@Test
public void orderedMapAdapter()
{

MutableList<Integer> keys = Lists.mutable.with(3, 2, 1);
MutableOrderedMap<Object, Object> orderedMap =
OrderedMaps.adapt(
keys.injectInto(
new LinkedHashMap<>(),
(map, each) -> {
map.put(each, each);
return map;
}));

LinkedHashMap<Object, Object> expected = new LinkedHashMap<>();
expected.put(3, 3);
expected.put(2, 2);
expected.put(1, 1);

Assert.assertEquals(expected, orderedMap);
Assert.assertEquals(keys, orderedMap.keysView().toList());
Assert.assertEquals(Interval.fromTo(3, 1), orderedMap.toList());
}

Update: Here’s an example using forEachWithIndex to populate the orderedMap.

@Test
public void orderedMapAdapter()
{
MutableOrderedMap<Integer, Integer> orderedMap =
OrderedMaps.adapt(new LinkedHashMap<>());

MutableList<Integer> keys = Lists.mutable.with(3, 2, 1);
keys.forEachWithIndex(orderedMap::put);

Map<Object, Object> expected = new LinkedHashMap<>();
expected.put(3, 0);
expected.put(2, 1);
expected.put(1, 2);

Assert.assertEquals(expected, orderedMap);
Assert.assertEquals(keys, orderedMap.keysView().toList());
Assert.assertEquals(Interval.zeroTo(2), orderedMap.toList());
}

Welcome: toStringOfItemToCount (for primitive bags)

We’ve had this method available on object Bags since version 3.0. Now toStringOfItemToCount is available for all primitive Bag implementations.

@Test
public void toStringOfItemToCount()
{
MutableIntBag bag = IntBags.mutable.with(1, 2, 2, 3, 3, 3);
String string = bag.toStringOfItemToCount();

Assert.assertEquals("{1=1, 2=2, 3=3}", string);
}

Welcome: Two new Collectors on Collectors2

We now have aggregateBy and countByEach on Collectors2. The method aggregateBy gives us symmetry on Collectors2 with the same method on RichIterable. The method countByEach on the other hand, currently has no equivalent implementation in the RichIterable API. This method is experimental in nature, and if it proves useful enough, we may add it as a feature to RichIterable in a future release.

@Test
public void countByEach()
{
MutableBag<Integer> bag = Arrays.asList(5, 4, 3, 2, 1)
.stream()
.collect(Collectors2.countByEach(Interval::oneTo));

MutableBag<Integer> expected = Bags.mutable.empty();
expected.addOccurrences(5, 1);
expected.addOccurrences(4, 2);
expected.addOccurrences(3, 3);
expected.addOccurrences(2, 4);
expected.addOccurrences(1, 5);

Assert.assertEquals(expected, bag);
}

And there is more…

Have a look at some of the other features and improvements listed in the release notes. We look forward to seeing more contributors to Eclipse Collections in the future.

Have fun using Eclipse Collections 9.2 and all of the new features in your Java projects!

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.


Eclipse Collections 9.2 Released was originally published in Oracle Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.


by Donald Raab at May 21, 2018 05:59 AM

Flamingo?!?

by tevirselrahc at May 18, 2018 01:15 PM

I received an interesting email today. Someone asked why the logo contained a flamingo!

Well, that my image is that of an Ibis, not a flamingo!

An Ibis a bird that  is found in Egypt, where papyrus was used as paper (or even computers nowadays). That, and the Egyptian god Toth was often depicted as a man with the head of an ibis (I’ll let you make the link between that an me… 😉 )…

Well, I hope this clarifies that for everyone!


by tevirselrahc at May 18, 2018 01:15 PM

Code Mining Support in Xtext

by Karsten Thoms (thoms@itemis.de) at May 18, 2018 01:10 PM

One of the most notable new APIs in Eclipse Photon is called Code Mining. A code mining represents content (i.e. labels and icons) that are shown within the text editor, but are not part of the text itself. For example, within a method call statement a mining could display the name of parameters, or an icon above unit test methods could be shown that runs the test on clicking it.

Code-Mining-Preview


The following image illustrates such minings in Java code. The code minings are provided by the jdt-codemining Plug-in, which the API’s inventor Angelo Zerr is developing on GitHub. This will eventually be contributed to JDT when it is mature enough.

JDT-Code-Mining-PlugIn


Code Mining is a generic extension to text editors in Eclipse. The actual text to be displayed depends on the concrete language. It is up to the developers of the language tooling to implement the interface
org.eclipse.jface.text.codemining.ICodeMiningProvider and to register the provider with the org.eclipse.ui.workbench.texteditor.codeMiningProviders extension point.

Xtext’s integration of the Code Mining API

With version 2.14 the Xtext project offers an integration with the Code Mining API. The API is provided by the new plugin org.eclipse.xtext.ui.codemining. Xtext’s Domain-Model example has been extended to make use of this API and serves as a blue print for other languages.

First of all, the language’s generator workflow is extended to use the CodeMiningFragment:

import org.eclipse.xtext.xtext.generator.ui.codemining.CodeMiningFragment
...
Workflow {
  ...
  language = StandardLanguage {
    ...
    fragment = CodeMiningFragment {
      generateStub = true
      generateXtendStub = false
    }
  }
}

When the generator is executed it will create a <DSL>CodeMiningProvider stub class in the UI project and register it to the plugin.xml. The provider extends from AbstractXtextCodeMiningProvider, which implements the general contract of an ICodeMiningProvider.

The Code Mining feature distinguishes between minings that are shown above a mined text line (line header minings) and minings shown within a line (line content minings – like the Java example above). AbstractXtextCodeMiningProvider offers some convenience methods createNewLineHeaderCodeMining() and createNewLineContentCodeMining() to create appropriate instances of ICodeMining.

The developer’s task is to implement the createCodeMinings() method:

Code-Mining-Method


In this method basically the resource is analysed to identify text to be displayed for some elements. Then the location for that text in the document has to be computed. Usually this affects accessing the document or the
node model using NodeModelUtils.

In the Domain-Model Example return types of operations are optional. When not declared, the return type is inferred. Therefore code minings could be created that display the inferred return type when not specified.

Domain-Model-Example-Code-Mining


The example’s
DomainmodelCodeMiningProvider class implements the createCodeMinings() method as follows: First, all Operation instances in the resource are collected. For each instance that doesn't have an explicit type set, the inferred return type’s name is computed. The type should be displayed after the closing parenthesis. The parenthesis’ Keyword is looked up in the grammar and stored in rightParenthesisKeyword_4. From the node model the node representing the parenthesis is searched to find the document offset where the text is to be displayed. Finally, the acceptor is called with a line content mining created from offset position and the inferred type name.

Code-Mining-Override

A look behind the scenes

Code Mining is an extension to JFace’s SourceViewer. The new interface ISourceViewerExtension5 defines the contract for code mining support in source viewers.

Xtext uses this extension in the XtextCodeMiningReconcileStrategy and calls the extension methods (mainly updateCodeMinings()) when the text in the editor is reconciled. Xtext’s main IReconcilingStratetgy implementation XtextDocumentReconcileStrategy was already aggregating two custom reconciling strategies, but not well prepared to add a third. It was refactored to aggregrate multiple now.

The XtextCodeMiningReconcileStrategy will only be added when code mining support is provided by a DSL. Thus there will be no overhead for any existing DSL until they implement code mining. Users will currently experience a small delay on the text update, since minings are computed and displayed asynchronously.

A note on backward compatility

The Xtext framework is backward compatible to older versions of the Eclipse Platform. With Xtext 2.14, the project still targets Eclipse Luna (4.4) as lowest supported platform to run on and is built and tested against it.

Since Code Mining is a new feature that's only provided on Eclipse Photon (4.8) and later, this raised some challenges on compatibility:

  • Xtext must be buildable with Eclipse Luna as Target Platform
  • DSLs developed on a 4.8+ Platform with Code Mining must be deployable on Eclipse Oxygen and earlier
  • The DSL’s editor must run on Eclipse Oxygen and earlier without breakage, just the minings are not displayed

We'll highlight these challenges and how they were solved in Xtext in a later blog post.

Conclusion

Code Mining is a new feature in Eclipse text editors that can provide valuable context information to developers within displayed text. Xtext 2.14 adopts the Code Mining API and offers an own API suited for Xtext DSL implementations. A usage reference is contained in the Domain-Model example. DSLs providing a Code Mining implementation are safely installable on older Eclipse versions.

Kudos to Angelo Zerr, who has contributed the API to Eclipse Photon and was always helpful to solve issues that we faced with the API and its implementation. On itemis side, a huge part of the effort was done by student René Purrio, who carefully analyzed the implementation and did intensive testing. With tight cooperation with our Xtext core team he was able to shape a nice implementation and contribute a valuable feature to Xtext.


by Karsten Thoms (thoms@itemis.de) at May 18, 2018 01:10 PM

How to Integrate Arduino with Eclipse Mita

by Robin Herrmann (robin.herrmann@itemis.de) at May 17, 2018 01:46 PM

Developing embedded devices, especially for IoT applications, can be a very complex task and requires a lot of knowledge. In the last blog post of my colleague Thomas Kutz we introduced Eclipse Mita, a new programming language designed for developing embedded IoT devices. It comes with a concise syntax based on event-driven paradigms and abstracts from the underlying hardware. 

Its two level architecture (application logic vs. platform specifics) allows to write easy-to-read application code without diving into hardware specifics. However, Eclipse Mita currently only supports the XDK platform as it was originally developed in the scope of Bosch’s XDK device.

In my master thesis I investigated how additional platforms can be integrated with Eclipse Mita and furthermore I implemented a prototype based on the popular Arduino Uno platform.

The prototype comes with support for time-depending events, buttons and LEDs. Additional features can be added later on, however, in this blog I want to show what’s possible with this extension.

Create Arduino platform definition

Eclipse Mita comes with a two level architecture, thus separating application logic from hardware specifics as much as possible. In order to integrate a new platform, one needs to contribute a platform definition as well as a bunch of platform specific code generators, the greenish parts of the picture below.


Eclipse-Mita-Arduino-Plattform-Definition-1

The platform definition specifies which sensors and connectivity channels are available. In general, it is divided into three parts:

  1. Sensor type definitions
  2. Connectivity type definitions
  3. Platform - collection of concrete sensors and connectivities

There are several options to specify the platform. This is a simple example to demonstrate how it could be done:

package platforms.arduino;

sensor Button {
    generator "com.yakindu.mita.platform.arduino.sensors.ButtonGenerator"
    modality is_pressed : bool
    event pressed
    event released
}

connectivity named-singleton LED {
    generator "com.yakindu.mita.platform.arduino.connectivity.LedGenerator"    
    signal light_up(color : LedColor) : bool
}

enum LedColor {
    Red,
    Yellow,
    Orange
}

alias button_one for Button
alias button_two for Button

platform Arduino {
    has button_one
    has button_two
    has LED
}

Let’s go through it step by step. First, every platform needs to be specified within a package. This can be later imported in any user created Mita application.

package platforms.arduino;

After this we can specify the sensor and connectivity types. In this case it is the button as a sensor. A sensor type defines several so-called modalities as well as events. Modalities define the data or state of a sensor; here is_pressed represents the pressed status of our button. However, instead of polling this status in our application code, we want to be informed on a status change via events. For this, we define two different events, the pressed and the released event, which can later on be used within the user programmed application code to define corresponding reactions. Lastly, we need to specify a code generator that implements the hardware specific parts.


sensor Button {
    generator "com.yakindu.mita.platform.arduino.sensors.ButtonGenerator"
    modality is_pressed : bool
    event pressed
    event released
}

To use LEDs, we define a connectivity called LED. It contains a signal with which the LED can be controlled. Supported colors are declared as an enumeration here.

connectivity named-singleton LED {
    generator "com.yakindu.mita.platform.arduino.connectivity.LedGenerator"    
    signal light_up(color : LedColor) : bool
}

enum LedColor {
    Red,
    Yellow,
    Orange
}

As our platform contains two different buttons, we need to instantiate them like this:

alias button_one for Button
alias button_two for Button

With this definition there are two buttons. Both of them can be used and have their own modalities and events (just like classes and objects, basically).

Last but not least, the platform itself must be declared. The platform defines which components are used, via the keyword has.

platform Arduino {
    has button_one
    has button_two
    has LED
}

With this specification the Arduino platform contains of two buttons, defined as a sensor and the LED defined as a connectivity. The buttons got two events, pressed and released and a modality is_pressed. They can be used within the application code. The LED can be controlled by changing the light_up signal.

Use Arduino platform definition in your own application

Once you have defined the platform, you can use it in your application code by importing the corresponding package. All components which are specified in the imported platform package can be used in your application code. This is demonstrated in the picture below:

Eclipse-Mita-Arduino-Plattform-Definition-2


The button
button_one that we have specified in the platform can be referred to in the application code, especially to its modalities and events, like the event pressed here.

After finishing your application, C code generators are used to generate C code, ready to be compiled and then written into Arduino’s flash memory. The code generators are split into two parts. The application generators are already predefined and don’t need to be adjusted anymore. The platform generators are implemented based on the used target platform, here Arduino. This is actually the heavy lifting part when contributing an own platform. However, since Eclipse Mita is open source you can have a look in already implemented platform code generators and start from there.

The following example demonstrates what a simple application could look like, for controlling a red LED with two buttons:

package main;
import platforms.arduino;

setup led : LED {
    var red = light_up(color = Red);
}

every button_one.pressed {
    led.red.write(true);
}

every button_two.pressed {
    led.red.write(false);
}

This simple example might not be technically sophisticated, but as the supported components expand, the complexity of the application grows. By adding connectivities and sensors like bluetooth, wifi, accelerometers, gyroscopes, writing custom C code becomes time and cost expensive. With generalized and common C code generators a reliable development can be achieved and your development process is extremely accelerated.

Do you think a certain platform should be supported by Eclipse Mita? Feel free to leave a comment or send a mail and let us know!

Don't miss any new article!  Subscribe to our blog


by Robin Herrmann (robin.herrmann@itemis.de) at May 17, 2018 01:46 PM

Eclipse Kura on the Intel UP² with CentOS

by Jens Reimann at May 16, 2018 11:01 AM

Intel UP² In the past I was testing modifications to Kura with a Raspberry Pi 3 and Fedora for ARM. But I got a nice little Intel UP² just recently, and so I decided to perform my next Kura tests, with the modifications to the Apache Camel runtime in Kura, on this nice board. Creating a new device profile for Kura using CentOS 7 and the Intel UP² looked like a good idea anyway.

At the time of writing, the PR for merging the device profile into Kura is still pending (PR #2093). But my hope is that this will be merged before Kura 4 comes out.

Build your own Kura image

But it is possible to try this out right now by using the preview branch (preview/intel_up2_1) on my forked repository: ctron/kura.

The following commands use the kura-build container. For more information about building Kura with this container see: https://github.com/ctron/kura-build and https://hub.docker.com/r/ctron/kura-build/.

So for the moment you will need to build this image yourself. But if you have Docker installed, then it only needs a few minutes to create your own build of Kura:

docker run -v /path/to/output:/output -ti ctron/kura-build -r ctron/kura -b preview/intel_up2_1 -- -Pintel-up2-centos-7

Where /path/to/output must be replaced with a local directory where the resulting output should be placed. If you are running Docker with SElinux enabled, then you might need to append :z to the volume:

docker run -v /path/to/output:/output:z -ti ctron/kura-build -r ctron/kura -b preview/intel_up2_1 -- -Pintel-up2-centos-7

As you might guess, it is also possible to build other branches and repositories of Kura in the same way. That docker image only ensures that all the necessary build dependencies are present when executing the build.

If you are running on Linux and do have all the dependencies installed locally. Then of course there is no need to run through Docker, you can simply call the build-kura script directly:

./build-kura preview/intel_up2_1 -r ctron/kura -b preview/intel_up2_1 -- -Pintel-up2-centos-7

Setting up CentOS 7

This is rather simple step, you simply need to download CentOS from https://www.centos.org/download/ (the Minimal ISO is just fine). Copy the ISO to a USB stick (https://wiki.centos.org/HowTos/InstallFromUSBkey). On a Linux-ish system this should work like (where /dev/sdX is the USB stick, all data on this stick will be lost!):

sudo dd if=CentOS-7-x86_64-Minimal-1804.iso of=/dev/sdX bs=8M status=progress oflag=direct

Rebooting your UP with the USB stick attached, this should reboot into the CentOS installer from where you can perform a standard installation.

After the installation is finished and you booted into CentOS, you will need to enable EPEL, as Kura requires some extra components (like wireless-tools and hostapd). You can do this by executing:

sudo yum install epel-release

You might also want to install a more recent kernel into CentOS. All the core things works with the default CentOS kernel. However some things like support for the GPIO support is still missing in the default CentOS kernel. But the mainline kernel from ELRepo can easily be installed:

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install kernel-ml

For more information check e.g.: https://www.howtoforge.com/tutorial/how-to-upgrade-kernel-in-centos-7-server/

Installing Kura on the Intel UP²

Copy the RPM you just created from the build process over to the UP, e.g. by:

scp kura-build-output/2018XXXX-YYYY/kura-intel-up2-centos-7*.rpm user@my-up:

And then on the device run:

yum install kura-*.rpm

This will install the Kura package as well as any required dependencies. After the installation has completed, reboot the machine and navigate your web browser to “http://my-up”, using the credentials “admin” / “admin”.

More information

The post Eclipse Kura on the Intel UP² with CentOS appeared first on ctron's blog.


by Jens Reimann at May 16, 2018 11:01 AM

Developer Advocate Wars / Arms Race

by Chris Aniszczyk at May 15, 2018 02:59 PM

While I’m not a huge fan of an arms race (or trade wars) especially given the current political situation in the world these days, I am a HUGE FAN of the mantra of “developers are the new kingmakers” coined by the fine folks at Redmonk. For those of you who haven’t noticed, there’s been a developer advocate hiring arms race by the major hyperscale cloud providers. I’ve previously written how CNCF is unique amongst open source foundations by having involvement from all the major cloud providers so I have an interesting vantage point in seeing a trend amongst them in ramping up developer advocacy hiring over the last couple of years. Furthermore, this hiring blitz is even more evident for me given the last couple of weeks have been conference crazy in the cloud native space with CloudNativeCon/KubeCon, MSBuild, Google IO and Red Hat Summit happening.

So what is happening with developer advocacy and the hyperscale cloud providers?

Note: If you aren’t familiar with the term developer advocate, I highly recommend this presentation by Patrick Chanzenon and blog from Ashley McNamara as an introduction to the profession.

Google

Google historically has been one of the early proponents of developer advocacy/relations and has invested in it since 2006 (see this excellent presentation for a historical perspective). A cursory search on LinkedIn shows a few hundred developer advocates employed at Google covering a variety of technologies from browsers to cloud. They also recently hired some heavy hitters like Sam Ramji and even Adam Seligman of Salesforce fame to help further build out their developer relations organization which was a smart move:

Anyways, I consider Google a leader in developer relations and with folks like Kelsey Hightower on staff, they are ahead of the curve.

I expect them to continue hiring like crazy to onboard more people onto their cloud offerings given their position in the market.

Microsoft

I used to work with Jeff Sandquist at Twitter and was delighted to hear he went back to Microsoft to build a developer advocacy focused organization. MS isn’t new at this game as some of us who are old enough and did MFC programming back in the day may remember Microsoft and their Channel9 advocacy program. Microsoft has been investing heavily in developer relations by making key hires (e.g., Ashley McNamara, Bridget Kromhout) and have rebooted their investment in open source to become one of the largest open source contributors in the industry. I’m not the first person to notice this trend by far, my friends at RedMonk noticed last year also. Searching the Microsoft job site, I see them hiring a handful of developer advocates mostly focused on cloud but they already have a large established roster of folks. It’s hard to get an exact count through the inexact science of flipping through LinkedIn search results, but I’d peg it 50-100 people currently employed doing developer relations.

Amazon (AWS)

In late 2016, Amazon started to expand their open source credibility by hiring folks like Adrian Cockroft, Zaheda Borat and Arun Gupta.

Using ancedata from my own experience being at events the last few years, Amazon has been aggressively speaking at conferences popular in the open source community. They have started to open source more examples and work with the community to improve them (e.g., https://github.com/aws-samples/aws-workshop-for-kubernetes)

It’s hard to get an exact number of people employed doing developer relations at AWS but going through the inexact science of LinkedIn search results, it looks to be in the 25-50 range which seems lower than I expected, but it’s hard as developer advocate is a fluid title (some people call themselves evangelists). In terms of hiring, searching the AWS jobs site I came across a couple of handful of developer advocate focused jobs so they seem to be aggressively hiring in this space. Also on a related note, I’m forever a fan of AWS for their execution and open discussion about hiring older engineers.

IBM

IBM traditionally has a strong position with their interactions with the open source community and even built a formal open source program within the company (I was also a fan of their DeveloperWorks initiative and even wrote technical articles for them in the past). They have also showed how making early bets on open source initiatives like Linux and Eclipse can reshape markets. In terms of developer advocacy, it seems about a year ago hired Jonas Jacobi to focus on developer relations from what I’ve been able to ascertain. They recently hosted an open source developer event in San Francisco called IBM Index which signals a desire to build developer communities outside the traditional IBM enterprise events like Think.

From a cursory LinkedIn search, IBM has 100+ developer advocates working on things from AI to Cloud. In terms of hiring, I’ve only found a handful of job descriptions currently open that are focused on developer advocacy. However, there were many job descriptions that were labeled software engineering that seemed to heavily focus on developer advocacy, for example, the folks that work on something called the IBM Cloud Garage seem to be a developer relations style job.

Oracle

Oracle has a burgeoning cloud business and according to some news sources, Oracle is actively trying to hire a new executive to run developer relations. A cursory job search shows that Oracle is ramping up their hiring, I see dozens of developer advocate positions open along with some more senior director level positions. I continue to expect Oracle to invest heavily in developer relations as this is an area they aren’t known for but has become table stakes in the public cloud business in my opinion.

Alibaba (and BAT+)

Alibaba and their cloud business is growing fast worldwide even though we don’t hear much about them in North America. In my opinion, they are making smart moves in Southeast Asia, India and other markets but that’s for another article to discuss. In my quest to learn about developer advocacy at Alibaba and even the other BAT companies, it was hard pressed to find any folks individually working on this. It’s clear to me that Alibaba has developer relations folks as if you go to their Alibaba Developers site there is some great content there but it’s been difficult to find current folks employed in devrel there and what they are hiring for. I’ll chalk this up to my inability to understand how job searching works in China and maybe one of my readers can shed some light on this. My hunch is that Alibaba will aggressively start hiring developer relations people worldwide if they didn’t start already, it will be fun to watch.

Conclusion

So what did I learn while I wrote this article? Well first off, getting hard numbers of how many job openings out there is a terrible science, sites like LinkedIn, Glassdoor and Indeed make it very difficult to extract data from their platforms to analyze. Second, developer relations is a nascent field and there’s no standard job description or career ladder. In many companies you have titles that range from “developer advocate” to “developer evangelist” to even “software engineer” that have primary responsibilities as developer relations. There have even been boutique communities popup to support people in the role of developer relations, see the Evangelist Collective slack as an example. Also the hiring of developer advocates isn’t just for large cloud providers or companies… you see some of the smart modern startups like Hashicorp, Turbine Labs and others hiring folks exclusively to make it easier to onboard developers to their tooling.

Finally, my prediction is that we will see cutthroat competition amongst the hyperscale cloud providers in hiring developer relations talent, especially out of the incumbents. The rest of the industry will learn from this experience that having a strong developer relations team is table stakes for any developer focused business. I’d love to write more on this topic but I’m short on time and I’m sure my friends at Redmonk can do a better job on this topic than me 🙂


by Chris Aniszczyk at May 15, 2018 02:59 PM

JBoss Tools 4.6.0.AM1 for Eclipse Photon.0.M6

by jeffmaury at May 15, 2018 07:55 AM

Happy to announce 4.6.0.AM1 (Developer Milestone 1) build for Eclipse Photon.0.M6.

Downloads available at JBoss Tools 4.6.0 AM1.

What is New?

Full info is at this page. Some highlights are below.

General

Eclipse Photon

JBoss Tools is now targeting Eclipse Photon M6.

Forge Tools

Forge Runtime updated to 3.9.0.Final

The included Forge runtime is now 3.9.0.Final. Read the official announcement here.

Enjoy!

Jeff Maury


by jeffmaury at May 15, 2018 07:55 AM

Starting a new open-source project

May 14, 2018 10:00 PM

Working on open-source is a skill…​

Three month ago I started to use and to contribute swagger-codegen. It feelt natural to fix and to add the stuff I needed there.

Then I received an invitation from a group of people that had started a fork of the project. Without going into the details, I think that each member had its own reasons to work on this fork. We wrote a summary in the project Q&A.

Enable project specific settings
Image 1. OpenAPI Generator logo proposition by @jimschubert

The last days were really exiting, we have started the openapi-generator project officially. We have now a GitHub repository: OpenAPITools/openapi-generator The first feedback arrives. We have pushed our first SNAPSHOT artifacts on sonatype central repository. We are close to our first release…​

Running an open-source project

I realised during this experiment that participating in an open-source project and running it is really a skill. Some people have it, they are directly alined, they understand what they need to do. Other do not understand how it works.

I have learned it from talented people. All developers involved with projects hosted at the Eclipse Foundation and contributors of the Asciidoctor project have shown me the way. They were excellent teachers.

What is next for OpenAPI Generator?

Starting an open source project is not only about code. Communication and marketing are also important. I hope we will manage build a community of user around our project. This is the best way to find potential contributors.

About OpenAPI Generator:

If you wonder what the project is about, here my short definition:

An OpenAPI Specification (OAS) is a great way to describe API in a standardised, machine readable and programming language-agnostic manner. OpenAPI Generator is an engine to generate documentation, API clients and server stubs in different languages for a given OpenAPI Specification.


May 14, 2018 10:00 PM

New Proposed Charter for OS.bea Working Group

May 14, 2018 06:00 PM

New proposed charter for OS.bea Working Group is ready for review. Paticipate by adding feedback on the mailing-list.

May 14, 2018 06:00 PM

EclipseCon Europe 2018 Call for Papers

May 14, 2018 06:00 PM

Review the CFP, talk with your team and submit your talks today!

May 14, 2018 06:00 PM

Eclipse Mita – Bringing software development for the IoT to a higher level

by Thomas Kutz (kutz@itemis.de) at May 11, 2018 08:30 AM

Software development for embedded IoT systems is not an easy task. In most cases, you’ll have to write C or C++ code; both coming with a higher learning curve than modern programming languages like Go and Rust. And in most cases, you’ll have to write a fair amount of lines of code to make an LED blink, the Hello World application of embedded software development.
However, especially when you come from an application development point of view, the real difficulty lies in dealing with the hardware you are developing for. Browsing data sheets and manuals to understand how things are connected on your platform, and how communication works between your platform and peripheral devices can be very time consuming and frustrating. Also, you have to keep an eye on memory and energy consumption as both are usually highly restricted in embedded devices. This often results in hardware specifics being interweaved in your actual application logic. Porting the same application onto another hardware then often requires to rewrite large parts of your code.

Mita-Logo

Eclipse Mita is a new programming language for the IoT that aims to mitigate the aforementioned difficulties. It comes with a more concise syntax based on event-driven paradigms and clearly separates between application logic and platform capabilities. Eclipse Mita was initially developed by Bosch Connected Devices and Solutions with the help of itemis. It was first implemented for the XDK Workbench, the IDE for Bosch’s XDK device, where the language is currently called XDK Live. However, from the beginnings the goal was to create a language that is not bound to a specific hardware, but allows to integrate with multiple platforms. As the project is now open source and part of the vivid Eclipse ecosystem, more platforms, like Arduino or Raspberry Pi, are expected to be supported in the near future.

Mita-Code-Generator-angepasst

Eclipse Mita is built with the goal in mind to separate application logic from hardware specifics. Therefore, it comprises two layers of abstraction: an application logic layer where functionalities are defined in an event-driven reactive programming style, and a platform definition layer where the hardware capabilities, like sensors, actuators and connectivity channels, are described. Then, on application level, one selects a platform definition to enable all therein defined hardware capabilities and thus making them available in the language to define reactions on a certain event or to read-out specific sensor data.

The code written with Eclipse Mita directly transpiles into C code. This makes Eclipse Mita usable wherever C is the target language which is usually the case for embedded software. The framework comes with two sets of C code generators: application code generators and platform specific code generators. Application code generators know how to transform Mita language constructs like event handlers, for-each loops, or exceptions into valid C code. On the other hand, the platform specific code generators know how to access your hardware’s sensor data or which register values to write to make your LED blink.

The obvious advantage of such a strict separation of concerns in the Mita framework is the possibility to integrate multiple platforms. For this, one needs to supply a platform definition file together with the platform specific code generators. The application language can be used out of the box and all its future advancements do not affect the hardware specific parts. This makes it possible to create an IDE for embedded software development that can be used across different platforms and hardware manufacturers.


package main;

import platforms.xdk110;

setup led : LED {
    var red = light_up(color = Red);
}

every button_one.pressed {
    led.red.write(true);
}

every button_two.pressed {
    led.red.write(false);
}

Here you can see a simple application written in Eclipse Mita. In contrast to the generated C code it is quite self-explanatory. Also note that the import statement is the only hint for which platform the application is written.

In upcoming blog posts we will show how to port this example onto an Arduino Uno, and even how to use YAKINDU Statechart Tools in combination with Eclipse Mita. So if you don’t want to miss that, subscribe to our blog!

Don't miss any new article!  Subscribe to our blog


by Thomas Kutz (kutz@itemis.de) at May 11, 2018 08:30 AM

Eclipse Common Build Infrastructure: Upcoming Changes

May 10, 2018 02:00 PM

Eclipse CBI is undergoing important changes, including Kubernetes/ Docker via Red Hat OpenShift & CloudBees Jenkins Enterprise.

May 10, 2018 02:00 PM

Going Serverless

by Doug Schaefer at May 10, 2018 12:00 AM

Going Serverless

Well, after a couple of years running my cdtdoug.ca server on AWS and the couple of years before that on DigitalOcean, I finally got tired of managing my own server and have moved my blog over to Github Pages. I’m using the default Minima template to get me going, but reading through the Jekyll docs, it looks like I’ll have some fun tweaking my own setup the way I want it.

For the first 8 years of my blogging life, I had hosted it on Google’s Blogger. But being the foolhearty geek craving to learn new things, I got my own little server in the cloud and moved my blog there, first on Wordpress and then recently moved to the much lighter weight Ghost. I learned a lot and it was pretty fun but I think I got what I wanted out of it and it’s time to move on to the next thing.

The other reason for getting a server was to do some home IoT projects. I had visions of setting up my own MQTT broker there and a simple node.js web site to provide the UI. But the world has changed. I am now looking at serverless offerings that should allow me to do all this without having to manage a server and at a fraction of the cost of even the t2.nano. One device, a few thousand messages a month, a simple REST API and a tiny static web site. It’s almost free.

So that’s my next adventure. First, I’m hoping I’ve set up the Planet Eclipse feed to pick up the generated RSS XML file properly. Then I’m off to play with some new toys.


by Doug Schaefer at May 10, 2018 12:00 AM

ECF Photon supports OSGi Async Intent

by Scott Lewis (noreply@blogger.com) at May 09, 2018 09:27 PM

In a previous post, I indicated that ECF Photon will support OSGi R7.   What does this mean for  remote service developers?

Support osgi.async Remote Service Intent

The OSGi R7 Remote Services specification has been enhanced with new remote service intents.  Remote Service Intents allow remote service authors to specify requirements on the underlying distribution system.   The osgi.async intent allows the service interface to use return types like Java8's CompletableFuture or OSGi's Promise.   When a distribution provider supports this intent, the remote service proxy will automatically implement the asynchronous/non-blocking behavior for the service consumer.

For example, consider a service interface:
public interface Hello {
CompletableFuture<String> hello(String greetingMessage);
}
When an implementation of this service is registered and exported as a remote service:
@Component(property = { "service.exported.interfaces=*", "service.intents=osgi.async" })
public class HelloImpl implements Hello {
public CompletableFuture hello(String greetingMessage) {
CompletableFuture<String> future = new CompletableFuture<String>();
future.complete("Hi. This a response to the greeting: "+greetingMessage);
return future;
}
}
Then when a Hello servicee consumer discovers, imports and the remote service is injected by DS:
@Component(immediate=true)
public class HelloConsumer {

@Reference
private Hello helloService;

@Activate
void activate() throws Exception {
// Call helloService.hello remote service without blocking
helloService.hello("hi there").whenComplete((result,exception) -> {
if (exception != null)
exception.printStackTrace(exception);
else
System.out.println("hello service responds: " + result);
});
}
}
The injected helloService instance will automatically implement the asynchronous/non-blocking remote call via the distribution provider.   No need for the consumer to implement anything other than calling the 'hello' method and handling the response via implementing whenComplete.   The Java8 CompletionStage, Future, and OSGi's Promise are also supported return types.

This makes it very easy to define, implement, and efficiently use loosely-coupled asynchronous remote services.   It also makes remote service contracts transport independent, allowing the swapping of distribution providers or custom providers without changes to the service interface contract.

by Scott Lewis (noreply@blogger.com) at May 09, 2018 09:27 PM