Allow parsing jakarta.rs applications

[fwiesweg]

I migrated our application to the new jakarta.ws.rs namespace from the old javax.ws.rs and noticed the typescript-generator has not yet added support for it. So I went ahead and basically copied the javax scanner and parser along with the respective tests, making adjustments where necessary.

It's a bit of an ugly solution since it duplicates test and library code, and there are prettier solutions out there (e.g., FasterXML's jackson uses the maven-shading-plugin [1] and maven classifiers), but in this case, I found it worthwhile to support both jaxrs and jakarta from the same jar, in case a dependent application needs to generate TS from both specs at the same time, since they are not mutually exclusive.

FasterXML/jackson-datatypes-misc#11

[vojtechhabarta]

This situation with changed packages of JAX-RS is really unfortunate. Similar problem is with JAXB and JSON-B. To be honest I am not much happy with copy-paste solution. But currently I don't know how to deal with this situation.

[fwiesweg]

No, we're all quite unhappy about it. We could theoretically fix it using automatic code generation, but that's not straightforward to fix. The above mentioned repo recently also ended up merging the copy-paste-solution instead of the maven-shade-plugin because it broke something somewhere down the line.

I think it's justified in this case since you can (theoretically) have a jakarta.ws.rs.core.Application and a javax.ws.rs.core.Applicationin the same application without causing conflicts, and you might want to create typescript interfaces from both of them.

[vojtechhabarta]

In 1d533d9 I improved JAX-RS support so it handles both V2 and V3 (javax and jakarta).
@fwiesweg do you want to check it before the release?

[fwiesweg]

Dear Vojtěch,

tested it and works for me, so I certainly wouldn't mind this being released. Thanks a lot!

If you don't mind a proposal, I would probably have maintained to different set of annotations, to be chosen between based on the type of the Application object passed in: if it's a javax Application, I would then have used the javax set consistently, and otherwise the jakarta one, to have clear semantics in case both the javax and jakarta annotations are present on an object, at the expense of having to pass a jakarta/javax flag all the way down.

We're having a flagday migration, so such edge cases don't affect me, but maybe there's someone else doing a piecewise migration? Well, it's probably not be worth the effort right now.

Thanks again for the work, your generator is very helpful! If you happen to pass by Berlin, drop me a message for a beer ;)

Best,
Florian

[vojtechhabarta]

Thanks for warm words 🙂

You are right that whole application should use either javax or jakarta annotations consistently. I tested how Jersey works and it really only considers annotations corresponding to one used on Application.

But I hope it is not a big problem so I will release it as it is now and let's see if there is a demand for improvements.