Remove/deprecate/downgrade Apache Derby support

[yrodiere]

Description

Hibernate ORM is moving its Derby dialect to "community dialects": https://hibernate.atlassian.net/browse/HHH-18037

In practice, this means using Hibernate ORM with Derby requires an extra Maven dependency, which other supported databases don't require.

I was told this decision stems from Apache Derby not being very active anymore; @sebersole may be able to answer questions about this. From what I can see it does indeed not seem very active, since it got 3 releases in the past 4 years, addressing 22 issues total over those 3 releases / 4 years.

Question is: how do we address this in Quarkus?

Implementation ideas

Ways forward in Quarkus itself when we'll upgrade to Hibernate ORM 7.0:

• Add a dependency to hibernate-community-dialects in the Hibernate ORM extension, and suffer from the potential impact on application size on disk, but preserve the feature as is.
• Introduce a new, unsupported extension for Hibernate ORM community dialects, and move Apache Derby support there. I would put the extension in the Quarkiverse, and call for someone interested in Derby support to maintain it. We could potentially move JDBC support for Derby to the Quarkiverse too (maybe to the same repository?)
• Suggestions?

[yrodiere]

@maxandersen @tqvarnst You will want to know about this.

[gsmet]

We could use a trick similar to what @geoand used for Flyway: https://github.com/quarkusio/quarkus/pull/41583 .

Using this approach, I think things could be transparent for the users.

That being said, maybe we should consider deprecating the Derby support if we think it's not going to be maintained.

Not having commits doesn't mean completely being unmaintained btw, maybe it's good enough for what people use it for?

[yrodiere]

We could use a trick similar to what @geoand used for Flyway: #41583 .

Using this approach, I think things could be transparent for the users.

I have no idea how this works but I like it -- it would indeed be great.

That being said, maybe we should consider deprecating the Derby support if we think it's not going to be maintained.

+1 as I suspect testing in Hibernate ORM will also be less consistent, so compatibility may not be as good as it used to be.

Not having commits doesn't mean completely being unmaintained btw, maybe it's good enough for what people use it for?

Maybe. It also means not many new SQL features get implemented though, meaning more and more features being added to Hibernate ORM will not be implemented for Derby and/or will need to have a completely different implementation. I suspect that has a cost in terms of maintenance in Hibernate ORM.

[geoand]

I have no idea how this works but I like it -- it would indeed be great

It's an awesome feature and if you just copy existing examples, there is nothing to it

[sebersole]

Moving the support to hibernate-community-dialects simply means we won't maintain it, beyond implementing "stubs" for new Hibernate features. We'd expect pull-requests from the community to support this Dialect. We don't have the knowledge nor bandwidth.

[sebersole]

I have no idea how this works but I like it -- it would indeed be great

It's an awesome feature and if you just copy existing examples, there is nothing to it

Very cool

[yrodiere]

Moving the support to hibernate-community-dialects simply means we won't maintain it, beyond implementing "stubs" for new Hibernate features. We'd expect pull-requests from the community to support this Dialect.

That fact that "we won't maintain it" and more importantly (from what I was told) that testing upstream will be limited to the bare minimum is not neutral for downstream integrations. It affects the extent to which we can support Derby in Quarkus.

We don't have the knowledge nor bandwidth.

Completely fair. You'll notice "this decision needs to be reverted in Hibernate ORM" wasn't even on the table.

It doesn't change the fact this has impact downstream, so downstream needs to be made aware of such change, and analyze impact. Which is done.

---

Anyway, conclusion:

• technically the move to another JAR isn't a problem, thanks to @geoand's solution in https://github.com/quarkusio/quarkus/pull/41583
• even if something bad happens and we end up removing support entirely, things should be fine, as @maxandersen showed me numbers proving that Derby use is very marginal among Quarkus users. It's orders of magnitude lower than h2.

[geoand]

technically the move to another JAR isn't a problem, thanks to @geoand's solution in https://github.com/quarkusio/quarkus/pull/41583

I should note that it was @aloubyansky who introduced Conditional Dependencies to Quarkus, I'm just the most common user of them :)