Introduce a notion of libraries with descriptor to allow having non extension to be referenced and added

[ia3andy]

          by discussing this with @aloubyansky we may need to introduce a notion of libraries with descriptor to allow having non extension to be registered and referenced (and added through code.quarkus.io and all).

Things like quarkus-junit5 or quarkus-playwright could be added through this.

This is for everything which is for Quarkus and helping on a developer project but are not extensions (deployment/runtime).

Originally posted by @ia3andy in https://github.com/quarkusio/quarkus/issues/26700#issuecomment-1703009832

[ia3andy]

@aloubyansky could you have a look on how difficult this would be?

cc @maxandersen

[aloubyansky]

It needs to be thought out. What are the use-cases? Do we need a descriptor? What would be in it? Could this metadata be maintained outside JARs instead?

[ia3andy]

It needs to be thought out. What are the use-cases? Do we need a descriptor? What would be in it? Could this metadata be maintained outside JARs instead?

The first two uses cases are quarkus-junit5 and quarkus-playwright, any test library implementing QuarkusTestResourceConfigurableLifecycleManager could be in the same situation.

I guess anything that is related to Quarkus, but doesn't fit in the runtime/deployment could fit.

The descriptor is important as it contains the library info for the tooling, the only pre-requisite is to have it indexed in the tooling.

[aloubyansky]

Would those libraries be "accompanying" Quarkus extensions for better dev experience? Could this info be added to those extensions instead? There a could be other libraries that we don't control that possibility could fit these used cases.

[ia3andy]

Would those libraries be "accompanying" Quarkus extensions for better dev experience? Could this info be added to those extensions instead? There a could be other libraries that we don't control that possibility could fit these used cases.

Yes that could be a possibility (as an option of course), but quarkus-junit5 would be accompanying all the extensions (which is alright I guess).

So when you would pick an extension we would suggest adding those companions in the tooling (For the CLI it would be logged)?

[ia3andy]

> quarkus ext add quinoa
Quinoa has been added.

To help test/develop with Quinoa, we suggest using "quarkus-playwright" and " quarkus-junit5".

I am not sure, @maxandersen any thoughts?

[maxandersen]

I grok why playwright is usefull but remind what quarkus-junit5 does "special" for quinoa?

[ia3andy]

I grok why playwright is usefull but remind what quarkus-junit5 does "special" for quinoa?

it's for any extension, nothing special for Quinoa.

[maxandersen]

okey, so we already today add quarkus-junit5 by default - I'm assuming you are suggesting to have this expanded to be more generic and can add others.

I can see the appeal but also see it being annoying/problematic if added automatically.

Especially as we really don't want users to add extensions they don't need.

I would say when https://github.com/quarkusio/quarkus/issues/26700 becomes a reality and extensions can express what scope they make sense in (i.e. test) then its less of a concern; but even then I wouldn't think always adding playwright would be meaningful when adding quinoa as playwright is quite a massive dependency.

That said, having a way for extensions to express suggestions for extensions that can be shown or included could be useful for sure.

But mainly a nice to have I would say.

Got examples of others than just the one for quinoa and playwright?

[aloubyansky]

This is not exactly about extensions @maxandersen it's about "relevant JAR dependencies".

[melloware]

I just ran into this as well trying to make my MailPit DevService also have an accompanying Test helpers to allow integration testing against the running Dev Service go smoother similar to what Andy is trying to do with Playwright.

https://github.com/quarkiverse/quarkus-mailpit