Road to Quarkus 3

[Max Rydahl Andersen]

Hi all,

We are happy to formally announce the start of Quarkus 3 development.

In short, this means the various Quarkus.NEXT efforts already underway will be combined into a 3.x Alpha release stream. We ask that all extension authors and contributors take some time to try these out when they land. Your feedback will go a long way to ensuring we have a solid platform come Final. As a start, we have some questions at the end of this e-mail and would love to hear your initial thoughts.

Why the major version bump?

Quarkus 2.x was initially released in June 2021. It introduced great features such as continuous testing, Vert.x 4, and MicroProfile 4 (Watch [0] if you are feeling nostalgic). Quarkus aims to move fast, bringing a cutting-edge user experience with the latest technologies. We seek to bring as much as possible incrementally in minor releases, allowing you to stay current without disruption. Larger scale changes that can’t be delivered in this way are developed separately until the time is right for a major release. We have reached that point: More than a year passed and the technologies and practices evolved, and we have a number of major changes queued that we would like to bring to Quarkus while still evolving and keeping the ever-growing ecosystem around it.

What’s in it?

As we progress and get feedback we’ll adjust and post more around user visible features and updates here and on the blog.

The current list of known highlights for Quarkus 3 are (but are not limited to):

• Hibernate 6 - faster, safer, better (Check [1] to see how awesome it is).
• Move from Java EE to Jakarta EE (10) API and packages - following the latest evolution of the Java world
• Micro profile 6 - the latest update of all the MP specifications continuing evolving alongside the state of the practice
• HTTP/3 support (aka Quic) - the new HTTP version fixing the head-of-line blocking problem, using UDP [2].
• IO_URING - the next generation of asynchronous IO support. Let’s be clear: this is a complete game changer if you are interested in performance and efficiency (response time, latency…)
• Improved virtual threads (loom) and structured concurrency support - based on the lessons learned from our initial integration [3], we are now looking into expanding and improving the support.
• Documentation revamp - we hear you….We are working on better and more structured documentation following the diataxis framework principles [4]
• Tooling for updates - it’s going to be a new major version, but we want to make the migration as smooth as possible. Thus we will provide migration tools.
• Move from Reactive Streams to java.util.concurrent.Flow - time to evolve; Flow has been in the JDK since Java 9.
• A new gRPC server, more flexible and easier to maintain
• A revamped dev UI
• <Your extension awesome feature/improvements here>

Release Plan Approach
—----------------------------
As usual, we will continue the monthly cadence release of the 2.x version of Quarkus. Quarkus 3.x preview (alphas, betas) will be released in parallel. Due to the size and the nature of the work, it will take more than a month to integrate the change set we want and collect feedback (from users, and extension maintainers...) from the previous release. Thus, 3.x release cadence will be a bit slower than usual.

Thus the intent is to have a time period of some months to allow continuous integration and start releasing a Quarkus Platform with whatever members are ready to do and then continuously include more.

3.0.0.Final probably will have partial platform members which can then join 3.x in future releases. I.e. hypothetically Camel contributes 20 extensions; they might only have 10 ready - the rest would be added over time.

Depending on feedback and how we progress this does mean that we will look into having a 2.x version supported with CVE and bug fixes for a longer period of time than usual.

Proposed plan:

• Start doing 3.0.0.Alpha core and platform releases at regular intervals to allow easy integration builds, starting first from 2.13.3 in the coming week
• 2.x releases will continue to happen on a monthly basis
• Announce Quarkus 3 on Quarkus blog when 3.0.0.Alphas start being useful for users to try
• Feedback from and Outreach to extension contributors and users on readiness and challenges to help and adjust
• If all goes well, aim for a 3.0.0.Final in February 2023

Breakage? Keep calm!

While the major version bump signals possible breaking changes, we still ask that all contributors still aim for a smooth upgrade experience. Changes like the move to Jakarta with its package renames have a big impact. We intend on doing what we can to make it so current extensions and user applications can migrate from Quarkus 2 to Quarkus 3 by providing tooling to perform the migration.

