Why can't I get the microprofile bom to work?

[sst...@redhat.com]

So I wanted to use the io.microprofile:microprofile 1.0.0 BOM, but when I tried it I'm not seeing the CDI and JAX-RS versions it is supposed to be locking down. This simple pom:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>org.eclipse.microprofile.test</groupId>

    <artifactId>microprofile-bom-test</artifactId>

    <version>1.0-SNAPSHOT</version>

    <packaging>jar</packaging>

    <dependencyManagement>

      <dependencies>

        <dependency>

          <groupId>io.microprofile</groupId>

          <artifactId>microprofile</artifactId>

          <version>1.0.0</version>

          <type>pom</type>

          <scope>import</scope>

        </dependency>

        </dependencies>

    </dependencyManagement>

    <dependencies>

        <dependency>

            <groupId>javax.enterprise</groupId>

            <artifactId>cdi-api</artifactId>

        </dependency>

        <dependency>

            <groupId>javax.ws.rs</groupId>

            <artifactId>javax.ws.rs-api</artifactId>

        </dependency>

    </dependencies>

    <build>

        <pluginManagement>

        <plugins>

            <plugin>

                <groupId>org.apache.maven.plugins</groupId>

                <artifactId>maven-jar-plugin</artifactId>

                <version>3.0.2</version>

            </plugin>    

        </plugins>

        </pluginManagement>

   </build>

</project>

fails to run due to not picking up the cdi and jaxrs version information from the bom:

[tmp 798]$ mvn dependency:tree

[INFO] Scanning for projects...

[ERROR] [ERROR] Some problems were encountered while processing the POMs:

[ERROR] 'dependencies.dependency.version' for javax.enterprise:cdi-api:jar is missing. @ line 23, column 21

[ERROR] 'dependencies.dependency.version' for javax.ws.rs:javax.ws.rs-api:jar is missing. @ line 27, column 21

 @ 

[ERROR] The build could not read 1 project -> [Help 1]

[ERROR]   

[ERROR]   The project org.eclipse.microprofile.test:microprofile-bom-test:1.0-SNAPSHOT (/private/tmp/pom.xml) has 2 errors

[ERROR]     'dependencies.dependency.version' for javax.enterprise:cdi-api:jar is missing. @ line 23, column 21

[ERROR]     'dependencies.dependency.version' for javax.ws.rs:javax.ws.rs-api:jar is missing. @ line 27, column 21

[ERROR] 

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException

[tmp 802]$ mvn -version

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T12:39:06-07:00)

Maven home: /usr/local/Cellar/maven/3.5.0/libexec

Java version: 1.8.0_121, vendor: Oracle Corporation

Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre

Default locale: en_US, platform encoding: UTF-8

OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"

I'm not having problems with other BOMs.

[John D. Ament]

According to the README, you're supposed to use it as a dependency with scope provided.

<dependency>

    <groupId>io.microprofile</groupId>

    <artifactId>microprofile</artifactId>

    <version>1.0.0</version>

    <type>pom</type>

    <scope>provided</scope>

</dependency>

https://github.com/microprofile/microprofile-bom

Hopefully we don't replicate this problem in 1.1.

John

[sst...@redhat.com]

I did try that as well as using that within the usual dependencies section rather than inside dependencyManagement section. Using -X does not show any type of error. I had see something about properties not being resolved so I cloned the microprofile-bom and put the version numbers explicitly in, but I'm still seeing the same problem with that. Guess I'll have to get maven in the debugger to see what it's problem is.

[sst...@redhat.com]

So here is the issue. The way the io.microprofile:micro profile bom is written, it must be used in the project/dependencies element, AND it cannot have any references to the same dependencies without versions as it usually done when importing a bom.

So, this skeleton works:

