Re: karaf-maven-plugin:verify and sun internal requirements

[ran...@opennms.org]

As far as I can tell (at least in Karaf 4.3, which is what we’re using), there 
are no sun.* exports in jre.properties. (just a subset of com.sun.*)

They are used a bit in the source, but config.properties in the base assembly 
and itests put them into org.osgi.framework.system.packages.extra= rather than 
relying on them being considered a core part of the JRE.

Also, the startup scripts do the jre 9+ add-exports and add-opens stuff on a 
few sun.* things for module-access purposes, but I assume those don’t translate 
into visibility of the packages inside Karaf for resolution purposes.  The 
bundles in the Karaf source that use sun.* APIs (like in diagnostic/boot/) have 
sun.misc;resolution:=optional in the exports, so it probably just happens to 
work without relying on a hard import dependency.

I’ll try to throw together a simple pom project today to make it fail.

--
Benjamin Reed (he/him)
Principal Software Engineer | Raleigh, NC
[signature_2082375981]

From: Jean-Baptiste Onofré 
Date: Saturday, April 30, 2022 at 12:29 AM
To: user@karaf.apache.org 
Subject: Re: karaf-maven-plugin:verify and sun internal requirements
Hi,

verify is based on the list of features it's loading.framework/static feature 
is the base, standard or minimal comes above framework.

So, I would start to check the features list in verify MOJO .

If you can reproduce it on a test case, I can take a look. Else, I will try to 
reproduce (afair, we are using sun.* package in Karaf or Camel features/bundles 
and verify passes).

Regards
JB

On Fri, Apr 29, 2022 at 8:30 PM ran...@opennms.org<mailto:ran...@opennms.org> 
mailto:ran...@opennms.org>> wrote:
It’s quite an extensive list of features, further down our pipeline we’re 
creating a custom Karaf distribution for internal use with the assembly goal.

That said, I have figured out how to make this work after digging into the 
plugin source a bit. It’s a little hacky but does the right thing.

First, I have a custom.properties in the resources directory of my project, 
which contains:

jre-11 = ${jre-10}, \
sun.nio, \
sun.nio.ch<http://sun.nio.ch>, \
sun.nio.cs, \
sun.nio.fs, \
sun.reflect

Second, I use the maven-dependency-plugin:unpack goal to extract 
config.properties and jre.properties from the upstream 
org.apache.karaf:apache-karaf:*:tar.gz into the same target directory that 
resources get put.

Finally, I added this to the verify configuration:

  
file:${project.build.outputDirectory}/config.properties

This way I get the “distribution” config.properties but my own overlaid 
custom.properties to put the extra modules into the list of JRE exports.

I dug around in recent openjdk8 and 11 runtimes and it appears there are a 
decent number of things that are not in the default Karaf jre.properties – I 
don’t know if this is an oversight, or on purpose.

I have no idea why it works at runtime without having to do similar 
jre.properties shenanigans, I haven’t had a chance to dig into Karaf internals 
enough to understand.

Is it worth me submitting a patch with the additional runtime exports?

Thanks,
Ben
--
Benjamin Reed (he/him)
Principal Software Engineer | Raleigh, NC
[signature_414762316]

From: Jean-Baptiste Onofré mailto:j...@nanthrax.net>>
Date: Thursday, April 28, 2022 at 1:23 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org> 
mailto:user@karaf.apache.org>>
Subject: Re: karaf-maven-plugin:verify and sun internal requirements
Hi Ben,

What features repos/features are you using in the karaf-maven-plugin 
configuration ?

Regards
JB

On Thu, Apr 28, 2022 at 4:56 PM ran...@opennms.org<mailto:ran...@opennms.org> 
mailto:ran...@opennms.org>> wrote:
I’m attempting to use karaf-maven-plugin:verify to verify our features files.

They load just fine at runtime, but the verify plugin fails on:

missing requirement [de.ruedigermoeller.fst/2.57.0] osgi.wiring.package; 
filter:="(osgi.wiring.package=sun.nio.ch<http://sun.nio.ch>)"

The sun.nio package doesn’t even appear to be defined in jre.properties, so I’m 
not sure if it’s just something that’s normally inferred from the runtime 
environment without any configuration, but I can’t seem to figure out how to 
make verify accept it without forking fst and making my own fixes to their 
manifest.

Any ideas how to deal with this without doing something hacky like shading? I 
tried wrap: on the fst bundle to override the Import-Package, but I guess wrap 
must not do anything if there’s already valid bundle metadata.

Thanks,
Ben


--
Benjamin Reed (he/him)
Principal Software Engineer | Raleigh, NC
[signature_598361874]