Especially for the core API’s we will aim to allow such migration to be trivial and thus can be automated in a similar manner as how we’ve done automatic conversion of Quarkus 2.x to use Jakarta named packages.

Questions to Extension Authors

If you are a contributor to anything in the Quarkiverse (whether hosted in github.com/quarkiverse hub or outside), we have some initial questions for you:

• Any questions/feedback on the above plan for Quarkus 3?
• Can your extension have a branch/version available that is compatible with 3.0.0.Alpha in this timeline?
  • If yes - let us know approximately when and we should ensure we have ecosystem CI setup to include it for the 3.0.0.Alpha builds
  • If no - why not? Anything we can help with?

Any major features/updates you would like to get highlighted in announcements/communications on Quarkus 3 for your extension?

Thank you

We look forward to your feedback, and we’ll keep posting here for development news and on the blog/discussions for user-related updates on the road to Quarkus 3.

On behalf of the Quarkus team
Thank you,

[0] - https://quarkus.io/blog/quarkus-2-0-0-final-released/
[1] - https://www.youtube.com/watch?v=pc6QIwx0EL0
[2] - https://www.redhat.com/architect/http3
[3] - https://www.youtube.com/watch?v=514Ub0jNiII
[4] - https://diataxis.fr/

[Loïc MATHIEU]

Hi,

Great to see this ! 

I also propose to evolve Elasticsearch support to the new Java Client and drop support for the old High Level one.

There is already a PR for this (https://github.com/quarkusio/quarkus/pull/22622) waiting for the Jakarate EE rewritting. Moving to 3.0 means we can drop support for deprecated extension without having to deal with some releases that proposes both (which would have been difficult).

When will be a 3.0 branch ready to receives PR ?

Regards,

Loïc

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/37587A45-CD7D-4691-88FC-830FAB255409%40redhat.com.

[Max Rydahl Andersen]

Hi,

Great to see this ! 

I also propose to evolve Elasticsearch support to the new Java Client and drop support for the old High Level one. 

Remind me - did elasticsearch get their licenses cleared up for those clients yet? (Ie. Parts of it was still under non-open source)

There is already a PR for this (https://github.com/quarkusio/quarkus/pull/22622) waiting for the Jakarate EE rewritting. Moving to 3.0 means we can drop support for deprecated extension without having to deal with some releases that proposes both (which would have been difficult). 

Yeah - so elasticsearch is used in popular extensions like camel so we just need to make sure they have a viable pathway. 

When will be a 3.0 branch ready to receives PR ? 

For now we keep doing it via migration steps in quarkus core repo for as long as possible.  

maybe best to coordinate with Guillaume what makes sense to do for elasticsearch situation?

[Loïc MATHIEU]

The license issue is cleared up in the new Java Client that is Apache v2.

I don't know for Camel but for Hibernate Search, it uses the low level rest client which is another client designed for frameworks that must have cross-version support (which the deprecated High Level and the new Java Client didn't provide).

For the schedule, if there is no yet, not problem, my PR is already on-ice and we can sort this up when the first alpha will be scheduled. Guillaume is already aware of the PR and the issue with incompatibilities between clients.

[Jorge Solórzano]

Hi,

This is awesome, thanks!

I just have one small additional proposal that I don't see mentioned here, it's being considered to require Java 17 as minimum version? Java versions are also moving faster, next year we will have Java 21 and will be the next LTS release, and since Quarkus 3.0 is planed to be released in February 2023 it make sense to bump the Java version as well, as a side note Spring Boot 3.0 will be released in November 2022 and it will require Java 17, so we should not get behind ;)

Regards,

[Georgios Andrianakis]

Hi,

We are unlikely to bump the minimum Java version. However that should not make a difference for users who want to use 17 or above, as we do test and support using those.

So supporting Java 11 as the minimum, does not leave users behind in any way - it's just that the Quarkus codebase itself can't be written with Java 17 constructs - but just to hammer the point home, those constructs can be in user code.

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/20638d38-7f22-485c-b6b0-3a98db7d39cen%40googlegroups.com.

