RHAMT Eclipse Plugin 4.1.0.Final has been released!

by josteele at July 18, 2018 12:06 PM

Happy to announce version 4.1.0.Final of the Red Hat Application Migration Toolkit (RHAMT) is now available.

Getting Started

Downloads available through JBoss Central and from the update site.

RHAMT in a Nutshel

RHAMT is an application migration and assessment tool. The migrations supported include application platform upgrades, migrations to a cloud-native deployment environment, and also migrations from several commercial products to the Red Hat JBoss Enterprise Application Platform.

What is New?

Eclipse Photon

The tooling now targets Eclipse Photon.

Photon

Ignoring Patterns

Specify locations of files to exclude from analysis (using regular expressions).

Ignore Patterns

External Report

The generated report has been moved out of Eclipse and into the browser.

Report View

Improved Ruleset Schema

The XML ruleset schema has been relaxed providing flexible rule structures.

Schema

Custom Severities

Custom severities are now included in the Issue Explorer.

Custom Category

Stability

A good amount of time has been spent on ensuring the tooling functions consistently across Windows, OSX, and Linux.

You can find more detailed information here.

Our goal is to make the RHAMT tooling easy to use. We look forward to your feedback and comments!

Have fun!
John Steele
github/johnsteele


by josteele at July 18, 2018 12:06 PM

JBoss Tools and Red Hat Developer Studio for Eclipse Photon

by jeffmaury at July 17, 2018 03:43 PM

JBoss Tools 4.6.0 and Red Hat Developer Studio 12.0 for Eclipse Photon are here waiting for you. Check it out!

devstudio12

Installation

Red Hat Developer Studio comes with everything pre-bundled in its installer. Simply download it from our Red Hat Developer product page and run it like this:

java -jar devstudio-<installername>.jar

JBoss Tools or Bring-Your-Own-Eclipse (BYOE) Developer Studio require a bit more:

This release requires at least Eclipse 4.8 (Photon) but we recommend using the latest Eclipse 4.8 Photon JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under "JBoss Tools" or "Red Hat Developer Studio".

For JBoss Tools, you can also use our update site directly.

http://download.jboss.org/jbosstools/photon/stable/updates/

What is new?

Our main focus for this release was on adoption of Java10, improvements for container based development and bug fixing. Eclipse Photon itself has a lot of new cool stuff but let me highlight just a few updates in both Eclipse Photon and JBoss Tools plugins that I think are worth mentioning.

OpenShift 3

Enhanced Spring Boot support for server adapter

Spring Boot runtime was already supported by the OpenShift server adapter. However, it has one major limitation: files and resources were synchronized between the local workstation and the remote pod(s) only for the main project. If your Spring Boot application had dependencies that were present in the local workspace, any change to a file or resource of one of these dependencies was not handled. This is not true anymore.

Server tools

Wildfly 13 Server Adapter

A server adapter has been added to work with Wildfly 13. It adds support for Servlet 4.0.

Fuse Tooling

Camel Rest DSL from WSDL wizard

There is a new "Camel Rest DSL from WSDL" wizard. This wizard wraps the wsdl2rest tool now included with the Fuse 7 distribution, which takes a WSDL file for a SOAP-based (JAX-WS) web service and generates a combination of CXF-generated code and a Camel REST DSL route to make it accessible using REST operations.

To start, you need an existing Fuse Integration project in your workspace and access to the WSDL for the SOAP service. Then use File→New→Other…​ and select Red Hat Fuse→Camel Rest DSL from WSDL wizard.

On the first page of the wizard, select your WSDL and the Fuse Integration project in which to generate the Java code and Camel configuration.

SOAP to REST Wizard page 1

On the second page, you can customize the Java folder path for your generated classes, the folder for the generated Camel file, plus any customization for the SOAP service address and destination REST service address.

SOAP to REST Wizard page 2

Click Finish and the new Camel configuration and associated Java code are generated in your project. The wizard determines whether your project is Blueprint, Spring, or Spring Boot based, and it creates the corresponding artifacts without requiring any additional input. When the wizard is finished, you can open your new Camel file in the Fuse Tooling Route Editor to view what it created.

Fuse Tooling editor Rest Tab

That brings us to another new functionality, the REST tab in the Fuse Tooling Route Editor.

Camel Editor REST tab

The Fuse Tooling Route Editor provides a new REST tab. For this release, the contents of this tab is read-only and includes the following information:

  • Details for the REST Configuration element including the component (jetty, netty, servlet, etc.), the context path, the port, binding mode (JSON, XML, etc.), and host. There is only one REST Configuration element.

  • A list of REST elements that collect REST operations. A configuration can have more than one REST element. Each REST element has an associated property page that displays additional details such as the path and the data it consumes or produces.

Fuse Tooling Rest Elements Properties View
  • A list of REST operations for the selected REST element. Each of the operations has an associated property page that provides details such as the URI and output type.

Fuse Tooling Rest Operations Properties View

For this release, the REST tab is read-only. If you want to edit the REST DSL, use the Route Editor Source tab. When you make changes and save them in the Source tab, the REST tab refreshes to show your updates.

Camel URI completion with XML DSL

As announced here, it was already possible to have Camel URI completion with XML DSL in the source tab of the Camel Route editor by installing the Language Support for Apache Camel in your IDE.

This feature is now installed by default with Fuse Tooling!

Camel URI completion in source tab of Camel Editor

Maven

Maven support updated to M2E 1.9.1

The Maven support is based on Eclipse M2E 1.9.1, bringing the following features:

Advanced classpath isolation

Thanks to Eclipse Photon, there are new two different classpathes, the main and the test classpath. The main classes will now no longer see the test classes and dependencies

Embedded Maven runtime

The embedded Maven runtime is now based on Apache Maven 3.5.3.

Archetype catalog management

It is now possible to disable an archetype catalog.

Java 9/10 support

Support for Java 9/10 has been improved: bugs fixes, better handling of module path.

Java Developement Tools (JDT)

Support for Java™ 10

Quick fix to change project compliance and JRE to 10

A quick fix Change project compliance and JRE to 10 is provided to quickly change the current project to be compatible with Java 10.

quickfix change compliance 10

Java Editor

Quick Fix to add @NonNullByDefault to packages

A new quick fix is offered to fix issues that are reported when the Missing &apos@NonNullByDefault&apos annotation on package warning is enabled. If the package already has a package-info.java, the quick fix can be invoked from the editor:

add nnbd existing packageinfo

Otherwise, the quick fix must be invoked from the problems view, and will create a package-info.java with the required annotation:

add nnbd create packageinfo

When invoked from the problems view, both variations of the quick fix can fix the problem for multiple packages simultaneously.

You can now Ctrl+click or use Open Declaration (F3) on case or default keywords to quickly navigate to the beginning of the switch statement.

navigate to switch
Escape non-ASCII characters when pasting into a string literal

The Java > Editor > Typing > Escape text when pasting into a string literal preference option now has a suboption Use Unicode escape syntax for non-ASCII characters:

escape non ascii settings

When enabled, characters outside the visible ASCII range will be replaced by unicode escape sequences when pasted into a string:

escape non ascii example
Improved Java syntax coloring in the dark theme

To improve readability in the dark theme, bold style usage has been reduced and some colors that were too close to each other have been altered.

java syntax dark

The colors of links in code element information control now takes the color settings of the Hyperlink text color and the Active hyperlink text color from the Colors & Fonts preference page into account. The readability in the dark theme has been improved a lot by this.

Before:

element info before

After:

element info after
Improved coloring of inherited members in the Quick Outline in the dark theme

The Eclipse default dark theme now includes styling of inherited members in JDT’s Quick Outline. This improves readability in the dark theme a lot. The color can be configured via the Java > Inherited Members color definition on the Colors and Fonts preference page.

Before:

inherited before

After:

inherited after

