GitHub

Project is hosted in the Eclipse organization at GitHub.

Jakarta Bean Validation

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

This project is created as part of the process of transitioning Java EE 8 technologies to the Eclipse Foundation as described in The Eclipse Enterprise for Java Project Top Level Project Charter. Unlike most of the Java EE specifications, Bean Validation was led by a non-Oracle organization, namely Red Hat.

The project aims to continue the standardization work of the Bean Validation specification, which is part of the Java EE platform, but which also is designed for use in Java SE environments. Previous revisions ofthat specification were created under the Java Community Process (JCP): 

  • Bean Validation 1.0 (JSR 303), part of Java EE 6
  • Bean Validation 1.1 (JSR 349), part of Java EE 7
  • Bean Validation 2.0 (JSR 380), part of Java EE 8

Quoting the Bean Validation 2.0 specification, its goals are these:

Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and error-prone. To avoid duplication of these validations in each layer, developers often bundle validation logic directly into the domain model, cluttering domain classes with validation code that is, in fact, metadata about the class itself.

This JSR defines a metadata model and API for JavaBean validation. The default metadata source is annotations, with the ability to override and extend the metadata through the use of XML validation descriptors.

The validation API developed by this JSR is not intended for use in any one tier or programming model. It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as rich client Swing application developers. This API is seen as a general extension to the JavaBeans object model, and as such is expected to be used as a core component in other specifications. Ease of use and flexibility have influenced the design of this specification.

Scope

Project Scope: The Jakarta Bean Validation project defines and maintains the Jakarta Bean Validation specification and related artifacts.

Specification Scope: Jakarta Bean Validation describes a means for declaring constraints on Java object models, APIs to validate constraints and query for constraint meta-data.

Description

Bean Validation is a specification which

  • lets you express constraints on object models via annotations

  • lets you write custom constraints in an extensible way

  • provides the APIs to validate objects and object graphs

  • provides the APIs to validate parameters and return values of methods and constructors

  • reports the set of violations (localized)

  • runs on Java SE but is integrated in Java EE 6 and later; Bean Validation 2.0 is part of Java EE 8

E.g. like so:

public class User {

private String email;

@NotNull @Email
public String getEmail() {
return email;
}

public void setEmail(String email) {
this.email = email;
}
}

public class UserService {

public void createUser(@Email String email, @NotNull String name) {
// ...
}
}

While you can run validation manually, it is more natural to let other specifications and frameworks validate data at the right time (user input in presentation frameworks, business service execution by CDI, entity insert or update by JPA).

In other words, run once, constrain anywhere.

Why Here?

Bean Validation 2.0 (as defined by JSR 380) is part of the Java EE 8 platform; as the latter is in the process of being migrated to the Eclipse foundation and will be continued under the Jakarta EE brand, it makes sense to host Bean Validation there too, ensuring a coherent evolution of all the Jakarta EE specifications under one umbrella.

Future Work

Future work on Bean Validation will happen based on feedback and demand by the community. Explorations for future features are conducted by the community in the Bean Validation reference implementation Hibernate Validator. Examples for potential future evolution in the specification include the following:

  • Define a Java API as a source for constraints (as an alternative to the currently supported annotation and XML-based means of configuring constraints)
  • Open up the specification for non POJO models (e.g. JSON strings, maps etc.)
  • Integration with record types if added in a future Java version
  • Closer integration with lambda expressions and method handles for specifying validation logic
Initial Contribution

As all JSR-driven specifications, Bean Validation is made up of a spec document, an API and a TCK. Their current source code (i.e. the initial contribution) can be found under the beanvalidation GitHub organization:

  • beanvalidation-spec: the normative specification of Bean Validation
  • beanvalidation-api: the Java API
  • beanvalidation-tck: the TCK ("Technology Compatibility Kit"), a comprehensive set of tests asserting complience of Bean Validation implementations

Red Hat has the IP rights necessary for contributing these immediately. The spec text, API code and TCK code have been developed by the members of the Bean Validation expert groups.

In the actual API, there are no dependencies to third-party libraries. The TCK has the following dependencies:

It also depends on the following specifications from the Jakarta EE platform:

  • EE Interceptors 1.2
  • CDI 1.2
  • Expression Language 3.0
  • EJB 3.1
Source Repository Type

Eclipse Cargo Tracker - Jakarta EE DDD Blueprints

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Cargo Tracker was officially part of the Java EE Blueprints project and focused on DDD. I would like to bring the project forward onto Jakarta EE.

