Flatten quarkus-bom

[aloubyansky]

Flatten quarkus-bom with io.quarkus:quarkus-platform-bom-maven-plugin's flatten-platform-bom goal. This goal generates a POM file containing the effective set of the managed dependencies of the original BOM ordered alphabetically (although there is a parameter to preserve the original ordering) with the exception of the Quarkus platform artifacts (such as the json descriptor and properties) that are moved to the top of the BOM.

[maxandersen]

why would we want it sorted alphabeticvally and not by ordering as that is/can be significant ?

will this not affect origins in new platform metadata if we start flattening the boms or is that what you refer to about platform being an exception ?

[gastaldi]

I'm curious: can you elaborate on how ordering can be significant on a flattened BOM?

[maxandersen]

was about to say it defines the order on the classpath - so one can shadow the other...but I then realize if its used as bom pom then that doesn't happen.

[aloubyansky]

why would we want it sorted alphabeticvally and not by ordering as that is/can be significant ?

Simply to make it more human friendly.

will this not affect origins in new platform metadata if we start flattening the boms or is that what you refer to about platform being an exception ?

Correct. This is platform friendly as well.

[famod]

Are you guys sure that ordering is not important here? I think it is, especially for conflicting transitive versions.

Btw, CI failed big time.

[famod]

PS: I guess IDEs like Eclipse won't pick up the flattened BOM, right? (when the BOM module is imported as a project)

[maxandersen]

Wdym picked up?

[famod]

AFAIK, workspace resolution in Eclipse won't be using the flattened BOM from target in modules that depend on it (/import it). It'll probably use the regular unflattened one.

[aloubyansky]

AFAIK, workspace resolution in Eclipse won't be using the flattened BOM from target in modules that depend on it (/import it). It'll probably use the regular unflattened one.

Let's clarify, the flattened bom in the Quarkus repo specifically. Content-wise, It has no changes compared to its original version.

[aloubyansky]

Are you guys sure that ordering is not important here? I think it is, especially for conflicting transitive versions.

The ordering in the BOM or dependencyManagement in general?? I'd be very much surprised. It's ordering of the actual dependencies in the pom that is significant, afaik.

Btw, CI failed big time.

I'll investigate that.

[famod]

The ordering in the BOM or dependencyManagement in general??

dependencyManagement in general. But since a BOM is also just a collection of dependencyManagement entries, I do see an implication there as well.

Sorry, not much time ATM. I'll have to take a look at the resulting BOM before making any further assumptions...

[famod]

I think the main problem in CI is this:

Warning:  The POM for io.quarkus:quarkus-core-deployment:jar:999-SNAPSHOT is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details

[aloubyansky]

The ordering in the BOM or dependencyManagement in general??

dependencyManagement in general. But since a BOM is also just a collection of dependencyManagement entries, I do see an implication there as well.

A BOM is nothing more than a dependencyManagement which is nothing more than a set of version constraints.

[aloubyansky]

[INFO] --- quarkus-maven-plugin:999-SNAPSHOT:generate-code (default) @ quarkus-cli ---
[WARNING] The POM for io.quarkus:quarkus-core-deployment:jar:999-SNAPSHOT is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for io.quarkus:quarkus-core-deployment:999-SNAPSHOT
[ERROR] 'dependencies.dependency.version' for io.quarkus.gizmo:gizmo:test-jar is missing. @ 

[aloubyansky]

Apparently,

            <dependency>
                <groupId>io.quarkus.gizmo</groupId>
                <artifactId>gizmo</artifactId>
                <type>test-jar</type>
                <version>${gizmo.version}</version>
            </dependency>

is flattened to

      <dependency>
        <groupId>io.quarkus.gizmo</groupId>
        <artifactId>gizmo</artifactId>
        <version>1.0.7.Final</version>
        <classifier>tests</classifier>
      </dependency>

And I am not sure how to fix that properly, atm.

[aloubyansky]

Ok, I figured out where to get the proper type from but it reports the classifier as tests.

[aloubyansky]

According to https://maven.apache.org/guides/mini/guide-attached-tests.html the test-jar dependency is supposed to be accompanied with the classifier tests.

[aloubyansky]

I'm tempted to simply duplicate test-jar constraints: one with the tests classifier and one w/o.

[aloubyansky]

That appears to work. I am going with that.

[famod]

I checked a few scenarios I had in mind (with a sample project) and my concerns have now vanished!
I'm not sure whether I had some old Maven (pre-3.6 or even pre-3.5) behavior in mind or it was simply a bug in my matrix. 😉

TL;DR: LGTM

[gsmet]

Sorry for the nitpicking but this should be https.

[aloubyansky]

Fixed