Introducing the Jakarta EE Specification Process

by Mike Milinkovich at October 16, 2018 07:18 PM

I am very happy to announce that we are publishing a draft of the Eclipse Foundation Specification Process for community review and feedback. This specification process will be used by Jakarta EE as the new open specification process, replacing the JCP process previously used for Java EE. It is also expected that this new process will be of interest to other Eclipse working groups.

We are really looking forward to your feedback, which you can do via the Jakarta EE Community mailing list (preferred), or on the document comments.  The feedback provided will be used as input to finalizing a first version of the specification process and its adoption by Jakarta EE and other working groups at the Eclipse Foundation.  

As you are reviewing this draft specification process, please keep in mind the following key points about the approach that was taken by the Specification Committee.

  1. We want to design a specification process to replace the JCP. While there are many differences with the JCP, the key objective was to make the whole process as lightweight as possible.
  2. We want the specification process to be as close to open source development as possible. This is actually not a trivial exercise, as by its very nature drafting specifications is a somewhat different process.
  3. This is the Eclipse Spec Process, so we want to reuse the Eclipse Development Process wherever possible, and we want to ensure that the general flow and tone of the EDP is followed.
  4. We want to create a process that allows code-first development. Specifically, we want to enable a culture where experimentation can happen in open source and then have specifications be based on those experiences.
  5. We want the specifications that result from this process to be as high quality as possible. In particular, this means that we need to take care of the intellectual property flows, and to protect the community’s work from bad actors. This requirement manifests as two fundamentally important differences from the EDP:
    • Specification Committee approval is required for releases from Spec Projects, in addition to the normal PMC approval; and
    • We introduce the notion of “Participants” who are committers who represent specific member companies on a Spec Project. This is necessary to ensure that the IP contributions (particularly patents) from companies are properly captured by the process.

All of us at the Eclipse Foundation would like to recognize the tireless efforts of the members of the Specification Committee. A lot of hard work has gone into this document, and it’s very much appreciated. We are certain that Jakarta EE, and many other Eclipse technologies, benefit from the thoughtful efforts of this Committee.  In particular, we would like to thank the following Specification Committee members and alternates:

Fujitsu: Kenji Kazumura​, Mikel DeNicola
IBM: Dan Bandera​, Kevin Sutter
Oracle: Bill Shannon​, Ed Bratt​, Dmitry Kornilov
Payara: Steve Millidge​, Arjan Tijms
Red Hat: Scott Stark, Mark Little
Tomitribe: David Blevins​, Richard Monson-Haefel
PMC Representative: Ivar Grimstad
Elected Members: Alex Theedom, Werner Keil​

I also wish to recognize Tanja Obradovic and Wayne Beaton from the Eclipse Foundation team who have driven the process throughout – many thanks to you both!


by Mike Milinkovich at October 16, 2018 07:18 PM

Example demonstrating connectivity to an MQTT broker

October 16, 2018 04:00 AM

Eclipse Ditto can now connect to MQTT 3.1.1 brokers.

Perfect timing to happily welcome a new colleague to our team behind Eclipse Ditto: David.

In order to get familiar with Ditto and the development with digital twins, David was assigned with one of his first tasks to get his hands on one of our newest features, MQTT connectivity which was released recently with milestone 0.8.0-M2.

On his journey into digital twin land he made a great example with an ESP8266 powered board connected via an MQTT broker to Ditto and published it to the Eclipse Ditto examples repository:

This example is about how to communicate between device and solution in a two way pattern through Ditto using MQTT. This means we will add a policy, a thing and a MQTT connection to Ditto. When Ditto ist set up and working, we will create real world device (“octopus board”) and connect it to it’s digital twin via MQTT.

At the end, we will create a basic frontend webapp. The webapp will automatically connect to Ditto when you type in your credentials, automatically pull your things and show them in a list.
You can create, modify and delete devices in the webapp and if there is a real world device connected to the thing in the list, you can send it a command message to control any feature on it. The list of things will always be up-to-date when you listen to server-sent-events, which you can activate easily with pressing a button.

Eclipse Ditto bidirectional MQTT diagramSource: https://github.com/eclipse/ditto-examples

We will use an Octopus-board with an ESP8266 on it. It has several sensors built in, but for simplicity we will just use it’s temperature and altitude sensor.
To show the functionality of Eclipse Ditto messages, we will switch on/off a LED on the Octopus-board through it.

If you have any wishes, improvements, are missing something or just want to get in touch with us, you can use one of our feedback channels.

Ditto


The Eclipse Ditto team


October 16, 2018 04:00 AM

Smart Home Day

by Anonymous at October 13, 2018 04:30 PM

