search

FasterXML / jackson-jaxrs-providers

Multi-module project that contains Jackson-based "old" JAX-RS (ones under `javax.ws.rs`) providers for JSON, XML, YAML, Smile, CBOR formats
Apache License 2.0
111 stars 78 forks source link

Missing `MANIFEST.MF` in `jakarta`-classifier artifacts of `JAX-RS providers`, `JAXB annotations` module #160

Closed EldoronTheMighty closed 1 year ago

EldoronTheMighty commented 2 years ago

I just tried installing the following Jackson OSGi Bundles on Karaf (4.4.1)

com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.12.2/jar/jakarta com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.12.2/jar/jakarta com.fasterxml.jackson.module/jackson-module-jaxb-annotations/2.12.2/jar/jakarta

Which resulted in the following error message:
java.io.FileNotFoundException: META-INF/MANIFEST.MF

install-jackson-on-karaf-error.log

So I checked out the following jars hosted at maven central,

which indeed did not include a MANIFEST.MF. The last version I found to have a MANIFEST.MF included was 2.12.2. So my guess here is, that's a bug. Is there any chance an updated jar, at least of version 2.12.7, could be republished?

Please note that this only concerns the Jakarta version. The Javax versions do have a MANIFEST.MF file.

cowtowncoder commented 2 years ago

That is unfortunate, and obviously not something that was intended. One thing that'd help would be seeing if local build from 2.12 branch reproduces the problem -- I have no idea why MANIFEST.MF might be missing, when build succeeds. So republishing would likely only publish similar jars missing the manifest. It would also be good to know if 2.13.3 has similar issue.

But first one question: links you include are for JAX-RS, NOT Jakarta version. Plus one for JAXB annotations module. So which artifacts actually have the problem? Could you update the description with updated links, assuming ones included are not problematic ones.

Right now I am swamped will all kinds of issues so help here would be appreciated: I think in the past OSGi felix bundle plug-in has had some issues once or twice, but I do not remember details unfortunately.

As to republishing: Maven does not allow replacement of artifacts, they are considered immutable. Admins at Sonatype can, technically speaking, physically change things, but that is the last resort and probably not applicable here. Unfortunately publishing a full 2.12.8 set is a big undertaking (2-4 hours) so I'd likely instead want to just publish 2.12.7.1 micro-patch of artifacts needed. And for that would need to know what to publish, and then publish matching micro-patch jackson-bom. No further releases were planned for 2.12 branch so this is mostly useless overhead, aside from fixing this issue.

cowtowncoder commented 2 years ago

Ohhhhhh. It's the jakarta-classifier. With 2.13.x this is changed to eliminate classifier-variant and instead there is separate packages:

So I would actually recommend trying out 2.13 upgrade instead. Given that 2.12.x is the end of jakarta classifier variants (it was a short term attempt at providing upgrade path to solve the whole JAX-vs-Jakarta Royal Mess but did not work out well wrt transitive deps) I don't think I will spend time trying to resolve this. I think the issue, whatever it is, is due to repackaging set up used to create these variants.

cowtowncoder commented 2 years ago

Oh and this is wrong repo since jackson-databind is not affected. Will move to another repo.

EldoronTheMighty commented 2 years ago

Thanks for moving the issue to the correct repository and thanks for responding so quckly.

Unfortunately we can not switch to version 2.13 at the moment. In short it's because Jackson is pulled in as a transitive dependency of RESTeasy, which currently does not support the new jackson-jakarta-rs-json-provider and the adapted jakarta namespace. I'll get a runtime error saying that com.fasterxml.jackson.jaxrs.json.JacksonJaxbJsonProvider is not found, which makes sense since it's not. So unfortunately I'm stuck with using 2.12. and the jakarta classifier.

I fully understand that solving an issue that is actually not relevant anymore, since as you mentioned the classifier solution is not existing in newer versions, has not a high prio to you, but it would be really appreciated if you could anyway try to fix it. A micro patch as version 2.12.7.1 would be perfect.

Thanks for taking the time so far.

cowtowncoder commented 2 years ago

@EldoronTheMighty Ah. Yes, transitive dependencies are tricky. That does complicate things.

I would not mind patch release (and matching bom), but I would need help in figuring out how to resolve the underlying issue.

One thing that I find odd, however, is that it seems to me that RESTeasy should NOT be using jakarta classfier version but the "vanilla" one, if I understand what you are saying correctly. 2.13 provides both "new" (Jakarta-depending one) as well as "old" one (plain JAXB, no classifiers).

EldoronTheMighty commented 2 years ago

Sure thing, I'll try to help where I can. Just need to know what to check, or to do.

So I had a look at the source code from RESTeasy, especially their Jackson-JSON-Provder, especially their pom-File. They specifiy jackson-jaxrs-json-provider as a dependency with the jakarta classifier. Which makes sense I guess since they also had to make the switch to the new jakarta namespace. If I'm not completely wrong newer versions of RESTeasy are not supporting javax anymore (I had a look at the newese release 6.1.0.Final).

Additionally they even exclude the non jakarta version of jackson https://github.com/resteasy/resteasy/blob/main/providers/jackson2/pom.xml#L51

For now they rely on version 2.12.6 of Jackson as can be found here https://github.com/resteasy/resteasy/blob/main/resteasy-dependencies-bom/pom.xml#L19.

cowtowncoder commented 2 years ago

If they do need Jakarta-dependant versions, they should switch dependency to jackson-jakarta-rs-provider package, 2.13(.3). Unfortunately that does mean switching to different artifact id. And it might be possible to do that with exclusions even if RESTeasy itself does not, although granted exclusions can get hairy.

cowtowncoder commented 1 year ago

I don't think there is much to be done here, closing. Please re-file with up-to-date issue information if and as necessary.