[Max Rydahl Andersen]

On 19 Oct 2022, at 7:15, Georgios Andrianakis wrote:

As Georgios points out users can use Java 17 features just fine and we default to it
for created projects.

For now we don't plan on dropping Java 11 support; but might consider deprecating it
as graalvm native image most likely will drop java 11 in the 3.x lifespan.

Of course, if libraries Quarkus depends on start compiling only for Java 17 things might change.

/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DCAxaudcZG%2BaB8nLzc8SPp236owmig_gXdODO%2BaL%3DYpQ%40mail.gmail.com.

[Loïc MATHIEU]

There is no support for Java 17 on Amazon Lambda for now (Google Cloud Functions support it, not sure for Azure) so we would lose support for it.

See https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/1F4342E3-105E-47F9-9F13-9BC67E888247%40redhat.com.

[Jorge Solórzano]

Ok, this is a compelling reason to still support Java 11, losing support for AWS Lambda is not a good deal.

Anyway, I know end users can use Java 17+, and the current set of features planned for Quarkus 3 is way more awesome and impactful than requiring Java 17 for the core, so thanks again!

[Max Rydahl Andersen]

On 19 Oct 2022, at 15:46, Loïc MATHIEU wrote:

> There is no support for Java 17 on Amazon Lambda for now (Google Cloud
> Functions support it, not sure for Azure) so we would lose support for it.
> See https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

Users can use their own java 17 based images if need be.

Also, I'm sure Amazon will eventually fix this.

/max

>
> Le mer. 19 oct. 2022 à 15:32, Max Rydahl Andersen <mand...@redhat.com> a
> écrit :
>
>> On 19 Oct 2022, at 7:15, Georgios Andrianakis wrote:
>>
>> As Georgios points out users can use Java 17 features just fine and we
>> default to it
>> for created projects.
>>
>> For now we don't plan on dropping Java 11 support; but might consider
>> deprecating it
>> as graalvm native image most likely will drop java 11 in the 3.x lifespan.
>>
>> Of course, if libraries Quarkus depends on start compiling only for Java
>> 17 things might change.
>>
>> /max
>>
>>
>> Hi,
>>

>> We are unlikely to bump the *minimum* Java version. However that should

>> not make a difference for users who want to use 17 or above, as we do test
>> and support using those.
>> So supporting Java 11 as the minimum, does not leave users behind in any
>> way - it's just that the Quarkus codebase itself can't be written with Java

>> 17 constructs - but just to hammer the point home, those constructs *can*

>>>> - Hibernate 6 - faster, safer, better (Check [1] to see how awesome
>>>> it is).
>>>> - Move from Java EE to Jakarta EE (10) API and packages - following

>>>> the latest evolution of the Java world

>>>> - Micro profile 6 - the latest update of all the MP specifications

>>>> continuing evolving alongside the state of the practice

>>>> - HTTP/3 support (aka Quic) - the new HTTP version fixing the

>>>> head-of-line blocking problem, using UDP [2].

>>>> - IO_URING - the next generation of asynchronous IO support. Let’s

>>>> be clear: this is a complete game changer if you are interested in
>>>> performance and efficiency (response time, latency…)

>>>> - Improved virtual threads (loom) and structured concurrency support

>>>> - based on the lessons learned from our initial integration [3], we are now
>>>> looking into expanding and improving the support.

>>>> - Documentation revamp - we hear you….We are working on better and

>>>> more structured documentation following the diataxis framework principles
>>>> [4]

>>>> - Tooling for updates - it’s going to be a new major version, but we

>>>> want to make the migration as smooth as possible. Thus we will provide
>>>> migration tools.

>>>> - Move from Reactive Streams to java.util.concurrent.Flow - time to

>>>> evolve; Flow has been in the JDK since Java 9.

>>>> - A new gRPC server, more flexible and easier to maintain
>>>> - A revamped dev UI
>>>> - <Your extension awesome feature/improvements here>