Re: karaf-maven-plugin:verify and sun internal requirements

[Jean-Baptiste Onofré]

Hi,

verify is based on the list of features it's loading.framework/static
feature is the base, standard or minimal comes above framework.

So, I would start to check the features list in verify MOJO
.

If you can reproduce it on a test case, I can take a look. Else, I will try
to reproduce (afair, we are using sun.* package in Karaf or Camel
features/bundles and verify passes).

Regards
JB

On Fri, Apr 29, 2022 at 8:30 PM ran...@opennms.org 
wrote:

> It’s quite an extensive list of features, further down our pipeline we’re
> creating a custom Karaf distribution for internal use with the assembly
> goal.
>
>
>
> That said, I have figured out how to make this work after digging into the
> plugin source a bit. It’s a little hacky but does the right thing.
>
>
>
> First, I have a custom.properties in the resources directory of my
> project, which contains:
>
> jre-11 = ${jre-10}, \
>
> sun.nio, \
>
> sun.nio.ch, \
>
> sun.nio.cs, \
>
> sun.nio.fs, \
>
> sun.reflect
>
>
>
> Second, I use the maven-dependency-plugin:unpack goal to extract
> config.properties and jre.properties from the upstream
> org.apache.karaf:apache-karaf:*:tar.gz into the same target directory
> that resources get put.
>
>
>
> Finally, I added this to the verify configuration:
>
>
>
>
> file:${project.build.outputDirectory}/config.properties
>
>
>
> This way I get the “distribution” config.properties but my own overlaid
> custom.properties to put the extra modules into the list of JRE exports.
>
>
>
> I dug around in recent openjdk8 and 11 runtimes and it appears there are a
> decent number of things that are not in the default Karaf jre.properties
> – I don’t know if this is an oversight, or on purpose.
>
>
>
> I have no idea why it works at runtime without having to do similar
> jre.properties shenanigans, I haven’t had a chance to dig into Karaf
> internals enough to understand.
>
>
>
> Is it worth me submitting a patch with the additional runtime exports?
>
>
>
> Thanks,
>
> Ben
>
> --
>
> *Benjamin Reed* *(he/him)*
> *Principal Software Engineer* *|* Raleigh, NC
> [image: signature_414762316]
>
>
>
> *From: *Jean-Baptiste Onofré 
> *Date: *Thursday, April 28, 2022 at 1:23 PM
> *To: *user@karaf.apache.org 
> *Subject: *Re: karaf-maven-plugin:verify and sun internal requirements
>
> Hi Ben,
>
>
>
> What features repos/features are you using in the karaf-maven-plugin
> configuration ?
>
>
>
> Regards
>
> JB
>
>
>
> On Thu, Apr 28, 2022 at 4:56 PM ran...@opennms.org 
> wrote:
>
> I’m attempting to use karaf-maven-plugin:verify to verify our features
> files.
>
>
>
> They load just fine at runtime, but the verify plugin fails on:
>
> *missing requirement [de.ruedigermoeller.fst/2.57.0] osgi.wiring.package;
> filter:="(osgi.wiring.package=sun.nio.ch <http://sun.nio.ch>)"*
>
> The sun.nio package doesn’t even appear to be defined in jre.properties,
> so I’m not sure if it’s just something that’s normally inferred from the
> runtime environment without any configuration, but I can’t seem to figure
> out how to make verify accept it without forking fst and making my own
> fixes to their manifest.
>
> Any ideas how to deal with this without doing something hacky like
> shading? I tried wrap: on the fst bundle to override the Import-Package,
> but I guess wrap must not do anything if there’s already valid bundle
> metadata.
>
>
>
> Thanks,
>
> Ben
>
>
>
>
>
> --
>
> *Benjamin Reed* *(he/him)*
> *Principal Software Engineer* *|* Raleigh, NC
> [image: signature_598361874]
>
>
>
>

Re: karaf-maven-plugin:verify and sun internal requirements

[ran...@opennms.org]

It’s quite an extensive list of features, further down our pipeline we’re 
creating a custom Karaf distribution for internal use with the assembly goal.

That said, I have figured out how to make this work after digging into the 
plugin source a bit. It’s a little hacky but does the right thing.

First, I have a custom.properties in the resources directory of my project, 
which contains:

jre-11 = ${jre-10}, \
sun.nio, \
sun.nio.ch, \
sun.nio.cs, \
sun.nio.fs, \
sun.reflect

Second, I use the maven-dependency-plugin:unpack goal to extract 
config.properties and jre.properties from the upstream 
org.apache.karaf:apache-karaf:*:tar.gz into the same target directory that 
resources get put.