Scope

Eclipse Cargo Tracker provides an example application that showcases core Jakarta EE technologies.

Goals

  • Demonstrate well established architectural patterns/blueprints for enterprise development with Jakarta EE using pretty close to a real world application.
  • Demonstrate a concrete implementation of DDD concepts.
  • Showcase some core Jakarta EE technologies.
  • Jakarta EE does not attempt to be a walled garden. Like all open standards, the goal of Jakarta EE is to provide a reliable core standard foundation that a vibrant ecosystem of plug-ins and extensions can be built around. In that spirit, we will incorporate a select set of representative tools that complement Jakarta EE well such as Maven, JUnit, Cargo, JMeter, soapUI, Arquillian, PrimeFaces and DeltaSpike.

Non-Goals

  • Comparison with other technologies such as Spring or .NET. We suggest you do your own research using the plethora of good information already available. This project is squarely about showing you how you could write good Jakarta EE applications and nothing else.
  • Attempting to demonstrate the very wide gamut of Jakarta EE APIs and features. While we do incorporate a pretty representative set of Jakarta EE APIs and features, it is not our goal to serve as a kitchen sink of comprehensive Jakarta EE samples. The Jakarta EE Examples project serves that purpose far better than us.
  • While it is certainly possible to learn certain aspects of Jakarta EE (primarily how to architect good Jakarta EE applications), this project is not intended to teach you the basics of Jakarta EE. The Jakarta EE Tutorial is intended as a basic learning tool for Jakarta EE.
Description

This project demonstrates how you can develop applications with the Jakarta EE platform using widely adopted architectural best practices like Domain-Driven Design (DDD). The code is intended to mirror a non-trivial application that developers in the real work would work on. It attempts to demonstrate first-hand how you can use Jakarta EE to effectively meet practical enterprise concerns such as productivity, agility, testability, flexibility, maintainability, scalability and security.

Why Here?

Since Java EE is moving to Eclipse, Cargo Tracker should move here as well to maintain community cohesion. It is a valuable project in the overall Jakarta EE portfolio.

Project Scheduling

The first build should be possible right after the transfer from Oracle. After that, I plan to merge my temporary updates in subsequent months, which will include adopting Jakata EE 8. The project is currently at Java EE 7.

Beyond that there is a roadmap that existed at Oracle: https://github.com/javaee/cargotracker/issues. I plan to keep working on it going forward.

Future Work

I plan to keep working on the items here: https://github.com/javaee/cargotracker/issues. The biggest next bit of work is adopting Jakarta EE 8 and Java SE 8.

I plan to blog, tweet and speak about the project. Hopefully that will result in a few more contributors.

Project Leads
Committers
Mentors
Interested Parties

I believe Oracle and Payara is interested in moving this project to Eclipse.

Initial Contribution

The Code at Oracle is here: https://javaee.github.io/cargotracker/. I created a temporary version (also under MIT) here: https://github.com/m-reza-rahman/cargo-tracker. For now I just want the code from Oracle transferred over. Any copyrigths are currently held by Oracle.

Source Repository Type

Eclipse iceoryx

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

iceoryx is an inter-process communication (IPC) middleware for POSIX based operating systems. It features shared memory capabilities which allow a true zero-copy data transfer.

Originating from the automotive domain, it is crucial to transfer a huge amount of data between multiple processes to realize driver assistance systems or automated driving applications. Moreover, the same efficient communication mechanism can be applied to a broader range of use cases, e.g. in the field of robotics or game development.

Scope

Eclipse iceoryx provides algorithms and libraries for shared memory communication on POSIX operating systems.

Description

In domains like automotive, robotics or gaming, a huge amount of data must be transferred between different parts of the system. If these parts are actually different processes on a POSIX based operating system like Linux, this huge amount of data has to be transferred via an inter-process-communication (IPC) mechanism.

The mechanisms provided by the operating system, like message queues, normally require to copy the data and are subject to context switches between user and kernel space. In fact, it is often not only one but many copies of the transferred data between the sender and the receiver. If it comes to GBytes/s data exchange rates, avoiding these copies becomes a crucial factor.

iceoryx is a middleware with a zero-copy shared memory approach which is optimized for the huge data inter-process-communication.

Why Here?

The OpenADx working group is currently under preparation for becoming an official Eclipse WG. OpenADx information are currently hosted at the Eclipse Wiki.

