Quarkus and Okhttp dependencies

[Guillaume Smet]

Hi,

We are in a bit of a problematic situation with Okhttp:

- the newer versions are dependent on the Kotlin runtime (and we don't really like that)

- the old ones have a CVE, we are not directly affected, but as we enforce the old version in our BOM, the situation is not ideal

We started some work to get rid of the dependency: the Kubernetes Client for instance does not depend on Okhttp anymore but is using the Vert.x web client.

Unfortunately, that was the top of the iceberg as we have several other dependencies requiring Okhttp:

Extensions:

- Infinispan via an OpenTelemetry dependency and directly (opentelemetry-exporter-otlp-common)

- OpenTelemetry via opentelemetry-exporter-otlp-common again

- Jaeger via jaeger-thrift

Test framework:

- Infinispan again via org.infinispan:infinispan-server-testdriver-core -> org.infinispan:infinispan-client-rest (note that there is a dependency convergence issue in Infinispan, the extension and the test framework depend on different versions of Okhttp)

- the Kubernetes Client test extension is still depending on Okhttp via io.fabric8:kubernetes-server-mock

So while the situation has slightly improved thanks to the work on the Kubernetes Client, the situation is still messy.

I'm not sure if we always actually need Okhttp and, if we don't, it might be a good start to exclude it.

If we do, I think we need to come up with a plan for each use case reported above.

Thoughts?

For the record, here are the various dependency trees:

+-io.quarkus:quarkus-test-infinispan-client:jar:999-SNAPSHOT
  +-org.infinispan:infinispan-server-testdriver-core:jar:14.0.6.Final:compile
    +-org.infinispan:infinispan-server-runtime:jar:14.0.6.Final:compile
      +-org.infinispan:infinispan-server-hotrod:jar:14.0.6.Final:compile
        +-org.infinispan:infinispan-server-core:jar:14.0.6.Final:compile
          +-io.opentelemetry:opentelemetry-exporter-otlp-common:jar:1.23.1:compile
            +-com.squareup.okhttp3:okhttp:jar:4.10.0:runtime
and
+-io.quarkus:quarkus-test-infinispan-client:jar:999-SNAPSHOT
  +-org.infinispan:infinispan-server-testdriver-core:jar:14.0.6.Final:compile
    +-org.infinispan:infinispan-server-runtime:jar:14.0.6.Final:compile
      +-org.infinispan:infinispan-client-rest:jar:14.0.6.Final:compile
        +-com.squareup.okhttp3:okhttp:jar:3.14.9:compile
and
+-io.quarkus:quarkus-test-infinispan-client:jar:999-SNAPSHOT
  +-org.infinispan:infinispan-server-testdriver-core:jar:14.0.6.Final:compile
    +-org.infinispan:infinispan-server-runtime:jar:14.0.6.Final:compile
      +-org.infinispan:infinispan-client-rest:jar:14.0.6.Final:compile
        +-com.squareup.okhttp3:okhttp-sse:jar:3.14.9:compile
          +-com.squareup.okhttp3:okhttp:jar:3.14.9:compile

-----

[ERROR] io.quarkus:quarkus-test-kubernetes-client:jar:999-SNAPSHOT
[ERROR]    io.fabric8:kubernetes-server-mock:jar:6.5.0
[ERROR]       io.fabric8:mockwebserver:jar:0.2.2
[ERROR]          com.squareup.okhttp3:mockwebserver:jar:3.12.12
[ERROR]             com.squareup.okhttp3:okhttp:jar:3.12.12
[ERROR]                com.squareup.okio:okio:jar:1.15.0 <--- banned via the exclude/include list

-----

[ERROR] io.quarkus:quarkus-jaeger:jar:999-SNAPSHOT
[ERROR]    io.jaegertracing:jaeger-thrift:jar:1.8.1
[ERROR]       com.squareup.okhttp3:okhttp:jar:4.9.3
[ERROR]          com.squareup.okio:okio:jar:2.8.0

-----

[ERROR] io.quarkus:quarkus-opentelemetry:jar:999-SNAPSHOT
[ERROR]    io.opentelemetry:opentelemetry-exporter-otlp-common:jar:1.23.1
[ERROR]       com.squareup.okhttp3:okhttp:jar:4.10.0
[ERROR]          com.squareup.okio:okio-jvm:jar:3.0.0

--

Guillaume

[Bruno Baptista]

Ideally, OTel shouldn't be coupled to a particular client...
Will discuss with them.

--

Bruno Baptista
http://twitter.com/brunobat_

[Roberto Cortez]

Hi,

Unfortunately, both the HTTP and gRPC exporters provided by OpenTelemetry use Okhttp. We cannot exclude it.

I’ve found this issue where some folks are having problems with OTel with Okhttp:

https://github.com/open-telemetry/opentelemetry-java/issues/4777

I don’t think we have an easy way out. We can either:

- Write our own HTTP / gRPC exporter 

- Propose an SPI in OTel that allows us to change the backing HTTP client easily.

I prefer us to avoid having to write and maintain our exporter, but realistically it is the faster option.

Cheers,

Roberto

[Marc Nuri San Felix]

Hi,

From the Kubernetes Client side, the only dependency to OkHttp comes from the Kubernetes Mock server (as you said).

Our goal was to bump OkHttp to the latest 4.x version now that Quarkus uses Vert.x instead of OkHttp. Given that the mock server is a test dependency, is the Kotlin runtime dependency still a problem? Refactoring the Mock Server out of the client would be a considerable task. If it's not a problem, my suggestion would be to align all of the test framework modules to use the latest OkHttp version, this would certainly be the easiest and fastest solution.

BR

--

Marc

[Holly Cummins]

We are in a bit of a problematic situation with Okhttp:

- the newer versions are dependent on the Kotlin runtime (and we don't really like that)

- the old ones have a CVE, we are not directly affected, but as we enforce the old version in our BOM, the situation is not ideal

A dependency on kotlin would be less intrusive for Quarkus 3, because Kotlin is no longer loaded parent-first, so we don’t get that parent-first ripple through the codebase we used to see. 

(I’m not advocating we bring the latest version in, just pointing out something that’s changed recently.)

--
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/CALt0%2Bo_%3DjESqwpH9LhKNz3EpZFfvv%2B%2BW3FTzLp2v6DgVVJPODQ%40mail.gmail.com.

[Bruno Baptista]

Hi
This will be discussed in the OTel Java SIG meeting tomorrow.

It remains uncertain whether a new SPI will be approved or if its implementation is feasible with the current codebase, however there is some interest in moving to the standard JDK HTTP Client.

Let's see what the discussion leads to.

If we need to do a custom exporter I would prefer to do it upstream on the OTel side.

In any case, there is no quick solution for this problem.

Cheers

[Max Rydahl Andersen]

Its worth remembering the issue with okhttp dependency is not on Kotlin as such but on kotlin standard library - which is great and all;
but if you care about being able to make reproducible builds (which more and more people do) introducing a whole new toolchain at such a low level is quite problematic.

That's where the problem lies. Then adding on top the issues of modules etc.

/max
https://xam.dk/about

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/C2CD87C5-E0A0-4C96-B7B6-3F7394B759AF%40redhat.com.

[Max Rydahl Andersen]

I don't think we know the answer to it yet. Issue is that kotlin stdlib itself has transitive dependencies so if we don't lock the versions things gets problematic quite fast.

With the new (to me :) info that open telemetry at its core has a hard dependency on okhttp it is problematic.

/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/CAEdGhmaQqPbzN2xbVjgCU%2BmQMx7kXC_m-1T8CTKf-xmHkWPFnA%40mail.gmail.com.

[Max Rydahl Andersen]

Might be worth sharing with them that kubernetes client managed to extract their http interactions so it was feasible to have custom http clients allowing them to use the client optimize for their runtime stack.

Might be worth something as core as open telemetry to explore that option.
/max
https://xam.dk/about

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CADgv5Wgb%3D13TTJq%2BNEKcWHtiLGoHwkL3APFp7z5OvKBCPXZtTQ%40mail.gmail.com.

[Stuart Douglas]

On Thu, 16 Mar 2023 at 19:45, Max Rydahl Andersen <mand...@redhat.com> wrote:

Its worth remembering the issue with okhttp dependency is not on Kotlin as such but on kotlin standard library - which is great and all;
but if you care about being able to make reproducible builds (which more and more people do) introducing a whole new toolchain at such a low level is quite problematic.

Also AFAIK it will lock you into a specific version of Kotlin, which will almost certainly become problematic at some point.

Stuart

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/ABA9FC00-E285-4F52-B902-C3A8A6252E02%40redhat.com.

[Roberto Cortez]

We can also write our own custom exporter. We just use the one provided by OTel.

For users, this will be transparent because the OTel extension includes the exporter, so we can just replace it.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/3A91265E-CD58-425D-9D69-72514F778EA6%40redhat.com.

[brunobat]

We discussed this subject yesterday, at the OTel Java SIG.
Would implement the OTlp exporter using the stock JDK HTTP client would be good enough?
On the meeting there was concern on creating an SPI for this due to its complexity.

Cheers.

Bruno

[Georgios Andrianakis]

On Fri, Mar 17, 2023 at 11:39 AM brunobat <brun...@gmail.com> wrote:

We discussed this subject yesterday, at the OTel Java SIG.
Would implement the OTlp exporter using the stock JDK HTTP client would be good enough?

I don't see why not.

 

On the meeting there was concern on creating an SPI for this due to its complexity.

What kind of complexity?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/541023de-42bb-47a5-82d7-d4c35e696443n%40googlegroups.com.

[Bruno Baptista]

Georgios Andrianakis <gand...@redhat.com> escreveu no dia sexta, 17/03/2023 à(s) 09:57:

On Fri, Mar 17, 2023 at 11:39 AM brunobat <brun...@gmail.com> wrote:

We discussed this subject yesterday, at the OTel Java SIG.
Would implement the OTlp exporter using the stock JDK HTTP client would be good enough?

I don't see why not.

 

On the meeting there was concern on creating an SPI for this due to its complexity.

What kind of complexity?

To start with, the person who originally implemented the exporter is no longer part of the project.
It has many layers, many configs and with time, other exporters were created on top of the common functionality using OkHttp. 

I'm taking a deeper look and documenting how it works... 

[Georgios Andrianakis]

On Fri, Mar 17, 2023 at 12:39 PM Bruno Baptista <brun...@gmail.com> wrote:

Georgios Andrianakis <gand...@redhat.com> escreveu no dia sexta, 17/03/2023 à(s) 09:57:

On Fri, Mar 17, 2023 at 11:39 AM brunobat <brun...@gmail.com> wrote:

We discussed this subject yesterday, at the OTel Java SIG.
Would implement the OTlp exporter using the stock JDK HTTP client would be good enough?

I don't see why not.

 

On the meeting there was concern on creating an SPI for this due to its complexity.

What kind of complexity?

To start with, the person who originally implemented the exporter is no longer part of the project.
It has many layers, many configs and with time, other exporters were created on top of the common functionality using OkHttp. 

I'm taking a deeper look and documenting how it works... 

Okay, so no real problems, just a lack of proper abstractions currently.

Thanks

[Roberto Cortez]

Yes, even other exporters provided by OTel, like Jaeger delegate to the Okhttp implementation.

There is already an issue with a similar discussion:

https://github.com/open-telemetry/opentelemetry-java/issues/4777

OTel minimum Java version is 8, so they would also need to support an MR JAR with the JDK 11 implementation and keep something for 8.

There is already a generic SPI for the SpanExporter (used by the default Okhttp implementation), which would allow plugging a Vert.x based exporter, for instance. We may need to try to implement it and propose the missing pieces. Due to the nature of the exporters, which can be over any protocol (not just http), I’m not sure if there is any again in going more specific at the SPI level.

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-kQod2jVr%2BMUuncJbAkFPLg%2BXgaDyKUAb4qxws53vcMpg%40mail.gmail.com.

[Guillaume Smet]

My understanding is that Georgios made progress on this for OpenTelemetry? Is the OpenTelemetry situation completely solved?

If so... and if we drop SmallRye OpenTracing and quarkus-jaeger from the tree, I *think* we could limit our Okhttp exposure to tests and get rid of it in the BOM.

If the answer to the first question is yes, could we consider dropping SmallRye OpenTracing and quarkus-jaeger from the tree for 3.3? In that case, I could start an experiment and see if we could drop it from our BOM.

I'm not completely sure if getting rid of it in our BOM will completely get rid of it in the Platform BOM though as it would still be present in test dependencies. @Alexey Loubyansky WDYT?

--

Guillaume

[Georgios Andrianakis]

On Thu, Jul 20, 2023 at 2:33 PM Guillaume Smet <guillau...@gmail.com> wrote:

My understanding is that Georgios made progress on this for OpenTelemetry? Is the OpenTelemetry situation completely solved?

Yup, OpenTelemetry no longer depends on OkHTTP

--

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/CALt0%2Bo_EDv7zdOsPJWGOd1eF%3DpkzCTvQn%2B1xJZArC3idnEnHSQ%40mail.gmail.com.

[Bruno Baptista]

Hi all,
If no one objects, I'm in favor of dropping SmallRye OpenTracing and quarkus-jaeger.

In the past we already announced that we were going to drop SR OpenTracing but I don't remember doing the same for quarkus-jaeger.

In any case we should drop them. Should we target this for Quarkus 3.3 or 3.4?

Cheers

Bruno Baptista

[Roberto Cortez]

Yes, feel free to drop SR OpenTracing and Jaeger.

Should we move these to Quarkiverse?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/e6d34494-cfa2-4dde-bffd-a240c0d128c2n%40googlegroups.com.

[Bruno Baptista]

Yes, I think we shouldn't just delete the extensions. 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/2D3229DB-C530-4858-8A9D-F092E45EC640%40yahoo.com.

[Georgios Andrianakis]

+1 for removing from core and moving to the quarkiverse

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CADgv5WijiRbHDNM%3DPx1JDVKh72f5F%2BiYmFaNMeX6LyfcQKSSPg%40mail.gmail.com.

[George Gastaldi]

Juat a friendly reminder that before moving to Quarkiverse, it would be nice to make sure someone will actually maintain them and if there is a future for these extensions. Let's avoid ending up with dead extensions in Quarkiverse.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-m%3DGMB%3DA1hd5SLBju8nKsxu4AmMzYmnq1Y-DrB-6ajF0Q%40mail.gmail.com.

[Bruno Baptista]

So... What's the solution?
Marked them as read only or archived in Quarliverse?

Bruno Baptista

https://twitter.com/brunobat_

https://redhat.com

You received this message because you are subscribed to a topic in the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/quarkus-dev/C2b45e5l6l0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJjYgbu1SwO_Zn7wR7hxoEjcD_4-QaASJCnxtZN_Hn_O7g%40mail.gmail.com.

[George Gastaldi]

I'd suggest to mark them as deprecated and remove from core in a future release. No need to move to Quarkiverse if there is no future for them

[Max Rydahl Andersen]

I missed this as backlog from mail during pto.

What was the conclusion of these?

IMO it's fine to have extensions in quarkiverse that is just "last release" rather than remove them.
Really depends on how much usage they had in case someone wants to take it over it's better to have them properly archived than just "vanish".

We already in past defined how we deal with extensions moving out of core:

• move to quarkiverse repo
• setup maven redirects as long as it makes sense (possibly forever)
• let it grow (or archive) independently

Maybe we should write this down somewhere more prominent :)

/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJiv%2BwH0x6FcVtEwgsdtVCw77J8FY0VKJF8V_%2BSD0yqrOg%40mail.gmail.com.

[Bruno Baptista]

I can say that the quarkus-opentelemetry extension after quarkus 3.3.x uses a Vert.x based exporter. No OkHttp anymore.

Bruno Baptista

https://twitter.com/brunobat_

https://redhat.com

[Max Rydahl Andersen]

> I can say that the quarkus-opentelemetry extension after quarkus 3.3.x uses
> a Vert.x based exporter. No OkHttp anymore.

Yes - I got that part; sorry for the ambiguity in my mail.

It was the removal/moving of Smallrye OpenTracing and Jaeger I was asking to.

/max

> Bruno Baptista
> https://twitter.com/brunobat_
> https://redhat.com
>
>
> On Fri, Sep 15, 2023 at 11:14 AM Max Rydahl Andersen <mand...@redhat.com>
> wrote:
>
>> I missed this as backlog from mail during pto.
>>
>> What was the conclusion of these?
>>
>> IMO it's fine to have extensions in quarkiverse that is just "last
>> release" rather than remove them.
>> Really depends on how much usage they had in case someone wants to take it
>> over it's better to have them properly archived than just "vanish".
>>
>> We already in past defined how we deal with extensions moving out of core:
>>

>> - move to quarkiverse repo
>> - setup maven redirects as long as it makes sense (possibly forever)
>> - let it grow (or archive) independently

>>>>>>>>> <https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_EDv7zdOsPJWGOd1eF%3DpkzCTvQn%2B1xJZArC3idnEnHSQ%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/e6d34494-cfa2-4dde-bffd-a240c0d128c2n%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/quarkus-dev/e6d34494-cfa2-4dde-bffd-a240c0d128c2n%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/2D3229DB-C530-4858-8A9D-F092E45EC640%40yahoo.com
>>>>>>> <https://groups.google.com/d/msgid/quarkus-dev/2D3229DB-C530-4858-8A9D-F092E45EC640%40yahoo.com?utm_medium=email&utm_source=footer>
>>>>>>> .

>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bruno Baptista
>>>>>> http://twitter.com/brunobat_
>>>>>> --
>>>>>> 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/CADgv5WijiRbHDNM%3DPx1JDVKh72f5F%2BiYmFaNMeX6LyfcQKSSPg%40mail.gmail.com

>>>>>> <https://groups.google.com/d/msgid/quarkus-dev/CADgv5WijiRbHDNM%3DPx1JDVKh72f5F%2BiYmFaNMeX6LyfcQKSSPg%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/CALeTM-m%3DGMB%3DA1hd5SLBju8nKsxu4AmMzYmnq1Y-DrB-6ajF0Q%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/quarkus-dev/CALeTM-m%3DGMB%3DA1hd5SLBju8nKsxu4AmMzYmnq1Y-DrB-6ajF0Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .

>>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "Quarkus Development mailing list" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/quarkus-dev/C2b45e5l6l0/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> quarkus-dev...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJjYgbu1SwO_Zn7wR7hxoEjcD_4-QaASJCnxtZN_Hn_O7g%40mail.gmail.com

>>>> <https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJjYgbu1SwO_Zn7wR7hxoEjcD_4-QaASJCnxtZN_Hn_O7g%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/CAMmsnJiv%2BwH0x6FcVtEwgsdtVCw77J8FY0VKJF8V_%2BSD0yqrOg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/quarkus-dev/CAMmsnJiv%2BwH0x6FcVtEwgsdtVCw77J8FY0VKJF8V_%2BSD0yqrOg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>

[Bruno Baptista]

Right…

George didn’t what us to move abandonware to Quarkiverse and I can understand that.

Should we move these deprecated extensions to Quarkiverse anyway or should we find another place for them?

Bruno Baptista
http://twitter.com/brunobat_

On 15 Sep 2023, at 11:42, Max Rydahl Andersen <mand...@redhat.com> wrote:



[George Gastaldi]

Having this extension in Quarkiverse means someone will eventually ask for improvements. 

Again, If there are zero plans (and people) to maintain/support it I'd prefer to have it deprecated and removed from core in a later release than to move to Quarkiverse and introduce redirects that nobody will ever test if/when a breaking change in Quarkus comes up.  

Let's not use it as an extension graveyard (maybe we can create a separate org for that?). 

[Guillaume Smet]

I don’t know. 

If we move it to Quarkiverse, keeping them working might be easy anyway and we could do it and community members could do it if we don’t. 

If we drop the extension, that’s not an option. 

Le 15 sept. 2023 à 14:31, George Gastaldi <ggas...@redhat.com> a écrit :



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

[George Gastaldi]

To me “keep them working” implies that the extension is somewhat going to be maintained but I understand this is not the case here. Maybe we haven’t made that clear in the wiki, but one of the requirements of having it in Quarkiverse is that we need someone to be pinged (the extension lead) if a problem in the extension appears (CVEs, Quarkus core API breakages, etc.)   

 

Best Regards,

George Gastaldi

[Bruno Baptista]

I guess that poor fellow would be me, no worries about that.

Bruno

[George Gastaldi]

Ah, that’s fine by me then, let’s do it ;)