Convert Jakarta dependencies to jakarta.* variants

[jesse-gallagher]

trafficstars

These commits move to JEE9 and and MP Config 3, using the recent SmallRye Config releases to work with jakarta.*. In my checking, all tests pass and my current active app works - there shouldn't be functional changes beyond the namespace and dependency updates.

[genie-jnosql]

Can one of the admins verify this patch?

[jesse-gallagher]

Since this compiles cleanly locally, I guess that the build failure here is because the built upstream API is the JEE8-targeted one, which would make sense.

[redmitry]

Hello, IMHO the problem is that jakarta.nosql API still uses javax.json: pom.xml for instance: https://github.com/eclipse-ee4j/nosql/blob/master/api/communication/communication-query/src/main/java/jakarta/nosql/query/JSONQueryValue.java

Dmitry

[jesse-gallagher]

Indeed. I think this is waiting for it to become practical to merge in the jakarta.* move from the API project. Otavio has an original PR for that sitting around, and I have one that expands on it in order to finish some lingering switched Jakarta APIs (like JSON) and XML files.

Once those or an equivalent go in, then this PR would be safe and the builds should start passing.

[redmitry]

Hello,

I am afraid it's not that simple. I have compiled jnosql / nosql, but had to push up some libraries versions of nosql and add more javax.* -> jakarta.* changes to the jnosql.

Here are my observations:

1. nosql should be JEE version agnostic (javax.* vs jakarta.*)
2. the only API dependence is in the JSONQueryValue which may generalized as JSONQueryValue<T> extends QueryValue<T> where T is provided by the implementation of "jnosql".
3. there could be two versions of "jnosql" implementation (javax.* and jakarta.*) the same way as there are for other libraries.
4. all dependencies in the "nosql" that are "javax" specific are used only for the TCK and tests. to compile "nosql" with "jakarta" I pushed up these versions: <jakarta.annotation.version>2.0.0</jakarta.annotation.version> <jakarta.enterprise.cdi.version>3.0.1</jakarta.enterprise.cdi.version> <jakarta.json.bind.version>2.0.0</jakarta.json.bind.version> <jakarta.json.version>2.0.0</jakarta.json.version> <jakarta.validation.version>3.0.1</jakarta.validation.version> but IMO these properties/dependencies must be moved to the TCK / TEST.
5. "jnosql" imports libraries' versions from "nosql" - with (4) must be decoupled.

Cheers,

Dmitry

[jesse-gallagher]

I do think it'd be good for the API to have minimal references to other Jakarta specs for this portability reasons, but there are also a few cases where it uses DI (like Database) and Annotations (like ServiceLoaderProvider).

I haven't looked into using Eclipse Transformer, but perhaps its Maven plugin could help accomplish the goal of writing to javax.* but also producing a jakarta.* build during this transitional period.

[otaviojava]

We're updated to Jakarta EE 10

[mpredli01]

This is awesome!

On Wed, Jan 18, 2023 at 1:35 PM Otávio Santana @.***> wrote:

We're updated to Jakarta EE 10

— Reply to this email directly, view it on GitHub https://github.com/eclipse/jnosql/pull/258#issuecomment-1387537684, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA63D7A7IGMM3IBXEAWIKIDWTAZWVANCNFSM5NQBHXKA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Code, Test, Write, Cycle, Run, Drink, Sleep ... Repeat Director, Garden State JUG https://gsjug.org

Lead Java Queue Editor, InfoQ https://www.infoq.com/ About Me http://about.me/mpredli/ @mpredli https://twitter.com/mpredli redlich.net/

Laissez Les Bon Temps Rouler he/him/his https://medium.com/gender-inclusivit/why-i-put-pronouns-on-my-email-signature-and-linkedin-profile-and-you-should-too-d3dc942c8743