Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Foundation’ Category

Introducing the EE.next Working Group

with 4 comments

As part of our continuing adventures in migrating Java EE to the Eclipse Foundation I am pleased to announce that the draft of the EE.next Working Group charter  has now been posted for community review. Comments and feedback are welcomed on the ee4j-community@eclipse.org mail list. But please please pretty please make sure you read the FAQ (also copied below) before you do.

You can think of this EE.next group as the replacement for the Java Community Process for Java EE. It will be the body that the ecosystem can join and participate in at a corporate level. Individuals can also join if they are committers on EE4J projects. EE.next will also be the place where the new specification process will be created and managed, and where specs will be reviewed and approved.

Under the process for establishing Eclipse Foundation working groups, there will now be a community review period lasting a minimum of 30 days.

 

FAQ

What is the purpose of a working group?

An Eclipse Foundation working group is a special-purpose consortia of Eclipse Members interested in supporting a technology domain. They are intended to complement the activities of a collection of Eclipse Foundation open source projects. Open source projects are excellent for many things, but they typically do not do a great job with activities such as marketing, branding, specification and compliance processes, and the like.

What is the role of the PMC versus the working group or the working group Steering Committee?

Eclipse Foundation projects are self-governing meritocracies that set their own technical agendas and plans. The Project Management Committee for an Eclipse top-level project oversees the day-to-day activities of its projects through activities such as reviewing and approving plans, accepting new projects, approving releases, managing committer elections, and the like.

Working groups and their steering committees are intended to complement the work happening in the open source projects with activities that lead to greater adoption, market presence, and momentum. Specifically the role of the working group is to foster the creation and growth of the ecosystem that surrounds the projects.

Working groups do not direct the activities of the projects or their PMC. They are intended to be peer organizations that work in close collaboration with one another.

Who defines and manages technical direction?

The projects manage their technical direction. The PMC may elect to coordinate the activities of multiple projects to facilitate the release of software platforms, for example.

Because the creation of roadmaps and long term release plans can require market analysis, requirements gathering, and resource commitments from member companies, the working group may sponsor complementary activities to generate these plans. However, ultimately it is up to the projects to agree to implement these plans or roadmaps. The best way for a working group to influence the direction of the open source projects is to ensure that they have adequate resources. This can take the form of developer contributions, or under the Member Funded Initiatives programs, working groups can pool funds to contract developers to implement the features they desire.

Why are there so many levels of membership?

Because the Java EE ecosystem is a big place, and we want to ensure that there are roles for all of the players in it. We see the roles of the various member classes to roughly align as follows:

  • Strategic members are the vendors that deliver Java EE implementations. As such they are typically putting in the largest number of contributors, and are leading many of the projects.
  • Influencer members are the large enterprises that rely upon Java EE today for their mission critical application infrastructure, and who are looking to EE.next to deliver the next generation of cloud native Java. They have made strategic investments in this technology, have a massive skills investment in their developers, and want to protect these investments as well as influence the future of this technology.
  • Participant members are the companies that offer complementary products and services within the Java EE ecosystem. Examples include ISVs which build products on Java EE, or system integrators that use these technologies in delivering solutions to their customers.
  • Committer members are comprised of the committers working on the various EE4J projects who are also members of the Eclipse Foundation. While the Eclipse bylaws define the criteria for committers to be considered members, in essence any committer members are either a) a committer who is an employee of an EE.next member company or b) any other committer who has explicitly chosen to join as a member. Giving Committer members a role in the working group governance process mimics the governance structure of the Eclipse Foundation itself, where giving committers an explicit voice has been invaluable.

What makes this different from the Java Community Process (JCP)?

The EE.next working group will be the successor organization to the JCP for the family of technologies formerly known as Java EE. It has several features that make it a worthy successor to the JCP:

  1. It is vendor neutral. The JCP was owned and operated first by Sun and later by Oracle. EE.next is designed to be inclusive and diverse, with no organization having any special roles or rights.
  2. It has open intellectual property flows. At the JCP, all IP flowed to the Spec Lead, which was typically Oracle. We are still working out the exact details, but the IP rights with EE.next and EE4J will certainly not be controlled by any for-profit entity.
  3. It is more agile. This is an opportunity to define a 21st century workflow for creating rapidly evolving Java-based technologies. We will be merging the best practices from open source with what we have learned from over 15 years of JCP experience.