<project...>

    <modelVersion>4.0.0</modelVersion>
    <groupId>org.eclipse.microprofile.test</groupId>
    <artifactId>microprofile-bom-test</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <dependencies>

        <dependency>
          <groupId>io.microprofile</groupId>
          <artifactId>microprofile</artifactId>
          <version>1.0.0</version>
          <type>pom</type>
          <scope>provided</scope>
        </dependency>

    </dependencies>
</project>

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ microprofile-bom-test ---

[INFO] org.eclipse.microprofile.test:microprofile-bom-test:jar:1.0-SNAPSHOT

[INFO] \- io.microprofile:microprofile:pom:1.0.0:provided

[INFO]    +- javax.enterprise:cdi-api:jar:1.2:provided

[INFO]    |  +- javax.el:javax.el-api:jar:3.0.0:provided

[INFO]    |  +- javax.interceptor:javax.interceptor-api:jar:1.2:provided

[INFO]    |  \- javax.inject:javax.inject:jar:1:provided

[INFO]    +- javax.ws.rs:javax.ws.rs-api:jar:2.0.1:provided

[INFO]    \- javax.json:javax.json-api:jar:1.0:provided

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

If you put in an explicit dependency on javax.enterprise:cdi-api either before or after the io.microprofile:microprofile bom:

    <dependencies>
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
        </dependency>

        <dependency>
          <groupId>io.microprofile</groupId>
          <artifactId>microprofile</artifactId>
          <version>1.0.0</version>
          <type>pom</type>
          <scope>provided</scope>
        </dependency>

    </dependencies>

this fails with that 'dependencies.dependency.version' is missing error:

[ERROR]   The project org.eclipse.microprofile.test:microprofile-bom-test:1.0-SNAPSHOT (/private/tmp/pom2.xml) has 1 error

[ERROR]     'dependencies.dependency.version' for javax.enterprise:cdi-api:jar is missing. @ line 11, column 21 

So this style of bom is an alias for importing a fixed set of project dependencies. The style of bom I'm used to allows you to choose from amongst a set of fixed version dependencies. It does require a different structure in the bom. When I change the 1.0.1-SNAPSHOT microprofile-bom to use that style, and change the project pom to:

<project ...>
...

    <dependencyManagement>
      <dependencies>

        <dependency>
          <groupId>io.microprofile</groupId>
          <artifactId>microprofile</artifactId>

          <version>1.0.1-SNAPSHOT</version>
          <type>pom</type>

          <scope>import</scope>
        </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
        </dependency>

    </dependencies>
</project>

This also works, with the benefit of allowing you to only add the dependency on javax.enterprise:cdi-api and pick up the version from the io.microprofile:micro profile bom without also pulling in the javax.ws.rs:javax.ws.rs-api:2.0.1 dependency:

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ microprofile-bom-test ---

[INFO] org.eclipse.microprofile.test:microprofile-bom-test:jar:1.0-SNAPSHOT

[INFO] \- javax.enterprise:cdi-api:jar:1.2:compile

[INFO]    +- javax.el:javax.el-api:jar:3.0.0:compile

[INFO]    +- javax.interceptor:javax.interceptor-api:jar:1.2:compile

[INFO]    \- javax.inject:javax.inject:jar:1:compile

I think that is the style of bom we want, no? I'll create an issue in the microprofile-bom project requesting that.

[Ondro Mihályi]

Hi,