Join us for the second installment of Smart Home Day on 21 October, the Sunday before EclipseCon Europe.

The Smart Home Day focuses specifically on Eclipse SmartHome-based solutions such as openHAB and QIVICON. It is an awesome opportunity for all community members to meet and exchange ideas.

There will be great talks from core project maintainers, solution providers, and other community members. The agenda has been carefully compiled to addresses developers, tech-savvy users, and other smart home enthusiasts alike.


by Anonymous at October 13, 2018 04:30 PM

Ten reasons to use Eclipse Collections

by Donald Raab at October 12, 2018 02:37 AM

You may only need one.

It’s a sign

Top Ten Reasons to use Eclipse collections

  1. Rich, fluent, and functional APIs with good symmetry (productivity)
  2. Memory Efficiency (performance)
  3. Optimized Eager APIs (performance)
  4. Primitive Collections (productivity & performance)
  5. Immutable Collections (predictability and performance)
  6. Lazy APIs (performance)
  7. Parallel APIs (performance)
  8. Multimaps (productivity and type safety)
  9. Bags (productivity and type safety)
  10. Mutable and Immutable Collection Factories (productivity)

If the collection framework(s) you are using today is (are) missing one or more of these features, and you need them, then it would really be worth your time to check out and try Eclipse Collections.

Additional Reasons to try Eclipse Collections

  1. It’s open source and managed at the Eclipse Foundation and you can contribute to the library if there is something you need
  2. Eclipse Collections 9.0, 9.1 and 9.2 were released with a lot useful features that were contributed by 30 members of the open source community
  3. There are fun code katas to get you started
  4. Easy to understand and refactor to if you already know lambdas/ streams
  5. The Eclipse Collections website is available in seven different languages

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


Ten reasons to use Eclipse Collections 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 October 12, 2018 02:37 AM

Presentation: "Yo... Ask Me Anything" - Panel of NY Senior Java Developers

by Justin Lee, Don Raab, Chandra Guntur, Sai Sharan Donthi, Jeanne Boyarsky at October 11, 2018 03:28 AM

The panelists discuss thoughts on the latest trends in Java, the new release model, modules, modern garbage collectors, Kotlin for the enterprise, Eclipse stewardship of JEE and the rising complexity of the Java source language.

By Justin Lee, Don Raab, Chandra Guntur, Sai Sharan Donthi, Jeanne Boyarsky

by Justin Lee, Don Raab, Chandra Guntur, Sai Sharan Donthi, Jeanne Boyarsky at October 11, 2018 03:28 AM

JBoss Tools and Red Hat Developer Studio for Eclipse 2018-09

by jeffmaury at October 09, 2018 09:17 AM

JBoss Tools 4.9.0 and Red Hat Developer Studio 12.9 for Eclipse 2018-09 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.9 (2018-09) but we recommend using the latest Eclipse 4.9 2018-09 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 Java11, improvements for container based development and bug fixing. Eclipse 2018-09 itself has a lot of new cool stuff but let me highlight just a few updates in both Eclipse 2018-09 and JBoss Tools plugins that I think are worth mentioning.

OpenShift 3

Inner loop for Spring Boot applications

Although Spring Boot applications were already supported by the OpenShift server adapter, the global developer experience has been enhanced. Let’s complete the full workflow.

Bootstrapping your Spring Boot applications

A new generator (wizard) has been added to JBoss Tools. It’s called the Launcher application as it’s based on the fabric8-launcher project. When you launch JBoss Tools, you should see this in Red Hat Central:

spring boot inner loop

Click on the Launcher application link and the following wizard will appear:

spring boot inner loop1

Switch the Mission field to rest-http as we want to generate a simple REST application and switch the Runtime field to spring-boot current-community as we want to generate a Spring Boot based application.

Then set the Project name field to myfirstrestapp and leave other fields as-is.

spring boot inner loop2

Click the Finish button. A new project will be added to your local workspace. It may takes some times as Maven will resolve all the Spring Boot dependencies and thus need to download them from the Internet.

When the project is build and if you expand the myfirstrestapp in the Project explorer window, you should see this:

spring boot inner loop3
Storing your source code on GitHub

As OpenShift builder images retrieves code on a Git repository, we first need to push the just generated application code to GitHub. The following section assumes that you created a repository called myfirstrestapp under your GitHub account.

We will first create a local Git repository for our application code then push it to GitHub.

Select the myfirstrestapp project and right click the Team → Share project…​ menu item:

spring boot inner loop4

Then select the Git repository type and click the Next button:

spring boot inner loop5

Select the Use or create repository in parent folder of project checkbox then select the myfirstrestapp project:

spring boot inner loop6

Click on the Create repository button and the on the Finish button.

