aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Ross (JIRA)" <>
Subject [jira] [Commented] (ARIES-1146) Aries Subsystem use of org.osgi.service.repository.Repository interface problematic
Date Wed, 12 Feb 2014 20:03:19 GMT


John Ross commented on ARIES-1146:

Note that this will be addressed in the subsystems R6 implementation.

The subsystem-api bundle will continue to provide the org.osgi.service.repository API at version
1.0 for backwards compatibility. I'm open to removing it altogether but will not do so without
a sufficient consensus. I am aware of at least one product that would be affected. Also note
this would require a major version bump to 2.0.

The subsystem-impl bundle no longer even imports the org.osgi.service.repository API. Instead,
it looks for all registered repository services, regardless of version, then uses reflection
to invoke the 1.0 methods Repository.findProviders and RepositoryContent.getContent.

> Aries Subsystem use of org.osgi.service.repository.Repository interface problematic
> -----------------------------------------------------------------------------------
>                 Key: ARIES-1146
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>          Components: Subsystem
>    Affects Versions: 1.0
>            Reporter: David Bosschaert
> Aries Subsystems can work with OSGi repositories to provision resources as required by
the OSGi Subsystem spec. However the implementation also implements the Repository interface
itself to provide Repository facades over other things like the Felix Repository, the .esa
content and other things...
> Looking at the relevant Import-Package header, I see that it's defined as follows:
>   org.osgi.service.repository;version="[1.0,2)"
> This is problematic since the Repository interface is a Provider Type and hence version
1.1 can (and will) contain new methods. Using a 1.1 Repository will then break the current
Subsystems implementation, as it's local Repository facades are implementing the Repository
1.0 interface.
> Changing the version range to "[1.0, 1.1)" is not a good idea either, because that will
limit the integration with Repository services. I.e. the won't make Subsystems work with Repository
1.1 implementations.
> So we do want to keep the import 
>   org.osgi.service.repository;version="[1.0,2)"
> in tact, but need to change the Subsystems implementation in such a way that it can continue
to work if the Repository interface moves to 1.1, where new methods are added...

This message was sent by Atlassian JIRA

View raw message