[GitHub] [felix-atomos] tjwatson commented on issue #7: fix build badge
tjwatson commented on issue #7: fix build badge URL: https://github.com/apache/felix-atomos/pull/7#issuecomment-595951313 Thanks Ray! 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 With regards, Apache Git Services
[GitHub] [felix-atomos] tjwatson merged pull request #7: fix build badge
tjwatson merged pull request #7: fix build badge URL: https://github.com/apache/felix-atomos/pull/7 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 With regards, Apache Git Services
[GitHub] [felix-atomos] rotty3000 commented on issue #7: fix build badge
rotty3000 commented on issue #7: fix build badge URL: https://github.com/apache/felix-atomos/pull/7#issuecomment-595943377 @tjwatson you can verify this by using the "View File" in the github diff view. The link should work. 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 With regards, Apache Git Services
[GitHub] [felix-atomos] rotty3000 opened a new pull request #7: fix build badge
rotty3000 opened a new pull request #7: fix build badge URL: https://github.com/apache/felix-atomos/pull/7 Signed-off-by: Raymond Augé 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 With regards, Apache Git Services
[jira] [Work logged] (FELIX-6228) Atomos maven plugin
[ https://issues.apache.org/jira/browse/FELIX-6228?focusedWorklogId=399300=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-399300 ] ASF GitHub Bot logged work on FELIX-6228: - Author: ASF GitHub Bot Created on: 06/Mar/20 19:10 Start Date: 06/Mar/20 19:10 Worklog Time Spent: 10m Work Description: tjwatson commented on pull request #1: FELIX-6228: Atomos maven plugin URL: https://github.com/apache/felix-atomos/pull/1 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 Issue Time Tracking --- Worklog Id: (was: 399300) Remaining Estimate: 0h Time Spent: 10m > Atomos maven plugin > --- > > Key: FELIX-6228 > URL: https://issues.apache.org/jira/browse/FELIX-6228 > Project: Felix > Issue Type: Improvement > Components: Atomos >Reporter: Tom Watson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Copied from https://github.com/tjwatson/atomos/issues/15 > For example, the following can be considered for an Atomos maven plugin: > - Reflection Configuration: the org.atomos.substrate.config.ReflectConfig > class provides a gogo command reflectConfig that generates a json config for > specifying the required class reflection information for Bundle activators > and for OSGi Declarative services. It would be good to have a plugin that can > do the same when creating a native image. > - Resource Configuration: the org.atomos.substrate.config.ResourceConfig > class provides a gogo command resourceConfig that generates a json config for > specifying the required resource matching patterns to include package > resources in a native image. It would be good to have a plugin that can do > the same when creating a native image. > - Bundle Entry Configuration: the > org.atomos.substrate.config.SubstrateService class provides a gogo command > substrateBundles that can be used to extract the non-package resources used > for bundle entry content (for example META-INF/MANIFEST.MF and Declarative > Service XML files) into a directory structure that can be used during native > image generation to include a index for Atomos to discover the included > bundles and their entries. It would be good to have a plugin that can do the > same when creating a native image. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [felix-atomos] tjwatson merged pull request #1: FELIX-6228: Atomos maven plugin
tjwatson merged pull request #1: FELIX-6228: Atomos maven plugin URL: https://github.com/apache/felix-atomos/pull/1 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 With regards, Apache Git Services
[jira] [Closed] (FELIX-6236) ssh / telnet gogojline
[ https://issues.apache.org/jira/browse/FELIX-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bischof closed FELIX-6236. - Resolution: Not A Problem > ssh / telnet gogojline > -- > > Key: FELIX-6236 > URL: https://issues.apache.org/jira/browse/FELIX-6236 > Project: Felix > Issue Type: New Feature > Components: Gogo JLine >Reporter: Stefan Bischof >Priority: Major > > It would be nice to have ssh and telnet support for gogo-jline > With this commit the ssh / telnet support of gogo jline moved from /src to > /test > > [https://github.com/apache/felix-dev/commit/ad2d6481f58126130aefb01cdcf7b11eacb1c567] > What are the reasons? Could we add the support back? -- This message was sent by Atlassian Jira (v8.3.4#803005)
AW: [DISCUSS] Project Contribution to Apache Felix
Hi Thomas, Thanks for your quick feedback. The spec you mentioned is similar to this project [1], Peter worked on. This addresses the problem with the start levels - non-dynamism. Many developers start trying to control the bundle start level when they run in timing dependencies. Since, in OSGi, we always support dynamic behaviour, such a solution to use start level is not encouraged. The Condition Service (as specified in RFC 242) addresses a similar problem. On the other hand, feature flags addresses high-level enablement/disablement of a flag, allowing teams to modify system behaviour without changing code. This can help the team in making more informed decisions about a feature, shortening the release cycle, performing A/B testing, and empowering people other than engineers allowing them to control releases, among others. This also enables you to have a very well established feature flag life-cycle management, ensuring platforms remain stable over different feature flags combinations and the testing complexity that grows harder and harder with each new flag. I would really like to further discuss if there exists any scope to collaborate on an implementation for such feature flags integration. Thanks and Regards, Amit [1] - https://github.com/aQute-os/biz.aQute.osgi.util/tree/master/biz.aQute.osgi.conditionaltarget Von: Thomas Watson Gesendet: Freitag, 6. März 2020 14:52 An: dev@felix.apache.org Betreff: Re: [DISCUSS] Project Contribution to Apache Felix Hi Amit, This sounds like it is trying to solve a similar problem that an OSGi R8 spec proposal call "Conditions" is trying to address with RFC 242 [1]. It would be good to understand how the two approaches differ. If they are solving similar issues then perhaps it would be better to collaborate on an implementation of the proposed condition factory in Felix. The Condition specification is going to impact the SCR implementation also, so the Felix project will need to react to the Condition specification regardless. Tom [1] https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf On Fri, Mar 6, 2020 at 7:25 AM Amit Mondal wrote: > Hello, everyone: > > I am writing this email to propose a project I did work on earlier. The > project introduces support of feature flags for the OSGi environment. > Probably many of you already know about feature flags or feature toggles. I > would like to further elaborate a bit for those who are not familiar with > it. > > It turns out that when many people hear the term feature flags, they > fixate on the word - flag and are thinking of something much older - other > flags in software engineering. They are referring to a compile-time flag or > a server configuration flag or maybe a server configuration file. While > those are indeed flags, what they all have in common is that they are > global. What I mean by that is they impact every user passing through that > piece of software. > > But when I say feature flags, sometimes called feature toggles or > ops-toggles, I’m talking about a very different thing. I’m referring to > making a dynamic decision in my code - live. I’m deciding which way I’m > going to send a user, without having to push new code and without having to > change a config file. It’s not static, like those other examples of flags. > It’s a user-by-user, session-by-session decision. > > The key benefit of using feature flags is that they decouple development > from app releases. This means two things: > > * features can be merged before they are fully implemented > * fully implemented features can remain hidden until you are ready to > release them > > First and foremost, feature flags help developers because incomplete > features can be merged! This allows to split a feature into many small > increments and merge those branches one by one. > > Secondly, feature flags also help with releasing. In the old days, an app > release could get blocked when finding a last-minute issue on a new > feature. Thanks to feature flags, this can no longer happen! If a feature > isn’t fully ready, it can just be temporarily disabled. Even more, when a > feature is ready to ship, you no longer have to do a big bang roll out to > all users. Instead, you can gradually roll out and make a data-driven > decision on to roll out further or maybe even rollback! That dramatically > de-risks rolling out new features. > > Finally, improvements to new features can be built side by the side of the > old feature and using A/B tests you can then decide which feature should > remain. This allows optimising user engagement in your app. > > I believe this was sufficient to portray the idea behind feature flags. I > have worked on a prototype version [1] of the feature flags that leverages > pure OSGi specifications. Being an Eclipse committer, I see several > benefits of making such a project flourish under the supervision of the > developers
Re: [DISCUSS] Project Contribution to Apache Felix
Hi Amit, This sounds like it is trying to solve a similar problem that an OSGi R8 spec proposal call "Conditions" is trying to address with RFC 242 [1]. It would be good to understand how the two approaches differ. If they are solving similar issues then perhaps it would be better to collaborate on an implementation of the proposed condition factory in Felix. The Condition specification is going to impact the SCR implementation also, so the Felix project will need to react to the Condition specification regardless. Tom [1] https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf On Fri, Mar 6, 2020 at 7:25 AM Amit Mondal wrote: > Hello, everyone: > > I am writing this email to propose a project I did work on earlier. The > project introduces support of feature flags for the OSGi environment. > Probably many of you already know about feature flags or feature toggles. I > would like to further elaborate a bit for those who are not familiar with > it. > > It turns out that when many people hear the term feature flags, they > fixate on the word - flag and are thinking of something much older - other > flags in software engineering. They are referring to a compile-time flag or > a server configuration flag or maybe a server configuration file. While > those are indeed flags, what they all have in common is that they are > global. What I mean by that is they impact every user passing through that > piece of software. > > But when I say feature flags, sometimes called feature toggles or > ops-toggles, I’m talking about a very different thing. I’m referring to > making a dynamic decision in my code - live. I’m deciding which way I’m > going to send a user, without having to push new code and without having to > change a config file. It’s not static, like those other examples of flags. > It’s a user-by-user, session-by-session decision. > > The key benefit of using feature flags is that they decouple development > from app releases. This means two things: > > * features can be merged before they are fully implemented > * fully implemented features can remain hidden until you are ready to > release them > > First and foremost, feature flags help developers because incomplete > features can be merged! This allows to split a feature into many small > increments and merge those branches one by one. > > Secondly, feature flags also help with releasing. In the old days, an app > release could get blocked when finding a last-minute issue on a new > feature. Thanks to feature flags, this can no longer happen! If a feature > isn’t fully ready, it can just be temporarily disabled. Even more, when a > feature is ready to ship, you no longer have to do a big bang roll out to > all users. Instead, you can gradually roll out and make a data-driven > decision on to roll out further or maybe even rollback! That dramatically > de-risks rolling out new features. > > Finally, improvements to new features can be built side by the side of the > old feature and using A/B tests you can then decide which feature should > remain. This allows optimising user engagement in your app. > > I believe this was sufficient to portray the idea behind feature flags. I > have worked on a prototype version [1] of the feature flags that leverages > pure OSGi specifications. Being an Eclipse committer, I see several > benefits of making such a project flourish under the supervision of the > developers working on Felix. As Felix community primarily focuses on OSGi, > this project would avail benefits from further development, maintenance and > adoption. > > Currently, the project is licensed under the Apache 2.0 software license, > but it still uses my top-level domain in the bundles. If you think the > project would be valuable, I would love to make the bundle names compatible > with the Felix naming conventions. > > I would really appreciate your opinion regarding this proposal for the > contribution. > > > Thanks and Regards, > Amit > > > [1] - https://github.com/amitjoy/feature-flags-for-osgi >
[DISCUSS] Project Contribution to Apache Felix
Hello, everyone: I am writing this email to propose a project I did work on earlier. The project introduces support of feature flags for the OSGi environment. Probably many of you already know about feature flags or feature toggles. I would like to further elaborate a bit for those who are not familiar with it. It turns out that when many people hear the term feature flags, they fixate on the word - flag and are thinking of something much older - other flags in software engineering. They are referring to a compile-time flag or a server configuration flag or maybe a server configuration file. While those are indeed flags, what they all have in common is that they are global. What I mean by that is they impact every user passing through that piece of software. But when I say feature flags, sometimes called feature toggles or ops-toggles, I’m talking about a very different thing. I’m referring to making a dynamic decision in my code - live. I’m deciding which way I’m going to send a user, without having to push new code and without having to change a config file. It’s not static, like those other examples of flags. It’s a user-by-user, session-by-session decision. The key benefit of using feature flags is that they decouple development from app releases. This means two things: * features can be merged before they are fully implemented * fully implemented features can remain hidden until you are ready to release them First and foremost, feature flags help developers because incomplete features can be merged! This allows to split a feature into many small increments and merge those branches one by one. Secondly, feature flags also help with releasing. In the old days, an app release could get blocked when finding a last-minute issue on a new feature. Thanks to feature flags, this can no longer happen! If a feature isn’t fully ready, it can just be temporarily disabled. Even more, when a feature is ready to ship, you no longer have to do a big bang roll out to all users. Instead, you can gradually roll out and make a data-driven decision on to roll out further or maybe even rollback! That dramatically de-risks rolling out new features. Finally, improvements to new features can be built side by the side of the old feature and using A/B tests you can then decide which feature should remain. This allows optimising user engagement in your app. I believe this was sufficient to portray the idea behind feature flags. I have worked on a prototype version [1] of the feature flags that leverages pure OSGi specifications. Being an Eclipse committer, I see several benefits of making such a project flourish under the supervision of the developers working on Felix. As Felix community primarily focuses on OSGi, this project would avail benefits from further development, maintenance and adoption. Currently, the project is licensed under the Apache 2.0 software license, but it still uses my top-level domain in the bundles. If you think the project would be valuable, I would love to make the bundle names compatible with the Felix naming conventions. I would really appreciate your opinion regarding this proposal for the contribution. Thanks and Regards, Amit [1] - https://github.com/amitjoy/feature-flags-for-osgi
[jira] [Resolved] (FELIX-5954) Update Apache Felix Web Console Documentation
[
https://issues.apache.org/jira/browse/FELIX-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-5954.
-
Resolution: Fixed
Thanks, I've updated the documentation
> Update Apache Felix Web Console Documentation
> -
>
> Key: FELIX-5954
> URL: https://issues.apache.org/jira/browse/FELIX-5954
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
>Reporter: Jorge Cercas
>Assignee: Carsten Ziegeler
>Priority: Critical
>
> Please (at least) add the *http.service.filter* configuration option to the
> Apache Felix Web Console documentation here [Apache Felix Web
> Console|http://felix.apache.org/documentation/subprojects/apache-felix-web-console.html]
> After endless searching, the description below was found at
> [AEM|http://www.aemstuff.com/osgi/aem62.html]
> {quote}The Http Service Selector is an OSGi filter used to select the Http
> Service to which the Web Console binds. The value of this property (if not
> empty) is combined the object class selection term to get the actual service
> selection filter like
> (&(objectClass=org.osgi.service.http.HttpService)(selector)). This property
> must not have leading an trailing parentheses. For example, to bind to the
> service with service ID 15 set the selector to 'service.id=15' (without the
> quotes). By default (if this property is not set or set to an empty string)
> the Web Console binds with any Http Service available.
> {quote}
> {color:#93c763} {color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-5954) Update Apache Felix Web Console Documentation
[
https://issues.apache.org/jira/browse/FELIX-5954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-5954:
---
Assignee: Carsten Ziegeler
> Update Apache Felix Web Console Documentation
> -
>
> Key: FELIX-5954
> URL: https://issues.apache.org/jira/browse/FELIX-5954
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
>Reporter: Jorge Cercas
>Assignee: Carsten Ziegeler
>Priority: Critical
>
> Please (at least) add the *http.service.filter* configuration option to the
> Apache Felix Web Console documentation here [Apache Felix Web
> Console|http://felix.apache.org/documentation/subprojects/apache-felix-web-console.html]
> After endless searching, the description below was found at
> [AEM|http://www.aemstuff.com/osgi/aem62.html]
> {quote}The Http Service Selector is an OSGi filter used to select the Http
> Service to which the Web Console binds. The value of this property (if not
> empty) is combined the object class selection term to get the actual service
> selection filter like
> (&(objectClass=org.osgi.service.http.HttpService)(selector)). This property
> must not have leading an trailing parentheses. For example, to bind to the
> service with service ID 15 set the selector to 'service.id=15' (without the
> quotes). By default (if this property is not set or set to an empty string)
> the Web Console binds with any Http Service available.
> {quote}
> {color:#93c763} {color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