The Project explorer view is updated:

spring boot inner loop7

Select the myfirstrestapp project and right click the Team → Show in Repositories View menu item. A new view called Git Repositories will be added to the perspective:

spring boot inner loop8

Inside this view, select the Remotes node and right click the Create Remote…​ menu item. The following dialog will be displayed:

spring boot inner loop9

Click on the OK button, the following dialog will be displayed:

spring boot inner loop10

Click on the Change…​ button and enter git@github.com:GITHUB_USER/myfirstrestapp in the URI field, replacing GITHUB_USER by your real GitHub user name.

Then click the Finish button and then on the Save button.

Pushing code to GitHub

We are now ready to push our application code to GitHub. Select the myfirstrestapp project in the Project explorer view, right click the Team → Commit menu item. A new view call Git Staging will open:

spring boot inner loop11

Double click on the view title to maximize it:

spring boot inner loop12

Select all the files listed in the Unstaged changes list and click the &apos+&apos button. The files will then move to the Staged Changes list:

spring boot inner loop13

Enter a commit message (ex &aposInitial version&apos) and click the Commit and Push…​ button. the following dialog will be displayed:

spring boot inner loop14

Click on the Next button:

spring boot inner loop15

Click on the Finish button to start the push operation.

A dialog with the result of the push operation will be displayed. Click the OK to dismiss it.

Add Spring Boot Devtools to the packaged application

In order to support live update on an OpenShift cluster, we must add Spring Boot DevTools to our Spring Boot application.

Open the pom.xml in the myfirstrestapp. Locate the spring-boot-maven-plugin and add the following section:

            <configuration>
                    <excludeDevtools>false</excludeDevtools>
                  </configuration>

The whole spring-boot-maven-plugin section is given below:

      <plugin>
              <groupId>org.springframework.boot</groupId>
              <artifactId>spring-boot-maven-plugin</artifactId>
              <executions>
                <execution>
                  <goals>
                    <goal>repackage</goal>
                  </goals>
                  <configuration>
                    <excludeDevtools>false</excludeDevtools>
                  </configuration>
                </execution>
              </executions>
            </plugin>

Close and save the pom.xml file.

Push the change to GitHub: select the Team → Commit…​ with a new commit message (ex &aposWith DevTools&apos)

Deploy the application on OpenShift

Before we can deploy the application on OpenShift, we must first create an ImageStream on our OpenShift cluster. The reason is that the Spring Boot support relies on S2I builds that will explode the Spring Boot uber JAR when Spring Boot DevTools is present. As this is not supported by all Java based S2I images, we will use one that supports it, ie fabric8/s2i-java:2.2

First, in the myfirstrestapp project, create a new JSON file called springboot.json and set the content of this file to:

{
          "apiVersion": "image.openshift.io/v1",
          "kind": "ImageStream",
      	"metadata": {
      		"name": "springboot"
      	},
          "spec": {
              "lookupPolicy": {
                  "local": false
              },
              "tags": [
                  {
                      "annotations": {
      					"tags": "builder,java"
      				},
                      "from": {
                          "kind": "DockerImage",
                          "name": "registry.access.redhat.com/fuse7/fuse-java-openshift:1.1"
                      },
                      "importPolicy": {},
                      "name": "1.1",
                      "referencePolicy": {
                          "type": "Source"
                      }
                  }
              ]
          }
      }

Then, from the OpenShift explorer view, select the OpenShift connection for your cluster (if you don’t have one already defined, you must define it), right click on the New → Resource…​ menu item and the following dialog will be displayed:

spring boot inner loop16

You can select the OpenShift project you want to work with and then click on the Browse Workspace…​ button and select the springboot.json file in the myfirstrestapp project:

spring boot inner loop17

Click the OK and Finish buttons. The new ImageStream will be created and a status dialog will be displayed:

spring boot inner loop18
Create the application on OpenShift

We’re now ready to create the application on the OpenShift cluster. Select the OpenShift connection, right click the New → Application…​ menu item. If you scroll down the list, you should see the springboot ImageStream we just created:

spring boot inner loop19

Select this ImageStream and click the Next button:

spring boot inner loop20

Enter `myfirstrestapp in the `Name field, `https://github.com/GITHUB_USER/myfirstrestapp in the Git Repository URL field, replacing GITHUB_USER by your real GitHub user name and click the Next`` button.

On the Deployment Configuration & Scalability dialog, click the `Next button.

On the Service & Routing Settings, select the 8778-tcp port and click the Edit button, change the 8787 value to 8080:

spring boot inner loop21

Click the OK button then the Finish button.

The list of OpenShift resources created will be displayed by a dialog:

spring boot inner loop22