After the discussion a long time ago (https://groups.google.com/d/topic/microprofile/nX3C65gYdI4/discussion), most of us agreed that we want to have an uber-dependency, which you can just add as a provided dependency and get all MicroProfile API, similar to the javaee-api artifact.

The current MicroProfile BOM is intended to be used that way, but it's sill a bit confusing, because it's a kind of hybrid - it's called BOM, packaging type POM and is intended to be used as a provided dependency in <dependencies> not in <dependencyManagement>, highly non-standard.

In theory, it's also possible to update the artifact so that it can be used as a BOM instead, so that devs can choose if they import it as a BOM to provide default artifact versions or depend on it as a provided dependency to get started with MicroProfile quickly. Or we'd better create 2 separate artifacts for these scenarios.

Maybe we can change the packaging to JAR and still use it as a both provided dependency and a BOM. I'll try to experiment.

However, I still don't get much the usecase for importing a BOM - it's easier to just define specific dependencies like CDI or Config, there are separate API artifacts for them. BOM as I've seen it used is to provide versions for internal libraries of application servers so that applications can be built against the same versions. For MicroProfile, it's specified which versions of API artifcts should be used, so that's not an issue.

--Ondro

[Ladislav Thon]

2017-08-03 15:33 GMT+02:00 Ondro Mihályi <ondrej....@gmail.com>:

After the discussion a long time ago (https://groups.google.com/d/topic/microprofile/nX3C65gYdI4/discussion), most of us agreed that we want to have an uber-dependency, which you can just add as a provided dependency and get all MicroProfile API, similar to the javaee-api artifact.

The current MicroProfile BOM is intended to be used that way, but it's sill a bit confusing, because it's a kind of hybrid - it's called BOM, packaging type POM and is intended to be used as a provided dependency in <dependencies> not in <dependencyManagement>, highly non-standard.

I think I've seen POMs like these to use qualifier "dep" or "depchain". I think BOM is something different by convention; something you <scope>import</scope> in <dependencyManagement> to manage artifact versions for you.

LT

 

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/77b41098-3246-4248-a0e9-a411923497b8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[sst...@redhat.com]

The use case is that while you establish the scope and versions of dependencies for a platform, you don't dictate the complete set of dependencies that a user pulls in. It allows for finer grained dependencies. If we are going to keep this style of bom then the README should be more explicit about how to use it because where I hear bom I think import via dependencyManagement as Ladislav mentioned. I'll create a pull request for that change in the interim.

[Ondro Mihályi]

I agree that the name of the repository is very unfortunate - the artifact isn't a BOM, it's just a maven artifact with POM packaging, having some dependencies on other API artifacts. We should probably rename the repo to avoid further confusion. Hopefully the changes to the readme suggested by Scott will be enough.

I understand the argument for puling only a subset of dependencies, but since MP specifies only API dependencies, which are very small, it doesn't make much sense to filter them. The download size will be very small and that's the main concern for filtering dependencies as I understand it. So having all or only a subset of MP APIs as dependencies makes no real difference. However, if we can find a solution how to use the current artifact as a usual BOM, I'm not against it.

--Ondro

[Ondro Mihályi]

I have an idea:

What about changing the BOM artifact into regular parent artifact, which would be also usable as a BOM, and create another artifact to be used as an uber dependency in a project to get started quickly?

I realized that using POM packaging for an uber artifact as we do now isn't natural, because users need to specify artifact type instead of using the implicit JAR type. We can't simply change the packaging into JAR, because the current artifact is used also as a parent for the spec submodule, so we need to have a parent and a JAR artifact in the end.

Currently, the structure of the modules in the microprofile-bom repo is:

org.eclipse.microprofile:microprofile-bom (POM type, parent, depends on API modules, used as an uber-dependency)
 |- org.eclipse.microprofile:microprofile-spec (POM type, has microprofile-bom as parent, generates a PDF document)

 

I suggest the following structure:

org.eclipse.microprofile:microprofile-bom (POM type, parent, no dependencies, specifies dep versions in dependencyManagement, can be used as a BOM)
|- org.eclipse.microprofile:microprofile-spec (no change)
|- org.eclipse.microprofile:microprofile (new artifact, JAR packaging, has microprofile-bom as parent, used as an uber-dependency)

Do you think it would work?

--Ondro

[sst...@redhat.com]

Yes, that sounds good, but for the 1.1 release I would just go with what we have with the two outstanding pull requests merge to clarify the usage and set the release versions.

I think we do need a parent pom in general to capture consistent plugin configuration like the checkstyle, release related config, etc.

[Werner Keil]

I'm not sure, why it should not be used in dependencyManagement?

I changed the sample app to use the 1.0 BOM

https://github.com/keilw/microprofile-samples/blob/master/pom.xml

(still hasn't been merged, I don't know why, guess just overlooked?;-/)

And it works fine. Ivar said, he plans to change his samples for other events to  use the BOM instead of the Java EE 7 API after our DWX presentation.

If the Samples were to use the 1.0 BOM they could also be tagged and further adjusted to 1.1 some day...

Werner

[Alasdair Nottingham]

You can only have a single parent, and everyone has an opinion on what the parent should be so I think that would be less useful. 

Alasdair Nottingham

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/13a6b046-df12-4c11-a92e-8f2441c487d0%40googlegroups.com.

[Werner Keil]

No that wouldn't work as you need a "Parent" (currently not more than JSON-P 1.1, JAX-RS 2.0 and CDI 1.1, at least those match the Java EE 7 equivalent used by most features right now) and an "Outbound BOM" including some of the new APIs like Config.

The Outbound POM could be based on an "internal" Parent POM, at least that way it would be consequent and consistent.

Looking at many differences in CDI alone

http://www.cdi-spec.org/news/2014/04/14/CDI-1_2-released/

a vast majority of all feature-subprojects relies on Java EE 7 either Full or Web Profile with CDI 1.1 only.

Werner

[Werner Keil]

Why would 

|- org.eclipse.microprofile:microprofile (new artifact, JAR packaging, has microprofile-bom as parent, used as an uber-dependency)

be a JAR?

Take Agorava, which mostly Antoine and I contributed to, there's a Parent POM

https://github.com/agorava/agorava-parent

And a BOM

https://github.com/agorava/agorava-bom

Both its API and implementing parts like

https://github.com/agorava/agorava-core

Connectors like

https://github.com/agorava/agorava-twitter

And a sample application like

https://github.com/agorava/agorava-socializer/blob/develop/pom.xml

Use the combination of those two. 

It would make it safer and more consequent, if the Parent POM was also defined across a particular  MicroProfile generation, else you have island solutions like Config-parent POM (although Config does not even use more than CDI on the API level and I doubt JAX-RS is even used by most implementations, JSON could be, depending on the type of config source) 

Another separate demonstrator uses Agorava with Fitness APIs like Fitbit or Strava:

https://github.com/unitsofmeasurement/uom-spaces/blob/master/uom-quantifier/pom.xml

Note, only the BOM is used in DependencyManagement, so the exact version of Agorava API or other depencendies are properly defined and usable.

The Parent POM could therefore be optional, but a BOM should have all the right dependencies even if some of them may be optional.

Werner

[Ondrej Mihályi]

The parent POM is definitely optional. But when we add more modules into the same repository, it's convenient to have a parent to build everything together easily. My proposal uses the same artifact as a BOM and also as a parent POM for an API artifact, but we can also have separate parent, BOM and API modules. I just wanted to reduce their number and use the parent as a BOM.

The answer to "why the microprofile artifact should be a JAR?" is that it's supposed to be an aggregate API artifact, same as the javaee-api artifact. Right now, you have to type "<type>pom</type>" when including it as a dependency. With type JAR, you don't have to do that which makes it easier and more natural to use. This is more a workaround for maven, no other reason.

Agorava also has an API artifact, and not surprisingly, it's a JAR artifact: https://github.com/agorava/agorava-core/blob/develop/agorava-core-api/pom.xml

The only difference would be that the microprofile JAR wouldn't contain any classes, only dependencies which would be transitively added to the project to add all API available in MicroProfile. With POM packaging, we would get the same, but with the need to type "<type>pom</type>"

--Ondro

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/UINnSKJBtrI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/508981cf-7ee3-43f0-a6c0-b120a34d68f8%40googlegroups.com.

[Werner Keil]

Yes agorava-core does define JAR artifacts, but I thought your suggestion only refers to the BOM repository. And I would not see a JAR there.

For a template how the BOM might be applied to e.g. microprofile-config-api, etc. it makes sense, but the simple artifactID "microprofile" matches that of the older BOM.

agorava-bom may contain a few elements that are Wildfly-specific, but it mostly defines "core" depencendies. In the case of MicroProfile "core" may also include selected APIs e.g. the corresponsing version of the config-api if another feature would like to use configuration underneath the hood. It is a <dependencyManagement> include artifact, so you have the correct versions whether it is used by core components including the TCK or consuming applications. 

So the biggest difference and IMO a mistake in the MicroProfile BOM is, that Agorava BOM uses

<dependencyManagement>
	<dependencies>

...

While the MP one just starts at

	<dependencies>

...

Werner

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Werner Keil]

The WildFly BOMs https://github.com/wildfly/boms are some very good examples.

They even offer "BOM of BOMs" allowing to pick a particular BOM for a certain environment or scenario. E.g. tooling, etc.

There may be fewer BOMs for MicroProfile but allowing some to use e.g. Servlets or WebSockets, I guess one or the other profiled BOM would not hurt in the MicroProfile BOM repository either.

They all have in common, that they're applied to dependencyManagement, not dependencies.

This only worked for the 1.0 BOM because e.g. sample applications do use all 3 upstream dependencies, but even Config 1.0 uses just 1, 2 at most, so it makes no sense to force all 3 or 4 onto every project. The 1.1 BOM should also put them in dependencyManagement as a requirement for which to use and in which version, which ones could be mandatory, that's up to a TCK, not the POM or BOM anyway.

Werner

[Ondrej Mihályi]

The whole point of this discussion is that what we now call as MicroProfile BOM is not a BOM at all. It's intended to be used as a normal dependency, providing all APIs with a simple maven dependency. What's confusing a bit is that it's of type POM and not of type JAR as most other API artifacts (e.g. javaee-api or agorava-core-api). What's confusing even more that the repository is called microprofile-bom, while it should rather be called differently, e.g. microprofile-spec or microprofile-umbrella).