>>>>
>>>> Release Plan Approach
>>>> —----------------------------
>>>> As usual, we will continue the monthly cadence release of the 2.x
>>>> version of Quarkus. Quarkus 3.x preview (alphas, betas) will be released in
>>>> parallel. Due to the size and the nature of the work, it will take more
>>>> than a month to integrate the change set we want and collect feedback (from
>>>> users, and extension maintainers...) from the previous release. Thus, 3.x
>>>> release cadence will be a bit slower than usual.
>>>>
>>>> Thus the intent is to have a time period of some months to allow
>>>> continuous integration and start releasing a Quarkus Platform with whatever
>>>> members are ready to do and then continuously include more.
>>>>
>>>> 3.0.0.Final probably will have partial platform members which can then
>>>> join 3.x in future releases. I.e. hypothetically Camel contributes 20
>>>> extensions; they might only have 10 ready - the rest would be added over
>>>> time.
>>>>
>>>> Depending on feedback and how we progress this does mean that we will
>>>> look into having a 2.x version supported with CVE and bug fixes for a
>>>> longer period of time than usual.
>>>>
>>>> Proposed plan:
>>>>

>>>> - Start doing 3.0.0.Alpha core and platform releases at regular

>>>> intervals to allow easy integration builds, starting first from 2.13.3 in
>>>> the coming week

>>>> - 2.x releases will continue to happen on a monthly basis
>>>> - Announce Quarkus 3 on Quarkus blog when 3.0.0.Alphas start being

>>>> useful for users to try

>>>> - Feedback from and Outreach to extension contributors and users on

>>>> readiness and challenges to help and adjust

>>>> - If all goes well, aim for a 3.0.0.Final in February 2023

>>>>
>>>> Breakage? Keep calm!
>>>>
>>>> While the major version bump signals possible breaking changes, we still
>>>> ask that all contributors still aim for a smooth upgrade experience.
>>>> Changes like the move to Jakarta with its package renames have a big
>>>> impact. We intend on doing what we can to make it so current extensions and
>>>> user applications can migrate from Quarkus 2 to Quarkus 3 by providing
>>>> tooling to perform the migration.
>>>>
>>>> Especially for the core API’s we will aim to allow such migration to be
>>>> trivial and thus can be automated in a similar manner as how we’ve done
>>>> automatic conversion of Quarkus 2.x to use Jakarta named packages.
>>>> Questions to Extension Authors
>>>>
>>>> If you are a contributor to anything in the Quarkiverse (whether hosted
>>>> in github.com/quarkiverse hub or outside), we have some initial
>>>> questions for you:
>>>>

>>>> - Any questions/feedback on the above plan for Quarkus 3?
>>>> - Can your extension have a branch/version available that is

>>>> compatible with 3.0.0.Alpha in this timeline?

>>>> - If yes - let us know approximately when and we should ensure we

>>>> have ecosystem CI setup to include it for the 3.0.0.Alpha builds

>>>> - If no - why not? Anything we can help with?

>>>>
>>>> Any major features/updates you would like to get highlighted in
>>>> announcements/communications on Quarkus 3 for your extension?
>>>> Thank you
>>>>
>>>> We look forward to your feedback, and we’ll keep posting here for
>>>> development news and on the blog/discussions for user-related updates on
>>>> the road to Quarkus 3.
>>>>
>>>> On behalf of the Quarkus team
>>>> Thank you,
>>>>
>>>> [0] - https://quarkus.io/blog/quarkus-2-0-0-final-released/
>>>> [1] - https://www.youtube.com/watch?v=pc6QIwx0EL0
>>>> [2] - https://www.redhat.com/architect/http3
>>>> [3] - https://www.youtube.com/watch?v=514Ub0jNiII
>>>> [4] - https://diataxis.fr/
>>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to quarkus-dev...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/quarkus-dev/20638d38-7f22-485c-b6b0-3a98db7d39cen%40googlegroups.com