Java Views and Dialogs

Test sources

In the Java Build Path project settings, there is now an attribute Contains test sources to configure that a source folder contains test sources. (Note: test sources must have their own output folder). Similarly, for projects and libraries there is an attribute Visible only for test sources. This setting also exists for classpath containers, and if it is set to Yes for one of these, this value will be used for all contained libraries and projects.

1 sourcefolder settings 521330

Test source folders and dependencies are shown with a darker icon in the build path settings, the package explorer and other locations. This can be disabled in Preferences > Java > Appearance:

1a modified test icon preferences 530179

Referenced projects can contain test sources and have test dependencies themselves. Usually, when test sources are compiled, the test code in projects on the build path will be visible. As this is not always desirable, it can be changed by setting the new build path attribute Without test code, that is available for projects, to Yes.

2 without test code 526858

Build path entries configured like this have a decoration [without test code] after the project name, which can be disabled in Preferences > General > Appearance > Label Decorations:

2a without test code decorator 530179

For each project, compilation is now done in two phases: First all main sources (which cannot see any test-code on the build-path) and then all test sources.

3 visibilities 224708

As a consequence, if the project is a modular Java 9 project, test dependencies like JUnit can not be referenced in the module-info.java, as they will not be visible while compiling it. The solution used to handle this is the same, that Maven uses: When test dependencies are put on the classpath, the module being compiled will automatically be configured to read the unnamed module during the compilation of the test sources, so the test dependencies will be visible.

Of course, code completion will not suggest test code in main sources:

4a completion in main 521331

There are now two dynamic Java working sets Java Main Sources and Java Test Sources containing the source folders grouped according to value of the Contains test sources attribute. This can for example be used to remove warnings in test sources from the problems view:

5a problems view 521336

To achieve this, create a new filter that shows warnings for the Java Main Sources working set and select it with the All Errors on Workspace filter:

5b problems view filters 521336

There are also dedicated filters to quickly remove hits in main code or test code from Java search results:

6 filter search result 521332

Similar, there is a filter to remove test code from Call hierarchies:

7 filter call hierarchy 521335

Another filter to remove test code exists for Quick type hierarchies:

8 filter quick type hierarchy 521333

Test source folders will be preselected in the New JUnit Test Case wizard

9 new junit 332602

In Run and Debug configurations, the Classpath tab (or Dependencies tab when launching with Java 9) contains a new option Exclude Test Code, that is automatically preselected when launching a Java Application from a source folder that is not marked to contain test sources:

10 launching 529321

When launching with Java 9 and this option is not selected, command line options will automatically be added so modules that have a non-empty classpath read the unnamed module. These command line options are part of what can be overridden using the new Override Dependencies button.

Sort library entries alphabetically in Package Explorer

The content of libraries are displayed in the order of the classpath. This makes it difficult to find specific libraries by their name, especially when projects have many dependencies. The library entries can now be sorted alphabetically when setting the preference Sort library entries alphabetically in Package Explorer on the Java > Appearance preference page:

jdt sort library pref
jdt library entries unsorted

The default for this preference is OFF.

Generate dialogs use verbs instead of OK

The Generate…​ dialogs of the Java tools have been adapted to use verbs instead of OK.

Java Compiler

This is an experimental support provided to allow the regular expression usage in search field while searching for module declaration. This can be considered as a wrapper of the API change.

To invoke the regular expression search from the search field under Java Search, start the expression with "/r " i.e, a slash &apos/&apos, the letter &aposr&apos and a blank &apos &apos (not tab) followed by a regex, an example of which is shown below:

mod.regex.trap

In the above example, all the characters trailing "/r " form a Java regular expression to denote a module name which starts with zero or more &aposn’s followed by the string ".ver" and followed again by zero or more number of arbitrary characters.

Another example would be to search for all modules that start with java.x followed by zero or more characters which is given by the regular expression /r java\.x.* - note the backslash for . to consider this as a "normal" character instead of the special regex].

Yet another example would be search for all module names that start with j followed by zero or more characters and ending with .xml which in regex language translates to /r j.*\.xml. Please note that here the first &apos.&apos is the special regex character while the second &apos.&apos is escaped to denote that this is a normal character.

Note: You should use this only for Declarations search for modules as it is not implemented for module references. Selecting All occurrences in conjunction with regex will default to finding only the Declarations matching the regex ignoring the references.

@NonNullByDefault per module

If a module is annotated with @NonNullByDefault, the compiler will interpret this as the global default for all types in this module:

@org.eclipse.jdt.annotation.NonNullByDefault
      module my.nullsafe.mod { ...

Note, however, that this requires an annotation type declared either with target ElementType.MODULE, or with no explicit target at all. Versions 2.2.0 and greater of bundle org.eclipse.jdt.annotation use the latter strategy and hence support a module-wide non-null default.

@NonNullByDefault improvements

When using annotation-based null analysis, there are now more ways to define which unannotated locations are implicitly assumed to be annotated as @NonNull:

  • @NonNullByDefault annotations based on enum DefaultLocation can also be used if the primary nullness annotations are declaration annotations (previously this was supported only for TYPE_USE annotations).

  • Support for @NonNullByDefault annotations that are targeted at parameters has been implemented.

  • Multiple different @NonNullByDefault annotations (especially with different default values) may be placed at the same target, in which case the sets of affected locations are merged.

  • Annotations which use a meta annotation @TypeQualifierDefault instead of a DefaultLocation-based specification are now understood, too, e.g. @org.springframework.lang.NonNullApi.

Version 2.2.0 of bundle org.eclipse.jdt.annotation contains an annotation type NonNullByDefault that can be applied to parameter and module declarations (in addition to the previously allowed targets).

Test sources

There is now support for running Java annotation processors on test sources. The output folder for files generated for these can be configured in the project properties in Java Compiler > Annotation Processing as Generated test source directory.

testsources apt 531072
New preference added "Compiler Compliance does not match used JRE"

A new preference Compiler Compliance does not match used JRE is added to Compiler Preference Building Page.

This preference indicates the severity of the problem reported when project’s used JRE does not match the compiler compliance level selected. (e.g. a project using JRE 1.8 as JRE System Library, and the compiler compliance is set to 1.7).

The value of this preference is by default WARNING.

If the JRE being used is 9 or above and the --release option is selected and even if the compiler compliance does not match the JRE being used, this option will be ignored.

This preference can be set as shown below:

jdt compiler compliance mismatch JRE

Java Formatter

New formatter profile page

The formatter profile preference page (Java > Code Style > Formatter > Edit…​) has a new look which makes it much easier to set preferences for formatting Java code. Instead of multiple tabs, all preferences are presented in an expandable tree.

formatter profile overview

You can use filtering to display only the settings with names matching a specific phrase. Filtering by values is also possible (prefix a value filter with a tilde).

formatter profile filtering

Most sections have a Modify all button in their header that lets you set all their preferences to the same value with one click.

formatter profile modify all

Some preferences have more convenient controls. For example, number values can be easily modified with arrow buttons. Wrap policy settings are controlled by simple toolbars so that you can see and compare multiple policies at once.

formatter profile wrap settings

In the preview panel you can now use your own code to immediately see how it will be affected by the modified settings. You can also see the raw form of standard preview samples and make temporary modifications to them.

formatter profile preview
Formatter: align Javadoc tags in columns

The formatter can now align names and/or descriptions in Javadoc tags in new ways. The formatter profile editor is available for selection, under Comments > Javadoc.

formatter javadoc prefs

For example, the Align descriptions, grouped by type setting is now used in the built-in Eclipse profile.

formatter javadoc preview

The setting previously known as Indent Javadoc tags is now called Align descriptions to tag width. The two settings related to @param tags also had their labels changed to better describe what they do.

Java code formatter preferences now styled for the dark theme

The formatter preferences tree styling has been fixed to work properly in the dark theme.

New Cleanup Action "Remove redundant modifiers"

The new cleanup action "Remove redundant modifiers" removes unnecessary modifiers on types, methods and fields. The following modifiers are removed:

  • Interface field declarations: public, static, final

  • Interface method declarations: public, abstract

  • Nested interfaces: static

  • Method declarations in final classes: final

The cleanup action can be configured as save action on the Unnecessary Code page.

jdt remove redundant modifiers

Debug

Launch configuration prototypes for Java Launch Configurations

A Java Launch Configuration can now be based on a prototype.

prototype java launch configuration

A prototype seeds attributes in its associated Java Launch Configurations with the settings specified in the Prototype tab.

prototype tab java launch configuration 1

Once a Java Launch Configuration has been created, you can override any initial settings from the prototype. You can also reset the settings of a Java Launch Configuration with the ones from its prototype. A Java Launch Configuration maintains a link to its prototype, but is a complete stand-alone launch configuration that can be launched, exported, shared, etc.

prototype tab java launch configuration 2
Advanced source lookup implementation

More precise advanced source lookup implementation, particularly useful when debugging applications that load classes dynamically at runtime.

New org.eclipse.jdt.launching.workspaceProjectDescribers extension point can be used to enable advanced source lookup for projects with non-default layout, like PDE Plug-In projects.

New org.eclipse.jdt.launching.sourceContainerResolvers can be used to download sources jar files from remote artifact repositories, like Maven Central or Eclipse P2.

Advanced source lookup affects debug launches only and can be enabled or disabled with Java > Debug > Use advanced source lookup (JRE 1.5 and higher) preference option:

advanced source lookup
Debugger listens to thread name changes

Debug view now automatically updates thread names if they are changed in the debuggee JVM. This shows live information for worker instances, as described above.

Technically speaking, Java debugger automatically adds a new (user invisible) breakpoint in the JVM and notifies clients (like Debug view) on a breakpoint hit. If this behavior is undesired for some reason, product owners can disable it via product customization.

The property value is: org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.javaDebug.ListenOnThreadNameChanges=false

Value displayed for method exit and exception breakpoints

When a method exit breakpoint is hit, the value being returned is now shown in the variables view.

returningvalue

Similarly, when an exception breakpoint is hit, the exception being thrown is shown.

throwingexception
Display view renamed to Debug Shell

The Display view has been renamed to Debug Shell to better match the features and purpose of this view. Also, a java comment is shown in the Debug Shell on fresh open that explains when and how to use it.

debugShell

And more…​

You can find more noteworthy updates in on this page.

What is next?

Having JBoss Tools 4.6.0 and Red Hat Developer Studio 12.0 out we are already working on the next release for Eclipse 2018-09.

Enjoy!

Jeff Maury


by jeffmaury at July 17, 2018 03:43 PM

Xtext editors for binary files

by Arne Deutsch (adeutsch@itemis.de) at July 13, 2018 12:10 PM

 What does "4 + 1" mean? Well, for example itemis employees have been developing a Java bytecode editor with Xtext. This editor allows the contents of .class files to be made visible and editable.
In the first part of this article I explained how the JBC editor is used. In this second part I want to discuss the technical problems that arise when you want to make a binary file editable with an Xtext-based editor. 

The first issue to solve for a text editor for binary files is to convert the binary data into a textual format without the text editor being involved. This is done by replacing the editor with an IDocumentProvider, which then performs appropriate transformations when loading and saving. As usual in Xtext this is done by dependency injection and registration within the UI module:

package com.itemis.jbc.ui

import com.itemis.jbc.ui.custom.JBCDocumentProvider
import org.eclipse.xtext.ui.editor.model.XtextDocumentProvider

@FinalFieldsConstructor
class JBCUiModule extends AbstractJBCUiModule {
    def Class<? extends XtextDocumentProvider> bindXtextDocumentProvider() {
        JBCDocumentProvider
    }
}

 
The JBCDocumentProvider now overrides the two methods setDocumentContent and doSaveDocument. The first method converts the binary stream into text, while the second returns binary content from the model the editor obtained from the XTextDocument.

package com.itemis.jbc.ui.custom

import com.itemis.jbc.binary.ByteCodeWriter
import com.itemis.jbc.jbc.ClassFile
import java.io.ByteArrayInputStream
import java.io.InputStream
import org.eclipse.core.runtime.CoreException
import org.eclipse.core.runtime.IProgressMonitor
import org.eclipse.jface.text.IDocument
import org.eclipse.ui.IFileEditorInput
import org.eclipse.xtext.resource.XtextResource
import org.eclipse.xtext.ui.editor.model.XtextDocument
import org.eclipse.xtext.ui.editor.model.XtextDocumentProvider
import org.eclipse.xtext.util.concurrent.IUnitOfWork

class JBCDocumentProvider extends XtextDocumentProvider {
    override protected setDocumentContent(IDocument document, InputStream contentStream,
            String encoding) throws CoreException {         document.set(new JBCInputStreamContentReader().readContent(contentStream, encoding))
    }

    override protected doSaveDocument(IProgressMonitor monitor, Object element,
            IDocument document, boolean overwrite) throws CoreException {
        if (element instanceof IFileEditorInput) {
            if (document instanceof XtextDocument) {
                if (element.file.exists && element.file.name.endsWith(".class")) {
                    document.readOnly(new IUnitOfWork.Void<XtextResource>() {
                        override process(XtextResource resource) throws Exception {
                            val ast = resource.parseResult.rootASTElement
                            element.file.setContents(new ByteArrayInputStream(

                                    ByteCodeWriter.writeClassFile(ast as ClassFile)),
true, true, monitor))});
                    return;
                }
            }
        }
        super.doSaveDocument(monitor, element, document, overwrite)
    }
}

 
This is enough to fool the Xtext-based editor, as it provides it with a plain text file, but the result is not quite satisfactory. This is because the editor compares the textual content with the binary data obtained from the .class file to highlight changed regions. This happens because the comparison algorithm does not get the file content directly from the editor, but instead requests IFileEditorInput from the file content and getStorage via the method to get the InputStream.
 

NoProxyForIFileInput

To make the comparison meaningful, this stream also has to be transformed in the same way as was done when creating the IDocument. To do this, the doSetInput (IEditorInput input) method is overridden by the JBCEditor, so that the set input is packaged in a dynamic proxy.

package com.itemis.jbc.ui.custom

import java.io.InputStreamReader
import java.lang.reflect.InvocationHandler
import java.lang.reflect.Method
import java.lang.reflect.Proxy
import org.eclipse.core.resources.IEncodedStorage
import org.eclipse.core.resources.IStorage
import org.eclipse.core.runtime.CoreException
import org.eclipse.ui.IEditorInput
import org.eclipse.ui.IFileEditorInput
import org.eclipse.xtext.ui.editor.XtextEditor
import org.eclipse.xtext.util.StringInputStream

class JBCEditor extends XtextEditor {
    override protected doSetInput(IEditorInput input) throws CoreException {
        if (input instanceof IFileEditorInput) {
            if (input.file.name.endsWith(".class")) {
                super.doSetInput(input.proxy)
                return
            }
        }
        super.doSetInput(input)
    }
    def private IFileEditorInput proxy(IFileEditorInput editorInput) {
        Proxy.newProxyInstance(this.class.classLoader, #[IFileEditorInput],
                new IFileEditorInputHandler(editorInput)) as IFileEditorInput
    }


The latter returns another dynamic proxy for the getStorage query, which converts the file content supplied by getContents into textual format.
 

package class IFileEditorInputHandler implements InvocationHandler {
    private final IFileEditorInput original

    new(IFileEditorInput original) {
        this.original = original
    }
    override invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if (method.name.equals("getStorage")) {
            return (method.invoke(original, args) as IStorage).proxy
        } else {
            return method.invoke(original, args)
        }
    }
    def private IStorage proxy(IStorage storage) {
        Proxy.newProxyInstance(this.class.classLoader, #[IStorage],
new IStorageHandler(storage)) as IStorage
    }
}
package class IStorageHandler implements InvocationHandler {
    private final IStorage original

    new(IStorage original) {
        this.original = original
    }
    override invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if (method.name.equals("getContents") && method.parameterCount === 0) {
            val reader = new InputStreamReader(original.contents)
            try {
                val content = new JBCInputStreamContentReader().readContent(original.contents
                        (original as IEncodedStorage).charset)
                return new StringInputStream(content)
            } finally {
                reader.close()
            }
        } else {
            return method.invoke(original, args)
        }
    }
}

 
As a result the editor.getStorage().GetContents() call returns the same content as was supplied by the document.get(), and the comparison of the document content with that from the file now yields the expected results.
 