The microprfile artifact shouldn't be used as a BOM and shouldn't be compared to wildfly BOM. It's only that the packaging type of POM is often used with BOM artifacts rather than with API artifacts. This makes it possible to use the same artifact as an API dependency and as a BOM, but its main purpose is to use it as a dependency, not in the dependency management, and we probably should create other maven artifacts as specific BOMs.

--Ondro

--

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/UINnSKJBtrI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/06bb50da-fc1d-48a2-a83c-618f007dedaf%40googlegroups.com.

[Werner Keil]

Whether we call it BOM, POM or something else, is secondary. Important is helping both API subprojects and their consumers all the way down to consuming apps 

Agorava has two with one called BOM, the other one Parent.

Given, MP tries to challenge Spring Boot, let's look at comparable artifacts there.

One called "Dependencies"  (this is the one with only <dependencyManagement> declarations)

https://github.com/spring-projects/spring-boot/tree/master/spring-boot-dependencies

The other "Parent" (combining <dependencyManagement> and actual <dependencies> based on it)

https://github.com/spring-projects/spring-boot/tree/master/spring-boot-parent

Right now every single project and all live master sample projects (because the use of the 1.0 BOM has not been merged into the 1.0 samples) out there use something of their own.

Most either use "javaee-7-api" or "javaee-7-web-api" meaning they don't even match the CDI version and likely others (like JAX-RS) exactly as "MicroProfile 1.0" or its BOM declare. Those Java EE 7 POMs are still based on CDI 1.1, not 1.2 just to take one exmple.