Is the WG steering committee roughly equivalent to the JCP Executive Committee?

No, not really. The JCP EC always had two mixed roles: as a technical body overseeing the specification process, and as an ecosystem governance body promoting Java ME, SE, and EE. In EE.next the Steering Committee will be the overall ecosystem governance body. The EE.next Specification Committee will focus solely on the development and smooth operation of the technical specification process.

Does a project have to be approved as a spec before it can start?

That is actually a decision which will be made by the EE4J PMC, not the working group. However, it is a goal of the people and organizations working on creating this working group that the Java EE community move to more of a code-first culture. We anticipate and hope that the EE4J PMC will embrace the incubation of technologies under its banner. Once a technology has been successfully implemented and adopted by at least some in the industry, it can then propose that a specification be created for it.

In addition to the Steering Committee, what other committees exist?

There are four committees comprising the EE.next governance structure – the Steering Committee, the Specification Committee, the Marketing and Brand Committee, and the Enterprise Requirements Committee. A summary of the make-up of each of the committees is in the table below.

Strategic Member Influencer Member Participant Member Committer Member
Member of the Steering Committee Appointed Elected Elected Elected
Member of the Specification Committee Appointed Elected Elected Elected
Member of the Marketing Committee Appointed Elected Elected Elected
Member of the Enterprise Requirements Committee Appointed Appointed N/A N/A
Advertisements

Written by Mike Milinkovich

February 5, 2018 at 2:43 pm

Posted in Foundation

EE4J: Current Status and What’s Next

with 5 comments

There is a lot going on as Java EE continues its migration to the Eclipse Foundation. Since there are so many parallel threads, I thought it would be a good idea to recap where we are, and what is coming up in the next few weeks.

First off, we are continuing to work on arriving at a new brand name. Last week the PMC provided the Eclipse Foundation with a potential list of names, and we are running trademark reviews to see if we believe that they can be properly secured. Obviously, we need to have a high degree of confidence that we can freely use the name around the world if we are going to use it to replace some as well known as Java EE. Once we have a short list of potentials we will be starting a community vote to help arrive at a final choice.

Secondly, the code is moving from the existing Oracle-led Java EE organization on GitHub into EE4J. The first nine projects which were proposed have all been created and provisioned, and the code is being moved into them as we speak. The next step on this front will be to propose the next round of projects to move next. As I understand it, the Oracle team will be proposing the JSON-B API and JavaMail projects next. Soon after will come JAX-B, JAX-WS, JSTL, UEL, JAF, Security, JTA, Enterprise Management, Concurrency, and Common Annotations. Everyone involved strongly believes that a key factor in the success of this entire migration is the rapid creation of a diverse and engaged open source community around this code, so we are moving as rapidly as possible to get these projects up and running.

We want to demonstrate to the world that these projects are capable of shipping. Therefore the short-term objective is to have the EE4J project ship a Java EE 8-compliant release as quickly as possible: i.e. a Java EE 8 certified release of Eclipse Glassfish and related projects. There are a couple of positive reasons for doing this:

  1. It demonstrates that the EE4J projects are fully functional as open source projects, and that they and the PMC can run through the full process of a release under the auspices of the Eclipse Foundation and the Eclipse Development Process.
  2. It gets downloadable code that users and adopters can access and run from EE4J as quickly as possible. Creating an ecosystem of developers and companies using this code is important, and the sooner we start the better.

A comment on the API projects that are moving over: several have asked on the mailing lists if the fact that the source has moved means that we can start changing the APIs directly in the EE4J projects. The short answer is “please, not quite yet”. There are several reasons for that:

  1. We want to focus in the short term on shipping an EE 8 compliant release. So the fewer moving parts while we’re doing that, the better.
  2. There is going to be a new spec process that is going to be managing the evolution of these APIs in the future, and it hasn’t been set up yet.
  3. As has been discussed in several venues, this new spec process is going to be bootstrapped with some rules around the continued use of the javax namespace. We’re still working on what those rules are.