Project Scheduling

Initial contribution is planned for end of October 2019

Future Work

This project is work in progress. New features will be added, also in exchange with feedback coming from the community. The goal is to have a code base that is production ready.

This work will be presented in the automotive and robotics community. Especially, there will be a binding to the ROS2 software stack. Yet, the iceoryx middleware is a piece of functionality that can be integrated in other communication frameworks.

Project Leads
Committers
Michael Poehnl
Mentors
Interested Parties

Hopefully many others soon.

ROS will be one of the potential partners/community

We believe that there will be some interest in the OpenADx community.

Initial Contribution

We plan to do the first contribution end of October 2019.

Code ownership is currently at Bosch.

Source Repository Type

Eclipse GLSP

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

The emergence of the language server protocol enabled a significant increase in modularity and flexibility for tools and applications that provide language support for textual languages, such as programming languages. By encapsulating the language support in tool-independent language servers, their functionality can be reused across multiple tools, platforms, and applications, whether they are based on a web technology stack or on rich-client technologies, such as the Eclipse IDE, Eclipse Theia, or other platforms.

Today, graphical modeling tools, such as diagram editors for flowcharts or UML class diagrams, are typically coupled to their tool platform, as they require a lot of infrastructure that is only available in platform-specific modeling frameworks, such as the Graphical Modeling Framework (GMF). This makes it difficult to transfer or share graphical modeling tools among different platforms. Even the tool-independent logic, for instance, the definitions which elements can be created or which editing operations are allowed in a certain context, can hardly be reused across different tool platforms. However, graphical modeling tools would also significantly benefit from a modular architecture, similar to the one of language servers for textual languages, because such an architecture would mitigate the current constraints and limited flexibility regarding their tool platform, user interface toolkits, and deployability. With such an architecture, large parts of the implementation of a graphical language support could be shared across multiple platforms and toolkits.

This project is strongly related to Eclipse Sprotty, as it heavily builds upon Sprotty for implementing a web-based graphical language client and reuses its existing client-server protocol for transferring graph models that represent diagrams. The Eclipse GLSP puts on top of Eclipse Sprotty: (i) a standalone server framework for implementing specific diagram servers, (ii) enhancements of the client-server protocol to allow the server to communicate available node and edge types, allowed edit operations, etc., as well as (iii) graphical language client implementations for different platforms. The graphical language client implementation for web-based platforms, such as Eclipse Theia, builds on Eclipse Sprotty directly and is, due to its technical proximity, also intended to be directly contributed to the Sprotty project.

An initial prototype as well as the principle idea of the graphical language server framework was presented at the EclipseCon Europe 2018.

Scope

The scope of the Eclipse GLSP comprises...

  • A generic server framework for building language-specific graphical language servers
  • A protocol for communicating graphical language definitions (e.g. which edit operations are allowed in a certain context), as well as for transferring the application of edit operations
  • A generic client framework for different platforms in order to allow building specific graphical language clients that can communicate with graphical language servers

Out of scope are…

  • Diagramming frameworks, such as Eclipse Sprotty or GEF and GMF. Those shall be reused in order to build graphical language clients for different platforms.
  • Tools to define or generate diagram editors, such as GMF Tooling or Sirius.
Description

The GLSP provides extensible components to enable the development of diagram editors including edit functionality in (distributed) web-applications via a client-server protocol. By applying the architectural pattern of the language server protocol (LSP) to graphical languages and diagram modeling tools, it aims to achieve the same modularity and flexibility for diagram editors that has been enabled by the LSP for textual languages.

Textual languages, as supported by the LSP, significantly differ from graphical languages due to their graph-based structure, due to their way of being visualized in an editor, as well as due to  the nature of editing commands users can perform. Thus, it is impractical to directly reuse the language server protocol and language server or client frameworks. Instead, dedicated protocols and frameworks tailored to the specific requirements of graphical languages and diagram editors are required.

The main goal of GLSP is to encapsulate as much knowledge as possible about the graphical language on the server in the sense that available node and edge types, available operations, or validation is performed on the server, while the client-side editor is only responsible for rendering the diagram, providing the editing tools for the edit operations defined by the server, as well as visual feedback while editing. The actual manipulation of the underlying graph model is eventually delegated to the server, which after performing the manipulation, just sends an update to the client, which will then update the diagram rendering.

