Could not find io.quarkus.platform:quarkus-bom:3.0.0.Final.

[punkratz312]

Describe the bug

  > Could not find io.quarkus.platform:quarkus-bom:3.0.0.Final.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/io/quarkus/platform/quarkus-bom/3.0.0.Final/quarkus-bom-3.0.0.Final.pom
     If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
     Required by:
         project :serverless

Expected behavior

No response

Actual behavior

➜  serverless git:(prototype) ✗ gradle clean build 
> Task :serverless:quarkusGenerateCode FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':serverless:quarkusGenerateCode'.
> Could not resolve all files for configuration ':serverless:quarkusProdBaseRuntimeClasspathConfiguration'.
   > Could not find io.quarkus:quarkus-arc:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-container-image-jib:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-flyway:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-hibernate-orm-panache-kotlin:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-hibernate-orm-rest-data-panache:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-hibernate-validator:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-jdbc-postgresql:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-kotlin:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-logging-json:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-logging-sentry:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-micrometer-registry-prometheus:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-opentelemetry-exporter-otlp:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-quartz:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-qute:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-rest-client-reactive-jackson:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-resteasy-reactive:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-resteasy-reactive-jackson:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-resteasy-reactive-qute:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-smallrye-health:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-smallrye-jwt:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-smallrye-jwt-build:.
     Required by:
         project :serverless
   > Could not find io.quarkus:quarkus-smallrye-openapi:.
     Required by:
         project :serverless
   > Could not find io.quarkus.platform:quarkus-bom:3.0.0.Final.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/io/quarkus/platform/quarkus-bom/3.0.0.Final/quarkus-bom-3.0.0.Final.pom
     If the artifact you are trying to retrieve can be found in the repository but without metadata in 'Maven POM' format, you need to adjust the 'metadataSources { ... }' of the repository declaration.
     Required by:
         project :serverless

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s
16 actionable tasks: 3 executed, 13 up-to-date
➜  serverless git:(prototype) ✗ 

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot[bot]]

/cc @evanchooly (kotlin), @geoand (jib,kotlin)

[punkratz312]

diff:

:...skipping...
diff --git a/02_Software/TherapyExecutor/scheduler/build.gradle.kts b/02_Software/TherapyExecutor/scheduler/build.gradle.kts
index b288490b7..5e57ca8b0 100644
--- a/02_Software/TherapyExecutor/scheduler/build.gradle.kts
+++ b/02_Software/TherapyExecutor/scheduler/build.gradle.kts
@@ -1,6 +1,6 @@
 plugins {
     id("com.avast.gradle.docker-compose") version "0.16.12"
-    id("io.quarkus") version "2.16.6.Final"
+    id("io.quarkus") version "3.0.0.Final"
     kotlin("jvm")
 }
 dependencies {
@@ -28,7 +28,7 @@ dependencies {
     implementation("org.jboss.logmanager:log4j2-jboss-logmanager:1.1.1.Final")
     implementation("org.jboss.slf4j:slf4j-jboss-logmanager:2.0.1.Final")
     implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
-    implementation(enforcedPlatform("io.quarkus.platform:quarkus-bom:2.16.6.Final"))
+    implementation(enforcedPlatform("io.quarkus.platform:quarkus-bom:3.0.0.Final"))
     implementation(kotlin("stdlib"))
     implementation(project(":dsl-implementation"))
     implementation(project(":shared"))
diff --git a/02_Software/TherapyExecutor/serverless/build.gradle.kts b/02_Software/TherapyExecutor/serverless/build.gradle.kts
index 1b9c286f4..752e5fcf8 100644
--- a/02_Software/TherapyExecutor/serverless/build.gradle.kts
+++ b/02_Software/TherapyExecutor/serverless/build.gradle.kts
@@ -1,6 +1,6 @@
 plugins {
     id("com.avast.gradle.docker-compose") version "0.16.12"
-    id("io.quarkus") version "2.16.6.Final"
+    id("io.quarkus") version "3.0.0.Final"
     kotlin("jvm")
     kotlin("plugin.allopen") version "1.8.10"
 }
@@ -37,7 +37,7 @@ dependencies {
     implementation("org.jboss.slf4j:slf4j-jboss-logmanager:2.0.1.Final")
     implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
     implementation("org.junit.platform:junit-platform-commons:1.9.2")
-    implementation(enforcedPlatform("io.quarkus.platform:quarkus-bom:2.16.6.Final"))
+    implementation(enforcedPlatform("io.quarkus.platform:quarkus-bom:3.0.0.Final"))
     implementation(kotlin("stdlib"))
     implementation(project(":dsl-implementation"))
     implementation(project(":executor"))
(END)

[geoand]

This is expected as the whole Quarkus platform has not been released for version 3.0.0.Final. That will happen next week

[punkratz312]

@geoand is this intended? its kind of an unpleasant release train.

please why is this not timed together? the next situation is pretty sure if this behaviour doesn’t get adjusted.

[geoand]

As I said before, it's expected. The reason is that the platform has other members that need to do their releases based on the the just released Quarkus version

[punkratz312]

Thank you for your input. It's worth considering that using the final CR could also be a viable option for the team. However, it's important to note that the current approach of organizing and coordinating releases could benefit from improvement. The lack of communication and coordination has led to some inconvenience for the community and customers, and it may be helpful to address this in a more professional manner. Making changes to improve this process could help prevent invalid states and ensure a smoother experience for everyone involved.

[geoand]

If we could change this we would, but it's not possible

[punkratz312]

It would be great if the team could consistently follow the proper way of dependency management in their pom or gradle files, regardless of whether they use .final, CR2, or 3. It would ensure consistency and avoid any potential issues in the future. Just my opinion!

[punkratz312]

Furthermore, I am somewhat surprised, but not entirely, to see that the release candidate was issued despite me reporting a bug. It appears that a third and potentially final release candidate, version 3, was not released. It is possible that there could be other hidden issues that were not addressed, including those that may have been uncovered after the bug I reported was fixed.

[gsmet]

An advice if you continue to interact with people working on Open Source projects: maybe avoid lecturing people when you have absolutely no idea what their requirements and constraints are.

Also wait for the official announcement before upgrading.

[punkratz312]

Also wait for the official announcement before upgrading.

Dependabot is a valuable tool for automatic version bumps. However, when a release is issued that doesn't work as expected, it can result in wasted time and people asking questions.

The good news is that CR (Release Candidate) releases are similar to .final releases in terms of deployable artifacts. So, from an external perspective, it's not a big deal to use CR releases. You can do whatever it takes to get the platform built and then combine it into a release train. A small timing gap is understandable, but several days of misleading state can be frustrating and may not feel very professional.

I believe that it's not offensive to anyone, just my personal opinion. If other projects can handle it, I'm confident that you can too. Let's strive for professionalism and efficiency in our processes.

[gsmet]

Dependabot doesn't update a version for an artifact that doesn't exist. So don't tell me it's Dependabot who pushed the update for a io.quarkus.platform artifact.

Please stop questioning our professionalism or how we do everything.

I won't comment any further here. I already warned you several times about your attitude. It's not improving.

[maxandersen]

@punkratz312 the release we announce is the quarkus platform. We have to release the quarkus core release first to let other platofrm members catch up.

Where did you see we release quarkus platform 3.0 that made you believe you could update to it ?

If you can tell us where we have communicated wrongly about releases let me know and we see what we can do to fix that.

[punkratz312]

Dependabot doesn't update a version for an artifact that doesn't exist. So don't tell me it's Dependabot who pushed the update for a io.quarkus.platform artifact.

you are right. normally we have 2 bumps if existing :

i only checked it by hand because of the dangling or at least suboptimal release situation, im sorry.

just use the final CR version for the bom release train and no inconsistent behaviour is possible. its not a big issue, but there is room for improvement. and since there is no difference between an snapshot release and and major release from technical point of view.

[geoand]

A word of advice: it pays off to be wary of ones own assumptions as very often they do not reflect reality...

[punkratz312]

@geoand yes you are right im sorry. i think you although using water to cook, so things might not be that complicated or special that it might seem. special problems need simple solutions.

i look at everything as a black box and doing try and error.

try: you are using dependency management at the moment right now, or at least processing the artefacts resulting from the release build so error: you can simple take an extra iteration with the CR approach, with code freeze or an extra branch.

i´m 10 years in the game enough to make these assumptions.

if you can’t follow or apply the approach the whole internet / world, is using its might not my fault pointing out this issue.

its some kind of workaround, i know thinks might not get as planned, but still the situation is kind of missleading. i was wondering before why dependa is point out an "empty" release and a few days later its usually fixed by itself. because thats the "workflow".

now i know, so you see its not the first time this behaviour confused your customers which compromised the user acceptance. you guys as developers should know how important it is to appreciate your users.

[punkratz312]

@punkratz312 the release we announce is the quarkus platform. We have to release the quarkus core release first to let other platofrm members catch up.

Where did you see we release quarkus platform 3.0 that made you believe you could update to it ?

If you can tell us where we have communicated wrongly about releases let me know and we see what we can do to fix that.

let other platofrm members catch up

yes fine. using a final CR approach, with a well fitting code freeze 🥶, as you guys take only a few days as i know this as a regular customer and user of your astonishing software, its no problem. they can catch up against the finall CR release candidate version and when they have catched up they wirte a little note we are ready lets release together in one approach and not dangling around like it it right now.

[maxandersen]

Leaving this here for others to learn why we have staged releases of our artifacts.

@punkratz312 I understand that you are getting confused that some io.quarkus: components were released as 3.0.0.final but io.quarkus.platform: was not yet released. I just want to point out that there is a tons of artifacts released with different version numbers from quarkiverse and other subcomponents which is released before and after the io.quarkus.platform - something we've done now for 3+ years for 200+ releases. Early days they were released at the same day because it was technical feasible but as the platform grew and things like Apache Quarkus Camel, Kogito, pieces of Quarkiverse were added it became impossible to keep it on the same day.

You state that a snapshot release is technically no different from Final - that is simply a false statement as snapshot requires use of a different maven repository and they are not guaranteed to be the exact same binary we all would be testing with.

Could we use CR's ? sure - we could and we do. Every month we do CR's and then do Final core and give platform members a week to integrate. Why do we do Final? Because components like Apache Quarkus Camel requires to use final releases in their releases and have a required 3 day voting period on every release.

Thus if we were to do as you suggest we would have to be doing way more releases and coordination just to orchestrate the releases and instead of taking a few days to it would be 6+ to accommodate for Apache foundation release processes.

That (and just to be able to notify extension developers Final is here) is why we for 2+ years have been recommending and using in all docs/examples the io.quarkus.platform: BOM's which is a separately released artifact to be what endusers* use for building Quarkus applications.

Use of io.quarkus.core artifacts is for extension development. I assume that is why you have dependabot tell you there are an update? or are you somehow using these dependencies with explicit versions?

[geoand]

If grinding through walls of useless text and random screenshots in reported issues (while we've already stated multiple times that we need a sample application to help) is not "appreciating" (whatever that's supposed to mean...) our users, then I don't know what is...

[punkratz312]

I appreciate your efforts and patience in explaining the situation to me. Your approach seems like a reasonable and efficient solution considering the massive coordination required. Perhaps we can create a simple wrapper for this situation, like a "quaki-final-stable-release-train-bundle" or something similar, and use it as the new standard. We can bump it whenever the release train is "truly" completed, as I understand that it's not done in one go. It would be helpful to save the valuable information in a readme or another easily accessible place, as it can get lost in the conversation. In other words, let's create a clear and concise reference for this process. Thanks, @maxandersen!

The staged releases of artifacts in the Quarkus project are done for several reasons. One reason is that there are numerous artifacts released with different version numbers from various subcomponents, such as Quarkiverse and other dependencies, which are released before and after the io.quarkus.platform artifacts. This has been the practice for over three years and for over 200 releases. In the early days, all releases were done on the same day, but as the platform grew and more components like Apache Quarkus Camel and Kogito were added, it became challenging to coordinate and release everything simultaneously.

Contrary to the suggestion that snapshot releases are no different from Final releases, snapshot releases require the use of a separate Maven repository and are not guaranteed to be the exact same binary that will be used for testing. This is why the Quarkus project uses Final releases, which are more stable and reliable, and are required by components like Apache Quarkus Camel for their own releases.

While it is possible to use Candidate Releases (CRs), the Quarkus project already does monthly CR releases, followed by Final releases for the core, which gives platform members a week to integrate. Final releases are also necessary to comply with the release processes of external organizations like the Apache Foundation, which require a 3-day voting period for each release. Releasing components separately would require even more releases and coordination, taking up more time and effort, and potentially delaying the overall release timeline to accommodate external processes.

To ensure that end users have a stable and reliable set of dependencies to build their Quarkus applications, the Quarkus project recommends and uses the io.quarkus.platform BOMs (Bill of Materials), which are released separately. These BOMs provide a consistent set of versions for all Quarkus dependencies. On the other hand, the io.quarkus.core artifacts are intended for extension development, and using them with explicit versions may result in dependabot notifications for updates.

In summary, the staged releases of artifacts in the Quarkus project are done to manage the complexity of the growing ecosystem and to provide stable and reliable dependencies for end users. Snapshot releases are not the same as Final releases, and using separate BOMs for end users and explicit versions for extension development helps maintain consistency and stability in the Quarkus project.