WithProxyForIFileInput

The editor implemented here is quite simple, in that each .class file is considered individually: there is no global scope to allow references between multiple files to be resolved and validated. This means that it isn’t easy to develop an entire project directly in class-file-format.

However, this is not a fundamental problem, merely a design decision. The editor is explicitly intended for editing individual .class files. There is nothing wrong, however, with the idea of extending the techniques to other binaries in order to create useful editors for them without an explicit intermediate textual format. These could be stored in files, and these files be linked by references within a global scope.


by Arne Deutsch (adeutsch@itemis.de) at July 13, 2018 12:10 PM

Eclipse Vert.x 3.5.3

by vietj at July 13, 2018 12:00 AM

We have just released Vert.x 3.5.3, a bug fix release of Vert.x 3.5.x.

Since the release of Vert.x 3.5.2, quite a few bugs have been reported. We would like to thank you all for reporting these issues.

Vert.x 3.5.3 release notes:

The event bus client using the SockJS bridge are available from NPM, Bower and as a WebJar:

Docker images are also available on the Docker Hub. The Vert.x distribution is also available from SDKMan and HomeBrew.

The artifacts have been deployed to Maven Central and you can get the distribution on Bintray.

Happy coding and see you soon on our user or dev channels.


by vietj at July 13, 2018 12:00 AM

Call for submissions for EclipseCon Europe 2018

July 06, 2018 03:00 PM

Be part of the EclipseCon Europe program. Submit your talks by July 16th.

July 06, 2018 03:00 PM

First Eclipse DemoCamp in Eindhoven: A Great Start and Even Greater Community

by Niko Stotz at July 05, 2018 03:25 PM

Yesterday, we held the first Eclipse DemoCamp ever in Eindhoven, at the Altran office. About 40 people from a dozen different companies joined in and enjoyed the nice dinner buffet.

Marc Vloemans of Eclipse Foundation kicked off the DemoCamp with a short introduction: DemoCamps are about showing the great work members of the Eclipse community contribute – committers and users alike. Marc emphasized the possibilities of sharing the work between different groups and projects, vastly simplified by the Open Source concept.

Next up was Karsten Thoms of itemis. He swept the audience with an awesome intro – go see it if you have the chance, for example at the DemoCamp Bonn next week or (most probably) EclipseCon Europe in October! Without spoiling the fun, let’s say it gave A New Hope …

Karsten reported on the many changes he and more than 100 other community members contributed to the Eclipse Platform for the Photon Release Train. He showed lots of examples of the general speed improvements of Eclipse Photon. Also, the Run Configuration’s “Add all required Plug-ins” button finally fulfills its promise!

Marc Hamilton explained Altran’s approach for real-world complex modeling environments based on half a dozen Eclipse technologies. At the end, there is always some software produced. Using a modeling approach, most of the actual software production is pushed to generators, while the engineers focus on describing the issue at hand in domain-specific languages.

Marc showed how EMF, OCL, QVTo, Acceleo, EGF, Xtext, and Sirius are used, and listed the advantages, drawbacks and a wishlist for each technology.

During the break, we had the opportunity to pick up stickers provided by Karsten and discuss with other members of the community.

After the break, we enjoyed the talk of Mélanie Bats, arriving directly from Obeo in Toulouse. She showed new features of Sirius 6, most prominently the ELK layout integration and the magic connector tool to auto-select applicable connections.

Furthermore, she gave an outlook on the future of Sirius both within Eclipse and in the Web. She envisioned a Graphical Server Protocol akin to the Language Server Protocol to federate diagramming providers from the clients.

Last but not least, Holger Schill of itemis presented the new features of Xtext 2.14. He reported on the huge effort required to get Xtext fully compatible with Java 9, 10, and Junit 5 in all supported environments – and there are plenty! Other notable enhancements include code mining support (showing additional information within the editor without changing the file) and support for new Project / File wizards. The latter ones do not only create plain wizards, but provide a rich API to create customized wizards without the usual hassle of creating SWT dialogs.

We presented a small gift to all the speakers, who spread the word in the community on their own expenses — Huge thanks to Marc, Karsten, Marc, Mélanie, and Holger!

Lots of community members stayed to discuss the presentations and talk to the creators of the technology we use every day.

We enjoyed the DemoCamp a lot. We’re looking forward to have even more talks, topics, and attendees next time!


by Niko Stotz at July 05, 2018 03:25 PM

Eclipse Foundation Annual Community Report

July 03, 2018 08:00 PM

The Eclipse Foundation's 2018 Annual Community Report has been published, and is now available.

July 03, 2018 08:00 PM

Rest Remote Services with Karaf and CXF/Jersey

by Scott Lewis (noreply@blogger.com) at July 03, 2018 06:55 PM

ECF's Photon Release now includes an example of using Karaf with the JaxRS distribution provider.

This distribution provider now fully supports OSGi R7 remote services, including async remote services, using either the Jersey or CXF JaxRS implementations.

This allows service developers to easily use only JAX-RS annotations to define and implement OSGi R7 remote services.

by Scott Lewis (noreply@blogger.com) at July 03, 2018 06:55 PM

Eclipse Newsletter | Eclipse Photon

July 03, 2018 05:00 PM

Naturally, this issue of the newsletter features some of the things that are new in Eclipse Photon!

July 03, 2018 05:00 PM

Using CMake for the ESP32 with the Eclipse C/C++ IDE

by Doug Schaefer at July 02, 2018 06:00 PM

The Photon release of the Eclipse C/C++ IDE now includes support for a number of different build systems. CMake is one of the most popular build systems with open source projects so it was an obvious candidate. The Eclipse CDT project has been working on CMake support for a few years and now it’s ready for wider adoption.

One of the open source projects using CMake is the Espressif IoT Development Framework, ESP-IDF, an SDK for their inexpensive and highly featured system on a chip, the ESP32. It is widely popular with hobbyists with boards available from a number of vendors. Though CMake support is currently in a feature branch, it is expected their CMake build files will make it to the master branch in the upcoming months.

This environment is a great example of how the new features in the Eclipse C/C++ IDE automate much of the build and launch process to speed up development on microcontroller projects. We will walk though each of the steps to build an application and get it running on a board and will highlight the new features in Eclipse Photon as we go.

Environment

Espressif provides thorough documentation on how to set up your development environment. Here’s a quick highlights of what I did for mine. I’m using Windows 10 with CMake, Ninja, and Python 2.7 provided by scoop. No MSYS or Cygwin. I use busybox for my shell but Eclipse doesn’t need it.

  • Follow the Setup Windows Toolchain from Scratch instructions to get the xtensa toolchain and mconf Kconfig utility. Add them to your PATH environment variable.
  • Checkout the features/cmake branch of the ESP-IDF. Make sure you do a recursive checkout to pick up it’s numerous git submodules. Set the IDF_PATH environment variable to the root location of the repo.
  • Install the pyserial Python library for esptool.