Therefore, the Graphical Language Server Platform aims at providing the following components:

  • Java-based server framework for building specific standalone diagram servers
  • Client-server protocol allowing the server to communicate available node and edge types, allowed editing operations, as well as for the client to invoke editing operations that are to be performed on the server
  • Frameworks for building diagram clients for different platforms
Why Here?

Eclipse has a long history of providing a home to all sorts of popular modeling technologies, including those for graphical modeling. In particular, the proposed project will heavily build on Eclipse Sprotty and is loosely related to other modeling technologies, such as GEF for rich-client based graphical language clients or EMF for managing models on the server.

Project Scheduling

The initial prototypical implementations will be contributed shortly after the proposal is accepted. After that we initiate regular milestone builds.

Future Work
  • Support for all typical editing functionality, such as undo & redo, property views, layout commands, copy & paste, etc.
  • Stabilization and improvements of an API for server and client customization
  • Simplification of authoring language-specific diagram servers
  • Client implementations based on other base technologies, such as GEF
Project Leads
Mentors
Interested Parties
  • Jan Köhnlein (TypeFox)
  • Miro Spönemann (TypeFox)
  • Pierre-Charles David (Obeo)
  • Benoit Combemale (Inria)
Initial Contribution

Initial prototypical implementation of (i) a standalone server framework for implementing specific diagram servers, (ii) enhancements of the client-server protocol to allow the server to communicate available node and edge types, allowed edit operations, etc., as well as (iii) graphical language client implementation based on Sprotty, unless this component will be contributed to the Eclipse Sprotty project.

Source Repository Type

crnk

Date Review
never
Date Trademark
never
Date Provisioned
never
Date Initial Contribution
never
Date Initial Contribution Approved
never
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Proposal State
Draft
Background