Finally, I added this to the verify configuration:

  
file:${project.build.outputDirectory}/config.properties

This way I get the “distribution” config.properties but my own overlaid 
custom.properties to put the extra modules into the list of JRE exports.

I dug around in recent openjdk8 and 11 runtimes and it appears there are a 
decent number of things that are not in the default Karaf jre.properties – I 
don’t know if this is an oversight, or on purpose.

I have no idea why it works at runtime without having to do similar 
jre.properties shenanigans, I haven’t had a chance to dig into Karaf internals 
enough to understand.

Is it worth me submitting a patch with the additional runtime exports?

Thanks,
Ben

--
Benjamin Reed (he/him)
Principal Software Engineer | Raleigh, NC
[signature_414762316]

From: Jean-Baptiste Onofré 
Date: Thursday, April 28, 2022 at 1:23 PM
To: user@karaf.apache.org 
Subject: Re: karaf-maven-plugin:verify and sun internal requirements
Hi Ben,

What features repos/features are you using in the karaf-maven-plugin 
configuration ?

Regards
JB

On Thu, Apr 28, 2022 at 4:56 PM ran...@opennms.org<mailto:ran...@opennms.org> 
mailto:ran...@opennms.org>> wrote:
I’m attempting to use karaf-maven-plugin:verify to verify our features files.

They load just fine at runtime, but the verify plugin fails on:

missing requirement [de.ruedigermoeller.fst/2.57.0] osgi.wiring.package; 
filter:="(osgi.wiring.package=sun.nio.ch<http://sun.nio.ch>)"

The sun.nio package doesn’t even appear to be defined in jre.properties, so I’m 
not sure if it’s just something that’s normally inferred from the runtime 
environment without any configuration, but I can’t seem to figure out how to 
make verify accept it without forking fst and making my own fixes to their 
manifest.

Any ideas how to deal with this without doing something hacky like shading? I 
tried wrap: on the fst bundle to override the Import-Package, but I guess wrap 
must not do anything if there’s already valid bundle metadata.

Thanks,
Ben


--
Benjamin Reed (he/him)
Principal Software Engineer | Raleigh, NC
[signature_598361874]

Re: karaf-maven-plugin:verify and sun internal requirements

[Jean-Baptiste Onofré]

Hi Ben,

What features repos/features are you using in the karaf-maven-plugin
configuration ?

Regards
JB

On Thu, Apr 28, 2022 at 4:56 PM ran...@opennms.org 
wrote:

> I’m attempting to use karaf-maven-plugin:verify to verify our features
> files.
>
>
>
> They load just fine at runtime, but the verify plugin fails on:
>
> *missing requirement [de.ruedigermoeller.fst/2.57.0] osgi.wiring.package;
> filter:="(osgi.wiring.package=sun.nio.ch )"*
>
> The sun.nio package doesn’t even appear to be defined in jre.properties,
> so I’m not sure if it’s just something that’s normally inferred from the
> runtime environment without any configuration, but I can’t seem to figure
> out how to make verify accept it without forking fst and making my own
> fixes to their manifest.
>
> Any ideas how to deal with this without doing something hacky like
> shading? I tried wrap: on the fst bundle to override the Import-Package,
> but I guess wrap must not do anything if there’s already valid bundle
> metadata.
>
>
>
> Thanks,
>
> Ben
>
>
>
>
>
> --
>
> *Benjamin Reed* *(he/him)*
> *Principal Software Engineer* *|* Raleigh, NC
> [image: signature_598361874]
>
>
>

karaf-maven-plugin:verify and sun internal requirements

[ran...@opennms.org]

I’m attempting to use karaf-maven-plugin:verify to verify our features files.

They load just fine at runtime, but the verify plugin fails on:

missing requirement [de.ruedigermoeller.fst/2.57.0] osgi.wiring.package; 
filter:="(osgi.wiring.package=sun.nio.ch)"

The sun.nio package doesn’t even appear to be defined in jre.properties, so I’m 
not sure if it’s just something that’s normally inferred from the runtime 
environment without any configuration, but I can’t seem to figure out how to 
make verify accept it without forking fst and making my own fixes to their 
manifest.

Any ideas how to deal with this without doing something hacky like shading? I 
tried wrap: on the fst bundle to override the Import-Package, but I guess wrap 
must not do anything if there’s already valid bundle metadata.

Thanks,
Ben


--
Benjamin Reed (he/him)
Principal Software Engineer | Raleigh, NC
[signature_598361874]