Re: Release schedule of http?
Great. Thanks! 2015-10-07 8:17 GMT+02:00 Carsten Ziegeler : > I'll start the release either tomorrow or Friday - definitely before the > weekend :) > > Regards > Carsten > > Am 07.10.15 um 11:41 schrieb Sten Roger Sandvik: > > The weekend went fast and I did not manage to get the time to read up on > > the release procedures. It's been a long time since I did this in the > > Felix project. If you are tired of waiting, then just release and I will > > probably be up to speed on the next releases :-) > > > > > > 2015-10-01 16:27 GMT+02:00 Sten Roger Sandvik : > > > >> Good. Will try to fix one issue and then call for a release. Probably > >> within the weekend. > >> > >> 2015-10-01 13:48 GMT+02:00 Carsten Ziegeler : > >>> Am 01.10.15 um 10:14 schrieb Sten Roger Sandvik: > Hi. > > I'm just wondering on when it's appropriate to call out for a release? > I have some "blockers" for the http bundles that I need really soon > :-) > > >>> There is no fixed schedule, in theory we can simply release whenever a > >>> single issue is fixed. > >>> Feel free to call for a release whenever you think it makes sense. > >>> > >>> You can either do the release yourself or I can do it, if you want. > >>> > >>> Regards > >>> Carsten > >>> -- > >>> Carsten Ziegeler > >>> Adobe Research Switzerland > >>> cziege...@apache.org > >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: Release schedule of http?
I'll start the release either tomorrow or Friday - definitely before the weekend :) Regards Carsten Am 07.10.15 um 11:41 schrieb Sten Roger Sandvik: > The weekend went fast and I did not manage to get the time to read up on > the release procedures. It's been a long time since I did this in the > Felix project. If you are tired of waiting, then just release and I will > probably be up to speed on the next releases :-) > > > 2015-10-01 16:27 GMT+02:00 Sten Roger Sandvik : > >> Good. Will try to fix one issue and then call for a release. Probably >> within the weekend. >> >> 2015-10-01 13:48 GMT+02:00 Carsten Ziegeler : >>> Am 01.10.15 um 10:14 schrieb Sten Roger Sandvik: Hi. I'm just wondering on when it's appropriate to call out for a release? I have some "blockers" for the http bundles that I need really soon :-) >>> There is no fixed schedule, in theory we can simply release whenever a >>> single issue is fixed. >>> Feel free to call for a release whenever you think it makes sense. >>> >>> You can either do the release yourself or I can do it, if you want. >>> >>> Regards >>> Carsten >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >> > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Release schedule of http?
The weekend went fast and I did not manage to get the time to read up on the release procedures. It's been a long time since I did this in the Felix project. If you are tired of waiting, then just release and I will probably be up to speed on the next releases :-) 2015-10-01 16:27 GMT+02:00 Sten Roger Sandvik : > Good. Will try to fix one issue and then call for a release. Probably > within the weekend. > > 2015-10-01 13:48 GMT+02:00 Carsten Ziegeler : > > Am 01.10.15 um 10:14 schrieb Sten Roger Sandvik: > >> Hi. > >> > >> I'm just wondering on when it's appropriate to call out for a release? > >> I have some "blockers" for the http bundles that I need really soon > >> :-) > >> > > There is no fixed schedule, in theory we can simply release whenever a > > single issue is fixed. > > Feel free to call for a release whenever you think it makes sense. > > > > You can either do the release yourself or I can do it, if you want. > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org >
[jira] [Commented] (FELIX-5063) Bundle-ClassPath directive does not accept entry parameters
[
https://issues.apache.org/jira/browse/FELIX-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945640#comment-14945640
]
Jean-Baptiste Onofré commented on FELIX-5063:
-
Thanks Seb for the report. I gonna take a look.
> Bundle-ClassPath directive does not accept entry parameters
> ---
>
> Key: FELIX-5063
> URL: https://issues.apache.org/jira/browse/FELIX-5063
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Sébastien Gandon
>Priority: Minor
>
> I need to create a manifest with an Bundle-ClassPath entry that contains
> parameters, but the *maven-bundle* plugin interprets the ';' as a ',' which
> is not what one would expected from an OSGI stand point.
> here is my instruction
> {code}
> {maven-dependencies},partner-${partner.version}.jar;mvn:org.talend.components.salesforce/partner/${partner.version}
>
> {code}
> here is what is generated
> {code}
> Bundle-ClassPath: force-wsc-35.0.0.jar,metadata-34.0.0.jar,json-simple-1
> .1.1.jar,javax.inject-1.jar,partner-34.0.0.jar,mvn:org.talend.component
> s.salesforce/partner/34.0.0
> {code}
> and we would have expected
> {code}
> Bundle-ClassPath: force-wsc-35.0.0.jar,metadata-34.0.0.jar,json-simple-1
> .1.1.jar,javax.inject-1.jar,partner-34.0.0.jar;mvn:org.talend.component
> s.salesforce/partner/34.0.0
> {code}
> Notice the semi-colon that was transformed into a colon.
> PS :
> here is an excerpt of the OSGI spec
>
> The Bundle-ClassPath manifest header must conform to the following syntax:
> Bundle-ClassPath ::= entry ( ',' entry )*
> entry::= target ( ';' target )* ( ';' parameter ) *
> target ::= path | '.' // See
> 1.3.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5063) Bundle-ClassPath directive does not accept entry parameters
[
https://issues.apache.org/jira/browse/FELIX-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Gandon updated FELIX-5063:
Description:
I need to create a manifest with an Bundle-ClassPath entry that contains
parameters, but the *maven-bundle* plugin interprets the ';' as a ',' which is
not what one would expected from an OSGI stand point.
here is my instruction
{code}
{maven-dependencies},partner-${partner.version}.jar;mvn:org.talend.components.salesforce/partner/${partner.version}
{code}
here is what is generated
{code}
Bundle-ClassPath: force-wsc-35.0.0.jar,metadata-34.0.0.jar,json-simple-1
.1.1.jar,javax.inject-1.jar,partner-34.0.0.jar,mvn:org.talend.component
s.salesforce/partner/34.0.0
{code}
and we would have expected
{code}
Bundle-ClassPath: force-wsc-35.0.0.jar,metadata-34.0.0.jar,json-simple-1
.1.1.jar,javax.inject-1.jar,partner-34.0.0.jar;mvn:org.talend.component
s.salesforce/partner/34.0.0
{code}
Notice the semi-colon that was transformed into a colon.
PS :
here is an excerpt of the OSGI spec
The Bundle-ClassPath manifest header must conform to the following syntax:
Bundle-ClassPath ::= entry ( ',' entry )*
entry::= target ( ';' target )* ( ';' parameter ) *
target ::= path | '.' // See
1.3.2
was:
I need to create a manifest with an Bundle-ClassPath entry that contains
parameters, but the *maven-bundle* plugin interprets the ';' as a ',' which is
not what one would expected from an OSGI stand point.
here is my instruction
{code}
{maven-dependencies},partner-${partner.version}.jar;mvn:org.talend.components.salesforce/partner/${partner.version}
{code}
here is what is generated
{code}
Bundle-ClassPath: force-wsc-35.0.0.jar,metadata-34.0.0.jar,json-simple-1
.1.1.jar,javax.inject-1.jar,partner-34.0.0.jar,mvn:org.talend.component
s.salesforce/partner/34.0.0
{code}
Notice the semi-colon that was transformed into a colon.
PS :
here is an excerpt of the OSGI spec
The Bundle-ClassPath manifest header must conform to the following syntax:
Bundle-ClassPath ::= entry ( ',' entry )*
entry::= target ( ';' target )* ( ';' parameter ) *
target ::= path | '.' // See
1.3.2
> Bundle-ClassPath directive does not accept entry parameters
> ---
>
> Key: FELIX-5063
> URL: https://issues.apache.org/jira/browse/FELIX-5063
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.0.0
>Reporter: Sébastien Gandon
>Priority: Minor
>
> I need to create a manifest with an Bundle-ClassPath entry that contains
> parameters, but the *maven-bundle* plugin interprets the ';' as a ',' which
> is not what one would expected from an OSGI stand point.
> here is my instruction
> {code}
> {maven-dependencies},partner-${partner.version}.jar;mvn:org.talend.components.salesforce/partner/${partner.version}
>
> {code}
> here is what is generated
> {code}
> Bundle-ClassPath: force-wsc-35.0.0.jar,metadata-34.0.0.jar,json-simple-1
> .1.1.jar,javax.inject-1.jar,partner-34.0.0.jar,mvn:org.talend.component
> s.salesforce/partner/34.0.0
> {code}
> and we would have expected
> {code}
> Bundle-ClassPath: force-wsc-35.0.0.jar,metadata-34.0.0.jar,json-simple-1
> .1.1.jar,javax.inject-1.jar,partner-34.0.0.jar;mvn:org.talend.component
> s.salesforce/partner/34.0.0
> {code}
> Notice the semi-colon that was transformed into a colon.
> PS :
> here is an excerpt of the OSGI spec
>
> The Bundle-ClassPath manifest header must conform to the following syntax:
> Bundle-ClassPath ::= entry ( ',' entry )*
> entry::= target ( ';' target )* ( ';' parameter ) *
> target ::= path | '.' // See
> 1.3.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID
[ https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945230#comment-14945230 ] Richard S. Hall commented on FELIX-5049: Funny, Tom Watson told me that Equinox used to do something like option (1) but he had removed it. I think option (1) creates its own issues, because now you are making it difficult for bundles to provide newer versions of packages provided by the framework. The only valid solution might be for bundles to require a service provider capability and for that service provider to have a proper "uses" constraint on the package it uses. Another option, but less nice, is to use a resolver hook to do what you want. > Resolver does not choose the revision with the lowest bundle ID > --- > > Key: FELIX-5049 > URL: https://issues.apache.org/jira/browse/FELIX-5049 > Project: Felix > Issue Type: Bug > Components: Resolver >Affects Versions: framework-5.2.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Attachments: felix-5049.diff > > > The Felix Resolver does not pick the exporting bundle with the lowest bundle > ID when multiple bundles export the same package. This causes > [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on > how to reproduce see that issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID
[
https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945140#comment-14945140
]
David Bosschaert edited comment on FELIX-5049 at 10/6/15 3:39 PM:
--
Hi [~rickhall], I see your point. I guess this is really around the fact that
the Framework cannot provide a substitutable import to the
{{org.osgi.service.resolver}} package and import that package to achieve a
single class-space.
Two further thoughts to consider:
1. We could make the framework special such that if a package is exported from
the framework then that will take precedence over other exporters in case of
such a close tie (i.e. change my proposed patch to not look at the number of
services but to prefer a framework-provided package in such situation).
-2. Another option would be to provide the resolver service in a separate
bundle rather than directly from the framework bundle and then ship that bundle
as part of the default.-
Actually, I've removed option 2 here as I think this won't work unless we
revert to reflection. The resolver service will have to have access to the
framework resolver implementation. If these end up being in a different
class-space if can't access those, so I think this is not a potential
possibility.
Option 1 above is left? How about it?
was (Author: bosschaert):
Hi [~rickhall], I see your point. I guess this is really around the fact that
the Framework cannot provide a substitutable import to the
{{org.osgi.service.resolver}} package and import that package to achieve a
single class-space.
Two further thoughts to consider:
1. We could make the framework special such that if a package is exported from
the framework then that will take precedence over other exporters in case of
such a close tie (i.e. change my proposed patch to not look at the number of
services but to prefer a framework-provided package in such situation).
2. Another option would be to provide the resolver service in a separate bundle
rather than directly from the framework bundle and then ship that bundle as
part of the default.
> Resolver does not choose the revision with the lowest bundle ID
> ---
>
> Key: FELIX-5049
> URL: https://issues.apache.org/jira/browse/FELIX-5049
> Project: Felix
> Issue Type: Bug
> Components: Resolver
>Affects Versions: framework-5.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: felix-5049.diff
>
>
> The Felix Resolver does not pick the exporting bundle with the lowest bundle
> ID when multiple bundles export the same package. This causes
> [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on
> how to reproduce see that issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID
[
https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945140#comment-14945140
]
David Bosschaert commented on FELIX-5049:
-
Hi [~rickhall], I see your point. I guess this is really around the fact that
the Framework cannot provide a substitutable import to the
{{org.osgi.service.resolver}} package and import that package to achieve a
single class-space.
Two further thoughts to consider:
1. We could make the framework special such that if a package is exported from
the framework then that will take precedence over other exporters in case of
such a close tie (i.e. change my proposed patch to not look at the number of
services but to prefer a framework-provided package in such situation).
2. Another option would be to provide the resolver service in a separate bundle
rather than directly from the framework bundle and then ship that bundle as
part of the default.
> Resolver does not choose the revision with the lowest bundle ID
> ---
>
> Key: FELIX-5049
> URL: https://issues.apache.org/jira/browse/FELIX-5049
> Project: Felix
> Issue Type: Bug
> Components: Resolver
>Affects Versions: framework-5.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: felix-5049.diff
>
>
> The Felix Resolver does not pick the exporting bundle with the lowest bundle
> ID when multiple bundles export the same package. This causes
> [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on
> how to reproduce see that issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID
[ https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945110#comment-14945110 ] Richard S. Hall commented on FELIX-5049: I don't think this is a good idea. I understand what you are trying to achieve, but I'm not sure the best way to achieve it. First of all, such a heuristic would lead to sorting results that varied over time and could become inconsistent dynamically. Secondly, even if you wanted to ignore the potential inconsistencies, it is still not clear the heuristic makes sense, since it only takes into account services registered directly by the package provider, but it is possible that there is an importer of the package that is providing the service too. This makes the heuristic mostly meaningless since it is just stabbing in the dark. And, of course, you really wouldn't want to take importers who provide into account because that would just exacerbate the first issue. Unfortunately, there is no good solution to this case, I don't think. > Resolver does not choose the revision with the lowest bundle ID > --- > > Key: FELIX-5049 > URL: https://issues.apache.org/jira/browse/FELIX-5049 > Project: Felix > Issue Type: Bug > Components: Resolver >Affects Versions: framework-5.2.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Attachments: felix-5049.diff > > > The Felix Resolver does not pick the exporting bundle with the lowest bundle > ID when multiple bundles export the same package. This causes > [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on > how to reproduce see that issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID
[ https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-5049: Attachment: felix-5049.diff There is still a possibility (and this is what is exposed in ARIES-1398) that both bundles are resolved. The major and minor versions of the package are the same. In this particular case the micro version is different. The framework provides 1.0.0 and registers a service. The bundle provides 1.0.1 but does not register a service. The felix-5049.diff patch proposes a solution to this that prefers the provider that has the most services registered in the package at hand, if the major and minor versions are identical and both of them are resolved. > Resolver does not choose the revision with the lowest bundle ID > --- > > Key: FELIX-5049 > URL: https://issues.apache.org/jira/browse/FELIX-5049 > Project: Felix > Issue Type: Bug > Components: Resolver >Affects Versions: framework-5.2.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Attachments: felix-5049.diff > > > The Felix Resolver does not pick the exporting bundle with the lowest bundle > ID when multiple bundles export the same package. This causes > [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on > how to reproduce see that issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5064) Framework should provide service capabilities for registered services
[
https://issues.apache.org/jira/browse/FELIX-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-5064.
-
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revision&revision=1706973
> Framework should provide service capabilities for registered services
> -
>
> Key: FELIX-5064
> URL: https://issues.apache.org/jira/browse/FELIX-5064
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-5.4.0
>
>
> The Felix framework registers the following three service:
> {code}org.osgi.service.resolver.Resolver
> org.osgi.service.packageadmin.PackageAdmin
> org.osgi.service.startlevel.StartLevel{code}
> The OSGi specifications define the {{osgi.service}} capability (chapter
> 135.5), the framework should provide these capability for these services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (FELIX-5064) Framework should provide service capabilities for registered services
[
https://issues.apache.org/jira/browse/FELIX-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5064 started by David Bosschaert.
---
> Framework should provide service capabilities for registered services
> -
>
> Key: FELIX-5064
> URL: https://issues.apache.org/jira/browse/FELIX-5064
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-5.4.0
>
>
> The Felix framework registers the following three service:
> {code}org.osgi.service.resolver.Resolver
> org.osgi.service.packageadmin.PackageAdmin
> org.osgi.service.startlevel.StartLevel{code}
> The OSGi specifications define the {{osgi.service}} capability (chapter
> 135.5), the framework should provide these capability for these services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5064) Framework should provide service capabilities for registered services
David Bosschaert created FELIX-5064:
---
Summary: Framework should provide service capabilities for
registered services
Key: FELIX-5064
URL: https://issues.apache.org/jira/browse/FELIX-5064
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-5.2.0
Reporter: David Bosschaert
Assignee: David Bosschaert
Fix For: framework-5.4.0
The Felix framework registers the following three service:
{code}org.osgi.service.resolver.Resolver
org.osgi.service.packageadmin.PackageAdmin
org.osgi.service.startlevel.StartLevel{code}
The OSGi specifications define the {{osgi.service}} capability (chapter 135.5),
the framework should provide these capability for these services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID
[ https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reopened FELIX-5049: - Assignee: David Bosschaert I'm reopening the issue as there is another constraint that I didn't take into account. The framework shouldn't pick a different (newer) version of a package if there is already a resolved version of the package available which can be used. That is the case here so the framework should not have resolved to the bundle with the higher version. > Resolver does not choose the revision with the lowest bundle ID > --- > > Key: FELIX-5049 > URL: https://issues.apache.org/jira/browse/FELIX-5049 > Project: Felix > Issue Type: Bug > Components: Resolver >Affects Versions: framework-5.2.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > > The Felix Resolver does not pick the exporting bundle with the lowest bundle > ID when multiple bundles export the same package. This causes > [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on > how to reproduce see that issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