Now we’re ready to fire up Eclipse.

CMake Project

In the New C/C++ Project wizard select “Empty or Existing CMake Project” from the list of templates and create a new project. This will create the project but without a CMakeLists.txt or any source files.

The Toolchain

We now need to tell CDT which toolchain to use when building the project. This will pass the required arguments to CMake when generating the Ninja files.

In the Preferences, select C/C++ and then CMake to see the list of toolchain files CDT will use with CMake. Click Add. Each CMake toolchain file is associated with a toolchain. Since we have the xtensa toolchain in our PATH, CDT will auto discover it and it will appear in the dropdown. Also enter the location of the esp-idf toolchain file which is in the esp-idf repo under tools/cmake/toolchain-esp32.cmake.

The Launch Target

Next we need to tell CDT to use the toolchain for our project. This is accomplished through the Launch Bar, the new widget set you see on the far left of the toolbar.

Click on the third dropdown and select New Launch Target. We need to tell CDT about the target where we’d like to launch our application. We’ll be using the flash loader so select Serial Flash Target. Enter a name for the target, “esp32” as the operating system, “xtensa” as the CPU architecture, and select the serial port your ESP32 device is connected to on your machine.

The OS and architecture need to match the settings for the toolchain. You can see those settings in the Preferences by selecting C/C++ and Core Build Toolchains. For GCC toolchains, CDT autodetects those settings by asking GCC for it’s target triple.

Build

For this first project, we’ll use the Hello World example from the ESP-IDF. It is found in the examples/get-started/hello_world. Copy the contents of this directory into your project. Since we’re using CMake you can delete the Makefile and the main/component.mk files to prove you’re using CMake.

Notice that the Launch Bar shows Run Hello World on ESP32. When you click the Build button, it will run a build of that project for the ESP32 Launch Target in Run mode, the only one available for the ESP32 for now, and will make sure the right toolchain and CMake toolchain file are used in the build.

Terminal

To see what our program does, we need to see the output from the serial port. I have an Adafruit Huzzah32 which uses USB to both power the board while in development and to talk over the serial port. We’ll use the Eclipse Terminal to connect to that serial port. Click the Terminal toolbar button and select Serial Terminal as the terminal type and complete the rest of the settings.

Launch

To get the app running on the board, we need to download it over the USB serial port and burn it into the flash memory on the device. The ESP-IDF has a tool for that called esptool. The IDF also has a nice wrapper script that manages flashing as well as a number of other handy operations.

To hook it up, we need to set up the launch configuration. This is where the Launch Bar shines. Click on the gear next to your project in the middle selector. It will open a launch configuration edit dialog. Since our target type is Serial Launch Target, it has a simple launch that executes an external tool. We’ll set it up to run python with the idf.py script and set the build directory and serial port and ask it to flash.

If you had a program running on your chip you’ll notice in the Terminal that it stopped printing there. The CDT has noticed that your launch target and the terminal are using the same serial port and pauses the terminal while the python script runs. This is especially important on Windows since only one program may control the serial port at a time. Once it starts up again, you see the output of your program. This makes it very easy to iterate changes.

Conclusion

The Eclipse Photon release of the C/C++ IDE is the culmination of a number of years of work on the Launch Bar and CDT’s new Core Build system that gives us CMake and makes it easy to integrate other build and launch tools. Bringing these tools together and having them work together to accellerate development is what Integrated Development Environments are all about.


by Doug Schaefer at July 02, 2018 06:00 PM

EclipseSource Oomph Profile – updated to Photon

by Jonas Helming and Maximilian Koegel at July 02, 2018 02:45 PM

Last week, Eclipse Photon has been released, a new version of the Eclipse IDE and platform. It contains many useful improvements, so it is worth to update.

One of many noteworthy extensions is the new support for code mining. In case you wonder what that is (you do not even find a definition on wikipedia), let us quickly introduce this new feature. The general idea is to add additional information to a source code editor, which is not code or a comment. That means, this information is not stored in the underlying file, but it augments the text editor during runtime. In fact, you cannot only add information, but also actions, essentially buttons, that can trigger context related behavior.

Let us look at an example: In the following screenshot, you see a test case, which is augmented via code mining. For every test, it shows the state of the last test run, as well as two “buttons” (run and debug) to trigger another execution of the test. The same is available for the test class (e.g. “run all”). The screenshot also shows another example for code mining. The parameter passed into the Junit method fail() is augmented by the type and the name, as defined in the signature of fail().

EclipseSource Oomph Profile - updated to Photon

Please note, that Eclipse itself does not provide any use cases of code mining, but it provides the ability to plugin code mining applications. The examples shown above are from the JDT Code Mining plugin, which can be found on Github. It allows to turn specific code mining applications on or off, depending on how useful you consider them.

Code Mining is a very interesting new feature an we look forward to new ideas and use cases that developers might add. Given the well-proven extension mechanism of Eclipse, it is relatively low effort to implement custom code mining extensions.

Further general improvements of the Eclipse Photon release are summarized in the following video, Java and Maven improvements in a separate video below.  Both are provided by Holger Voormann, whom we want to thank you for this great work!

As always, in case you use our EclipseSource Oomph profile (see here for more details), you should get a notification and Oomph will apply the update automatically. If you do not get the notification, just navigate to the menu entry “Help” => “Perform Set-Up Task”. This will automatically update all plugins to Photon, but keep all existing settings untouched.

Have fun with Eclipse Photon!


by Jonas Helming and Maximilian Koegel at July 02, 2018 02:45 PM

Touring the Eclipse Photon DemoCamps – Next stop: Eindhoven, NL, July 4th!

by kthoms at July 02, 2018 02:42 PM

Eclipse DemoCamps are a wonderful format to learn the hottest new stuff from all the bandwidth of Eclipse projects: Core IDE, IoT, Smart Home, Modeling, JakartaEE, MicroProfile, Tools and so on. It is also a great way to get in touch with creators, committers, influencers and users of these technologies.

For this DemoCamp season I am promoting the Eclipse Platform Project and thus the Eclipse Photon IDE. Eclipse Photon comes with a plethora of new features and improvements which are hard to compress into a DemoCamp format. Usually presentations in DemoCamps are just 20 minutes. Attendees should get an overview of multiple projects and interesting stuff with a wide range of topics. And since DemoCamps are in the evenings, attendees want to get entertained and not bored by long talks. The focus is on real demos, live coding and networking. I love to do that.

screenshot 178.png

My talk is named “Approaching Light Speed – News from the Eclipse Photon Platform“. I have given this talk already at EclipseCon France, at the DemoCamps in Zurich and Darmstadt, and internally at our itemis headquater before our yearly company wide party called itemis SummerCon. I have prepared quite a bunch of stuff to talk about. But different then usually, I do not perform live coding, but show coding with small screencasts in my presentation. For this talk I would have to switch too many between different code and workspaces, and comparisons to the previous version Eclipse Oxygen would make this even worse. It is just too confusing if I would switch so often. And would take much longer so I could present not that much.

At EclipseCon France I had 35 minutes for the talk, and even for that I had strip down the material I already had. The new supported Java versions 9 and 10 in JDT I could just scratch at surface level, although this is one of the real major things in Eclipse Photon. But platform improvements are that much that JDT has to be put into background. For a DemoCamp talk in 20 minutes challenges become bigger. However, in Zurich and Darmstadt I had only those 20 minutes and I thing I managed to give a smooth and interesting presentation. The attendees I spoke afterwards were impressed from all the great stuff that comes with the Eclipse Photon IDE and made them hungry to finally get Photon and use it for their work. Last week on June 27th it was finally time for the great release!