In the meantime if you really want to start prototyping some new APIs you are always free to fork the repos on GitHub.

Finally, we are working on establishing an Eclipse Foundation working group to provide a member-driven governance model for the EE4J community. Working groups are consortia which complement the Eclipse open source projects. Community-driven open source projects are great for a lot of things, but don’t do well with business and ecosystem topics such as marketing, developer outreach, branding, specifications, compliance programs, and the like. The first step in creating a working group is to write its core governance charter. We hope to have a draft of that available for review by the end of the month as well. My next blog post will provide some additional information and background on that topic.

Written by Mike Milinkovich

January 23, 2018 at 12:48 pm

Posted in Foundation

Eclipse Community Directions for 2018

leave a comment »

As 2018 begins I would like to share a few thoughts on where I think the Eclipse community is heading.  I am looking forward to an incredibly busy year for myself, the staff of the Eclipse Foundation, and our community, because this is going to be a year of tremendous growth and opportunity. I will try to give a brief overview of what I see as some of the exciting things that are going on at the Eclipse Foundation. I am sure that I will miss some, so apologies in advance!

Of course the big news of the past few months was the announcement by Oracle that Java EE is going to be moving to the Eclipse Foundation. This represents the largest single contribution to the Eclipse community since — well, the original Eclipse IDE project in 2001. It is approximately 35 new projects, hundreds of new committers and contributors, and millions of lines of code. It is and was an incredible endorsement of the Eclipse Foundation’s mission as the leading organization for individuals and companies to collaborate on commercial-friendly open source software. Since the announcement in September, we have created the new Eclipse Enterprise for Java (EE4J) top-level project, and source code is starting to move into the projects. During 2018 our collective mission will be to create a functioning and successful community around this code, pick a new brand to replace Java EE going forward, ship a release compatible with Java EE 8, open source the Java EE TCKs, and establish a new specification process to shape the future of cloud native Java. I feel out of breath just thinking of it.

But in addition to this Java EE work, it is clear that the Eclipse Foundation is now playing a pivotal role in the future of the Java ecosystem. Projects such as Eclipse MicroProfile (microservices for Java), Eclipse OpenJ9 (Java virtual machine), Eclipse DeepLearning4J (machine learning), Eclipse Collections (highly scalable collections), Eclipse JNoSQL (NoSQL for Java EE) and Eclipse Vert.x (reactive apps for Java) are leading the next generation of Java innovation.

From the Eclipse Science community comes Eclipse XACC, which I believe is the world’s first community-led open source project in the new field of quantum computing. Originating from Oak Ridge National Laboratory, XACC is working to integrate quantum processors with the high-performance computing environments that are the backbone of modern scientific computing. It will be exciting to see XACC ship its first release in 2018, and to support its desire to create an open collaboration to shape the next generation of computing hardware and programming paradigms.

The Eclipse IoT community has been a significant growth area within the Eclipse community over the past couple of years. In 2017 Eclipse IoT grew to over 25 projects, and is attracting a substantial developer and corporate community.. It is also a terrifically ambitious group, with a vision of providing technology stacks that span the smallest of constrained devices, through device gateways, to cloud-scale data collection and management runtimes. Late in 2017 the group published a white paper on the role that open source will play in Industry 4.0, or industrial IoT. This white paper is important because in many ways it sets out the vision for the group, which has been primarily focused on industrial IoT. In 2018 the primary goal for Eclipse IoT is to start shipping these stacks rather than simply projects. In other words, to create cross-project collaborations that provide IoT adopters with more complete solutions rather than individual building blocks. This will go a long way to paving the way for broad industry adoption of these open source IoT technologies.

Finally, a word on developer tools — the Eclipse Foundation’s original franchise. I noticed recently that according to at least one source, the Eclipse IDE is maintaining its position as the #1 IDE in the world, and grew its market share substantially last year. The goal for this year is to continue this trend. In addition, the Eclipse Che cloud IDE continues to grow its community and adoption. As more and more developers work on cloud native applications, the appeal of a cloud IDE that works where they do is going to grow. Che is well positioned to be the leader in this space and is the only community-led cloud IDE.