Click the OK button to dismiss it and when asked to import the application code, click the Cancel button as we already have the source code.

After the build is run (this may takes several minutes as the Maven build will download lots of dependencies), you should see a running pod:

spring boot inner loop23
Inner loop setup

We are going to synchronize the local Eclipse project with the remote OpenShift pod. Each time a file will be modified locally, then the pod will be updated accordingly.

Select the running pod in the OpenShift explorer, right click the Server Adapter…​ menu item, the following dialog will be displayed:

spring boot inner loop24

Click the OK button, the initial synchronization will be started and the Servers view will be displayed:

spring boot inner loop25

We’ve not setup the synchronization between our local Eclipse project and the remote OpenShift project. Each modification done locally will be reported on the remote OpenShift cluster.

Let’s modify our local application code and see the changes applied almost instantly:

Edit the file src/main/java/io/openshift/booster/service/Greeting.java in the myfirstrestapp project and change the FORMAT string value from Hello, %s! to Hello, Mr %s! and save the file.

The file should be now:

/*
       * Copyright 2016-2017 Red Hat, Inc, and individual contributors.
       *
       * Licensed under the Apache License, Version 2.0 (the "License");
       * you may not use this file except in compliance with the License.
       * You may obtain a copy of the License at
       *
       * http://www.apache.org/licenses/LICENSE-2.0
       *
       * Unless required by applicable law or agreed to in writing, software
       * distributed under the License is distributed on an "AS IS" BASIS,
       * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       * See the License for the specific language governing permissions and
       * limitations under the License.
       */
      package io.openshift.booster.service;
      
      // tag::snippet-greeting[]
      public class Greeting {
      
          public static final String FORMAT = "Hello, Mr %s!";
      
          private final String content;
      
          public Greeting() {
              this.content = null;
          }
      
          public Greeting(String content) {
              this.content = content;
          }
      
          public String getContent() {
              return content;
          }
      }
      // end::snippet-greeting[]

Then, in the ÒpenShift explorer` view, select the myfirstrestapp deployment and select the `Show In → Web Browser menu item and once the web browser is displayed, ckick the Invoke button, you should see the following view:

spring boot inner loop26

You’ve just experienced the inner loop on your Spring Boot application: any change done locally is reported and testable almost immedialtely on your OpenShift cluster.

You can restart the deployment in debug mode and you’ll be able to remote debug your Spring Boot application. Amazing, no ?

Server tools

Wildfly 14 Server Adapter

A server adapter has been added to work with Wildfly 14. It adds support for Java EE 8.

Hibernate Tools

Runtime Provider Updates

The Hibernate 5.3 runtime provider now incorporates Hibernate Core version 5.3.6.Final and Hibernate Tools version 5.3.6.Final.

The Hibernate 5.2 runtime provider now incorporates Hibernate Core version 5.2.17.Final and Hibernate Tools version 5.2.11.Final.

The Hibernate 5.1 runtime provider now incorporates Hibernate Core version 5.1.16.Final and Hibernate Tools version 5.1.10.Final.

Fuse Tooling

REST Viewer becoming an editor

Previously, there was a REST editor which was read-only. It is useful to have a great overview of already defined Camel REST DSL definitions. Now the editor and its related properties tab are also providing editing capabilities allowing to develop faster.

Fully Editable REST Editor

You can now:

  • Create and delete REST Configurations

  • Create and delete new REST Elements

  • Create and delete new REST Operations

  • Edit properties for a selected REST Element in the Properties view

  • Edit properties for a selected REST Operation in the Properties view

In addition, we’ve improved the look and feel by fixing the scrolling capabilities of the REST Element and REST Operations lists.

Java Developement Tools (JDT)

Java Editor

Improved Breadcrumb for Dark theme

The Breadcrumb in the Java Editor now uses a dark background in the Dark theme.

breadcrumb dark and light

In the Light theme, the Breadcrumb uses a flat look style instead of a gradient.

Quick fix to create abstract methods

The existing quick fix to create missing methods has been improved to create abstract method declarations. The option only appears when the target class is an abstract class.

quickfix create abstract method 1
Quick fix to convert to static import

A new quick fix has been implemented that allows the user to convert static field accesses and static methods to use a static import. It’s also possible to replace all occurrences at the same time.

quickfix convert to static import

Java Code Generation

Improved hashCode() and equals() generation

A new option in the Source > Generate hashCode() and equals()…​ tool allows you to create implementations using the Java 7 Objects.equals and Objects.hash methods.

hashcode equals dialog

The above setup generates the following code:

hashcode equals generation