My next stop is now the DemoCamp in Eindhoven this Wednesday on July 4th 2018. This DemoCamp will be held at the office from Altran and is organized by my former colleague Niko Stotz. This will be the first Eclipse DemoCamp held in Eindhoven, and maybe the first in the Netherlands (I don’t remember if one was already in the Netherlands so far). I am interested how engaged the developer community in and around Eindhoven is and hope for Niko that many interested people are making their way to the event!

My colleague and friend Holger Schill will present the new and noteworthy features of the new Xtext 2.14 release that ships with Eclipse Photon. Last week we showed this in the webinar Eclipse Photon Series: What’s New in the Eclipse Xtext 2.14?, which got recored on YouTube. If you want the information given there in 60 minutes condensed, make sure to visit the DemoCamp! Further you will see the wonderful Mélanie Bats. She will present all the new features in Eclipse Sirius 6. Besides all the news from the modeling technologies Marc Hamilton is showing how they use the Eclipse Modeling technology stack (Xtext, Sirius, EMF and others) at Altran to build solutions with them.

So, my fellow software engineers & craftsmen in the Netherlands, register for the Eindhoven DemoCamp now and see you there!


by kthoms at July 02, 2018 02:42 PM

Sirius 6

July 02, 2018 10:00 AM

Eclipse Sirius is a framework to easily and quickly create a graphical modeling workbench dedicated to your domain specific language.

This year at Obeo, we started working on two aspects: prepare the future of Sirius & provide new features for the upcoming 6.0 release which is part of the Photon release train.

Ready for Photon? Sirius 6.0 is there for you!

We have added several new features:

  • Support for background color on diagrams: it is now possible to dynamically compute the color of the diagram according to the state of the model. This is a small feature, but it continues to expand the visual customization capabilities available to specifiers. Background color on diagrams

  • New “magic” edge creation tool: All diagrams will now benefit for free from a new smart edge creation tool. Thanks to this end users no longer have to chase for the appropriate tool in the palette (which can contain many entries): just click on the source and target of the edge to create and Sirius will automatically detect which tools can be applied to them. If there is only one, the edge is created immediately. If several tools are possible as is the case of the animation, a menu opens to choose among the candidate tools. New “magic” edge creation tool

  • Quick navigation to service method implementation: Real-world modelers often need to call into Java code to perform complex operations on models or call into Sirius and Eclipse APIs. This is very straightforward to do in Sirius with the notion of Java services that can be transparently invoked from AQL expressions. It is now possible to navigate from the expressions in the Sirius specification which invoke a service method directly into the corresponding Java code with a single keystroke. Quick navigation to service method implementation

  • Integration with ELK for improved diagram layouts: Sirius has always proposed an automatic layout algorithm. Specifiers can now leverage the high-quality layout algorithms provided by the Eclipse ELK project. You can choose any of the algorithms proposed by ELK and tweak all their configuration parameters in the Sirius specification. The end users will transparently get a nicer layout when using the existing “Arrange All” action. This is experimental in Sirius 6.0. Give us feedback on which aspects to focus on for the future. Integration with ELK for improved diagram layouts Override ELK options

What’s next?

We are working on what would be the future of modeling tools. We already gathered some feedback from the community. You expect that modeling in the future would be: fast, simple, easy, beautiful, cloud & collaborative.

We believe that the concept of IDE is evolving. In the future, we will have more accessible tools and better tool integration. In the end, we think that tools should become IDE agnostic. We will have more and more tools dedicated to specific domains. These tools would be available more broadly, for various kind of users on any kind of platforms. We need frameworks to ease the creation of such specific tools dedicated to one usage. That’s why we believe in frameworks such as Sirius.

Sirius is a really nice framework to create dedicated desktop workbenches based today on the Eclipse platform. Our purpose is to bring the spirit of Sirius to the cloud: easily develop modeling workbenches but rendered in a browser and integrable in any web application.

So where are we today? We are going step by step and work on different aspects.

  1. Introduce web technologies in existing Eclipse views: Our first step is to introduce web technologies in existing Eclipse views. This approach is used to provide a brand new feature in Sirius 6.0 called Workflow which allows specifiers to guide users through the usage of their workbench. On the left of the following screenshot, we see a Sirius configuration file which defines a workflow with different actions using this new DSL. To the end-user, these are rendered as web elements inside the Eclipse view. Note that this new feature is still experimental in 6.0, and will be improved for version 6.1 this fall. Web components in Eclipse view
  2. Make Sirius independent from Eclipse platform: The idea is to make the Sirius code base more modular, isolating the core business concerns from the current Eclipse-based technology stack: the Eclipse UI, GMF, the workspace, and even the Eclipse Runtime itself. We will work on this progressively over several versions, making sure Sirius always keeps working even in the classical Eclipse-based context. The end goal is to get a set of core components that can be reused both in Eclipse and, more to the point, inside a web server exposing its services to any web client through a well-defined protocol.
  3. Render Sirius diagrams in a browser: Based on a classical Sirius configuration, we can render in a browser the graphical elements of a diagram. As usual, the specifier can work on the look and feel of his modeler iteratively. This prototype is based on Sprotty. Sprotty is a new project proposed to the Eclipse Foundation by TypeFox. It is a small, lightweight, open source & well architectured JavaScript graphical library providing rendering in SVG & well integrated with Eclipse ELK which provides auto-layout.
  4. Sirius integrated with Cloud IDEs: Sirius in a near future will be IDE-agnostic. Then you will be able to integrate Sirius based workbenches in any web application or any IDE. Have a look at the prototypes we already have of Sirius integrated in Eclipse Theia and of Sirius integrated in Eclipse Che. Sirius integrated with Cloud IDEs To sum up, we will keep working on the existing Sirius project and we will reintegrate the new web-related features and components. This summer we will continue our work on the modularization of the architecture. And for the 6.1 this fall, we will contribute a first version of web based diagrams based on the Graphical Server Protocol. Sirius timeline

At Obeo, we’re taking a community-first approach to influence the development of the next generation of modeling tools. Please tell us what you want! We have lots of ideas for the future of Sirius. But what we need is to know what YOU need. So please Speak Up!


July 02, 2018 10:00 AM

Simplified database transaction management with the Vert.x RxJava API

by tsegismont at July 02, 2018 12:00 AM

TL;DR As of 3.5, managing database transactions with Vert.x requires a lot of boilerplate code. Vert.x 3.6 will provide helpers and Observable transformers to easily make a reactive flow transactional.

Simple queries with the “Rxified” API

The Vert.x API for RxJava is one of the most popular modules in the Vert.x stack.

So we make sure the “Rxified” API is easy to use for common programming tasks, such as reading rows from a relational database and sending the result to the client:

dbClient.rxQuery("SELECT name, duration FROM tracks WHERE album = 'The Israelites'")
  .map(ResultSet::getResults)
  .map(rows -> {
    // Transform DB rows into a client-friendly JSON object
  })
  .subscribe(json -> {
    // Send JSON to the client
  }, t -> {
    // Send error to the client
  });

Managing transactions with Vert.x 3.5

But very often, developers have to implement complex interactions with the database, running inside a single transaction. To do so, the implementation must follow this process:

  • get a connection from the pool,
  • start a transaction,
  • execute queries,
  • if all queries succeed, commit the transaction,
  • otherwise, rollback the changes.

How does that translate to code?