So unlike the logo or mascots the name is not that important, BOM, Dependencies etc. it has to work the same way Spring or Agorava and several other projects use them.

Werner

On Wednesday, August 9, 2017 at 7:45:22 PM UTC+2, Ondro Mihályi wrote:

The whole point of this discussion is that what we now call as MicroProfile BOM is not a BOM at all. It's intended to be used as a normal dependency, providing all APIs with a simple maven dependency. What's confusing a bit is that it's of type POM and not of type JAR as most other API artifacts (e.g. javaee-api or agorava-core-api). What's confusing even more that the repository is called microprofile-bom, while it should rather be called differently, e.g. microprofile-spec or microprofile-umbrella).

The microprfile artifact shouldn't be used as a BOM and shouldn't be compared to wildfly BOM. It's only that the packaging type of POM is often used with BOM artifacts rather than with API artifacts. This makes it possible to use the same artifact as an API dependency and as a BOM, but its main purpose is to use it as a dependency, not in the dependency management, and we probably should create other maven artifacts as specific BOMs.

--Ondro

2017-08-09 11:42 GMT+01:00 Werner Keil <werne...@gmail.com>:

The WildFly BOMs https://github.com/wildfly/boms are some very good examples.

They even offer "BOM of BOMs" allowing to pick a particular BOM for a certain environment or scenario. E.g. tooling, etc.

