search

jakartaee / jaf-api

Jakarta Activation Specification project
https://jakartaee.github.io/jaf-api/
BSD 3-Clause "New" or "Revised" License
31 stars 33 forks source link

jakarta.activation-api is not a Multi Release JAR #122

Open aalmiray opened 1 year ago

aalmiray commented 1 year ago

Describe the bug Latest jakarta.activation-api (2.1.1) includes 3 classes compiled to bytecode 53 and 44 classes compiled to bytecode 52. All classes are found in the unversioned space which means enforcer rules for both Maven and Gradle will trigger and fail a build.

To Reproduce Steps to reproduce the behavior:

  1. Get jarviz 
    $ jarviz bytecode show --gav jakarta.activation:jakarta.activation-api:2.1.1
Unversioned classes. Bytecode version: 52 total: 44
Unversioned classes. Bytecode version: 53 total: 3

If the --details flag is added you get the names of the 3 classes causing trouble

Unversioned classes. Bytecode version: 53 total: 3
jakarta.activation.spi.package-info
jakarta.activation.package-info
module-info

Expected behavior These 3 classes should be inside /META-INF/versions/9. The JAR's manifest should have a manifest entry such as Multi-Release: true

https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#multi-release-jar-files

jhanders34 commented 1 year ago

Activation 2.1 is part of Jakarta EE 10 so the classes all should be Java 11 byte code, i.e. version 55, shouldn't it?

lukasj commented 1 year ago

Activation 2.1 is part of Jakarta EE 10 so the classes all should be Java 11 byte code, i.e. version 55, shouldn't it?

right, that is the requirement. OTOH we want mail, which depends on activation, to be able to support SE 8/Android

aalmiray commented 1 year ago

Normally I'd suggest using the moditect-maven-plugin to manage module-info.class in such a way that it can be versioned while still keeping Java 8 compatibility. However, in this case there are 2 additional package-info.class entries that are also compiled with Java 9.

IF these two additional classes must remain Java 9+ then moditect will be of little use. Instead, the build must be updated to support 2 source trees, probably add toolchains or expect the build to be invoked with a Java 9+ JDK as a requirement.

jhanders34 commented 1 year ago

jaxb API had to deal with this as well: https://github.com/jakartaee/jaxb-api/blob/3.0.1/jaxb-api/pom.xml#L214 should help give some ideas on how to do it.

lukasj commented 1 year ago

package info part of the problem is caused by a backward incompatible change in maven compiler plugin v 3.10.0