Additionally, arrays are handled more cleverly. The generation prefers the Arrays.deepHashCode and Arrays.deepEquals methods when dealing with Object[], Serializable[] and Cloneable[] or any type variables extending these types.

Java Views and Dialogs

Quick Fix for JRE Compiler Compliance Problem Marker

A new quick fix is provided on the JRE Compiler Compilance problem marker which is created when the compiler compliance does not match the JRE being used. This quick fix provides the option of opening the Compiler Compliance page of the project to fix the issue.

quickfix open cc page

Selecting this option opens the Compiler Compliance property page for the specified project as shown below.

quickfix cc page
Open Type dialog now always shows the full path

The Open Type dialog now always shows the full path of all the matching items.

open type full path

Java Formatter

Keep simple loops in one line

New formatter settings have been added that make it possible to keep the bodies of simple loops (without braces) in the same line as their headers, similar to previously existing setting for simple &aposif&apos statements. Different kind of loops (&aposfor&apos, &aposwhile&apos, &aposdo while&apos) can be controlled independently.

The settings can be found in the profile editor under New Lines > In control statements > Simple Loops.

formatter compact loops

There’s also a new setting to control how these loops should be handled if they exceed the maximum line width. It’s located under Line Wrapping > Wrapping settings > Statements > Compact loops (&aposfor&apos, &aposwhile&apos, &aposdo while&apos).

formatter compact loops wrap
Align items in columns

A feature previously known as align fields in columns has been expanded and can now be used for variable declarations and assignment statements as well.

An option has also been added to always align with spaces, even if tabs are used for general indentation. This is very similar to the Use spaces to indent wrapped lines option and is useful to make the code look good in editors with differing tab width.

All the settings related to aligning are now in the new preferences subsection: Indentation > Align items in columns.

formatter align in columns

Debug

Timeout for result of step operation

Observing the result of step operations may slow down execution, which may be unusable if the step takes long already. Therefore a timeout (default: 7000 ms) has been introduced after which the observation mechanism is disabled until the end of the step operation.

result timeout 537142

The timeout can be configured in Preferences > Java > Debug > Don’t show if step operation takes longer than (ms).

Option to hide running threads in Debug view

A new option has been introduced in the Debug view to show or hide running threads.

Hiding running threads can be useful when debugging heavily multithreaded application, when it is difficult to find threads stopped at breakpoints among hundreds or thousands of running threads.

hide running threads
Show Command Line button in Launch Configuration

A new button Show Command Line has been added in the Java Launch Configuration dialog.

show command line

Clicking the button will open a dialog to show the command line used for launching the application.

show command line detail
Option to disable thread name changes in Debug View

Thread name changes in the debuggee JVM are reflected in the Debug View. A VM option can now be used to disable this behavior, in case the JVM communication necessary for the name updates is not desired.

The functionality can be disabled by specifying the following VM option

-Dorg.eclipse.jdt.internal.debug.core.model.ThreadNameChangeListener.disable=true
Support for long classpath/modulepath

Classpath and/or modulepath are now shortened if they are longer than current operating system limits.

If a temporary jar is needed to shorten the classpath (Java 8 and previous versions), a dialog is shown asking for confirmation.

enable classpathonly dialog

The option Use temporary jar to specify classpath (to avoid classpath length limitations) is available in the Classpath tab of the Run/Debug Configuration dialog.

enable classpathonly option

And more…​

You can find more noteworthy updates in on this page.

What is next?

Having JBoss Tools 4.9.0 and Red Hat Developer Studio 12.9 out we are already working on the next release for Eclipse 2018-12.

Enjoy!

Jeff Maury


by jeffmaury at October 09, 2018 09:17 AM

EclipseSource Oomph Profile – updated to 2018-09

by Jonas Helming and Maximilian Koegel at October 09, 2018 08:10 AM

In September, Eclipse 2018-09 has been released, a new version of the Eclipse IDE and platform. It contains many useful improvements, so it is worth to update. It is the first release following the new release cycle with four equal releases per year. One of many noteworthy extensions is the new minimap view, which provides a complete overview of opened documents. It allows to browser files more efficiently and due to showing the selection, also identifying occurrences of certain expressions, e.g. usages of fields.

EclipseSource Oomph Profile - updated to 2018-09

Further general improvements of the Eclipse 2018-09 IDE are summarized in the following video, Git and Platform improvements in a separate video below.  Both are provided by Holger Voormann, whom we want to thank you once again 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 2018-09!


by Jonas Helming and Maximilian Koegel at October 09, 2018 08:10 AM

Welcome Jameka

by Thabang Mashologu at October 05, 2018 06:29 PM

I am thrilled to announce that Jameka Woodberry has joined the Eclipse Foundation as a Marketing Specialist based in Europe.