Anyone who has seen me speak over the past couple of years has likely heard me express the idea that the “community is the capacity.” The Eclipse Foundation is a 30 person organization that supports a community of hundred of projects, hundreds of members, thousands of committers and contributors, and millions of users. Whenever I take a moment to reflect on what we accomplish together it is breathtaking. The breadth of the technology that we collectively produce is vast, and our community spans the globe. Equally exciting, engagement continues to grow with a variety of industries notably automotive, power, transportation, etc. interested in leveraging the Eclipse Foundation as the place for open, commercial collaboration.

I am incredibly optimistic that 2018 is going to be one of the most exciting years we’ve ever had, so please get involved!

Written by Mike Milinkovich

January 22, 2018 at 8:01 am

Posted in Foundation

EE4J Code Arrives

Last week the EE4J project achieved an important milestone when the source code for the API and reference implementation of JSON-P JSR-374 project was pushed by Dmitry Kornilov into its GitHub repository in the EE4J organization. This is the first project of the initial nine proposed to reach this stage.

This may seem like a small step in a very large process, but it is a concrete demonstration of the commitment to move forward with the migration of Java EE to the Eclipse Foundation. The Oracle team and the Eclipse Foundation staff had a ton of work to do to make this possible. This is definitely one of those cases where the visible code contributions are just the visible tip of an iceberg’s worth of effort.

Here are just a few examples of the work that went on to get to this stage:

  • The names of the projects such as Glassfish represent important trademarks in the industry. Oracle transferred ownership of these project names to the Eclipse Foundation so that they can be held and protected for the community.
  • The EMO staff reviewed the projects proposals, ran the project creation review, provisioned the repositories and set up the committer lists.
  • The Oracle team packaged up the source code and updated the file headers to reflect the new EPL-2.0 licensing.
  • The EMO IP staff scanned the code and ensured that all was well before approving it for initial check-in.

Now that the collective team has run through this process with JSON-P we will be working to get the remaining eight initial projects pushed out as quickly as possible. Hopefully by the end of this month. Meanwhile, more projects will be proposed and we will be migrating a steady stream of Java EE projects into EE4J.

Exciting times!

Written by Mike Milinkovich

January 15, 2018 at 11:51 am

EE4J Progress: Nine New Projects Proposed at the Eclipse Foundation

I am very pleased to announce that the first nine project proposals for the Eclipse Enterprise for Java (EE4J) top-level project have been formally published for community review. This is the first step to making the migration of Java EE to the Eclipse Foundation a reality.

The process of migrating the EclipseLink (JPA) and Eclipse Yasson (JSON-B) projects to EE4J is also underway.

We look forward to feedback from the community on these proposals!

EE4J Project Proposals

Name: Eclipse Grizzly
Top-Level Project: EE4J
Stage: Community Review
Project Link: https://projects.eclipse.org/proposals/eclipse-grizzly

Description: Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Eclipse Grizzly NIO framework has been designed to help developers to take advantage of the Java™ NIO API.

Name: Eclipse OpenMQ
Top-Level Project: EE4J
Stage: Community Review
Project Link: https://projects.eclipse.org/proposals/eclipse-openmq

Description: Eclipse Open Message Queue (OpenMQ) is a complete message-oriented middleware platform, offering high quality, enterprise-ready messaging.

OpenMQ is included in GlassFish.

Name: Eclipse Mojarra
Top-Level Project: EE4J
Stage: Community Review
Project Link:  https://projects.eclipse.org/proposals/eclipse-mojarra

Description: Eclipse Mojarra is the Reference Implementation for the JavaServer Faces specification (JSR-372). JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications. It is also a MVC web framework that simplifies construction of user interfaces (UI) for server-based applications by using reusable UI components in a page.

Mojarra is included in GlassFish.

Name: Eclipse Message Service API for Java (JSR-914)
Top-Level Project: EE4J
Stage:  Community Review
Project Link: https://projects.eclipse.org/proposals/eclipse-message-service-api-java

Description: JSR- 914: The Java Message Service (JMS) API is a Java Message Oriented Middleware API for sending messages between two or more clients. It is an implementation to handle the Producer-consumer problem.

Name: Eclipse Tyrus
Top-Level Project: EE4J
Stage: Community Review
Project Link: https://projects.eclipse.org/proposals/eclipse-tyrus

