Skip to main content
Jump to: navigation, search

Difference between revisions of "MicroProfile/ArchGuidelines"

(Updates based on latest MP Architecture call)
m (Add comment that EL API should be excluded from CDI dependency)
 
Line 13: Line 13:
 
=== CDI Dependency ===
 
=== CDI Dependency ===
 
CDI first design and development for all specifications requires that the usage and developer experience when used in CDI is the paramount concern. This does not always require a CDI dependency. Any implementation that doesn’t utilize CDI needs to provide justification and receive approval prior.
 
CDI first design and development for all specifications requires that the usage and developer experience when used in CDI is the paramount concern. This does not always require a CDI dependency. Any implementation that doesn’t utilize CDI needs to provide justification and receive approval prior.
 +
 +
Currently, the EL API is not part of the base MicroProfile specifications, thus the transitive dependency on it from CDI API must be excluded by all specifications.
  
 
=== Non Java Properties files ===
 
=== Non Java Properties files ===

Latest revision as of 14:38, 14 August 2019

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

CDI first design and development for all specifications requires that the usage and developer experience when used in CDI is the paramount concern. This does not always require a CDI dependency. Any implementation that doesn’t utilize CDI needs to provide justification and receive approval prior.

Currently, the EL API is not part of the base MicroProfile specifications, thus the transitive dependency on it from CDI API must be excluded by all specifications.

Non Java Properties files

Non Java properties and files need to be accessible from the classpath, irrespective of the archive type.

SPI Packages

Specifications containing SPI packages are required to make those classes available within a separate SPI artifact of the specification, and not present within the API artifact.

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