>>> <https://groups.google.com/d/msgid/quarkus-dev/20638d38-7f22-485c-b6b0-3a98db7d39cen%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DCAxaudcZG%2BaB8nLzc8SPp236owmig_gXdODO%2BaL%3DYpQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DCAxaudcZG%2BaB8nLzc8SPp236owmig_gXdODO%2BaL%3DYpQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/quarkus-dev/1F4342E3-105E-47F9-9F13-9BC67E888247%40redhat.com
>> <https://groups.google.com/d/msgid/quarkus-dev/1F4342E3-105E-47F9-9F13-9BC67E888247%40redhat.com?utm_medium=email&utm_source=footer>
>> .
>>

/max
https://xam.dk/about

[Zineb Bendhiba]

Hello Loïc, Max,

On Mon, Oct 17, 2022 at 5:34 PM Loïc MATHIEU <loik...@gmail.com> wrote:

The license issue is cleared up in the new Java Client that is Apache v2.

I don't know for Camel but for Hibernate Search, it uses the low level rest client which is another client designed for frameworks that must have cross-version support (which the deprecated High Level and the new Java Client didn't provide).

 

For Camel : We deprecated the old ElasticSearch component and introduced a new one with the java client in Camel 3.19.

It's not yet available in camel-quarkus, as we wait for the Quarkus PR. (See issue  : https://github.com/apache/camel-quarkus/issues/4155)

As soon as we get a branch compiling with one of the Alphas in Camel-Quarkus, we start working on the new extension. And then, we could discuss/confirm the drop. Does that make sense?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVFZWN32LnkhzPcoYD-UMOQSY%2BWQNOqaXOPBy2V6Cmk-pg%40mail.gmail.com.

--

Zineb Bendhiba

[Melloware]

I plan on ensuring the MyFaces and OmniFaces Quarkus extensions are compatible with Quarkus 3 which will be Jakarta Faces 4.

[V. Sevel]

hi max, we will start working on the vault extension as soon as there is a 3.x quarkus core to run with.

cheers,

vincent

[Jacob Middag]

Hi Max,

A preliminary test showed that Artemis extension only needs to change some imports. We created https://github.com/quarkiverse/quarkus-artemis/issues/87 to track it and will create a branch when first alpha is available.

Regards,

[Max Rydahl Andersen]

Excellent! noted!

/max
https://xam.dk/about

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/3aca3a22-1862-48d0-8076-6d878b9373e7n%40googlegroups.com.

[Max Rydahl Andersen]

Great!

/max
https://xam.dk/about

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/111ab47e-2e63-47d8-be21-98539987e8e6n%40googlegroups.com.

[Max Rydahl Andersen]

Perfect!

/max
https://xam.dk/about

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/f9a6d8ee-e5c7-4431-a40e-b88e0691416cn%40googlegroups.com.

[Andy Damevin]

Hey folks,

I’ve been trying our future migration script on all the quickstarts 
The good news is that most of the quickstarts are building and testing successfully.

Below you may find the list of quickstarts which are failing (with a link to the error log). AFAIK they are failing because they are non-core extensions which require a new jakarta packages migration release.

• All kotlin (package rename not working)
• jms-quickstart
• amazon-quickstarts
• kafka-avro-schema-quickstart
• kogito-drl-quickstart
• kogito-pmml-quickstart
• kogito-quickstart
• microprofile-graphql-quickstart
• opentelemetry-quickstart
• opentracing-quickstart
• optaplanner-quickstart
• reactive-messaging-http-quickstart
• reactive-messaging-websockets-quickstart
• tika-quickstart

If I receive a few friendly smiles, I could even cook a migration script for extensions, WDYT? @George Gastaldi, we could maybe even automate this?

Full results

