Re: Documentation for Apache Felix Health Checks
I like that approach as well, if there is no objections I'll do it like that. -Georg On 2019-02-12 07:07, Christian Schneider wrote: +1 for using markup files in github for documentation. It is a bit inconvenient as long as we are not on git natively .. but I hope this soon changes. Christian Am Di., 12. Feb. 2019 um 14:00 Uhr schrieb Bertrand Delacretaz < bdelacre...@apache.org>: Hi Georg, On Mon, Jan 28, 2019 at 12:50 AM Georg Henzler wrote: > ...I would like to > move the documentation in the markdown file [3] to the correct location > which I believe is a sub page "Apache Felix Health Checks" underneath > [4],... Many projects today just use those Markdown files in GitHub for docs, the advantage IMO is that they stay with the code which can make it easier to remember to keep them up to date. If the Felix PMC agrees with that I would suggest just listing the new Health Checks modules at [4], pointing to the https://github.com/apache/felix/tree/trunk/healthcheck mirror and moving [3] so that it becomes the README of that path - as it's the general documentation for that group of modules. -Bertrand > [3] > http://svn.apache.org/viewvc/felix/trunk/healthcheck/docs/felix-health-checks.md?view=log=1849246 > [4] https://cwiki.apache.org/confluence/display/FELIX/Subprojects --
[jira] [Commented] (FELIX-6056) SCR exports promises
[ https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766579#comment-16766579 ] Thomas Watson commented on FELIX-6056: -- OK, I think we should change to not export promises or function (only import them). > SCR exports promises > > > Key: FELIX-6056 > URL: https://issues.apache.org/jira/browse/FELIX-6056 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Peter Kriens >Priority: Major > > Apache Felix SCR exports promises 1.0 as a convenience. However, since this > package contains the implementation it is a +provider+. Originally, the > import was correct for a provider, [1,1.1). however, last July it was > increased to [1,2). This therefore against the semantic versioning > specification that prescribes a minor import range when providing the > implementation of an API. > Exporting an package like Promises is not a good idea anyway. It is only a > convenience, promises have nothing to do with SCR in itself and that will > always back fire in the end. Even exporting it correctly causes unnecessary > version constraints since the order of resolving cannot be controlled. So if > you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or > 1.1 and it creates nasty class spaces. > It is inconvenient to make SCR depend on Promises. Personally I would not > have used promises or would have included the package privately. (No API of > SCR depends on Promises) Since SCR is such a crucial base component I > strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Documentation for Apache Felix Health Checks
+1 for using markup files in github for documentation. It is a bit inconvenient as long as we are not on git natively .. but I hope this soon changes. Christian Am Di., 12. Feb. 2019 um 14:00 Uhr schrieb Bertrand Delacretaz < bdelacre...@apache.org>: > Hi Georg, > > On Mon, Jan 28, 2019 at 12:50 AM Georg Henzler wrote: > > ...I would like to > > move the documentation in the markdown file [3] to the correct location > > which I believe is a sub page "Apache Felix Health Checks" underneath > > [4],... > > Many projects today just use those Markdown files in GitHub for docs, > the advantage IMO is that they stay with the code which can make it > easier to remember to keep them up to date. > > If the Felix PMC agrees with that I would suggest just listing the new > Health Checks modules at [4], pointing to the > https://github.com/apache/felix/tree/trunk/healthcheck mirror and > moving [3] so that it becomes the README of that path - as it's the > general documentation for that group of modules. > > -Bertrand > > > [3] > > > http://svn.apache.org/viewvc/felix/trunk/healthcheck/docs/felix-health-checks.md?view=log=1849246 > > [4] https://cwiki.apache.org/confluence/display/FELIX/Subprojects > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
[jira] [Commented] (FELIX-6056) SCR exports promises
[ https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766042#comment-16766042 ] Peter Kriens commented on FELIX-6056: - Yes, the API dependency is unfortunate since very few bundles use this class (let alone these rarely used methods). it is one of the few places where an OSGi spec references another spec than the framework. We always tried to keep these separate, which is imho good design. Not sure what happened here. The cost of not letting these functions use Promises would have been negligent. The reason they export functions as well is I assume that Promises needs requires them. Another good reason not to export a package that is not yours. > SCR exports promises > > > Key: FELIX-6056 > URL: https://issues.apache.org/jira/browse/FELIX-6056 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Peter Kriens >Priority: Major > > Apache Felix SCR exports promises 1.0 as a convenience. However, since this > package contains the implementation it is a +provider+. Originally, the > import was correct for a provider, [1,1.1). however, last July it was > increased to [1,2). This therefore against the semantic versioning > specification that prescribes a minor import range when providing the > implementation of an API. > Exporting an package like Promises is not a good idea anyway. It is only a > convenience, promises have nothing to do with SCR in itself and that will > always back fire in the end. Even exporting it correctly causes unnecessary > version constraints since the order of resolving cannot be controlled. So if > you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or > 1.1 and it creates nasty class spaces. > It is inconvenient to make SCR depend on Promises. Personally I would not > have used promises or would have included the package privately. (No API of > SCR depends on Promises) Since SCR is such a crucial base component I > strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FELIX-6043) ClassNotFoundException org.osgi.util.function.Function
[ https://issues.apache.org/jira/browse/FELIX-6043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-6043: - Assignee: Thomas Watson > ClassNotFoundException org.osgi.util.function.Function > -- > > Key: FELIX-6043 > URL: https://issues.apache.org/jira/browse/FELIX-6043 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.14 >Reporter: Pleeplop >Assignee: Thomas Watson >Priority: Minor > Fix For: scr-2.1.16 > > > The manifest declares org.osgi.util.function as exported but it is not > embedded. > A quick fix is to declare the dependency with maven > see https://github.com/apache/felix/pull/177 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-6056) SCR exports promises
[ https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766024#comment-16766024 ] Thomas Watson commented on FELIX-6056: -- Also see FELIX-6043. I'm perfectly fine having promises be imported. But I will point out that SCR API DOES use promises with the following return types from: org.osgi.service.component.runtime.ServiceComponentRuntime.enableComponent(ComponentDescriptionDTO) org.osgi.service.component.runtime.ServiceComponentRuntime.disableComponent(ComponentDescriptionDTO) And promises uses function. Current versions of SCR release say they export function but they don't actually have any of the content from function. > SCR exports promises > > > Key: FELIX-6056 > URL: https://issues.apache.org/jira/browse/FELIX-6056 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Peter Kriens >Priority: Major > > Apache Felix SCR exports promises 1.0 as a convenience. However, since this > package contains the implementation it is a +provider+. Originally, the > import was correct for a provider, [1,1.1). however, last July it was > increased to [1,2). This therefore against the semantic versioning > specification that prescribes a minor import range when providing the > implementation of an API. > Exporting an package like Promises is not a good idea anyway. It is only a > convenience, promises have nothing to do with SCR in itself and that will > always back fire in the end. Even exporting it correctly causes unnecessary > version constraints since the order of resolving cannot be controlled. So if > you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or > 1.1 and it creates nasty class spaces. > It is inconvenient to make SCR depend on Promises. Personally I would not > have used promises or would have included the package privately. (No API of > SCR depends on Promises) Since SCR is such a crucial base component I > strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6056) SCR exports promises
Peter Kriens created FELIX-6056: --- Summary: SCR exports promises Key: FELIX-6056 URL: https://issues.apache.org/jira/browse/FELIX-6056 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Reporter: Peter Kriens Apache Felix SCR exports promises 1.0 as a convenience. However, since this package contains the implementation it is a +provider+. Originally, the import was correct for a provider, [1,1.1). however, last July it was increased to [1,2). This therefore against the semantic versioning specification that prescribes a minor import range when providing the implementation of an API. Exporting an package like Promises is not a good idea anyway. It is only a convenience, promises have nothing to do with SCR in itself and that will always back fire in the end. Even exporting it correctly causes unnecessary version constraints since the order of resolving cannot be controlled. So if you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or 1.1 and it creates nasty class spaces. It is inconvenient to make SCR depend on Promises. Personally I would not have used promises or would have included the package privately. (No API of SCR depends on Promises) Since SCR is such a crucial base component I strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Documentation for Apache Felix Health Checks
Hi Georg, On Mon, Jan 28, 2019 at 12:50 AM Georg Henzler wrote: > ...I would like to > move the documentation in the markdown file [3] to the correct location > which I believe is a sub page "Apache Felix Health Checks" underneath > [4],... Many projects today just use those Markdown files in GitHub for docs, the advantage IMO is that they stay with the code which can make it easier to remember to keep them up to date. If the Felix PMC agrees with that I would suggest just listing the new Health Checks modules at [4], pointing to the https://github.com/apache/felix/tree/trunk/healthcheck mirror and moving [3] so that it becomes the README of that path - as it's the general documentation for that group of modules. -Bertrand > [3] > http://svn.apache.org/viewvc/felix/trunk/healthcheck/docs/felix-health-checks.md?view=log=1849246 > [4] https://cwiki.apache.org/confluence/display/FELIX/Subprojects