There may be fewer BOMs for MicroProfile but allowing some to use e.g. Servlets or WebSockets, I guess one or the other profiled BOM would not hurt in the MicroProfile BOM repository either.

They all have in common, that they're applied to dependencyManagement, not dependencies.

This only worked for the 1.0 BOM because e.g. sample applications do use all 3 upstream dependencies, but even Config 1.0 uses just 1, 2 at most, so it makes no sense to force all 3 or 4 onto every project. The 1.1 BOM should also put them in dependencyManagement as a requirement for which to use and in which version, which ones could be mandatory, that's up to a TCK, not the POM or BOM anyway.

Werner

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/UINnSKJBtrI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ondrej Mihályi]

So what do you suggest to do, Werner?

--Ondro

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a3ae0891-3c55-4319-b1c6-256211b13a45%40googlegroups.com.

[Werner Keil]

I suggest splitting it in two, along the lines of what you also mentioned, but these two "guiding POMs" should both be POMs.

If say a sample project shows how to use them, why not, but I already proposed a PR to https://github.com/eclipse/microprofile-samples/pull/41 (not sure, what prevented merging them, it worked for config or health, so no technical or license reasons, probably just lack of time by committers?;-/) so a dedicated "How to use the BOM" project may not make much sense.

Whether it was in a sub-project underneath the current "bom" repository like that "spec" documentation or in a completely separate repo, both would work.

This "so-called-BOM" is simply what both Agorava or Spring call "-parent" as it contains and enforces <dependencies> rather than works via <dependencyManagement> so it could be called "parent", see at least 3 other Eclipse projects with a separate repo: https://github.com/eclipse?utf8=%E2%9C%93&q=parent&type=&language=

And let the BOM work and act more like those in lots of other projects via dependencyManagement. To avoid confusion.

Werner

[Werner Keil]

Besides, once again, the BOM has never even been tagged with a 1.1 release tag https://github.com/eclipse/microprofile-bom/releases around July 21.

That's bad because it remains a Moving Target every vendor can interpret the way they feel best. Most won't even use the current BOM but stick to java-ee-7 plus maybe the Config API (either 1.0 or the 1.1 Snapshots) While the overall commit activity has finally reached a similar level as September 2016 (when 1.0 was "declared", the actual artifacts like a 1.0 BOM happened only in April 2017) it makes it hard for any project let alone a commercial product planning to use it.

Sure it is not necessary to make a compatibility claim, but then why even bother with TCKs?;-O

The damage remains to 1.1, so why not tag the BOM project almost a month after the 1.1 release date and try to fix it  for a 1.2 release.

Werner

[Werner Keil]

Check out the BOM of Bootique: https://github.com/bootique/bootique-bom

A rather similar Java Microframework inspired by Spring Boot or Dropwizard.