Skip to content

Commit

Permalink
Introduce ADR for renaming Reactive extensions
Browse files Browse the repository at this point in the history
  • Loading branch information
geoand committed Oct 22, 2023
1 parent 2b26502 commit 1aed8ba
Showing 1 changed file with 73 additions and 0 deletions.
73 changes: 73 additions & 0 deletions adr/0002-reactive-rename.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
= Rename Reactive extensions

* Status: proposed
* Date: 2023-10-17
== Context and Problem Statement

RESTEasy Reactive is the preferred REST stack in Quarkus, however in the almost 3 years since its release, we have seen
folks of all experience misunderstand its capabilities and being led to believe that it forces reactive programming on them.

With the advent of Virtual Threads in Java 19+, the problem becomes larger since in the minds of users, Reactive and Virtual Threads
are two different worlds.

The same problem applies to other extensions as well:

* Reactive Messaging
* Reactive Routes
* REST Client Reactive

The common theme here is that these extensions can work equally well with reactive and blocking code, but their name confuses users.

We have tried to clarify the situation with blog posts, talks and on the various communication channels, but there seems to be
no escaping the fact that "reactive" in the name primes people in a non-desirable way.


== Considered options

=== Do nothing

We can continue with the current situation, but that feels less than ideal given the recurrence of the problem.

=== Break users

We could simply rename the extensions without providing any backward compatibility with the old maven modules.
This would likely cause a lot of pain - even in the presence of the Quarkus CLI update process, a lot of users won't use it.

=== Maintain compatibility

We can come up with new names for the Quarkus extensions while also providing Maven relocations for the existing artifacts.
This way users will be able to adapt to the new names at their own pace.

Another option would be to create new extensions that simply include the existing ones, but this does not seem to provide
any real benefit over relocations.

==== REST Client

The Reactive REST Client is a special case, because although clearly the best name to use is `quarkus-rest-client`, unfortunately
that name is already taken by the legacy REST Client implemented in RESTEasy Classic.


== Decision

* Rename all `quarkus-resteasy-reactive*` maven modules to `quarkus-rest*`
* Rename all `quarkus-rest-client-reactive*` maven modules to `TODO`
** Rename all legacy `quarkus-rest-client-` to `TODO`
** Also rename the extensions that rely on the REST Clients (like Keycloak Admin Client extensions)
* Rename all `quarkus-smallrye-reactive-messaging-` maven modules to `quarkus-messaging-`
* Rename all `quarkus-reactive-routes-` maven modules to `quarkus-http-routes-`
* No Java code changes should be made - all code should continue to reside in the same packages
* Introduce Maven relocations to allow for users not updating their poms
* Introduce a recipe that the Quarkus CLI can use during update
* Update quickstarts
* Update codestarts
* Update tooling to indicate proper older / newer relationship
* Write a new blog post explaining why we made the change
* Update old blog posts to mention the new name
* Update prominent Quarkus demo application and workshops

== Consequences

* On the plus side, conveying the actual capabilities (blocking, non-blocking, Virtual Threads) of our stack should become easier.
** Furthermore, the new name aligns quite nicely with Java EE's Jakarta REST
* On the minus side, renaming is always confusing for users.

0 comments on commit 1aed8ba

Please sign in to comment.