Disabling build steps from Hibernate and Agroal Extensions

[Pedro Igor]

Hi,

In Keycloak, we should be able to support different types of storage, and using a database is no longer mandatory. For instance, it should be possible to completely replace a database with in-memory map-based storage.

I would like to know if it makes sense to use conditional build steps to enable/disable both Hibernate and Agroal extension steps when *re-augmenting* [1] the application so that we can completely disable build steps from these extensions.

[1] https://quarkus.io/guides/reaugmentation

Thanks.

Pedro Igor

[Thomas Darimont]

That would be great to have. This would also help to trim down keycloak distributions.

The quarkus based Keycloak distribution also ships with support for multiple databases (H2, PostgreSQL, MySQL, etc.). However, most of the time the database is fixed to one type, e.g. PostgreSQL. In this case the reaugmentation could also be used to remove / disable the unused database types.

--
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/f35a017f-89ba-4576-a530-6f4342a06a8dn%40googlegroups.com.

[Yoann Rodiere]

Hi,

Hibernate Search (so, another extension, not what you're using) already has a property named `quarkus.hibernate-search-orm.enabled` [1], but it's used to disable the extension at runtime. I believe other extensions have this as well, or at least I've seen requests for such features in other extensions. But so far, I've only seen this requested as a runtime flag, which obviously requires that build steps always be executed (just in case the extension is enabled at runtime).

Now, about disabling build steps... I suspect this has been discussed before, but I don't have the history in mind, so I'll let others (Sanne?) answer as to whether we can/want to do this or not.

I can start bike-shedding though, so here you go :)

If we end up adding this feature, and if we end up using an `enabled` property to control this feature (like in Hibernate Search), then I think the property should work both at build time and at runtime, for consistency, and because I think disabling stuff at runtime is a more widespread use case.

We would  have an `enabled` property that would default to `true`. If set to `false` at build time, then it's definitive, you can't set it back to true at runtime (you would get an exception on bootstrap). If it stays to the default value or is set to `true`, then you can still set it to `false` at runtime.

[1] https://quarkus.io/guides/hibernate-search-orm-elasticsearch#quarkus-hibernate-search-orm-elasticsearch_quarkus.hibernate-search-orm.enabled

Yoann Rodière

Hibernate Team

yo...@hibernate.org

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAK-7U1jBqdhV8tgbaE46AgGSTfZU9EvWV-DPzhv9yreUUTfxsQ%40mail.gmail.com.

[Pedro Igor]

Thanks, Yoann.

What I'm looking for is a property similar to yours. Good to know Hibernate Search has this option so perhaps it makes sense to also have something similar in HHH.

 

I might be wrong, but it seems that conditional steps also affect the build so steps are ignored depending on their condition. In our case, we need build steps excluded from re-augmentation because Keycloak is a mutable application.

Right now, we managed to achieve our goal (avoid bootstrapping EMF/DS) by conditionally creating our PU in our extension. That seems to be enough to "disable" the extension because there would be no JPA model to process.

[Yoann Rodiere]

I might be wrong, but it seems that conditional steps also affect the build so steps are ignored depending on their condition

In the case of Hibernate Search at least, I think that's wrong. As far as I can see, `enabled` in Hibernate Search is a runtime property, and it's only used to disable Hibernate Search at runtime and to prevent the creation of a few CDI beans (still at runtime). There's also a few bits about the Dev UI, but that's runtime too, and that's beside the point.

The build steps are executed even if `enabled` is `false`, because `enabled` is evaluated after the build (at runtime).

Anyway. Yes, it seems what you need would be similar to what we have in Hibernate Search, but not exactly identical, due to the need to apply the setting at build time.

In our case, we need build steps excluded from re-augmentation because Keycloak is a mutable application.

Do you mean you want the steps included in initial augmentation but disabled during re-augmentation? If there was an `enabled` property for Hibernate ORM/Agroal and working as I explained in my previous message, you could do that simply by setting it to false during re-augmentation.

Still, we're already talking about a technical solution, but:

I don't have the history in mind, so I'll let others (@Sanne Grinovero ?) answer as to whether we can/want to do this or not.

 

Yoann Rodière

Hibernate Team

yo...@hibernate.org

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/1cd56e47-bfb2-43e1-b287-8626f07a8f24n%40googlegroups.com.

[Pedro Igor]

Thanks, Yoann.

Yes, right now the server default is to use a database and we need the steps during the 1st augmentation.

As I mentioned before, we were able to achieve this by conditionally producing our default PU. If this approach is fine we can move forward with it ...