amazon-dynamodb-quickstart/: NOK
amazon-kms-quickstart/: NOK
amazon-s3-quickstart/: NOK
amazon-ses-quickstart/: NOK
amazon-sns-quickstart/: NOK
amazon-sqs-quickstart/: NOK
amazon-ssm-quickstart/: NOK
amqp-quickstart/: OK
awt-graphics-rest-quickstart/: OK
cache-quickstart/: OK
config-quickstart/: OK
context-propagation-quickstart/: OK
funqy-quickstarts/: OK
getting-started-async/: OK
getting-started-command-mode/: OK
getting-started-knative/: OK
getting-started-reactive-crud/: OK
getting-started-reactive/: OK
getting-started-testing/: OK
getting-started/: OK
google-cloud-functions-http-quickstart/: OK
google-cloud-functions-quickstart/: OK
grpc-plain-text-quickstart/: OK
grpc-tls-quickstart/: OK
hibernate-orm-multi-tenancy-quickstart/: OK
hibernate-orm-panache-kotlin-quickstart/: NOK
hibernate-orm-panache-quickstart/: OK
hibernate-orm-quickstart/: OK
hibernate-reactive-panache-quickstart/: OK
hibernate-reactive-quickstart/: OK
hibernate-reactive-routes-quickstart/: OK
hibernate-reactive-stateless-quickstart/: OK
hibernate-search-orm-elasticsearch-quickstart/: OK
infinispan-client-quickstart/: OK
jms-quickstart/: NOK
jta-quickstart/: OK
kafka-avro-schema-quickstart/: NOK
kafka-bare-quickstart/: OK
kafka-panache-quickstart/: OK
kafka-panache-reactive-quickstart/: OK
kafka-quickstart/: OK
kafka-streams-quickstart/: OK
kogito-dmn-quickstart/: NOK
kogito-drl-quickstart/: NOK
kogito-pmml-quickstart/: NOK
kogito-quickstart/: NOK
lifecycle-quickstart/: OK
liquibase-mongodb-quickstart/: OK
liquibase-quickstart/: OK
mailer-quickstart/: OK
micrometer-quickstart/: OK
microprofile-fault-tolerance-quickstart/: OK
microprofile-graphql-client-quickstart/: OK
microprofile-graphql-quickstart/: NOK
microprofile-health-quickstart/: OK
microprofile-metrics-quickstart/: OK
mongodb-panache-quickstart/: OK
mongodb-quickstart/: OK
mqtt-quickstart/: OK
neo4j-quickstart/: OK
openapi-swaggerui-quickstart/: OK
opentelemetry-quickstart/: NOK
opentracing-quickstart/: NOK
optaplanner-quickstart/: NOK
quartz-quickstart/: OK
qute-quickstart/: OK
rabbitmq-quickstart/: OK
reactive-messaging-http-quickstart/: NOK
reactive-messaging-websockets-quickstart/: NOK
reactive-routes-quickstart/: OK
redis-quickstart/: OK
rest-client-multipart-quickstart/: OK
rest-client-quickstart/: OK
rest-client-reactive-quickstart/: OK
rest-json-quickstart/: OK
scheduler-quickstart/: OK
security-jdbc-quickstart/: OK
security-jpa-quickstart/: OK
security-jwt-quickstart/: OK
security-keycloak-authorization-quickstart/: OK
security-oauth2-quickstart/: OK
security-openid-connect-client-quickstart/: OK
security-openid-connect-multi-tenancy-quickstart/: OK
security-openid-connect-quickstart/: OK
security-openid-connect-web-authentication-quickstart/: OK
security-webauthn-quickstart/: OK
software-transactional-memory-quickstart/: OK
spring-boot-properties-quickstart/: OK
spring-data-jpa-quickstart/: OK
spring-data-rest-quickstart/: OK
spring-di-quickstart/: OK
spring-scheduled-quickstart/: OK
spring-security-quickstart/: OK
spring-web-quickstart/: OK
stork-kubernetes-quickstart/: OK
stork-quickstart/: OK
tests-with-coverage-quickstart/: OK
tika-quickstart/: NOK
validation-quickstart/: OK
vertx-quickstart/: OK
websockets-quickstart/: OK

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/78A49523-D6D0-406B-BAB8-770693F83FA7%40redhat.com.

--

Andy Damevin

[George Gastaldi]

Hey Andy,

That’s great news, good job!

First we need to raise these issues against the respective failed extension repositories and let the maintainers aware of these errors (longer term we’ll probably also need to enhance the GitHub workflow that is triggered by the Quarkus Ecosystem CI to also build on the 3.x branch, not only `main`). 