Jameka comes to us from SAP, where she managed marketing programs for the EMEA region. Jameka has an MA in Business Psychology and an MBA in International Business with a focus on Marketing and Communications. Her wonderful personality and ample experience will be great assets to the Eclipse community.

Jameka is originally from California and is currently based in Wiesloch, Germany.  

Please join me in welcoming Jameka to the Eclipse Foundation marketing team.


by Thabang Mashologu at October 05, 2018 06:29 PM

Jakarta EE @EclipseFdn: Getting it done

by waynebeaton at October 03, 2018 06:31 PM

To say that bringing Jakarta EE to life at the Eclipse Foundation was a massive undertaking is a gross understatement.

We started this effort in early 2018. Today, we have 39 open source projects (as part of the EE4J Top Level Project) representing 14% of our overall project space. These projects collectively have 99 Git repositories (most of which are hosted in the eclipse-ee4j GitHub organization; a small number are hosted on Eclipse Foundation infrastructure) representing 8% of the repositories created and managed by the Eclipse Foundation’s IT team. We have 162 committers working on these projects, representing 10% of our total active committer community. These projects have made a combined 440 requests to the Eclipse Foundation’s IP Team to review intellectual property, representing 17% of the work done by the team. The Jakarta EE projects have 53 distinct CI instances running (or in the planning stages to run) on Eclipse Foundation build infrastructure, representing 30% of our work there (on the topic of build, if you have some spare cycles and want to contribute, we can use your help).

Added to the all of the project-related work, we’ve also been doing a lot of other work to  stand up the new Jakarta EE Working Group, bootstrap the new EE4J PMC, manage related trademarks and various legal agreements, recruit participants, build websites, improve infrastructure, hire and train new staff, and more.

By way of comparison, the work that we do with Eclipse IoT is at about the same scale, but grew more organically (one open source project at a time) over six years. Jakarta EE happened all at once.

While we engaged in this enormous chunk of work, we still did everything that we’ve always done. In just the first nine months of 2018, for example, the Eclipse Intellectual Property Team has already received and processed 30% more requests for reviews than they did in all of 2017! And the number of new project proposals, committers, and contributions (not including those that are related to Jakarta EE) that we’ve added in 2018 are on an upward trend compared with past years.

This has been an all-hands-on-deck sort of effort for the Eclipse Foundation staff. Even those of us who have not been directly involved in the work, have helped by taking on extra burdens so that those of use who were directly involved could stay focused.

This is not to say that we’ve done this alone: this has been a ginormous shared effort. We’ve had a lot of help from the Eclipse Foundation member companies that have contributed many talented people to the migration effort, and—of course—the members of our community who have stepped up.

I really want to name names, but the probability of me missing somebody is so high that I dare not. If you want to meet some of the key players, join us at EclipseCon Europe!

Home


by waynebeaton at October 03, 2018 06:31 PM

My first 100 days at the Eclipse Foundation

by Tanja Obradovic at October 03, 2018 01:22 PM

I made it to my first 100 days at the Eclipse Foundation! New beginnings are always exciting. It has been a blast and a challenge at the same time. Many twists and turns, but steady progress nevertheless for both Jakarta EE and me!

My experience at the Eclipse Foundation started with EclipseCon France 2018 in the amazing Toulouse. Clearly, I was always a strong believer in open source as a movement, but meeting people from different companies, and witnessing their enthusiasm in person is something different. As the Eclipse Foundation hosts over 350 different open source projects, the conference attracted not only technology developers, but different industries using them as well. Their presence and interest demonstrated the importance of open source in software development. Jakarta EE, naturally, was one of the highlights of the conference, clearly indicating huge interest of the community in evolving Java EE technology and making it ready for cloud-native Java application development.

At the time, mid-June 2018, it was still very early days for us both. So early that it was hard to contemplate the concrete first steps for Jakarta EE. We hadn’t yet completed migrating the necessary Java EE contributions from Oracle to the Eclipse Foundation, and still struggling with all the legal aspects required in the process. We had initial conversations on the new Specification Process that will fill the role of the Java Community Process, and started looking into the new world with open source TCKs and requirements for the Jakarta EE implementations. And for me, getting familiar with the working group members and its committees, the community members, the existing Eclipse Foundation processes already in use, the processes that need to be defined, and figuring out what to focus on first was a challenge for sure!

Jumping to the fall, not everything is ready, but steady progress has been made. The majority of the Java EE code, including TCKs and GlassFish, found a new home at the Eclipse Foundation. New processes are being developed and the first drafts are ready for internal review. Name spaces are being discussed and even some specifications are being suggested as possible first components under the Jakarta EE specification umbrella. And yes, another Eclipse Foundation conference is just around the corner. EclipseCon Europe 2018 is being actively planned. If you haven’t already, please register! Jakarta EE and MicroProfile Community Day is taking shape and we need your presence and participation.

