You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Cristiano <cv...@gmail.com> on 2018/11/24 12:52:08 UTC
[Discuss] What is the policy to upgrade to newer Core and Compendium
on Felix projects?
Hi Felix devs,
I had some free time today and did some investigations about what would
be necessary to change BundleRepository to support Repository spec
version 1.1.
I noted that BundleRepository has a dependency to org.apache.felix.utils
and both depends on old compendium and core 5.0. also they uses
different parent versions.
So I found that changing BundleRepository to support v1.1 certainly will
require both compendium and core be upgraded to 7.0 due the new
Repository class to require the newest Resource from Core.
Changing org.apache.felix.utils probably will affect other projects...
How you guys used to deal with that ?
Specifically about BundleRepositoy, I found that its current version
works with different packages providing basically same kind of classes.
Many of them are interfaces already provided by osgi alliance. for
example, Resource, Requirement, Capability, Repository and others. And
both felix.util and BundleRepository projects implements some of them.
examples :
* org.osgi.service.obr.Resource;
* org.apache.felix.bundlerepository.Resource;
* org.apache.felix.bundlerepository.Repository;
* org.osgi.service.repository.Repository;
* org.osgi.resource.Resource;
* org.apache.felix.bundlerepository.impl.ResourceImpl
* org.apache.felix.bundlerepository.impl.CapabilityImpl;
* org.apache.felix.bundlerepository.impl.RequirementImpl;
* org.apache.felix.utils.resource.ResourceImpl;
* org.apache.felix.utils.resource.CapabilityImpl;
* org.apache.felix.utils.resource.RequirementImpl;
I believe that many of those interfaces/classes was created before the
spec in order to support the old OBR.
But would be really necessary to keep them forever or would be possible
to do a major release dropping support for older stuffs and removing
duplicated ones?
thanks and best regards,
Cristiano
Re: [Discuss] What is the policy to upgrade to newer Core and
Compendium on Felix projects?
Posted by Cristiano <cv...@gmail.com>.
Hello again,
> Changing org.apache.felix.utils probably will affect other projects...
>
> How you guys used to deal with that ?
>
> You should not have to do this. Just make sure it's dependency comes after
> than the updated OSGi apis you use.
>
Ok, I've create a local branch here and started to play with the
improvement.
I've set maven POM in order to use core 7, removed compendium and added
/org.osgi.service.repository, org.osgi.namespace.service,
org.osgi.util.promise/.
I needed also to change POM of /org.apache.felix.utils/ since it has a
direct dependency to /org.osgi.service.repository /and /.
/
Next weekend I'll spend more time to figure out how to deal with this
new RequirementExpression and ExpressionCombiner ...
>> where the classes are internal only, then removing them is not so much of
>> an issue.
>>
>> Where they are exported it might be a little trickier. We'd have to look at
>> the exact scenarios.
>
Well, while digging into the source code, one concerning scenario have
called my attention: the use of a Resolver.
In the Repository specification is stated that a Repository service is
intended to be used in conjunction with the Resolver Service
Specification. Then, my understanding is that it should use a resolver
that implements *org.osgi.service.resolver.Resolver plus
ResolveContext*, but the BundleRepository provides and exports its own
*org.apache.felix.bundlerepository.Resolver *instead. *
*
In the last couple of years multiple improvements and fixes was made on
felix.resolver bundle, so wouldn't be more reliable and less error prone
to use it instead to use its own implementation?
best regards,
Cristiano
Re: [Discuss] What is the policy to upgrade to newer Core and
Compendium on Felix projects?
Posted by Raymond Auge <ra...@liferay.com>.
On Sat, Nov 24, 2018 at 7:52 AM Cristiano <cv...@gmail.com> wrote:
> Hi Felix devs,
>
> I had some free time today and did some investigations about what would
> be necessary to change BundleRepository to support Repository spec
> version 1.1.
>
> I noted that BundleRepository has a dependency to org.apache.felix.utils
> and both depends on old compendium and core 5.0. also they uses
> different parent versions.
>
> So I found that changing BundleRepository to support v1.1 certainly will
> require both compendium and core be upgraded to 7.0 due the new
> Repository class to require the newest Resource from Core.
>
The ideal approach would be to replace the osgi.compendium dependency by
the specific OSGi API dependencies (from maven central) necessary. This
will also ensure that there's no accidental dependency increase where none
is needed. For example:
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.service.repository</artifactId>
<version>1.1.0</version>
</dependency>
>
> Changing org.apache.felix.utils probably will affect other projects...
>
> How you guys used to deal with that ?
>
You should not have to do this. Just make sure it's dependency comes after
than the updated OSGi apis you use.
>
>
> Specifically about BundleRepositoy, I found that its current version
> works with different packages providing basically same kind of classes.
> Many of them are interfaces already provided by osgi alliance. for
> example, Resource, Requirement, Capability, Repository and others. And
> both felix.util and BundleRepository projects implements some of them.
> examples :
>
> * org.osgi.service.obr.Resource;
> * org.apache.felix.bundlerepository.Resource;
> * org.apache.felix.bundlerepository.Repository;
> * org.osgi.service.repository.Repository;
> * org.osgi.resource.Resource;
> * org.apache.felix.bundlerepository.impl.ResourceImpl
> * org.apache.felix.bundlerepository.impl.CapabilityImpl;
> * org.apache.felix.bundlerepository.impl.RequirementImpl;
> * org.apache.felix.utils.resource.ResourceImpl;
> * org.apache.felix.utils.resource.CapabilityImpl;
> * org.apache.felix.utils.resource.RequirementImpl;
>
where the classes are internal only, then removing them is not so much of
an issue.
Where they are exported it might be a little trickier. We'd have to look at
the exact scenarios.
>
>
> I believe that many of those interfaces/classes was created before the
> spec in order to support the old OBR.
>
> But would be really necessary to keep them forever or would be possible
> to do a major release dropping support for older stuffs and removing
> duplicated ones?
>
Hmm, we should more deeply investigate a path forward without a major
release. If we look hard enough there's usually a way :)
Sincerely,
- Ray
>
>
> thanks and best regards,
>
> Cristiano
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)