www.crnk.io started as an implementation of the JSON:API specification (see https://jsonapi.org/). This to let people more quickly, consistently implement true, resource-oriented, discoverable RESTful APIs. With JSON:API as shared standard it frees users from many lower-layer protocol details and opens up new possiblities for automation in the area of documentation, having default implementations for various data stores, doing linking/aggregating of resources, enforcing security, etc. The goal of everything together is to let developers focus more on application development than building REST APIs. In more recent days the transport format has become more flexible for use cases where the JSON:API is not a perfect fit (e.g. its normalized nature with a dedicated inclusion secion).

Scope

building resource-oriented RESTful APIs with everything needed around it.

out-of-scope: building a new framework, it should integrate well with existing frameworks and provide the means to more quickly build REST APIs.

 

Description

Crnk is a native resource-oriented rest library where resources and relationships are first class citizens and not just path mappings on methods. This simplifies development and opens up many, powerful new possibilities. Crnk follows the JSON:API specification and recommendations in Java to facilitate building RESTful applications. To quote the specification:

By following shared conventions, you can increase productivity, take advantage of generalized tooling, and focus on what matters: your application.

Crnk will take care of everything else from low-level REST protocol details to resource linking and error handling. In the progress, the application gains a rich, discoverable API with sorting, filtering, paging, HATEOAS and more. For more information see www.crnk.io

Why Here?

eclipse has a excellent track record for hosting open source projects. There are also a variety of projects working in the area, like microprofile, vert.x, jakarta, etc. having a higher-level rest api could benefit a great number of users, similar e.g. Spring Data does in the Spring ecosystem, but with a stronger foundation (building on standards, native support for relationships/graphs, independent of the spring ecosystem, lightweight).

 

Project Scheduling

contribution now, from then on we continue with regular releases, like every two, three months.

Future Work

- more documentation

- more examples

- support for graal native => make it ightweight and provide sub-50ms startup

- more support for vert.x

- community growth

- refinements & integrate with more data sources

- potentially support other transport formats like GraphQL which are similar in spirit but also part ways with many of the benefits of RESTful APIs.

- OpenAPI/swagger

- contribute to the JSON:API standard

Project Leads
Committers
Interested Parties

it is already in use by various people, e.g. at adnovum.ch we make in a variety of projects. e.g. in the blockchain space where accessing ledger data and establishing relationships to other data is quite essential.

Initial Contribution

see www.crnk.io

Source Repository Type

Eclipse Cloe

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

Work in the field of Automated Driving (AD) requires many multi-faceted processes incorporating a variety of software tools. In particular, any software that will be used in a vehicle must undergo rigorous testing, increasingly including vehicle and traffic simulation, as part of the verification and validation (V&V) strategy.

As of yet, there is no standard for interoperability between various simulation tools and the AD software in development. Coupling the system-under-test with tools provided by simulation vendors often leads to a lock-in effect, where use of one tool makes use of another prohibitively expensive. This costs the automotive industry more time and money than should be necessary.

Cloe is one part of such an Automated Driving toolchain, which will be handled in the OpenADx working group.

Scope

Eclipse Cloe provides simulation middleware and simulation-engine bindings for connecting simulation engines to the "software under test".

Description

Cloe is an enhanced middleware solution for closed-loop simulations, with a focus on functional software tests on system level. Cloe is used as a development tool for interactive and scripted workstation simulations, for code debugging, and for automated tests on servers. Cloe covers a central part of the verification and validation strategy, needed by all vendors in the field of Automated Driving.

  • Cloe acts as closed-loop simulation master and middleware for all involved components, such as simulator engine, vehicle controller, and component models.

  • Cloe provides a tool for orchestrating such closed-loop simulations in a variety of environments, e.g. on localhost or in a Kubernetes cluster.

  • Cloe provides a lightweight web-based user-interface for visualizing the simulation state.

  • Simulations are described through Cloe stack-files for reproducibility.

These core characteristics of Cloe allow it to (partially) fulfil the closed-loop simulation in the V&V strategy. Vehicle controllers and models can be easily integrated with Cloe and immediately have access to multiple simulator engines. Given M simulator engines and N vehicle controllers, Cloe allows the number of integrations to be reduced to M+N, rather than M×N that would otherwise be necessary. Multiple simulator engines are supported, proprietary as well as open source. This allows a user to mix-and-match engines to their system-under-test based on test requirements. Cloe provides generalized interfaces allowing ground truth and key-performance indicator extraction, as well as fault injection.

Orchestration features provided by Cloe allow faster scaling of simulation tests and evaluation. Through containerization and the simulation description files, development artifacts along with their tests can be easily archived and the results quickly reproduced.

Why Here?

The OpenADx working group is currently under preparation for becoming an official Eclipse WG. OpenADx information is currently hosted at the Eclipse Wiki.

Project Scheduling

Initial contribution is planned for middle of July 2019

Future Work
  • API and data model – As Cloe’s user base grows and usage requirements are better understood, the API, REST interface and data model of Cloe will be adapted.
  • Compatibility – In the future, Cloe shall support additional simulator engines, both open source and proprietary. We also plan to support upcoming automotive industry standards like the Open Simulation Interface and OpenSCENARIO.
  • Usability – From upgrading the web interface to support for additional operating systems, there are still a lot of usability features we have in mind for Cloe.
Mentors
Interested Parties

Microsoft, Mathworks, Tesis (part of Vector Informatics). AVL, AUDI, Volkswagen

Initial Contribution

Code exists, but have to be cleaned for the initial contribution. We would like to do the first contribution mid of July 2019.

Update on the timeline: We are facing some problems with incompatibilities. We have to shift the expected initial contribution date to end of 2019 end of May/June 2020. Sorry!

Code ownership is currently at Bosch.

During our OpenADx events, we have a lot of interest in this area, e.g. Mathworks, Tesis. AVL, Microsoft, ...

We also performed an OSS Scan; results will be provided with the initial contribution.

Source Repository Type

Eclipse ShellWax

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Editing shell script files is an operation every developer does every now and then. As such having a good and rich editor inside your IDE is crucial for development.

With the advent of LSP (language server protocol) creating a good editor using existing language server and relying on existing infrastructure provided by LSP4E, TM4E and related projects is now way easier and provides reacher UX compared to handling all the language specifics in the Eclipse plugin.

Finding that the existing DLTK subproject for shell editor is too expensive to maintain this one is intended to be the natural replacement for it coming from same developers.

Scope

The goal of Eclipse ShellWax is to provide a rich editor for shell script files using existing language server for the purpose. Goal of the project is to be thin wrapper around language server and shell interpreters as provided by the operating system.

Description

Eclipse ShellWax will provide editor for *.sh files with:

  • outline
  • autocomplete
  • error markers
  • hover help
  • and other common editor functions.

Executing shell scripts from inside the IDE and seeing output in Eclipse console will be supported too.

Why Here?

The Eclipse Foundation has a strong history and community around building vendor-agnostic developer tools. Eclipse IDE is still the leading IDE and close relation with rest of the ecosystem makes it a natural fit.

Project Scheduling

Initial contribution: May 2019

Stable release: Sep 2019

Future Work

Although the project is supposed to be thin wrapper there will be a lot of work to:

* Stabilize running and integrating with different operating systems and their shells

* Support for future changes in Eclipse IDE stach

* Support for future changes in used language server

Project Leads
Mentors
Initial Contribution

The initial contribution will come from the ShellWax project (https://github.com/akurtakov/shellwax). This includes all the major functionality listed above.

Source Repository Type

Eclipse Repairnator

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Eclipse Repairnator comes from research activities in the area of automated bug fixing. These activities have been performed in the last 8 years with PhD students and collaborators at the University of Lille, Inria, University of Valenciennes, KTH Royal Institute of Technology and others. Those techniques have now reached a maturity level to start being transferred to the software industry.

Scope

The scope of the Eclipse Repairnator project is to transfer academic results in the domain of intelligent continuous integration (“AI for CI”) to industry.

Description

Eclipse Repairnator is an intelligent bot for continuous integration: it suggests fixes for bugs and missing tests for quality assurance. Repairnator is artificial intelligence for continuous integration: “AI for CI“. Repairnator is an open-source software project, resulting from years of academic research in the field of software engineering.

Reparinator started as an open source project on GitHub. By becoming an Eclipse project, we expect that it will grow and mature with contributions from multiple companies and research groups.

Repairnator is visible, there have been press articles about Repairnator in 12+ more different languages: https://github.com/Spirals-Team/repairnator/issues/771

Why Here?

Eclipse Repairnator is a natural fit in the Eclipse Foundation. First, it is a software engineering and software engineering has always been a key aspect of the Eclipse ecosystem. Second, it is an open-innovation project involving both industry and academia, which is also a specialty of the foundation.

Joining the Eclipse Foundation will be a key enabler for open-innovation done in an appropriate collaboration structure (from an IP and from a legal perspective).

Repairnator will bring to the Eclipse Foundation strong ties with the Swedish industry and with the software engineering research community.

Project Scheduling

Q1 2019: join Eclipse with an initial consortium

Q2 2019: ramp up software development

Q3 2019: first industrial results

Q4 2019: Release of version 1.0

Future Work

There are currently 4 PhD theses directly related to Repairnator, funded by the European Commission, the Wallenberg foundation, and the Swedish Foundation for Strategic Research. The outcome of this constant research work will feed the Repairnator project in the mid and the long term.

Project Leads
Committers
mmisingnameana
Mentors
Interested Parties
  • KTH Royal Institute of Technology

    • Martin Monperrus (Project leader), Frédéric Loiret, Benoit Baudry, Benjamin Tellström, Zimin Chen, He Ye

  • Inria

    • Lionel Seinturier, Benjamin Danglot, Oscar-Luis Vera Pérez

  • Saab AB:

    • Stefan Andersson?

    • Mats Jonsson, Software Specialist @ Saab AB, Group Strategy

  • Ericsson:

    • Under discussion

Initial Contribution

Today, the Repairnator repository consists of 36,000 lines of code. Together with its key dependencies, it reaches 100,000 lines of code. See https://github.com/Spirals-Team/repairnator/

Source Repository Type

Jakarta EE Examples

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

I created this project to have JakartaEE examples that can be used freely without the need to add any license to the given examples when copying

Scope

Example applications of Jakarta EE technology.

Description

Examples for Jakarta EE.

Why Here?

To define a common place for examples for Jakarta EE.

Project Scheduling

It is a code repository with examples so it would be added upon when folks add more examples, but no releases are necessary as folks are expected to checkout/fork the project to get the examples

Future Work

More examples.

Project Leads
Committers
Manfred Riem
Arjan Tijms
Mentors
Initial Contribution

All the examples are licensed with the license associated with the project and all contributions where made sure to be under that license.

Source Repository Type

I'm confused on the license that is being proposed to be used with this project.  The EE4J project has defined the Eclipse EPL v2 as the default license.  The use of alternate licenses such as Apache v2 can also be proposed.  I don't understand what license will be used for these examples. 

In reply to by ksutter

The current license is a BSD Zero Clause (which is effectively equivalent to public domain). We don't have this license represented in our system at this point. 

A project using a different license than that already approved by the TLP charter is exceptional, but completely reasonable. From a licensing point of view, our general approach is recommend a BSD style (usually the EDP-1.0) because it's completely expected that examples will be modified and distributed under different licenses (which is permitted by the BSD). The BSD Zero Clause takes it one step further by removing all requirements to include notices regarding the source, license, etc.

If the PMC is concerned about this licensing scheme, I recommend that you engage with the project team on the tracking bug.

Oracle is in the process of contributing two existing samples repositories - GlassFish samples and Java EE samples.  The former would be contributed to the GlassFish project.  The latter would be contributed to the Jakarta EE Platform project, which already contains Jakarta EE tutorials and corresponding example code.  I don't think we want competing Jakarta EE samples projects or repositories.

I recommend that we either:

  1. Wait for Oracle to contribute the existing Java EE samples repository to the Jakarta EE Platform project and withdraw this project proposal, or
  2. Continue with the creation of this new project and Oracle will contribute the existing Java EE samples repository to this project

After which the additional samples proposed here would be added to the Java EE samples repository.

I'm hoping that the existing samples repositories will be contributed by Oracle in the next week or two, depending on IP review.

All samples contributed by Oracle are using BSD/EDL license. We are planning to contribute more samples and this project looks like a good place for them. What are reasons behind choosing BSD Zero Clause? Why not go for BSD/EDL for consistency reasons? If we decide transferring Oracle samples to this project, can we use different license?

Eclipse Codewind

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State
Created
Background

Traditionally, applications have been created on the developer's desktop, debugged locally, and then built and deployed through an automated devops pipeline. There are often numerous differences between these environments, including operating system, runtime or package versions, and environment.

The advent of Docker allowed the runtime to be packaged and moved between environments with repeatability, and Kubernetes has emerged as the deployment and management system of choice for large-scale Docker deployments. However, development is still usually done on a local environment without using these technologies and taking advatage of this new deployment platform.

Likewise, the Eclipse Foundation hosts both a classic desktop IDE (Eclipse platform) and a cloud-hosted IDE on Kubernetes (Eclipse Che), but no tools that help develop, debug, or deploy applications for Kubernetes, nor consistency in creating cloud-native applications regardless of your IDE.

Scope

The goal of Eclipse Codewind is to provide tools to help building high-quality cloud-native applications for Kubernetes, regardless of which IDE or language you use. This includes the capability to rapidly create an application from template or sample, support for launching, updating, testing, and debugging in Docker containers on the desktop, and support for the same directly on Kubernetes regardless of where the source is. The tools will also provide help to move an existing application to Docker and Kuberenetes, and validation to ensure that applications follow best practises.

To support this, Codewind will include plugins to the Eclipse platform and Eclipse Che, and a VisualStudio Code extension. A common library will be used by all of these tools to provide the function (e.g. creating, testing, and deploying applications) in a consistent way across the IDEs.

Description

Eclipse Codewind will start by providing an IDE-agnostic library for tools required for cloud application development:

  • Generating projects from templates
  • Creating a template or example from a current project
  • On the desktop: starting projects in Docker
  • Deploying applications to Kubernetes
  • Incremental update of applications running in Docker or Kubernetes
  • Debug and other support for these deployed projects
  • Application performance testing tools

Codewind will also provide Eclipse platform and Eclipse Che plugins, and a VisualStudio extension (and possibly others in the future) to allow users of these popular IDEs to create and deploy cloud-native applications in a consistent way from directly within their IDE.

Why Here?

The Eclipse Foundation has a strong history and community around building vendor-agnostic developer tools. Eclipse also hosts two of the main IDEs which we plan to extend, making it a natural fit for Codewind.

Project Scheduling

Initial contribution: May.

Tech preview & beta: 3Q2019

First release: 4Q2019

Future Work

Although the major peices will be in place after the initial contribution, we do not expect Codewind to be 'complete' at this point. Some of the main areas that need to be investigated:

  • Improving incremental development support for more languages
  • Support in other IDEs or development tools
  • Tools for helping with automated testing, and other aspects of app development that may change in cloud
  • Adoption of a vendor-neutral Kubernetes dev CLI

IBM will continue to invest in evolving Codewind and addressing these concerns, but welcomes additional participation in these areas or others.

Project Leads
Committers
Mentors
Interested Parties

IBM

Red Hat

Initial Contribution

The initial contribution will come from the IBM Microclimate project (http://microclimate.dev). This includes all the major functionality listed above, although it is in the process of being refactored to better fit into these environments.

Source Repository Type