Description: Eclipse Tyrus provides a reference implementation for Java API for WebSocket, starting from the specification defined by JSR-356.

Name: Eclipse Java API for RESTful Web Services (JAX-RS)
Top-Level Project: EE4J
Stage: Community Review
Project Link: https://projects.eclipse.org/proposals/eclipse-restful-web-services-api-java

Description: JAX-RS: Java API for RESTful Web Services (JAX-RS) is a Java programming language API spec that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern.

Name: Eclipse Jersey
Top-Level Project: EE4J
Stage: Community Review
Project Link:https://projects.eclipse.org/proposals/eclipse-jersey

Description: Eclipse Jersey is a REST framework that provides JAX-RS (JSR-339) Reference Implementation and more. Jersey provides its own APIs that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development. Jersey also exposes numerous extension SPIs so that developers may extend Jersey to best suit their needs.

Name: Eclipse WebSocket API for Java (JSR-356)
Top-Level Project: EE4J
Stage: Community Review
Project Link: https://projects.eclipse.org/proposals/eclipse-websocket-api-java

Description: Java API for WebSocket (JSR-356), specifies the API that Java developers can use when they want to integrate WebSockets into their applications – both on the server side as well as on the Java client side.

Name: Eclipse JSON Processing
Top-Level Project: EE4J
Stage: Community Review
Project Link: https://projects.eclipse.org/proposals/eclipse-json-processing

Description: Eclipse JSON Processing (JSON-P) is a Java API to process (e.g. parse, generate, transform and query) JSON documents. It produces and consumes JSON in a streaming fashion (similar to StAX API for XML) and allows to build a Java object model for JSON using API classes (similar to DOM API for XML).

 

 

Written by Mike Milinkovich

November 21, 2017 at 11:31 am

Posted in Foundation

Help Pick the New Name for Java EE

This blog post is based on the text of Eclipse EE4J’s very first GitHub Issue. Please join the conversation over there!

We need a new brand name for the set of specifications that will be created by the new community process. This brand name will also become a certification mark in the industry for compatible, independent implementations. The open source projects that fall under the Eclipse EE4J top level project will be one such implementation. In short, we need a new name to replace “Java EE”. Much like the OpenJDK project implements the Java SE Platform specification, the EE4J projects will provide implementations of a set of specifications that we today call Java EE: we need a brand name for this set of specifications.

With this in mind, we are initiating a community process to select the brand name. This process will be managed by the EE4J Project Management Committee (“PMC”) with assistance from the Eclipse Management Organization (“EMO”). The name that is selected by this process must pass legal and other trademark searches to ensure that the names are available for use. As a result, it is possible that the favoured selection will not be the ultimate choice. The final decision will be made by the EMO Executive Director (“EMO(ED)”) in consultation with the PMC.

The process is described in greater detail below.

Nominations

Names can be nominated by anyone in the community via this GitHub Issue record.

Nominations will be open from November 15 until November 30, 2018.

Naming Guidelines

All suggested names must conform to the following:

Any suggested names which fail to meet the above criteria will be rejected.

Name Selection Process

The process will be executed as follows:

  1. Members of the community will be invited to enter their nominations into the specified channel;
  2. At the end of the nomination period, the names suggested by the community will be reviewed by the PMC to identify those which meet the criteria specified in the by the naming guidelines (depending on response, the PMC may decide to further reduce the list to a manageable size);
  3. The PMC will then initiate a community vote using the CIVS system (which will produce an overall ranking of the choices); and
  4. The results of the vote will be delivered to the EMO(ED) who will engage in the required legal and other trademark searches to ensure that the names are available for use, and consult with the PMC to make the final decision.

Since we have no idea what sort of community response to expect, it is difficult to time box anything other than the initial nomination process. But this will be an open and transparent process, and we invite the community to engage in all aspects of it. There is a great deal of legal, marketing, and community thought that goes into selecting an industry brand, so it’s important that we get this right. This may take a little time.

Written by Mike Milinkovich

November 15, 2017 at 11:29 am

Posted in Foundation

On Naming, or Why EE4J Does Not Suck

