Hi Jim,

Without it,  on JDK11 we will see META-INF.versions.11 from the export
package part, and we don't want it. And this META-INF.versions.11 thing is
from the maven-compiler-plugin in java9-plus profile.
The expected Export-Package should be like
Export-Package:
 org.apache.cxf.tracing;version="4.0.0",
 org.apache.cxf.management.jmx;version="4.0.0",
 org.apache.cxf.management.jmx.type;version="4.0.0",
 org.apache.cxf.management.jmx.export.runtime;version="4.0.0",
 org.apache.cxf.management.utils;version="4.0.0",
 org.apache.cxf.management.persistence;version="4.0.0",
 org.apache.cxf.management.counters;version="4.0.0",
 org.apache.cxf.management.interceptor;version="4.0.0"

The mystery in this profile was introduced in the first place to both
support JDK8 and JDK11. Since for CXF 4.x the minimum JDK version is
JDK11(don't need to consider JDK8 compatible anymore), I believe we are
safe to remove java9-plus profile in management/pom.xml all together.

Cheers
Freeman

On Tue, Apr 19, 2022 at 10:34 PM Jim Ma <mail2ji...@gmail.com> wrote:

> Hi Freeman,
> Do you know why we don't require this with JDK8 and only for JDK9 and plus
> ?
> I see the Export package info in META-INF built with JDK11 without this
> configuration already has this
> export package entry :
>
> Export-Package: org.apache.cxf.tracing;version="3.5.3",org.apache.cxf.
>  management.jmx;version="3.5.3",org.apache.cxf.management.jmx.type;ver
>  sion="3.5.3",org.apache.cxf.management.jmx.export.runtime;version="3.
>  5.3",org.apache.cxf.management.utils;version="3.5.3",org.apache.cxf.m
>  anagement.persistence;version="3.5.3",org.apache.cxf.management.count
>  ers;version="3.5.3",org.apache.cxf.management.interceptor;version="3.
>  5.3",META-INF.versions.11.org.apache.cxf.tracing;version="3.5.3",META
>  -INF.versions.11.org.apache.cxf.management.jmx;version="3.5.3",META-I
>  NF.versions.11.org.apache.cxf.management.jmx.type;version="3.5.3",MET
>  A-INF.versions.11.org.apache.cxf.management.jmx.export.runtime;versio
>  n="3.5.3",META-INF.versions.11.org.apache.cxf.management.utils;versio
>  n="3.5.3",META-INF.versions.11.org.apache.cxf.management.persistence;
>  version="3.5.3",META-INF.versions.11.org.apache.cxf.management.counte
>  rs;version="3.5.3",META-INF.versions.11.org.apache.cxf.management.int
>  erceptor;version="3.5.3"
>
>
> Cheers,
> Jim
>
>
> On Wed, Apr 20, 2022 at 3:04 AM Freeman Fang <freeman.f...@gmail.com>
> wrote:
>
>> Hi Jim,
>>
>> Please change the rt/management/pom.xml like this.
>>
>> <configuration>
>>                              <obrRepository>NONE</obrRepository>
>>                              <instructions>
>> -
>>  
>> <Export-Package>org.apache.cxf.management*,org.apache.cxf.tracing*</Export-Package>
>> +                                <Export-Package>
>> +
>>  org.apache.cxf.management.counters,
>> +
>>  org.apache.cxf.management.interceptor,
>> +
>>  org.apache.cxf.management.persistence,
>> +
>>  org.apache.cxf.management.utils,
>> +
>>  org.apache.cxf.management.jmx,
>> +
>>  org.apache.cxf.management.jmx.export.runtime,
>> +                                                org.apache.cxf.tracing*
>> +                                </Export-Package>
>>                              </instructions>
>>                              <niceManifest>true</niceManifest>
>>                          </configuration>
>> This fine-grained export package can avoid including the package from
>> cxf-core module.
>>
>> Best Regards
>> Freeman
>>
>> On Mon, Apr 18, 2022 at 11:50 PM Jim Ma <mail2ji...@gmail.com> wrote:
>>
>>> Thanks Andriy. Jira is filled :
>>> https://issues.apache.org/jira/browse/CXF-8695
>>> and PRs are sent.
>>>
>>>
>>> On Sun, Apr 17, 2022 at 9:28 AM Andriy Redko <drr...@gmail.com> wrote:
>>>
>>> > Hey Jim,
>>> >
>>> > This is interesting, I believe it is not needed, only some compiler
>>> args
>>> > need
>>> > tailoring (for JDK-11) but the classes should not be copied to
>>> versions/11.
>>> > Thanks!
>>> >
>>> > Best Regards,
>>> >     Andriy Redko
>>> >
>>> > JM> When building cxf-rt-management 3.5.1 with JDK11, some api classes
>>> are
>>> > JM> copied to the jar file. It looks like these classes are copied by
>>> the
>>> > JM> maven-bundle-plugin from java9-plus profile :
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > JM> *<profile>    <id>java9-plus</id>    <activation>
>>> > <jdk>[9,)</jdk>
>>> > JM> </activation>    <build>        <plugins>            <plugin>
>>> > JM>   <groupId>org.apache.felix</groupId>
>>> > JM> <artifactId>maven-bundle-plugin</artifactId>
>>> > JM> <extensions>true</extensions>                <configuration>
>>> > JM>     <obrRepository>NONE</obrRepository>
>>> > <instructions>
>>> >
>>> > JM>
>>> >
>>> <Export-Package>org.apache.cxf.management*,org.apache.cxf.tracing*</Export-Package>
>>> > JM>                   </instructions>
>>> > JM> <niceManifest>true</niceManifest>                </configuration>
>>> > JM>   </plugin-->        </plugins>    </build></profile> *
>>> >
>>> > JM> Why does cxf-rt-management need to copy these classes to the jar
>>> file
>>> > ? Is
>>> > JM> it still needed to duplicate these classes from cxf-core ?
>>> >
>>> > JM> Thanks,
>>> > JM> Jim
>>> >
>>> >
>>>
>>

Reply via email to