You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by "ranger@opennms.org" <ra...@opennms.org> on 2022/04/28 14:56:49 UTC
karaf-maven-plugin:verify and sun internal requirements
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]
Re: karaf-maven-plugin:verify and sun internal requirements
Posted by "ranger@opennms.org" <ra...@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é <jb...@nanthrax.net>
Date: Saturday, April 30, 2022 at 12:29 AM
To: user@karaf.apache.org <us...@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 <configuration/>.
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 ranger@opennms.org<ma...@opennms.org> <ra...@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:
<configuration>file:${project.build.outputDirectory}/config.properties</configuration>
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é <jb...@nanthrax.net>>
Date: Thursday, April 28, 2022 at 1:23 PM
To: user@karaf.apache.org<ma...@karaf.apache.org> <us...@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 ranger@opennms.org<ma...@opennms.org> <ra...@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
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
<configuration/>.
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 ranger@opennms.org <ra...@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:
>
>
>
>
> <configuration>file:${project.build.outputDirectory}/config.properties</configuration>
>
>
>
> 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é <jb...@nanthrax.net>
> *Date: *Thursday, April 28, 2022 at 1:23 PM
> *To: *user@karaf.apache.org <us...@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 ranger@opennms.org <ra...@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
Posted by "ranger@opennms.org" <ra...@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:
<configuration>file:${project.build.outputDirectory}/config.properties</configuration>
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é <jb...@nanthrax.net>
Date: Thursday, April 28, 2022 at 1:23 PM
To: user@karaf.apache.org <us...@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 ranger@opennms.org<ma...@opennms.org> <ra...@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
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 ranger@opennms.org <ra...@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]
>
>
>