“You keep using that word. I do not think it means what you think it means.” — Inigo Montoya, The Princess Bride, on Vizzini’s use of the word “inconceivable”.

On Thursday we announced that the draft top-level project charter for Eclipse Enterprise for Java (EE4J) was available for community feedback. Since that time, we haven’t received any feedback on the charter, but we have certainly had a lot of passionate feedback on the choice of name. If I could, I would summarize the bulk of the feedback that we’ve seen as “…EE4J is a pretty good acronym, but WTF is Eclipse doing in the name?” A lot of that feedback is based on some incorrect assumptions about what the EE4J name means. Which is totally my fault, because my initial blog post did not provide any context for how EE4J will be used, and not used, as a name and a brand. Hopefully this post will correct that.

Before I begin, I have to mention that a very large caveat on everything that follows. This post is based on my best guess on how things are going to work out, with the information I have at this moment. However, there are a significant number of agreements that have to be discussed regarding names, trademarks, and so on that have not yet been completed. It is possible that the future will not unfold as I think it will. So with that said….

EE4J is not the brand

I think that many people are assuming that EE4J will become the brand that replaces Java EE. Wrong. Java EE is a certification mark. To label something as “Java EE”, you need to get a license from Oracle and pass the TCKs. There are many implementations of Java EE such as WebLogic, WebSphere, JBoss, and Glassfish. EE4J is the name of the top-level project  at the Eclipse Foundation. As such it is the umbrella under which the source code and TCKs for Glassfish, EclipseLink, and (hopefully) Eclipse MicroProfile will exist.

We are months away from even starting to define the specification process that will be used in the future. However, when we do I expect that this new process will create a new certification mark which can be properly considered the new “Java EE” name. We will be engaging with the community in the selection of that name.

The existing project names will continue to be used

I have seen some comments along the lines of “…it’ll be weird to install Eclipse Enterprise for Java into IntelliJ”. I’m actually pretty sure that what people will be installing is more likely to be called something like Eclipse Glassfish, or Eclipse MicroProfile.

Again, EE4J is the name of the top-level project at Eclipse. The projects within EE4J will continue to have their own identity, just as they do today. The committers and the PMC for EE4J will be deciding what artifacts they will be releasing and whether anything actually ships under the name EE4J. Maybe they will, maybe they won’t. But only time will tell.

The solution space is smaller than you think

Anyone who has ever built and maintained a large piece of software knows that naming is hard. Naming widely used technologies that take on a brand identity and which require trademarking are harder still. Selecting the EE4J name had to solve a number of real world constraints:

  • We wanted it to contain the word Java, but it also had to comply with the Java trademark guidelines. Oracle is the only entity that can use the word Java at the beginning of a name. Which meant that using “for Java” was pretty much a fixed requirement.

  • Whether you call it JEE, J2EE, or Java EE for the entire life of the enterprise Java platform “EE” has been in the name. Continuing that tradition provides some clear benefits in terms of continuity and brand recognition. For what it is worth, we basically selected the acronym first and then backed into what the letters in the acronym might mean.

  • The name has to be available to be trademarked. We actually ran full legal trademark searches on a couple of alternate names, and EE4J was the clear winner in terms of availability.

Summary

Hopefully this post provides some context for the naming choice that will help people understand what EE4J is, and is not, as a project name, brand, and trademark.

As Mark Little of Red Hat said in his post earlier today

There’s a lot of pent-up passion and energy around Java EE and it would be so much better if individuals focused that on the charter at this point than complaining about the name. Yes, I understand that some people feel the name is important to the success of this effort but I can tell you all that there’s a lot more to choosing a name for a foundation or massively successful project than just … choosing the name.

The passion and commitment of the people in the Java EE community is amazing. Working with this community and welcoming you all to Eclipse is an opportunity and a responsibility that all of us at the Eclipse Foundation take very seriously. The future success of EE4J and the enterprise Java platform is going to be determined by whether we can get you talented, smart, and passionate Javaistas to contribute to the projects and the community. 

I am looking forward to JavaOne next week, and hope to see many of you there!

P.S. Comments and discussion are welcomed over on the ee4j-community list. There are already over 100 subscribers there!

Written by Mike Milinkovich

September 30, 2017 at 5:30 pm

Posted in Foundation