# The MicroProfile repo is the index to the whole specification

> The microprofile/microprofile repository is not the specification itself but the place where the top level decisions are recorded: the umbrella specification, the Maven bill of materials POM, and the links to every feature repository. It is Apache-2.0 licensed, Eclipse Foundation hosted, and it is where a team consuming the stack actually starts.

**microprofile/microprofile** — Repository for important documentation - the index to the project / community

- Repository: https://github.com/microprofile/microprofile
- Stars: 694 · Forks: 115
- Language: Java
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/microprofile-microprofile

## A repository whose job is to be an index

The repository description is the whole point: it is the repository for important documentation, the index to the project and community.

The README explains the reasoning. The MicroProfile project link at projects.eclipse.org has several sources of information and collaboration, and since there is a large volume of activity, there is a need for important decisions to be recorded in one place for future reference. That is the aim of this repository.

So it is a documentation and coordination repository in the literal sense, not a source tree for a runtime. That is the first thing to understand, and it explains everything else about the layout.

The top level entries match that reading. There is a spec/ directory holding the umbrella specification, a pom.xml for the bill of materials, README.adoc, faq.adoc, how-to-pr.adoc for the pull request process, CONTRIBUTING.adoc with a Spanish translation in CONTRIBUTING_es.adoc, a NOTICE file, a site.yaml, an attic/ directory, and an .asciidoctorconfig.adoc. The documentation is AsciiDoc throughout, and the Apache-2.0 licence header in the README is the standard Eclipse Foundation one.

The last push was on 2026-10-16 and the repository is not archived. The release history is the specification versions rather than code releases: 7.1 from 2025-06-19, 7.0 from 2024-08-22, and 7.0-RC1 from 2024-07-16.

## The umbrella specification and what it covers

The README states that this repository is used to house the top-level umbrella MicroProfile specification, with a link into the architecture document at spec/src/main/asciidoc/architecture.adoc in the Eclipse repository.

An umbrella specification is a different kind of document from an API specification. Where a feature specification defines types and methods, an umbrella specification describes how the features fit together: which parts of the platform a MicroProfile application is expected to use, what the compatibility model is, and what the individual specifications are responsible for.

That is a genuinely useful document and an unusual one, because the individual feature specifications are written by different teams in different repositories and released on their own schedules. Reading only the Metrics spec and only the Health spec gives you two accurate pictures of two features. Reading the umbrella spec gives you the picture of the platform, which is what determines whether a set of dependencies will behave sensibly together.

The repository also has a spec/ directory of its own, and an .asciidoctorconfig.adoc that configures the AsciiDoc toolchain. For a project whose output is specifications rather than code, that is the build system.

The project is described as community-focused at its heart, aiming to engage and encourage lively discussion through as many channels as possible, which is a useful signal about how the decisions in the umbrella document get made.

## The Maven bill of materials is the part you actually consume

The second thing the repository houses is the Maven bill-of-materials POM, and this is the artifact that has a direct effect on a build.

The README says the POM declares transitive dependencies on all the Java EE and MicroProfile artifacts covered by the umbrella specification, and that it can be used in one of two ways.

The first is to declare a dependency on the entire MicroProfile stack:

```xml
<dependencies>
    <dependency>
        <groupId>org.eclipse.microprofile</groupId>
        <artifactId>microprofile</artifactId>
        <version>6.0</version>
        <type>pom</type>
        <scope>provided</scope>
    </dependency>
</dependencies>
```

The second is to import the transitive dependencies for selective use, through dependencyManagement:

```xml
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.eclipse.microprofile</groupId>
            <artifactId>microprofile</artifactId>
            <version>6.0</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>
```

The difference between the two forms is the practical point. The first form pulls the whole stack onto your compile classpath in one line, which is convenient and is what a container that provides the runtime expects. The second form imports version constraints only, so you pick the artifacts you want and the BOM aligns their versions, which is what you want in a codebase that needs three of the twelve features and does not want the other nine on its classpath.

The scope of provided on the individual dependencies is also deliberate: these APIs are supplied by the runtime, not bundled into your application, which is the whole point of the provided scope in a Jakarta EE environment.

## The feature repositories, each on its own release cycle

The README has a section headed Code, code, code, and it lists the Eclipse GitHub repositories where each MicroProfile feature is developed. The descriptions in the list are short and worth reading as a taxonomy.

There is MicroProfile Config for application configuration, MicroProfile Health for a simple health check, and MicroProfile Metrics for metrics. Then MicroProfile Fault Tolerance, MicroProfile Rest Client for a type-safe REST client, MicroProfile OpenAPI for OpenAPI and annotations, and MicroProfile JWT Authentication for JWT authentication propagation. MicroProfile Telemetry covers telemetry integration, and MicroProfile GraphQL is the GraphQL specification.

The last entry is different in kind. MicroProfile Conference App is described as an Architectural Application to demonstrate MicroProfile on a variety of vendors, which is a reference implementation rather than a specification, and it is the closest thing in the list to a worked example of the whole platform.

The list also shows where the projects live, which is a governance detail that matters. The specification repositories are under the eclipse organisation on GitHub, while the site and blog repositories are under the microprofile organisation: microprofile-blog for the entries on microprofile.io/blog, and microprofile-site for the source of the application that powers microprofile.io. The README also points to the full list of MicroProfile repositories within the Eclipse organisation through a filtered search link.