// Get a connection from the pool
dbClient.rxGetConnection().flatMap(sqlConnection -> {
  // Setting auto-commit mode to false implicitely starts a transaction
  return sqlConnection.rxSetAutoCommit(false)
    .andThen(
      // Database queries
      sqlConnection.rxExecute("INSERT INTO albums (name) VALUES ('The Israelites')")
        .andThen(sqlConnection.rxExecute("INSERT INTO tracks (album, name) VALUES ('The Israelites', 'Israelites')"))
        .andThen(sqlConnection.rxExecute("INSERT INTO tracks (album, name) VALUES ('The Israelites', 'Too Much Too Soon')"))
        .andThen(sqlConnection.rxQuery("SELECT name FROM tracks WHERE album = 'The Israelites'").map(ResultSet::getResults))
    )
    // Commit if all queries succeed
    .flatMap(rows -> sqlConnection.rxCommit().andThen(Single.just(rows)))
    .onErrorResumeNext(throwable -> {
      // On error, rollback the changes
      return sqlConnection.rxRollback().onErrorComplete()
        .andThen(sqlConnection.rxSetAutoCommit(true).onErrorComplete())
        .andThen(Single.error(throwable));
    }).flatMap(rows -> sqlConnection.rxSetAutoCommit(true).andThen(Single.just(rows)))
    .doFinally(sqlConnection::close);
}).map(rows -> {
  // Transform DB rows into a client-friendly JSON object
}).subscribe(json -> {
  // Send JSON to the client
}, t -> {
  // Send error to the client
});

That is a lot of boilerplate around the specific database queries… It would be better to relieve the developer from maintaining it.

Vert.x 3.6 tools for transaction management

That is why Vert.x 3.6 will provide Observable transformers that can be applied to reactive flows with compose to make them transactional:

  • SQLClientHelper#txFlowableTransformer
  • SQLClientHelper#txObservableTransformer
  • SQLClientHelper#txSingleTransformer
  • SQLClientHelper#txMaybeTransformer
  • SQLClientHelper#txCompletableTransformer

These transformers wrap the corresponding source of events with SQL transaction management.

dbClient.rxGetConnection().flatMap(sqlConnection -> {
  return sqlConnection.rxExecute("INSERT INTO albums (name) VALUES ('The Israelites')")
    .andThen(sqlConnection.rxExecute("INSERT INTO tracks (album, name) VALUES ('The Israelites', 'Israelites')"))
    .andThen(sqlConnection.rxExecute("INSERT INTO tracks (album, name) VALUES ('The Israelites', 'Too Much Too Soon')"))
    .andThen(sqlConnection.rxQuery("SELECT name FROM tracks WHERE album = 'The Israelites'").map(ResultSet::getResults))
    .compose(SQLClientHelper.txSingleTransformer(sqlConnection))
    .doFinally(sqlConnection::close);
}).map(rows -> {
  // Transform DB rows into a client-friendly JSON object
}).subscribe(json -> {
  // Send JSON to the client
}, t -> {
  // Send error to the client
});

Source transformers provide maximum flexibility: you are still able to execute operations with the connection after the transaction completes.

However, you usually do not need the connection after the changes are commited or rollbacked. In this case, you may simply create you source observable with one of the transactional helper methods in io.vertx.reactivex.ext.sql.SQLClientHelper.

Let’s rewrite the previous example:

SQLClientHelper.inTransactionSingle(client, sqlConnection -> {
  return sqlConnection.rxExecute("INSERT INTO albums (name) VALUES ('The Israelites')")
    .andThen(sqlConnection.rxExecute("INSERT INTO tracks (album, name) VALUES ('The Israelites', 'Israelites')"))
    .andThen(sqlConnection.rxExecute("INSERT INTO tracks (album, name) VALUES ('The Israelites', 'Too Much Too Soon')"))
    .andThen(sqlConnection.rxQuery("SELECT name FROM tracks WHERE album = 'The Israelites'").map(ResultSet::getResults))
}).map(rows -> {
  // Transform DB rows into a client-friendly JSON object
}).subscribe(json -> {
  // Send JSON to the client
}, t -> {
  // Send error to the client
});

Give it a try

Vert.x 3.6 is expected around fall, but the code is already in master and snapshots are regularly published to Sonatype’s OSS repos.

So give it a try and feel free to provide your feeback on our user or dev channels.


by tsegismont at July 02, 2018 12:00 AM

Eclipse Marketplace Client, Photon Edition not opening in certain cases

June 29, 2018 12:00 AM

The Eclipse Marketplace Client, Photon edition has a bug where it fails to open in certain cases. If nothing happens when you try to access the Eclipse Marketplace via “Help > Eclipse Marketplace”, please update the Marketplace Client plug-in by doing the following:

Marketplace Client not opening in Photon

  1. Go to Help > Install New Software
  2. Paste the Marketplace Client update site url into the “Work with” field: http://download.eclipse.org/mpc/photon
  3. Select the “EPP Marketplace Client” checkbox
  4. Follow the wizard and restart your Eclipse to finish the installation.

We are working on providing an update to the Eclipse Photon release to distribute the fix through automatic updates and package downloads. In the meantime, please update manually if you are affected by this bug.

If you have any questions about this update process, please send an email to mpc-dev@eclipse.org. For more technical details, see bug 536385.

Blog post co-authored with Carsten Reckord.


June 29, 2018 12:00 AM

Jakarta EE, Eclipse MicroProfile and Cloud-Native at EclipseCon France

by Tanja Obradovic at June 28, 2018 07:59 PM

These are exciting times for the Java community! EclipseCon France (ECF) 2018, the first ECF since Oracle contributed Java EE to Eclipse Foundation, surely reflected that. The Jakarta EE brand, now firmly accepted by the community,  received heightened visibility at ECF via a track dedicated to Jakarta EE and related technologies. The MicroServices, MicroProfile, EE4J, & Java EE track included talks  related to cloud native application development using the MicroProfile programming model, EE4J and Jakarta EE (Java EE) technologies. Topics included: how to build a fault tolerant microservice, how to monitor and trace the service invocations, how to secure microservices, best practices, and more.  Based on session attendance and community feedback it is clear interest in Jakarta EE, MicroProfile and Microservices is high and growing.

The talks varied from a beginner to advanced level and were given by well known Java developers, open source project committers and community leaders. It was a fabulous opportunity to meet Java enthusiasts seeking community involvement and looking forward to contributing to the success of Jakarta EE for Cloud application development.

Here are some highlights from talks and presentations.

Cloud-Native Application Development

(based on RedHat presentation, Thomas Qvarnstrom, Cesar Saavedra)

In the case you are wondering what exactly is cloud-native application development, please refer to the great presentation from RedHat. It will give you answers on what changes are required from development and deployment perspective. This also means you’ll get pointers for architectural and organizational changes needed when developing cloud-native applications.

As we know “a picture tells a thousand words”, so here is the slide from the presentation that describes it all

 

  • Development assumes Service-based architecture with API-driven communication
  • Deployment is done using containers infrastructure and DevOps process (continuous integration and ongoing deployment, tight collaboration between teams)  

If you are wondering how different are Traditional from Cloud-Native Application Development is, again, one of the slides from the same presentation sums it up.

And finally, if you would like to develop cloud native applications here are steps you need to follow

  1. Evolve Cloud Native DevOps practices and culture (take advantage of new tech, faster approaches and tighter collaboration)
  2. Speed up existing applications (migrate app server to container-based platform)
  3. Use Application Services optimized for cloud and containers
  4. Choose right tool for right task - Multiple runtimes and frameworks
  5. Self-Service On-Demand Infra (allow developers to access infra when they need it with IT Ops control & visibility)
  6. Automate it to accelerate delivery (Integrated full-scale enterprise-wide automation)
  7. Implement Continuous Delivery, Integration and Deployment (CD/CI) - to provide updates w/o operational capacity & reduced risk
  8. Evolve a more modular architecture - Microservices Architecture and its alternatives
Eclipse MicroProfile

(Based on MicroProfile presentation, Ivar Grimstad)

Enterprise Java technologies like Java EE have evolved for nearly two decades to support distributed application architectures. The MicroProfile is the next step in that evolution and it is optimizing Enterprise Java for a microservices architecture.

Eclipse MicroProfile is an open-source community specification for Enterprise Java microservices, that is engaging individuals, organizations, and vendors collaborating within an open source (Eclipse Foundation) project.

The slide below shows how MicroProfile (an early release) relates to Java EE.

