Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

MicroProfile/ArchGuidelines

< MicroProfile
Revision as of 13:06, 11 June 2018 by Unnamed Poltroon (Talk) (Initial draft of arch guidelines based on first meeting)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Architecture Group Guidelines

This pages captures the guidelines the ArchitectureGroup has developed for the MicroProfile projects. You can find the meeting notes that are the basis for these guidelines [| here].

Versioning

See the Versioning page for guidelines are drawn from a series of calls on how spec versioning should work.

MicroProfile Configuration Integration

MicroProfile features should make use of the MicroProfile configuration feature to enable externalization of common setup that should be consistent across all MicroProfile runtime implementations. Each feature should use a property namespace of the form mp.<feature>.* to isolate the configuration property names. Each feature should have a section in it's specification document that identifies the property namespace prefix that the feature is using. As new namespaces are added, please update the following list of existing namespace prefixes:

  • mp.jwt.* - MicroProfile JWT configuration names
  • mp.openapi.* - MicroProfile OpenAPI configuration names

CDI Dependency

The current recommendation is that CDI API dependencies are layered to maximize the ability for implementations that are not based on CDI (Spring, Guice, ...) to adopt some level of implementation. At the base, if applicable, APIs that have no dependency injection API dependencies should be defined to allow for Java SE based implementations. The next level of dependency would be the use of the javax.inject.Inject annotation. The next level of dependency would be the use of interfaces that are defined by the CDI specification.

Coding Style Issues

A number of projects do make use of checkstyle and rat plugin configurations for validation of project conventions. We need to review the existing usage and propose a standard configuration that is exposed via a MicroProfile parent POM.

TCK Testing Frameworks

It is recommended that MicroProfile features make use of the TestNG and Arquillian testing frameworks when writing TCK unit tests.

Future Items

  • Finalize and agree on a parent pom.xml
    • Coding style configuration of rat and checkstyle maven plugins should be included
  • Need a plan on how to handle JPMS modules
  • Discuss/investigate on an MicroProfile Configuration feature or usage pattern for a bitset type of capability for toggling behaviors.
  • Backwards compatibility guarantees discussion needs to be revisited given the existence of the Jakarta EE effort.

Back to the top