[jira] [Created] (FELIX-6399) Reduce resource consumption during component checks
Carsten Ziegeler created FELIX-6399: --- Summary: Reduce resource consumption during component checks Key: FELIX-6399 URL: https://issues.apache.org/jira/browse/FELIX-6399 Project: Felix Issue Type: Improvement Components: System Ready Affects Versions: systemready-0.4.2 Reporter: Carsten Ziegeler Fix For: systemready-0.4.3 the components readycheck is each time (every 5 secs) iteration over all DS components just to check for a few. The iteration includes access to the service registry which (in Felix framework 6.x) has a lock There are two optimizations: - components check should only check for the configured ones instead of iterating over all components just to find the ones interested in - the resultcan be cached until an event occurs (service changed event of the SCR runtime as the runtime has a change count property to exactly avoid polling) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6401) Add deprecation annotations to systemready api
Carsten Ziegeler created FELIX-6401: --- Summary: Add deprecation annotations to systemready api Key: FELIX-6401 URL: https://issues.apache.org/jira/browse/FELIX-6401 Project: Felix Issue Type: Improvement Components: System Ready Reporter: Carsten Ziegeler Fix For: systemready-0.4.3 As the systemready api is superseeded by health checks, the api should be marked as such -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6400) Reduce resource consumption during component checks
[ https://issues.apache.org/jira/browse/FELIX-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-6400: Component/s: (was: System Ready) Health Checks > Reduce resource consumption during component checks > --- > > Key: FELIX-6400 > URL: https://issues.apache.org/jira/browse/FELIX-6400 > Project: Felix > Issue Type: Improvement > Components: Health Checks >Affects Versions: healthcheck.generalchecks 2.0.6 >Reporter: Carsten Ziegeler >Priority: Major > Fix For: systemready-0.4.3 > > > the components health check is each time (every 5 secs) iteration over all DS > components just to check for a few. The iteration includes access to the > service registry which (in Felix framework 6.x) has a lock > There are two optimizations: > - components check should only check for the configured ones instead of > iterating over all components just to find the ones interested in > - the resultcan be cached until an event occurs (service changed event of the > SCR runtime as the runtime has a change count property to exactly avoid > polling) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6400) Reduce resource consumption during component checks
[ https://issues.apache.org/jira/browse/FELIX-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-6400: Fix Version/s: (was: systemready-0.4.3) healthcheck.generalchecks 2.0.8 > Reduce resource consumption during component checks > --- > > Key: FELIX-6400 > URL: https://issues.apache.org/jira/browse/FELIX-6400 > Project: Felix > Issue Type: Improvement > Components: Health Checks >Affects Versions: healthcheck.generalchecks 2.0.6 >Reporter: Carsten Ziegeler >Priority: Major > Fix For: healthcheck.generalchecks 2.0.8 > > > the components health check is each time (every 5 secs) iteration over all DS > components just to check for a few. The iteration includes access to the > service registry which (in Felix framework 6.x) has a lock > There are two optimizations: > - components check should only check for the configured ones instead of > iterating over all components just to find the ones interested in > - the resultcan be cached until an event occurs (service changed event of the > SCR runtime as the runtime has a change count property to exactly avoid > polling) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6400) Reduce resource consumption during component checks
[ https://issues.apache.org/jira/browse/FELIX-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-6400: Affects Version/s: (was: systemready-0.4.2) healthcheck.generalchecks 2.0.6 > Reduce resource consumption during component checks > --- > > Key: FELIX-6400 > URL: https://issues.apache.org/jira/browse/FELIX-6400 > Project: Felix > Issue Type: Improvement > Components: System Ready >Affects Versions: healthcheck.generalchecks 2.0.6 >Reporter: Carsten Ziegeler >Priority: Major > Fix For: systemready-0.4.3 > > > the components health check is each time (every 5 secs) iteration over all DS > components just to check for a few. The iteration includes access to the > service registry which (in Felix framework 6.x) has a lock > There are two optimizations: > - components check should only check for the configured ones instead of > iterating over all components just to find the ones interested in > - the resultcan be cached until an event occurs (service changed event of the > SCR runtime as the runtime has a change count property to exactly avoid > polling) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6400) Reduce resource consumption during component checks
[ https://issues.apache.org/jira/browse/FELIX-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-6400: Description: the components health check is each time (every 5 secs) iteration over all DS components just to check for a few. The iteration includes access to the service registry which (in Felix framework 6.x) has a lock There are two optimizations: - components check should only check for the configured ones instead of iterating over all components just to find the ones interested in - the resultcan be cached until an event occurs (service changed event of the SCR runtime as the runtime has a change count property to exactly avoid polling) was: the components readycheck is each time (every 5 secs) iteration over all DS components just to check for a few. The iteration includes access to the service registry which (in Felix framework 6.x) has a lock There are two optimizations: - components check should only check for the configured ones instead of iterating over all components just to find the ones interested in - the resultcan be cached until an event occurs (service changed event of the SCR runtime as the runtime has a change count property to exactly avoid polling) > Reduce resource consumption during component checks > --- > > Key: FELIX-6400 > URL: https://issues.apache.org/jira/browse/FELIX-6400 > Project: Felix > Issue Type: Improvement > Components: System Ready >Affects Versions: systemready-0.4.2 >Reporter: Carsten Ziegeler >Priority: Major > Fix For: systemready-0.4.3 > > > the components health check is each time (every 5 secs) iteration over all DS > components just to check for a few. The iteration includes access to the > service registry which (in Felix framework 6.x) has a lock > There are two optimizations: > - components check should only check for the configured ones instead of > iterating over all components just to find the ones interested in > - the resultcan be cached until an event occurs (service changed event of the > SCR runtime as the runtime has a change count property to exactly avoid > polling) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6400) Reduce resource consumption during component checks
Carsten Ziegeler created FELIX-6400: --- Summary: Reduce resource consumption during component checks Key: FELIX-6400 URL: https://issues.apache.org/jira/browse/FELIX-6400 Project: Felix Issue Type: Improvement Components: System Ready Affects Versions: systemready-0.4.2 Reporter: Carsten Ziegeler Fix For: systemready-0.4.3 the components readycheck is each time (every 5 secs) iteration over all DS components just to check for a few. The iteration includes access to the service registry which (in Felix framework 6.x) has a lock There are two optimizations: - components check should only check for the configured ones instead of iterating over all components just to find the ones interested in - the resultcan be cached until an event occurs (service changed event of the SCR runtime as the runtime has a change count property to exactly avoid polling) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [felix-dev] abhishekgarg18 opened a new pull request #73: adding test cases for CQ-4318856
abhishekgarg18 opened a new pull request #73: URL: https://github.com/apache/felix-dev/pull/73 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315535#comment-17315535
]
Tom Watson commented on FELIX-6398:
---
Yes, that is the documentation I pointed to. I just wanted to clarify that it
would not be the normal recommended default to do that.
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Framework Security, Resolver
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315513#comment-17315513
]
Carsten Ziegeler commented on FELIX-6398:
-
[~tjwatson] Afaik you can configure bnd to include the micro version on the
import and I know projects are doing this .. :(
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Framework Security, Resolver
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315510#comment-17315510
]
Tom Watson commented on FELIX-6398:
---
Not arguing against fixing this, it needs fixed ... but what build tool encodes
a range down to the micro-version when compiling against the API JAR? I
thought BND only produced ranges down to the minor version on imports by
default: [https://bnd.bndtools.org/instructions/consumer_policy.html]
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Framework Security, Resolver
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-6398.
---
Resolution: Fixed
Done in
https://github.com/apache/felix-dev/commit/00c952340e51b9748d84cc63d1048d833f0a3cff
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Framework Security, Resolver
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6398:
--
Component/s: Resolver
Framework Security
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Framework Security, Resolver
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-6140) possible deadlock in ResolverImpl.EnhancedExecutor.await()
[ https://issues.apache.org/jira/browse/FELIX-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6140. - > possible deadlock in ResolverImpl.EnhancedExecutor.await() > -- > > Key: FELIX-6140 > URL: https://issues.apache.org/jira/browse/FELIX-6140 > Project: Felix > Issue Type: Bug > Components: Resolver >Affects Versions: resolver-2.0.0, resolver-1.16.0 >Reporter: Tom Watson >Assignee: Tom Watson >Priority: Major > Fix For: resolver-2.0.2 > > > The org.apache.felix.resolver.ResolverImpl.EnhancedExecutor class is used by > the ResolverImpl in order to run tasks in parallel during a resolve process. > When there is work that can happen in parallel the resolver will compute a > number of tasks and dispatch each task to the executor and then await for all > the tasks to complete. To do this the current code uses an AtomicInteger to > count up the number of tasks and then waits for each task to decrement the > count back to zero. > The way the code builds up the tasks recursively leaves it open to > incrementing the count and then getting some system failure. For example an > OutOfMemoryException, or before OSGi R7 we used to have the executor throw a > runtime exception on timeout. > This can make it such that the count will never reach zero and we end up > hanging. > See https://bugs.eclipse.org/bugs/show_bug.cgi?id=547830 and possible fix > that I plan to release soon at https://git.eclipse.org/r/#/c/143026/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FELIX-6212) Issues with uses capability checking with split packages and reexport
[ https://issues.apache.org/jira/browse/FELIX-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed FELIX-6212. - > Issues with uses capability checking with split packages and reexport > - > > Key: FELIX-6212 > URL: https://issues.apache.org/jira/browse/FELIX-6212 > Project: Felix > Issue Type: Bug > Components: Resolver >Affects Versions: resolver-1.16.0 >Reporter: Tom Watson >Assignee: Tom Watson >Priority: Major > Fix For: resolver-2.0.2 > > > First found in Eclipse bug > https://bugs.eclipse.org/bugs/show_bug.cgi?id=559118 > If a bundle A reexports multiple bundles (B and C) that export the same > package Y (which is a split package) and another bundle D requires A and > exports package X and package X uses Y then issues occur resolving bundles > that require package X and only get wired to one of the parts of the split > package Y. > The scenario is horrible and uses one of the most obnoxious trifecta of > "features" of OSGi which is the use of a split package, require-bundle and a > visibility of reexport. When determining the compatibility of the used > packages the resolver is supposed to detect if the used packages are subsets > of each other. The logic is getting all messed up here because each reexport > is making the used package set of sources only include a single part of the > package. This can lead to cases where the subset check fails. > I have a testcase and fix ready to go. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-6398:
-
Assignee: Karl Pauls
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315436#comment-17315436
]
Karl Pauls commented on FELIX-6398:
---
Yes, looks like there where some last minute changes to the versions that did
fall through the cracks. As far as I can see it is only the version numbers.
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6398) Update framework packages to osgi.core 8
[
https://issues.apache.org/jira/browse/FELIX-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-6398:
--
Fix Version/s: framework.security-2.8.2
resolver-2.0.4
> Update framework packages to osgi.core 8
>
>
> Key: FELIX-6398
> URL: https://issues.apache.org/jira/browse/FELIX-6398
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-7.0.0
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: framework-7.0.2, resolver-2.0.4, framework.security-2.8.2
>
>
> Although the R8 api is implemented by the framework, some of the package
> versions are slightly lower than the official R8 osgi.core jar - which can
> lead to unresolved packages if compiled against that jar but used with the
> Apache Felix Framework.
> These are the packages from osgi.core 8.0.0 which have lower versions in the
> release:
> {noformat}
> org.osgi.dto {version=1.1.1}
> org.osgi.resource {version=1.0.1}
> org.osgi.resource.dto {version=1.0.1}
> org.osgi.service.packageadmin {version=1.2.1}
> org.osgi.service.resolver {version=1.1.1}
> org.osgi.service.startlevel{version=1.1.1}
> org.osgi.service.url {version=1.0.1}
> org.osgi.util.tracker {version=1.5.3}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
adaptTo() 2021 - Call for Papers extended / Early Bird Tickets
Dear adaptTo() Community, We are extending our Call for Papers by another three weeks. The new deadline is April 23rd. So, if you would like to be a speaker, please visit https://adapt.to/cfp - and/or if you know any other potential speakers, please send them our way! I would also like to use this opportunity to remind you that Early Bird tickets are still available. Go to https://adapt.to/tickets before May 31st to take advantage of this offer. As the event usually sells out quickly, we advise you to buy your tickets as soon as possible. Kind regards on behalf of the adaptTo() Team, Stefan
[jira] [Created] (FELIX-6398) Update framework packages to osgi.core 8
Carsten Ziegeler created FELIX-6398:
---
Summary: Update framework packages to osgi.core 8
Key: FELIX-6398
URL: https://issues.apache.org/jira/browse/FELIX-6398
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: framework-7.0.0
Reporter: Carsten Ziegeler
Fix For: framework-7.0.2
Although the R8 api is implemented by the framework, some of the package
versions are slightly lower than the official R8 osgi.core jar - which can lead
to unresolved packages if compiled against that jar but used with the Apache
Felix Framework.
These are the packages from osgi.core 8.0.0 which have lower versions in the
release:
{noformat}
org.osgi.dto {version=1.1.1}
org.osgi.resource {version=1.0.1}
org.osgi.resource.dto {version=1.0.1}
org.osgi.service.packageadmin {version=1.2.1}
org.osgi.service.resolver {version=1.1.1}
org.osgi.service.startlevel{version=1.1.1}
org.osgi.service.url {version=1.0.1}
org.osgi.util.tracker {version=1.5.3}
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