Popularity and expansion of the profile in last two years (since the first release Sept 2016) is gaining a major momentum in the Java community. MicroProfile since then evolved and the current release Eclipse MicroProfile 2.0 specification looks like this

Who are MicroProfile implementers?

 

Jakarta EE

(based on IBM presentation, Kevin Sutter)

This talk provided a great overview of the status of the EE4J project set up to evolve the Java EE technologies contributed by Oracle to the Eclipse Foundation into the Jakarta EE platform.

The following material is being moved from Oracle to the Eclipse Foundation

  • Java EE 8 Specifications
  • Java EE 8 APIs
  • Java EE 8 RIs
  • Java EE 8 TCKs

Progress on the code move to Eclipse Foundation can be viewed  here.

The first Jakarta EE release is expected late 2018. The first Jakarta EE release will be equivalent to Java EE 8 platform.

There are additional changes taking place as well! Here are some of the highlights:

Oracle’s Java Community Process (JCP) [for Java EE only] is in going to be changed by the Jakarta EE Working Group.

Key Benefits of the Jakarta EE Working Group
  • Vendor Neutral
  • Open Intellectual Property Flows
  • More Agile and Flexible

Specification development approach change

  • JCP specification development was based on specification development first, then code based on the specification
  • Jakarta EE Working Group is proposing the reverse - Code development first and, then specification based on the code…

Oracle’s Java Specification Request (JSR) will be replaced by Eclipse Foundation Specification Process

Eclipse Foundation Licensing

  • Usage License (EPL v2*)
  • Specs, APIs, RIs, and TCKs!

MicroProfile and Java EE

MicroProfile1.4 (Java EE 7)

• Config 1.3 • Fault Tolerance 1.1 • JWT 1.1 • OpenTracing 1.1 • Rest Client 1.1

MicroProfile2.0 (Java EE 8)

• CDI 2.0 • JAX-RS 2.1 • JSON-P1.1 • JSON-B1.0 • (Common Annotations 1.3)

There is a lot of enthusiasam about revitalizing and modernizing the old Java EE specification and JCP process. It is refreshing to see the excitement and interset about the work already done, and furthermore the work being laid out for Jakarta EE - the cornerstone Cloud-native Application Development, as continuation of the success Java EE, once had in (monolithic) on-premise application development.

Lastly, much thanks to all community members and our sponsors that made the event extremely memorable and possible.  Looking forward to seeing many of you at EclipseCon Europe. See you all very soon. Shout out to Emily Jiang, IBM, chair of the MicroServices, MicroProfile, EE4J, & Java EE track and all the session contributors.


by Tanja Obradovic at June 28, 2018 07:59 PM

Papyrus’s Photonic 4.0!

by tevirselrahc at June 28, 2018 07:18 PM

It had to happen: Papyrus is now available at version 4.0! That’s Papyrus “Photon” for those of you who follow the Eclipse release names.

Curious about what was done in this release? You can find that in the list of addressed issues (a.k.a., the bug list). The following topics are addressed:

  • A new preference has been introduced to keep stereotype application with their base element see StereotypeApplication Preference
  • The hyperlink navigation has changed see Hyperlink Navigation
  • Add a preference page to configure the visualization of  external decorator  see External Decorator
  • Add auto-completion to select the type in the property view see  Auto complete type
  • Add an export to HTML to see model without papyrus see HTML Export
  • Development and adaptation of the Layer tool for the diagrams Layers .
  • Synchronization with ELK see ELK adaptation
  • Tables improvements:
    • display of a string instead of N/A
    • Matrix improvements
    • save by UUID not the positon
  • Diagrams improvements:
    • some problems about the name label of ports have been fixed
    • some resize action in the class diagram have been fixed.
    • sequence diagram – Better movement  management of Elements, introduction of combined fragment, RCPTT tests.
  •  Integrate a  tool to adapt your model based on the modification of the profile
  • Architecture framework : stabilization (easier customizations/modifications by the users) and bug corrections

Want to try it out? Here are a few links to help you:

 

(* In case you were wondering, “RCP” stands for “Rich Client Platform 😉


by tevirselrahc at June 28, 2018 07:18 PM

Take Your Code to the Next Level With Eclipse Photon

June 28, 2018 05:00 PM

Join over 4 million active users of the Eclipse IDE and take your coding to the next level with Eclipse Photon.

June 28, 2018 05:00 PM

EMF Forms and EMF Client Platform 1.17.0 released!

by Jonas Helming and Maximilian Koegel at June 28, 2018 10:55 AM

We are happy to announce that with the Photon release train, we have also shipped  EMF Forms and EMF Client Platform 1.17.0!

We want to thank our continuously active team of 10 contributors (40 contributors overall) for completing on 57 bug fixes and features. EMF Forms continues to be one of the most active projects at Eclipse.

We are thankful for all the feedback from our very active group of adopters, for which we have an additional improvement to announce:

During the 1.17.0 release cycle, we were talking with contributors and adopters about how to ease the adoption of new versions. While new features in EMF Forms are typically developed as optional additions, there are obviously always some fixes and changes that affect the existing default behavior. As EMF Forms is by definition a user visible framework, even small changes in a new version can sometimes have an unexpected effect in adopter projects. As an example ordering elements alphabetically in a list dialog by default can be considered to be a bug fix for a certain adopter project. For another adopter, this change could cause a regression, as the existing “undefined” order was good for them.

As another example, showing descriptive tooltips on table column headers might sound like an improvement. However, this change is bad if you never refined the underlying attribute descriptions. This “improvement” makes the string visible, which is not really comprehensible by end-users (see screenshot below for an example). Again, an “improvement” can cause unwanted behavior.

EMF Forms and EMF Client Platform 1.17.0 released!

While we always try to avoid changes to the default behavior and make new things optional, sometimes changes to core components make sense and are an improvement for most adopters. In any case, the developer team cannot possibly foresee all consequences of a change in all adopters projects.
However, due to the high development activity of EMF Forms, it is quite some effort for adopters to browse all fixed bug reports of a release to find relevant changes. Therefore, we decided to improve the communication about those kind of changes. To achieve this, we introduced the usage of a new keyword on our Bug Reports: “Test”.
The tag is to be used:

  • when the default behavior of a component has changed, even if they are considered an improvement
  • when a new feature has been added which is enabled by default
  • Any changes and adaptations of visible UI elements, even if they are considered an improvement
  • Non-trivial refactorings with a risk for regressions

Of course all of the above mentioned criteria are subject to interpretation, more details can be found in our contributions guideline. In general, the “Test” keyword highlights bug reports, which should definitely be looked at and tested in detail by all adopters, when they update to a new version.

We hope this helps all adopters, we are of course happy for any feedback on this. Finally, please note that we introduced the keyword during our last development cycle, so 1.17.0 is not fully triaged yet. Therefore, please consider to tag a bug report with the “Test” keyword yourself, if the change has an unexpected effect in your project so that other adopters can benefit from your findings.

Further, kindly continue to ask questions in the newsgroup and file Bug Reports.

In case you don’t know EMF Forms: It is a framework focused on the creation of form-based UIs. EMF Client Platform is designed to support the development of applications based on an EMF data model. If you are not yet familiar with EMF Forms, please refer to this tutorial for an introduction.

Both of these frameworks are part of the Eclipse Modeling Tools Photon package, but you can also find the new release on our download pages:

As always, we will also blog about new features of the EMF Forms / ECP 1.17.0 release in the upcoming weeks! Please follow this blog or follow us on twitter to get notified about the new posts.


by Jonas Helming and Maximilian Koegel at June 28, 2018 10:55 AM

New Photon Release of Eclipse IDE Ships With Full Rust Support

June 27, 2018 03:00 PM

The Eclipse Foundation today announced the Eclipse Photon simultaneous release.

June 27, 2018 03:00 PM