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 [email protected] <[email protected]>
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é <[email protected]>
> *Date: *Thursday, April 28, 2022 at 1:23 PM
> *To: *[email protected] <[email protected]>
> *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 [email protected] <[email protected]>
> 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]
>
>
>
>

Reply via email to