So MicroProfile is deliberately not a single repository. Each feature is developed, reviewed and released on its own, and this top level repository is where the umbrella view and the index live. That is the difference between the specification of the platform and the specification of a feature, and it is why a team looking for the Metrics API should not expect to find it here.

## Where the community conversation happens

The README lists the channels in detail, and the distinctions between them are practical rather than cosmetic.

The main site is the MicroProfile project at projects.eclipse.org, and the external site at microprofile.io continues to be maintained to promote the development and use of MicroProfile in the industry. Both sites are maintained for that purpose.

The wiki at wiki.eclipse.org contains up-to-date information about project development, tools and other documentation. The Google Group is described as the preferred place for discussions to take place. And besides the Google Group threads, which the README calls the main source of communication, there is the microprofile-dev mailing list, which should be used for conversation specific to the Eclipse way of doing things, so that the Eclipse team can more quickly recognise and respond to requests.

There is a third list for a different audience. Since the MicroProfile project is still in incubation, another useful mailing list is the incubation mailing list for asking general Eclipse process questions.

The split is worth understanding. The Google Group is where the community talks, the microprofile-dev list is where Eclipse process questions about a specific proposal get answered by the people who can answer them, and the incubation list is for the process itself.

The README also has a Notable Contributors section that is cut off in the text provided here, and a pull request guide in how-to-pr.adoc, which is the file to read before you propose a change to the umbrella specification.

## Where MicroProfile fits, and where it stops

The comparison worth making is with the alternatives for the same job, which are picking individual specifications, or using a single vendor's platform stack.

Against picking individual specifications, this repository is the map rather than the territory, and the difference matters when you are deciding what to depend on. A feature spec tells you the API. The umbrella spec tells you what the platform expects a MicroProfile application to look like, which is the information you need when you are deciding whether a set of features belongs in the same application.

The bill of materials is the other half, and it is the piece that has a concrete effect on a build. Without the BOM you are choosing versions of a dozen artifacts by hand and keeping them aligned by discipline. With it, one version string aligns everything, and the selective import form means you get the alignment without the whole classpath.

Against a vendor platform stack, the difference is portability. The whole point of the specifications is that a compliant implementation from any vendor works, and the Conference App reference application exists to demonstrate MicroProfile on a variety of vendors. The cost of that portability is that you work against the intersection of what the specifications require, which is generally less than what one vendor offers.

The limits are structural and they are not small. This repository does not contain the API of any feature, so it is not where you look up a method signature. The spec version and the BOM version are separate things and the README's example uses 6.0 while the release history lists 7.1, so a mismatch between the two is something to check rather than assume. The documentation is split across four places, the project site, the wiki, microprofile.io and the Google Group, and the README itself is a link index rather than a tutorial. And a repository whose stated purpose is recording decisions is going to be a poor guide to any single feature, because it deliberately does not try to be one.

The last thing to weigh is that the API and the code are in other repositories, which means the versioning you depend on is the versioning of those artifacts. The BOM is how you line them up.

## Conclusion

The microprofile/microprofile repository suits a Java team deciding which MicroProfile components to depend on and how to declare them, since the bill of materials POM is the artifact that makes that decision reproducible, and the umbrella specification document is where the cross-component architecture is recorded. It is the wrong repository if you are looking for the API of a single feature, since Config, Health, Metrics, Fault Tolerance, Rest Client, OpenAPI, JWT Authentication, Telemetry and GraphQL each have their own repository and their own release cycle. Before starting, read the umbrella specification rather than the individual feature docs, and decide whether the bill of materials POM at version 6.0 matches the runtime your application will deploy on.

## FAQ

### What does the microprofile/microprofile repository contain?

It houses the top-level umbrella MicroProfile specification, the Maven bill-of-materials POM, and the index of the feature repositories and community channels. The feature specifications themselves, such as Config, Health, Metrics and Fault Tolerance, live in separate Eclipse repositories with their own release cycles.

### How do I use the MicroProfile Maven bill of materials?

Either declare a dependency on the whole stack with the org.eclipse.microprofile:microprofile artifact at version 6.0 with type pom and scope provided, or import it in dependencyManagement to get version alignment and then depend on the individual features you want.

### Where do I ask questions about MicroProfile?

The README names the Google Group as the preferred place for discussions, the microprofile-dev mailing list for conversation specific to the Eclipse way of doing things, and the incubation mailing list for general Eclipse process questions, since the MicroProfile project is still in incubation.

### Where is the MicroProfile source code?

Each feature has its own repository under the Eclipse GitHub organisation, for example microprofile-config, microprofile-health, microprofile-metrics, microprofile-fault-tolerance, microprofile-rest-client, microprofile-open-api, microprofile-jwt-auth, microprofile-telemetry and microprofile-graphql. The microprofile organisation holds the blog and the site source.

### What is the MicroProfile Conference App for?

It is described as an Architectural Application to demonstrate MicroProfile on a variety of vendors, so it is a reference implementation of the whole platform rather than a specification, and it is the closest thing in the repository list to a worked example.

## Sources

- [Issues](https://github.com/microprofile/microprofile/issues)
- [License: Apache-2.0](https://github.com/microprofile/microprofile/blob/main/LICENSE)
- [microprofile/microprofile on GitHub](https://github.com/microprofile/microprofile)
- [README](https://github.com/microprofile/microprofile/blob/main/README.md)
- [Releases](https://github.com/microprofile/microprofile/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microprofile-microprofile