I am looking forward to finding out what the next 100 days will bring!


by Tanja Obradovic at October 03, 2018 01:22 PM

Eclipse Vert.x 3.5.4

by vietj at October 03, 2018 12:00 AM

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

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

Three CVE have also been reported and fixed in this release:

Vert.x 3.5.4 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 October 03, 2018 12:00 AM

Thorntail - A Micro implementation of Eclipse MicroProfile

by Anonymous at October 02, 2018 02:38 PM

by Ken Finnigan

In this article we introduce some of the topics Michal Szynkiewicz, from the Thorntail team, will be presenting during his EclipseCon session Thorntail - A Micro Implementation of Eclipse MicroProfile. Be sure to come by his session to learn all the details on Eclipse MicroProfile and how to use it in Thorntail!


by Anonymous at October 02, 2018 02:38 PM

Case Study: How Bosch Is Succeeding with Open Source at Eclipse IoT

October 02, 2018 02:00 PM

How is it that a 150-year-old, 400,000 employee industrial conglomerate is competing and winning in the rapidly involving IoT software industry?

October 02, 2018 02:00 PM

Case Study: How Bosch Is Succeeding with Open Source at Eclipse IoT

by Mike Milinkovich at October 02, 2018 12:04 PM

How is it that a 150-year-old, 400,000 employee industrial conglomerate is competing and winning in the rapidly involving IoT software industry? We’ve just published a case study in which Bosch shares how open collaboration at the Eclipse Foundation factors into that success. This case study is required reading for any organization considering pursuing an open source strategy.

This case study is yet another proof point that open source has won. No single company can deliver innovation at the pace and scale of open source. For industrial companies in particular, broadly adopted open technologies and standards are critical for success in the digital economy. It’s a case of disrupt or be disrupted — and open source holds the key for rapid and sustainable innovation in the digital age. The team at Bosch recognized all of this several years ago. When the time came for creating an IoT platform for themselves and their customers, Bosch chose open source to compete with proprietary vendors.

At the Eclipse Foundation, Bosch is successfully executing a long-term strategy to create a widely adopted open source platform for IoT. Having previously been a long-term Solutions member of the Eclipse Foundation, Bosch increased its membership level in the Eclipse Foundation to become a Strategic member and joined the Eclipse IoT Working Group in 2015. Beyond IoT, Bosch is an active participant in the Eclipse Foundation’s Automotive Industry community.

Some of the highlights from the case study (html) (pdf):

  • Bosch’s leadership in the Eclipse IoT community has helped position the company as a leader in the IoT industry.
  • Bosch has created six different IoT open source projects since joining the Eclipse IoT community. In addition, Bosch contributes to many other Eclipse IoT projects.
  • Bosch has contributed around 1.5 million lines of code to Eclipse projects. At present, over 60 Bosch developers work on Eclipse IoT projects.
  • Many of the Bosch IoT Suite commercial products are now based on Eclipse IoT projects. The open development process used by the Eclipse projects has been adopted by Bosch Software Innovations’ product development teams. The open source development model helps Bosch provide more transparency for their customers, and aids in recruiting new developers keen to work on open source.
  • The Eclipse Foundation’s clear, vendor-neutral rules for intellectual property sharing and decision-making make it easy to collaborate with other organizations on driving rapid innovation. The Foundation’s legal processes provide Bosch with the legal assurance that they can successfully embed open source technology into their commercial products.

We are thrilled that Bosch is seeing the benefits of their open source strategy and participation in the Eclipse community. Thanks to the contributions of Bosch engineers and many other developers within the Eclipse community, all can benefit from runtimes and frameworks creating a open, vendor-neutral platform for IoT.

To learn more about the Eclipse IoT community, head over to the Eclipse IoT Working Group website.


by Mike Milinkovich at October 02, 2018 12:04 PM

Eclipse CBI - Common Build Infrastructure changes

September 28, 2018 08:00 PM

The Eclipse CBI, which traces its roots back to 2006, has undergone some important changes recently, including a new Kubernetes+Docker-powered environment at https://jenkins.eclipse.org that re announced previously.

September 28, 2018 08:00 PM

Eclipse CBI - Common Build Infrastructure changes

by Denis Roy at September 28, 2018 06:56 PM

The Eclipse CBI, which traces its roots back to 2006, has undergone some important changes recently, including a new Kubernetes+Docker-powered environment at https://jenkins.eclipse.org that we announced previously.

