karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KARAF-4306) karaf-maven-plugin is not assembling the correct version of dependencies
Date Fri, 10 Feb 2017 08:09:41 GMT

    [ https://issues.apache.org/jira/browse/KARAF-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860899#comment-15860899

Guillaume Nodet commented on KARAF-4306:

I think this will be the case if you move the features to the startup stage.
There are 3 stages:
  * startup: the builder uses the OSGi resolver, computes the list of bundles and write them
in the etc/startup.properties
  * boot: the feature service will install those features at first boot
  * install: the bundles required by the features will be put into the system repository but
not installed

If you put a feature in the boot stage, all matching bundles will be downloaded by the feature
service, that's why they are put in the system repo.  If you move it at startup stage, the
bundles will be directly installed and only the list that has been computed at build time
is needed.

> karaf-maven-plugin is not assembling the correct version of dependencies
> ------------------------------------------------------------------------
>                 Key: KARAF-4306
>                 URL: https://issues.apache.org/jira/browse/KARAF-4306
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-tooling
>    Affects Versions: 4.0.4
>            Reporter: Raman Gupta
>            Assignee: Jean-Baptiste Onofré
>             Fix For: 4.0.9, 4.1.1
> This is similar to KARAF-3994.
> I see that the commit for that issue added the following TODO:
> * TODO Need to also check for version ranges. Currently ranges are ignored and all features
matching the name
> I have a similar problem -- the generated system repo contains all versions of a feature
that is matched by a range, not just the highest one that fulfills all of the requirements
of the boot features. This is an issue because the generated repo may contain older (or newer)
versions of libraries that have CVEs against them, which is then flagged by ops.
> For example:
> My feature depends on spring-dm which depends on spring range [2.5.6,4). At runtime,
Karaf only needs and uses Spring 3.2.14, but my system repo contains Spring 3.1.4 (as well
as three versions of Spring 4), all of which are defined in the Karaf Spring repo. And of
course, Spring 3.1.4 has CVEs against it, so the system is flagged by ops as using jars with
security problems (even though those jars are not actually used by the app).
> Shouldn't the Builder apply the same resolution logic as is used by Karaf itself, and
assemble only those jars?

This message was sent by Atlassian JIRA

View raw message