Resteasy vs Jakarta APIs

[Sanne Grinovero]

When we recently discussed the possibility of the upgrade to Resteady
v4 there was a concern about it switching to the Jakarta EE API
artifacts.

We discussed various possible solutions, but I'm surprised to see now
that the change which was applied isn't the one I recall being the
agreed preference: the extension is excluding the Jakarta APIs,
preferring to use
org.jboss.spec.javax.xml.bind:jboss-jaxb-api_2.3_spec .

It's confusing as changelog of 0.27.0 even reads:
- [4907] Upgrade to Hibernate Validator 6.1.0.Final, RESTEasy
4.4.0.CR1 and move to Jakarta artifacts

Was there an intentional change of mind? I don't like it particularly,
as we had other specs move to Jakarta (as mentioned previously) and
this seems to go in the wrong direction.

In particular, it ties my hands in trying to solve little usability
parpercuts like:
- https://github.com/quarkusio/quarkus/issues/1394
- https://github.com/rest-assured/rest-assured/issues/1226

Thanks
Sanne

[Guillaume Smet]

No, there wasn't a change of mind and I explained it a while back: we are using Jakarta artifacts except for JAXB API and JAX-RS API.

These two JBoss ones are indeed rebranded Jakarta artifacts + JBoss modules/SM related fixes that are not in Jakarta (yet?).

if we don't do that, we have a conflict as soon as a user adds a RESTEasy optional artifact as a lot of them depend either on the JAXB API or JAX-RS or both - and it's a very common use case: this was even the main reason why we did move to Jakarta artifacts. I discussed this a bit with Alessio and for now I think it's the best compromise we can have as RESTEasy only has partially moved to vanilla Jakarta artifacts.

In the long term, I would like to get rid of them and move these ones to standard Jakarta artifacts but Alessio told me they were not there yet on the RESTEasy side and they will need to push some patches to Jakarta (and they would need to be accepted).

Another option to fix this would be to rewrite the artifacts on the fly when building the dependency tree but this is post 1.0.

-- 

Guillaume

--
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/CAFm4XO3H%2Bg7NjhYauieqXgEsG8g%3D%2BefZp4R5-KiWt3JuJGXFpw%40mail.gmail.com.

[Sanne Grinovero]

On Wed, 13 Nov 2019 at 17:57, Guillaume Smet <guillau...@gmail.com> wrote:
>
> No, there wasn't a change of mind and I explained it a while back: we are using Jakarta artifacts except for JAXB API and JAX-RS API.
> These two JBoss ones are indeed rebranded Jakarta artifacts + JBoss modules/SM related fixes that are not in Jakarta (yet?).
>
> if we don't do that, we have a conflict as soon as a user adds a RESTEasy optional artifact as a lot of them depend either on the JAXB API or JAX-RS or both - and it's a very common use case: this was even the main reason why we did move to Jakarta artifacts. I discussed this a bit with Alessio and for now I think it's the best compromise we can have as RESTEasy only has partially moved to vanilla Jakarta artifacts.

Ok but we did discuss all this and AFAIR the conclusion was that it
was fine to have RESTEasy use the Jakarta APIs as well, as there's
various solutions to avoid the conflict which aren't that hard to
implement.
So while I can trust you probably had reasons, it still confused me
and I wonder why you discarded the solution we discussed.

> In the long term, I would like to get rid of them and move these ones to standard Jakarta artifacts but Alessio told me they were not there yet on the RESTEasy side and they will need to push some patches to Jakarta (and they would need to be accepted).

Odd, so why is Resteasy "upstream" using Jakarta and yet it's not good
enough for us?

> Another option to fix this would be to rewrite the artifacts on the fly when building the dependency tree but this is post 1.0.

Ok, thanks for updating us.

[Guillaume Smet]

Hi,

On Thu, Nov 14, 2019 at 9:40 AM Sanne Grinovero <sa...@hibernate.org> wrote:

On Wed, 13 Nov 2019 at 17:57, Guillaume Smet <guillau...@gmail.com> wrote:
>
> No, there wasn't a change of mind and I explained it a while back: we are using Jakarta artifacts except for JAXB API and JAX-RS API.
> These two JBoss ones are indeed rebranded Jakarta artifacts + JBoss modules/SM related fixes that are not in Jakarta (yet?).
>
> if we don't do that, we have a conflict as soon as a user adds a RESTEasy optional artifact as a lot of them depend either on the JAXB API or JAX-RS or both - and it's a very common use case: this was even the main reason why we did move to Jakarta artifacts. I discussed this a bit with Alessio and for now I think it's the best compromise we can have as RESTEasy only has partially moved to vanilla Jakarta artifacts.

Ok but we did discuss all this and AFAIR the conclusion was that it
was fine to have RESTEasy use the Jakarta APIs as well, as there's
various solutions to avoid the conflict which aren't that hard to
implement.
So while I can trust you probably had reasons, it still confused me
and I wonder why you discarded the solution we discussed.

No there's not. And I didn't discard anything we discussed. See below.

 

> In the long term, I would like to get rid of them and move these ones to standard Jakarta artifacts but Alessio told me they were not there yet on the RESTEasy side and they will need to push some patches to Jakarta (and they would need to be accepted).

Odd, so why is Resteasy "upstream" using Jakarta and yet it's not good
enough for us?

That's what you didn't understand: RESTEasy upstream uses vanilla Jakarta artifacts *except* for those two where it uses the rebranded JBoss artifacts which were updated to Jakarta. As previously stated, they need that for SM and JBoss modules support. We don't really need that in Quarkus so we could have taken the risk to use the vanilla Jakarta artifacts there too but... these dependencies are present in a lot of the optional RESTEasy artifacts that end users add to their projects.

So that would mean conflicting dependencies for our users and they would need to fix them themselves. Except if we provide a solution to somehow rewrite these dependencies when resolving them and this was out of the scope of this work (and might come with all sorts of new problems so it needs to be very carefully designed and tested and I'm pretty sure we will need Alexey's expertise on this).

FWIW, the rationale was explained in the original PR description so it shouldn't be a surprise: https://github.com/quarkusio/quarkus/pull/4907 . For the record, I started by migrating everything to Jakarta and had a branch ready for that and then got back to what I think is the best compromise for our users.

--

Guillaume

[William Burke]

IMO, you should keep backward compatibility with artifact names.  These artifacts have not changed in a decade!

--

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/CALt0%2Bo_Uz106dFbObTibWsp7F3Qwo4Kq0qGX5U2-L21TUZp6hQ%40mail.gmail.com.

--

Bill Burke

Red Hat