Then we could provide a PR for each failing extension (generated from a migration script) for the maintainers’ appreciation.

Best Regards,

George Gastaldi

Principal Software Engineer

Red Hat

[V. Sevel]

hello,

I am looking for somebody to review https://github.com/quarkiverse/quarkus-vault/pull/89

thanks for your help,

vincent

[Guillaume Smet]

On Thu, Nov 17, 2022 at 1:42 PM V. Sevel <vvs...@gmail.com> wrote:

hello,

I am looking for somebody to review https://github.com/quarkiverse/quarkus-vault/pull/89

thanks for your help,

I posted a review.

[Marco Bungart]

quarkus-artemis has upgraded to Quarkus 3.0.0.Alpha2. We can give an "almost all clear". We observed a compiler warning [1][2][3][4] of an old friend [5]:

    Warning:  unknown enum constant org.osgi.annotation.bundle.Requirement.Resolution.OPTIONAL
      reason: class file for org.osgi.annotation.bundle.Requirement$Resolution not found

The warning was neither present with 2.14.3.Final [6], nor with 3.0.0.Alpha1 [7].
What is interesting is that it only happens on 4 of our 12 integration test modules. All integration test modules have a common parent and thus use same dependencies. A call to "mvn dependency:tree" showed no difference between a module that produces a warning [8] an done that does not [9].

Ladislav Thon has hypothesized in zulip [10] that it could be related to another issue [11], although the warning messages differs.

[1]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/3639811313/jobs/6143666944#step:6:1705
[2]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/3639811313/jobs/6143666944#step:6:1974
[3]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/3639811313/jobs/6143666944#step:6:2997
[4]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/3639811313/jobs/6143666944#step:6:3386
[5]: https://github.com/quarkusio/quarkus/issues/19970
[6]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/3636261517/jobs/6136072642
[7]: https://github.com/quarkiverse/quarkus-artemis/actions/runs/3367740969/jobs/5585510164
[8]: https://pastebin.com/XT5dxAcM
[9]: https://pastebin.com/y1bMbhQT
[10]: https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Quarkus.203.2E0.2E0.2EAlpha2.20and.20an.20old.20friend/near/314479869
[11]: https://github.com/quarkusio/quarkus/issues/29206

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/78A49523-D6D0-406B-BAB8-770693F83FA7%40redhat.com.

[Holly Cummins]

Thanks for the update, Marco!

For others who are looking at starting the work to move to Quarkus 3, I’ve written up a cheat sheet. It collects up some of the tips from early adopters like Artemis, along with general best practices and how-tos for things like branching: https://github.com/quarkiverse/quarkiverse/wiki/Migrating-to-Quarkus-3.x

-H

--

Holly Cummins

Senior Principal Quarkus Software Engineer, Java Champion

Red Hat 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/ed1ce2f1-ef88-391b-26da-36664ffd1ac1%40googlemail.com.
<OpenPGP_0x1D62FE7F6FECFBC5.asc>

[Loïc MATHIEU]

Hi,

Quarkus Google Cloud Services extension pack works fine with Quarkus 3.0.0.Alpha2, changes are in a branch on my fork: https://github.com/loicmathieu/google-cloud-services/tree/quarkus-3.

I used the onliner from the wiki page then update to Alpha2 as the jbang script still use Aplha1.

Regards,

Loïc

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/C5287111-68FD-4FA2-93BC-88EED016BE0D%40redhat.com.

[Marco Bungart]

We additionally added "impsort:check" to the maven build step in 
quarkiverse/quarkus-artemis [1]. The goal "impsort:sort" is execute in the 
validate-phase, thus it might happen that the pipeline-build "reorders" the 
imports, but does not play the changes back. The explicit execution of 
"impsort:check" lets the pipeline fail if the imports are not properly ordered.

I have provided a corresponding PR to the quarkiverse-parent [2].

[1]: https://github.com/quarkiverse/quarkus-artemis/pull/108
[2]: https://github.com/quarkiverse/quarkiverse-parent/pull/68