Like all the Foundation's services, CBI does not operate at zero-cost, and its immense success over the years has given us many a headache in balancing operating cost vs. the great value it provides to our projects.

We've now defined the CBI offering in more clear terms; notably, the resources and support levels that projects can expect to receive. For 90% of our projects, these resources are sufficient and for them, nothing changes.

We are aware that one-size-does-not-fit-all, and some projects just need more. Additional resources are therefore available to projects that are backed by a Member company.

The CBI page at https://wiki.eclipse.org/CBI has all the info on CBI, JIPP and all the services that are included, as well as the available resources and service levels we're offering.

We hope Eclipse projects continue to receive great value from Eclipse CBI, and we continue to work hard on providing a service that meets the growing needs of our projects.


by Denis Roy at September 28, 2018 06:56 PM

Jakarta EE Status – September 2018 Update

by Mike Milinkovich at September 27, 2018 09:21 PM

Migrating Java EE to the Eclipse Foundation and Jakarta EE is a process not an event. In the past couple of weeks however, several very important milestones have occurred that deserve to be recognized.

  • 100% of Glassfish and related Java EE reference implementation components from Oracle have now been contributed, and published to GitHub repositories of the EE4J organization. For those of us at the Eclipse Foundation, part of the reason why this is so huge is that to a large degree, we’ve completed our part. The repos (99) have been provisioned, the committers (162) have been given access, and the initial intellectual property reviews (404) have been done. From this point on, progress on the projects is now largely under the control of the projects themselves.

ee4j_status

  • Builds for the EE4J projects are now running on Eclipse Foundation infrastructure based on our Jenkins-based Common Build Infrastructure.
  • The Java EE TCKs have been contributed and are now available in open source. The importance of this cannot be understated, as my colleague Tanja Obradović points out in her blog.
  • The Eclipse Foundation has signed the Oracle Java EE TCK agreement, which is going to allow us to ship Eclipse Glassfish certified as Java EE 8 compatible. This has also required us to create a testing infrastructure at the Eclipse Foundation, and allowed the EE4J projects to begin testing against the Java EE 8 TCKs.
  • IBM, Oracle, Payara, Red Hat, and Tomitribe have all committed to three years of funding for Jakarta EE ranging from $25K to $300K per year. This funding will allow us to create a dedicated team and fund marketing activities for the Jakarta EE Working Group.

This migration has been an enormous effort, and we certainly have a ways to go yet. But it’s always fun to celebrate some victories along the way.

If you are interested in learning more about Jakarta EE and the future of cloud native Java, please join us at EclipseCon Europe in Germany in October. There is a wealth of Jakarta EE and MicroProfile content. In particular, I hope to see you at the talk that I am doing with Wayne Beaton about the new specification process. Oh, and there’s also this other conference happening in San Francisco at the same time….

 


by Mike Milinkovich at September 27, 2018 09:21 PM

Java EE TCK is now open sourced at Eclipse Foundation

by Tanja Obradovic at September 27, 2018 08:37 PM

A major milestone was achieved this September 2018! The Jakarta EE TCKs are here and finally open sourced! It was long wished for and waited on by many. But what exactly does that mean?

Transparency: Vendors, customers, and the community, in general, can see what passing the tests really means (i.e. they can see the actual tests that are performed and gain better insight into the value of the process). Transparency, of course, extends to development. As new TCKs are developed, the community can monitor, influence, and engage in the process. Transparency is the gateway to openness, improved process quality, and — ultimately — better products.

Openness: Access by a broader community means that there is a greater pool of potential contributors than had existed before. A big part of openness is “leveling the playing field”, with influence and control being determined by a robust governance model and processes. This framework supports open collaboration on new ideas and opportunities, increasing the value of the work. This also means a shared burden.

Shared burden: By opening up the process to new ideas and contributors, we reduce dependency on any single organization or group, and have the potential to spread responsibility for building and maintaining the TCKs.

Vendor neutrality: Reducing dependency on any single organization or group provides us with insurance that the work can progress if that single entity reduces their investment.

The community is already collaborating on driving the TCKs forward. In the first two weeks since the TCKs were moved to the Foundation’s Git repositories, we had 18 commits from four committers from two different companies. This is another step in making the Jakarta EE brand, the future direction of enterprise Java™ technologies and inviting the community to be a part of it.


by Tanja Obradovic at September 27, 2018 08:37 PM

Eclipse Foundation and Cloud Native Computing Foundation Collaborate to Grow Kubernetes Use Cases in Trillion Dollar IoT Market

September 27, 2018 02:00 PM

Red Hat and other Eclipse IoT members will collaborate in working group to extend capabilities of Kubernetes for IoT Edge use cases.

September 27, 2018 02:00 PM