Re: Felix on git(box)

[Jean-Baptiste Onofre]

Hi Karl

I think a unique repository is fine (for all part), at least as a first step.

Do you need help about that ?

Regards
JB

> Le 21 févr. 2020 à 17:27, Karl Pauls  a écrit :
> 
> Hi,
> 
> I know i've been dragging my feet with regard to the migration to git.
> Unfortunately, I didn't find the time until now.
> 
> I would like to try to make some progress now and there are a couple
> of points to consider namely,
> 
> - our website is currently based on svn and we are using the apache
> cms which IIUC doesn't translate directly to the gitbox support.
> - with the ip clearance done, Tom would like to have a separate repo
> for atomos as there are several submodules in atomos already.
> 
> Hence, I would propose the following:
> 
> We create two git repos called felix-dev and felix-atomos and keep the
> current svn for the website.
> 
> That would mean, we move all of the current svn/trunk into the new
> felix-dev repo and put a Readme in the svn/trunk instead, pointing to
> the two new repositories. That way, the website would still work as
> is, the trunk would be in git, and we could give atomos a separate
> repo.
> 
> Effectively, that would give us 3 repos on github for now namely,
> apache/felix (which is just a Readme pointing to the other two repos),
> apache/felix-dev, and apache/felix-atomos. If in the future we want to
> move out other parts of the trunk into their own repo we could do so
> if we think it makes sense.
> 
> I should be able to get that done next week and I'll start with it on
> Tuesday unless somebody really is against it (in other words, I'm
> calling for lazy consensus).
> 
> The alternatives I see are to either create a separate repo per module
> directly or to convert the current svn to just be the felix repo which
> would require to rework the website with asf.yml support and not give
> Tom a separate repo for atomos. However, in both cases, we would need
> some volunteers as I likely don't have enough time.
> 
> regards,
> 
> Karl
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: Felix on git(box)

[Jean-Baptiste Onofre]

Hi Karl,

Thanks for the update and done that.

I confirm that I received the gitbox notification that I have permission on the 
repository.

Thanks again,
Regards
JB

> Le 28 févr. 2020 à 00:50, Karl Pauls  a écrit :
> 
> Hi,
> 
> I finished the migration to git. Following the outline from last week,
> we now have two git repositories namely:
> 
> Felix Dev - https://github.com/apache/felix-dev
> Felix Atomos - https://github.com/apache/felix-atomos
> 
> Felix Dev has been migrated with history and I managed to get our
> release tags hooked up as well. Tom imported Atomos into Felix Atomos
> too.
> 
> Subsequently, I created an "archived" branch for the old apache/felix
> mirror which is at the point the trunk was in. Then, I emptied the
> trunk, put a readme explaining where to find the new repositories, and
> that the mirror is now considered obsolete.
> 
> In other words, our third git repo (which is the read-only mirror of
> svn trunk) is still:
> 
> Felix - https://github.com/apache/felix
> 
> but is now only the index to our other repos.
> 
> Please double check that things are still working for you and that I
> didn't overlook anything obvious (I did update the scm connections in
> the poms already).
> 
> I will go over the website tomorrow and update the info about where to
> find the source code.
> 
> regards,
> 
> Karl
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: [VOTE] Release Apache Felix Configadmin Interpolator Plugin 1.1.0

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 28 févr. 2020 à 07:49, Carsten Ziegeler  a écrit :
> 
> We solved two issues in this release:
> 
> https://issues.apache.org/jira/projects/FELIX/versions/12347152
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1324
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1324 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [git] Separate git projects for SCR, Configadmin and http

[Jean-Baptiste Onofre]

+1 for that.

Do you want me to tackle other modules (I’m thinking about fileinstall, utils, 
framework to start with) ?

Regards
JB

> Le 1 mars 2020 à 12:11, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> I would like to move the SCR implementation, Configadmin implementation and 
> http implementation into separate git project each (only one for all http sub 
> projects).
> 
> If no one objects, I'll go ahead in the next days.
> 
> Thanks
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [git] Separate git projects for SCR, Configadmin and http

[Jean-Baptiste Onofre]

OK, I will start with these repos.

I keep you posted.

Regards
JB

> Le 1 mars 2020 à 14:26, Carsten Ziegeler  a écrit :
> 
> I think moving to a separate git makes sense for active (in some sense) 
> projects. So, yes, I guess it makes sense for the three you mentioned, too.
> 
> +1
> 
> Carsten
> 
> On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
>> +1 for that.
>> Do you want me to tackle other modules (I’m thinking about fileinstall, 
>> utils, framework to start with) ?
>> Regards
>> JB
>>> Le 1 mars 2020 à 12:11, Carsten Ziegeler  a écrit :
>>> 
>>> Hi,
>>> 
>>> I would like to move the SCR implementation, Configadmin implementation and 
>>> http implementation into separate git project each (only one for all http 
>>> sub projects).
>>> 
>>> If no one objects, I'll go ahead in the next days.
>>> 
>>> Thanks
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
> 
> -- 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [git] Separate git projects for SCR, Configadmin and http

[Jean-Baptiste Onofre]

Hi Karl,

Thanks for your feedback.

I think what you said makes sense and we should address these points in a clear 
way, with a defined process.

So, as I’m volunteer to help, let me come back on this thread with a process 
proposal, including a detailed action plan where we can agree all together.

Let me prepare something ;)

Thanks again,
Regards
JB

> Le 2 mars 2020 à 07:52, Karl Pauls  a écrit :
> 
> Wait, I am objecting  :-).
> 
> In the first place, while I realize there are benefits to having a git
> project matching a subproject (and yes, I would like to move framework
> at one point), most I can think of correspond with active development
> or at a minimum, need work beyond just creating the repo and doing a
> move - hence, I think we should only consider such a move if at least
> one out of these two are likely for a given subproject (preferably,
> both).
> 
> That in part is why I was ok with atomos because, it clearly has some
> active development atm and is running a lot of tests and builds in
> actions etc (the other part is Tom really insisting). For SCR,
> configadmin, and http I could accept the second argument (mostly
> because they have big-ish test suites) - provided we have the
> commitment to not only move them but really set them up so that PRs
> get checked automatically, the readme make sense, etc. I have a harder
> time seeing it for fileinstall and utils atm mostly because there has
> been very little activity or we don't have that much testing or
> documentation in place. The framework, I have quite some things queued
> up in my sandbox for connect - so I guess some level of active
> development applies but I would still call it a bit of a stretch atm
> unless we'd really set-up the test suite too.
> 
> In the second place, I strongly feel we should define a process (incl.
> all necessary steps/actions) for module breakout and get our house in
> order first. I don't think it is a good idea to start breaking out
> modules without a plan. It is unclear how we would break out modules
> (what are the steps/scripts to keep the tags, etc.) and how is that
> explained/workable e.g., how would you find/check out all modules,
> etc. Furthermore, we didn't yet update the website with the current
> change to our source repo (let alone, migrate the website itself to
> git). Starting to break out arbitrary modules is not going to make it
> more likely to have that documented and explained in a good way.
> 
> Having two (and a read-only, almost empty) repos is one thing to
> convey and work with - tens (or like some other project have, even
> hundreds) is another. Yes, all of theses things are solvable (and
> solved in one way or the other by other projects) but we need them
> solved for us and I suggest doing that first (including consensus).
> 
> In other words, in general I'm against to breaking out modules until
> the following is addressed:
> 
> - the website is migrated from svn (and cms.apache.org) to git and
> something that works with asf.yaml
> - the website content is updated to reflect the current git move
> (instructions, locations, links to svn, the works)
> - we have an agreed upon set of steps/actions/scripts to use to break
> out a module (incl. history, tags, website updates, etc).
> - and a documented way of working with our repos (how to find, check
> out together, etc).
> 
> Furthermore, wrt. "Separate git projects for SCR, Configadmin and
> http" until we have a proposal for the improvements we would get by
> breaking them out and have volunteers to implement them.
> 
> Finally, I'm against "other modules" until we determined on a
> case-by-case vote basis that we assume a development activity uptick
> is imminent and somebody proposes (and volunteers to implement)
> reasonable improvements we would get by breaking them out.
> 
> That said, I don't think any of the above is super hard to achieve -
> hence, if you (or others) are volunteering: let's get it done. Maybe
> start with creating JIRAs for the above and start discussions around
> how to achieve them?
> 
> regards,
> 
> Karl
> 
> On Mon, Mar 2, 2020 at 7:24 AM Jean-Baptiste Onofre  wrote:
>> 
>> OK, I will start with these repos.
>> 
>> I keep you posted.
>> 
>> Regards
>> JB
>> 
>>> Le 1 mars 2020 à 14:26, Carsten Ziegeler  a écrit :
>>> 
>>> I think moving to a separate git makes sense for active (in some sense) 
>>> projects. So, yes, I guess it makes sense for the three you mentioned, too.
>>> 
>>> +1
>>> 
>>> Carsten
>>> 
>>> On 01.03.2020 12:41, Jean-Baptiste Onofre wrote:
>>>> +

Re: March 2020 board report

[Jean-Baptiste Onofre]

Hi Karl,

The report looks good to me. I bet the board will ask some explanations about 
numbers (mailing list activity, …).

Regards
JB

> Le 9 mars 2020 à 22:39, Karl Pauls  a écrit :
> 
> Hi,
> 
> please find the board report below. Comments welcome.
> 
> ## Description:
> 
> Apache Felix is a project aimed at implementing specifications from the OSGi
> 
> Alliance as well as implementing other supporting tools and technologies
> 
> aligned with OSGi technology.
> 
> 
> ## Issues:
> 
> There are no issues requiring board attention.
> 
> 
> ## Membership Data:
> 
> Apache Felix was founded 2007-03-28 (13 years ago)
> 
> There are currently 68 committers and 27 PMC members in this project.
> 
> The Committer-to-PMC ratio is roughly 9:4.
> 
> 
> Community changes, past quarter:
> 
> - No new PMC members. Last addition was Georg Henzler on 2019-06-10.
> 
> - Stefan Bischof was added as committer on 2020-03-02
> 
> 
> ## Project Activity:
> 
> - Existing implementations have been improved/enhanced based on community
> 
> feedback.
> 
> - We did migrate from svn to git(box) and started reorganising around git
> 
> repositories (including a rework of our website to reflect the changes).
> 
> - We are discussing breaking out some of our bigger subproject into additional
> 
> git repositories.
> 
> - We accepted and integrated the "Atomos" contribution by Thomas Watson and
> 
> attracted a new committer in the process (Stefan Bischof).
> 
> - Released 3 components (mostly bug fixes overall).
> 
> 
> ## Releases:
> 
> - org.apache.felix.configadmin.plugin.interpolation-1.1.0 was released on
> 
> 2020-03-02.
> 
> - maven-scr-plugin-1.26.2 was released on 2019-12-07.
> 
> - org.apache.felix.scr.bnd-1.9.6 was released on 2019-12-07.
> 
> - org.apache.felix.scr.bnd-1.9.4 was released on 2019-12-07.
> 
> 
> ## Community Health:
> 
> - Overall the project is in ok health.
> 
> - Questions on the user list are answered, development concerns are either
> 
> discussed on the mailing list or directly in the JIRA issues.
> 
> - The project as well as the OSGi community in general is still in the process
> 
> of adapting to JPMS and Graal/substrate - however, we hope that Atomos and
> 
> the new OSGi Connect RFC will help in that area.
> 
> - We need to be on the lookout for new committers. Atomos and the move to 
> github
> 
> hopefully will help in attracting more people.
> 
> - We had no issues voting on releases and JIRA issues are generally addressed.
> 
> - dev@felix.apache.org had a 30% decrease in traffic in the past quarter
> 
> (292 emails compared to 415)
> 
> - us...@felix.apache.org had a 166% increase in traffic in the past quarter
> 
> (8 emails compared to 3)
> 
> - 30 issues opened in JIRA, past quarter (11% increase)
> 
> - 24 issues closed in JIRA, past quarter (33% increase)
> 
> - 19 commits in the past quarter (-47% decrease)
> 
> - 4 code contributors in the past quarter (-42% decrease)
> 
> - 9 PRs opened on GitHub, past quarter (-30% decrease)
> 
> - 14 PRs closed on GitHub, past quarter (133% increase)

Re: [VOTE] Release Apache Felix Http Jetty 4.0.16

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 12 mars 2020 à 17:15, dav...@apache.org a écrit :
> 
> Hi all,
> 
> I would like to release http.jetty-4.0.16
> 
> We solved the following issues in this release:
> https://issues.apache.org/jira/projects/FELIX/versions/12346636
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1325
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1325 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Best regards,
> 
> David Bosschaert

Re: [VOTE] Release FileInstall 3.6.6

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 1 avr. 2020 à 15:34, Guillaume Nodet  a écrit :
> 
> I'm calling a vote to release the following 4 bugs in FileInstall:
>* [FELIX-5832] - ConfigInstaller should only handle events for
> configurations it manages
>* [FELIX-6103] - ConfigInstaller, when using
> NotCachablePersistenceManager, can restore cached stale properties
>* [FELIX-6109] - NPE from null listener in DirectoryWatcher.findListener
>* [FELIX-6211] - fileinstall filter out subdirectories even though
> felix.fileinstall.subdir.mode property is set to 'recurse'
> 
> Staging repository:
>  https://repository.apache.org/content/repositories/orgapachefelix-1326/
> 
> 
> You can use this UNIX script to download the release and verify the
> signatures:
>  https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1326 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> -- 
> 
> Guillaume Nodet

Re: [VOTE] Release Apache Felix Web Console 4.4.0

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 2 avr. 2020 à 13:00, dav...@apache.org a écrit :
> 
> Hi all,
> 
> I would like to release webconsole-4.4.0
> 
> We solved the following issues in this release:
> https://issues.apache.org/jira/projects/FELIX/versions/12346045
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1327
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1327 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Best regards,
> 
> David Bosschaert

[VOTE] Apache Felix Gogo Parent 6 & Gogo JLine 1.1.6 releases

[Jean-Baptiste Onofre]

Hi everyone,

I’m calling a vote to release Gogo Parent 6 (just to update scm section) and 
Gogo JLine 1.1.6 containing:

* [FELIX-6214] - Gogo JLine range import/upgrade

Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-1328/ 


Please vote to approve this release:

 [ ] + 1 Approve the release
 [ ] -1 Don’t approve the release (please provide specific comments)

This vote will be open for 72 hours.

Regards
JB

Re: [VOTE] Apache Felix Gogo Parent 6 & Gogo JLine 1.1.6 releases

[Jean-Baptiste Onofre]

Good point, I will do a pass on other Gogo Jira and update then.

Thanks,
Regards
JB

> Le 5 avr. 2020 à 18:19, Raymond Auge  a écrit :
> 
> It would be nice to also update the gogo BOM, but not a stopper.
> 
> +1
> 
> - Ray
> 
> On Sun, Apr 5, 2020 at 1:54 AM Jean-Baptiste Onofre  wrote:
> 
>> Hi everyone,
>> 
>> I’m calling a vote to release Gogo Parent 6 (just to update scm section)
>> and Gogo JLine 1.1.6 containing:
>> 
>> * [FELIX-6214] - Gogo JLine range import/upgrade
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1328/ <
>> https://repository.apache.org/content/repositories/orgapachefelix-1328/>
>> 
>> Please vote to approve this release:
>> 
>> [ ] + 1 Approve the release
>> [ ] -1 Don’t approve the release (please provide specific comments)
>> 
>> This vote will be open for 72 hours.
>> 
>> Regards
>> JB
> 
> 
> 
> -- 
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)

Re: [VOTE] Apache Felix Gogo Parent 6 & Gogo JLine 1.1.6 releases

[Jean-Baptiste Onofre]

Casting my own +1 (binding)

Regards
JB

> Le 5 avr. 2020 à 07:54, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I’m calling a vote to release Gogo Parent 6 (just to update scm section) and 
> Gogo JLine 1.1.6 containing:
> 
> * [FELIX-6214] - Gogo JLine range import/upgrade
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1328/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1328/>
> 
> Please vote to approve this release:
> 
> [ ] + 1 Approve the release
> [ ] -1 Don’t approve the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> Regards
> JB

[RESULT][VOTE] Apache Felix Gogo Parent 6 & Gogo JLine 1.1.6 releases

[Jean-Baptiste Onofre]

Hi,

This vote passed with the following result:

+1 (binding): Ray Auge, Carsten Ziegeler, JB Onofré, Pierre de Rop, Karl Pauls, 
Guillaume Nodet, David Bosschaert

I’m promoting the artifacts to Maven Central and update Jira.

Thanks all for you vote.

Regards
JB

> Le 5 avr. 2020 à 07:54, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I’m calling a vote to release Gogo Parent 6 (just to update scm section) and 
> Gogo JLine 1.1.6 containing:
> 
> * [FELIX-6214] - Gogo JLine range import/upgrade
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1328/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1328/>
> 
> Please vote to approve this release:
> 
> [ ] + 1 Approve the release
> [ ] -1 Don’t approve the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> Regards
> JB

Re: Proposal for a microservice blueprint

[Jean-Baptiste Onofre]

Hi Christian,

That’s interesting, but I think that people are expecting more than that.

1. Most of the time, we do things too much complex.
2. Assembly again layers is not always easy
3. Where’s the runtime ?

Your main point is valid: lot of people went too far in fine grained services 
and now, they are thinking about "smart" micro services.
That’s exactly the purpose of Netflix using Apache Karaf.

Back on your point, that’s the target of "new" Karaf tool that I restarted 
(re-starting/founding Karaf Boot we discussed while ago that addressed exactly 
the points you mentioned).

So, why not having a blueprint (I still think people wants to create their own 
blueprint), but having tool + runtime is more interesting and that’s why I’m 
working on Karaf "DevX code" PoC.

Regards
JB

> Le 12 avr. 2020 à 11:58, Christian Schneider  a 
> écrit :
> 
> In recent years we saw a big trend towards micro services and cloud.
> Lately people discovered though that such services are often made too fine
> grained.
> The newest trend goes to building bigger micro services on the level of
> domain driven design bounded contexts.
> 
> Especially for these services OSGi is a very interesting platform as they
> need more internal structure than the more fine grained services.
> Unfortunately it is quite hard to build a cloud native service in OSGi from
> scratch.
> 
> So I would like to offer a blueprint for cloud native micro services inside
> the felix community. The goal is to provide all parts of a cloud native
> system that are usually needed, like:
> 
> * Declarative services as dependency injection
> * Aries Jaxrs Whiteboard for REST
> * Dropwizard metrics exported as Prometheus metrics
> * Swagger
> * Halbrowser
> * Felix healthchecks
> * Configuration using OSGi configurator + Environment variables plugin
> * Logging to console
> * Final application is provided as a runnable jar
> * Example docker build files
> * Example kubernetes yaml
> 
> What do you think?
> 
> Christian
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

Re: Proposal for a microservice blueprint

[Jean-Baptiste Onofre]

Hi Christian,

I will push the devx (for developer experience) branch today or tomorrow 
morning.

Basically, it contains:

- a BOM providing the dependencies (osgi.annotation, jarxrs, …)
- a core/SDK
- extension for the sdk (gradle, maven, cli, junit5) building artifacts and 
runtime

It comes from what we did on Karaf-boot (PoC), winegrower, and discussion I 
have with Netflix mainly.

François and I are working on this for some weeks now with the support of 
Romain as well.
That would be great to have a join effort around that.

Regards
JB

> Le 12 avr. 2020 à 19:58, Christian Schneider  a 
> écrit :
> 
> Looking forward to what you come up with. Do you already have something to
> look into or help with?
> 
> I will try to get along without a special runtime (basically just felix
> framework + suitably configured bundles).
> For a first application assembly I plan to use bnd maven plugins like in
> the enroute example.
> 
> There is a lot of possible space for improvements though. I hope there are
> some cool tools from karaf we can use to make the assembly and runtime even
> better.
> 
> Christian
> 
> Am So., 12. Apr. 2020 um 19:46 Uhr schrieb Jean-Baptiste Onofre <
> j...@nanthrax.net>:
> 
>> Hi Christian,
>> 
>> That’s interesting, but I think that people are expecting more than that.
>> 
>> 1. Most of the time, we do things too much complex.
>> 2. Assembly again layers is not always easy
>> 3. Where’s the runtime ?
>> 
>> Your main point is valid: lot of people went too far in fine grained
>> services and now, they are thinking about "smart" micro services.
>> That’s exactly the purpose of Netflix using Apache Karaf.
>> 
>> Back on your point, that’s the target of "new" Karaf tool that I restarted
>> (re-starting/founding Karaf Boot we discussed while ago that addressed
>> exactly the points you mentioned).
>> 
>> So, why not having a blueprint (I still think people wants to create their
>> own blueprint), but having tool + runtime is more interesting and that’s
>> why I’m working on Karaf "DevX code" PoC.
>> 
>> Regards
>> JB
>> 
>>> Le 12 avr. 2020 à 11:58, Christian Schneider 
>> a écrit :
>>> 
>>> In recent years we saw a big trend towards micro services and cloud.
>>> Lately people discovered though that such services are often made too
>> fine
>>> grained.
>>> The newest trend goes to building bigger micro services on the level of
>>> domain driven design bounded contexts.
>>> 
>>> Especially for these services OSGi is a very interesting platform as they
>>> need more internal structure than the more fine grained services.
>>> Unfortunately it is quite hard to build a cloud native service in OSGi
>> from
>>> scratch.
>>> 
>>> So I would like to offer a blueprint for cloud native micro services
>> inside
>>> the felix community. The goal is to provide all parts of a cloud native
>>> system that are usually needed, like:
>>> 
>>> * Declarative services as dependency injection
>>> * Aries Jaxrs Whiteboard for REST
>>> * Dropwizard metrics exported as Prometheus metrics
>>> * Swagger
>>> * Halbrowser
>>> * Felix healthchecks
>>> * Configuration using OSGi configurator + Environment variables plugin
>>> * Logging to console
>>> * Final application is provided as a runnable jar
>>> * Example docker build files
>>> * Example kubernetes yaml
>>> 
>>> What do you think?
>>> 
>>> Christian
>>> 
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> 
>>> Computer Scientist
>>> http://www.adobe.com
>> 
>> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

Re: [VOTE] Release http.base 4.0.10, http.bridge 4.0.12, and http.jetty 4.0.18

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 13 avr. 2020 à 17:43, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> We solved 2 issues in http.jetty 4.0.18:
> 
> https://issues.apache.org/jira/browse/FELIX-6257?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20http.jetty-4.0.18
> 
> and one issue in http.base 4.0.10 and http.bridge 4.0.12:
> https://issues.apache.org/jira/browse/FELIX-6253
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1330
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1330 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix SCR 2.1.18

[Jean-Baptiste Onofre]

+1 (binding)

Tested on Karaf examples.

Regards
JB

> Le 13 avr. 2020 à 17:00, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> We solved 9 issues in this release:
> https://github.com/apache/felix-dev/blob/org.apache.felix.scr-2.1.18/scr/changelog.txt
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1329
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1329 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Proposal for a microservice blueprint

[Jean-Baptiste Onofre]

And here’s come Winegrower: the OSGi programming flavor (with service) with a 
single flat class loader ;)

Regards
JB

> Le 15 avr. 2020 à 08:11, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> First, I'm not good at telling what should be done or providing visions for
> something new and revolutionary. I'm experienced with checking what SHOULD
> NOT be done and how to polish/stabilize/cleanup existing things, created by
> much clever people than me.
> 
> [...] such as graalvm or quarkus. (I know so little about this that I could
>> be wrong about what these are).
>> 
> 
> I can provide a little explanation, but I'm not core Quarkus dev. When
> talking about "cloud", the above are very important.
> 
> GraalVM is based on HotSpot with these (roughly) differences:
> - through JVMCI interface (https://openjdk.java.net/jeps/243) the normal
> _compiler_ of hotspot (the bytecode -> native code compiler, not the source
> -> bytecode one) is replaced by Graal compiler
> - Graal compiler is written in Java, so it's JITted itself
> - Graal claims to create better native code
> - *Graal allows ahead-of-time compilation*
> - SubstrateVM being part of Graal has `native-image` tool, so you can get
> ELF binary from a Jar
> 
> Quarkus leverages the above, and brings many dev-friendly aspects to it
> (it's developed by Red Hat and it's kind of similar situation as with
> Kubernetes - OpenShift) - mind that I'm not much experienced with it yet
> - brings new tools to the dev toolkit (mostly maven plugins)
> - brings an API to expose the ahead-of-time aspects of Graal - generally,
> you can mark methods/classes of your code (through annotations) as "running
> in build phase"
> - "build phase" is executed before even starting the VM. Imagine
> HIbernate. When you create Hibernate based µservice and you start it, lots
> of time is spent reading XML/annotations and building SessionFactory. With
> Quarkus, this *all can be done at build phase* and you end up with bytecode
> (or in native case - premade memory pages that can simply be mapped to your
> process). Then when your main() starts, you don't have to create
> SessionFactory - you *have it*
> 
> Mind that the above is not precise, but should not miss the picture (I'm
> for example not sure about the premade memory pages).
> 
> OK. Now what should be avoided. In Red Hat Fuse 6 was based only on Karaf.
> Fuse 7 though has more forms and there's a lot about OpenShift. The
> problematic thing was - how to put Karaf into OpenShift.
> 
> Think about what is important in "cloud" - you need your pod/container
> start as fast as possible because of all this scaling-to-demand thing.
> Imagine lambda-functions (or whatever it's called nowadays). If a µservice
> would spend 95% of the time building SessionFactory and 5% inserting the
> record into database, it'd be crazy.
> 
> With OSGi, lots of warmup comes from bundle resolution. I know the
> resolution state can be persisted. But still.
> 
> I don't have clear answers or even clear feedback to this thread. I feel
> one thing - there are 2 critical and fundamental OSGi aspects:
> - module layer (bundles, manifests, caps-reqs)
> - service layer (service registry)
> 
> And while the service layer (supported by e.g., SCR annotations/runtime) is
> *the synonym of µservices* (see blog from 2010 when no one talked about it
> yet: https://blog.osgi.org/2010/03/services.html), the module layer is what
> may be a problem here.
> 
> All the effort with felix-connect, Atomos (which I've just checked covers
> SubstrateVM scenarios - I wasn't aware of this) is about making
> module-layer more cloud friendly.
> 
> I feel a little confused. Having worked 100% with OSGi for >6 years I found
> the original module layer the most important thing - because of the bundle
> resolution, cap-req matching, versioning, bundle revisions and wirings. The
> API and programming model aspect of OSGi was not that important which has
> two consequences:
> 1) I just got used to it that I have access to BundleContext,
> BundleRevision and other API interfaces and e.g., blueprint.xml format
> 2) If not the module layer of OSGi, nothing would keep me using the above
> API
> 
> CDI and Spring (annotations, XML) are other, widely used programming (and
> code-architecting) models and I somehow feel that when module layer is
> gone, these models are simply better, more flexible and less constraining
> than SCR or Blueprint.
> 
> So when OSGi "adopts" the module layer to the "cloud", turning it into
> flat-classpath deployment, what's the reason to call it OSGi at all?
> 
> Please don't get me wrong - I'm not going to sabotage any effort, I want to
> avoid the confusion.
> 
> Imagine this
> - we turn module layer into flat classpath
> - we use aries-cdi to allow programming beans/services using CDI
> annotations (JavaEE)
> - we use aries-jaxrs to create WS/REST endpoints using Jax-RS annotations
> (JavaEE)
> - we hide BundleContext.getServiceReference()/getService() APi
> 
> 

Re: [VOTE] Release Apache Felix Parent 7

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 15 avr. 2020 à 13:53, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> i've updated our parent pom to the latest plugin versions, switched to Java 8 
> as the default version (bnd >= 4.0.0 requires it anyway), changed http: urls 
> to https: and allow to use Java versions > 9 for a project.
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1331
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1331 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix CM Json 1.0.0

[Jean-Baptiste Onofre]

+1 (binding)

It’s great because I need this release for Karaf ;)

Thanks Carsten !

Regards
JB

> Le 17 avr. 2020 à 07:50, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> i've extracted the handling of json based configurations from the 
> configurator implementation and made a separate api out of it which allows to 
> read/write configuration (resources). Without this api, tooling needing to 
> deal with configuration resources either needed to reinvent the wheel or 
> depend on configurator implementation internals.
> 
> So please cast your vote for the first release of this module
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1332
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1332 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix Converter 1.0.14

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 17 avr. 2020 à 10:26, David Bosschaert  a 
> écrit :
> 
> Hi all,
> 
> I would like to release org.apache.felix.converter-1.0.14
> 
> We solved the following issues in this release:
> https://issues.apache.org/jira/projects/FELIX/versions/12346490
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1333
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1333 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Best regards,
> 
> David Bosschaert

Re: Proposal for a microservice blueprint

[Jean-Baptiste Onofre]

Hi Thomas,

Did you take a look on Winegrower ? (Just curious):

https://github.com/apache/karaf-winegrower 


Regards
JB

> Le 17 avr. 2020 à 15:47, Thomas Watson  a écrit :
> 
> I just want to clarify a bit on Atomos and OSGi Connect.  While OSGi
> Connect does allow some more flexibility in the Module Layer of OSGi, it is
> not entirely getting rid of it.  There is still a resolution, there are
> still bundle wirings and the powerful requirement/capability model, there
> are still bundle events and so on.  What it does allow is loading of
> bundles from alternative formats/sources to allow the usage of OSGi
> technology in environments not previously possible (such as Graal
> native-image).  If you have issues today getting resolution to work for a
> particular deployment of OSGi bundles then these same resolution issues
> will be present when using Atomos.  On the other hand, if you find value in
> the OSGi development model then you can continue to develop your bundles as
> you do today but then have the flexibility to deploy your bundles in
> environments not previously possible.  The fact that we continue to do a
> resolution of connect bundles is an effort to make sure all the things your
> bundle needs to be functional is available and accessible from your connect
> bundle.
> 
> Tom
> 
> On Wed, Apr 15, 2020 at 1:11 AM Grzegorz Grzybek 
> wrote:
> 
>> Hello
>> 
>> First, I'm not good at telling what should be done or providing visions for
>> something new and revolutionary. I'm experienced with checking what SHOULD
>> NOT be done and how to polish/stabilize/cleanup existing things, created by
>> much clever people than me.
>> 
>> [...] such as graalvm or quarkus. (I know so little about this that I could
>>> be wrong about what these are).
>>> 
>> 
>> I can provide a little explanation, but I'm not core Quarkus dev. When
>> talking about "cloud", the above are very important.
>> 
>> GraalVM is based on HotSpot with these (roughly) differences:
>> - through JVMCI interface (https://openjdk.java.net/jeps/243) the normal
>> _compiler_ of hotspot (the bytecode -> native code compiler, not the source
>> -> bytecode one) is replaced by Graal compiler
>> - Graal compiler is written in Java, so it's JITted itself
>> - Graal claims to create better native code
>> - *Graal allows ahead-of-time compilation*
>> - SubstrateVM being part of Graal has `native-image` tool, so you can get
>> ELF binary from a Jar
>> 
>> Quarkus leverages the above, and brings many dev-friendly aspects to it
>> (it's developed by Red Hat and it's kind of similar situation as with
>> Kubernetes - OpenShift) - mind that I'm not much experienced with it yet
>> - brings new tools to the dev toolkit (mostly maven plugins)
>> - brings an API to expose the ahead-of-time aspects of Graal - generally,
>> you can mark methods/classes of your code (through annotations) as "running
>> in build phase"
>> - "build phase" is executed before even starting the VM. Imagine
>> HIbernate. When you create Hibernate based µservice and you start it, lots
>> of time is spent reading XML/annotations and building SessionFactory. With
>> Quarkus, this *all can be done at build phase* and you end up with bytecode
>> (or in native case - premade memory pages that can simply be mapped to your
>> process). Then when your main() starts, you don't have to create
>> SessionFactory - you *have it*
>> 
>> Mind that the above is not precise, but should not miss the picture (I'm
>> for example not sure about the premade memory pages).
>> 
>> OK. Now what should be avoided. In Red Hat Fuse 6 was based only on Karaf.
>> Fuse 7 though has more forms and there's a lot about OpenShift. The
>> problematic thing was - how to put Karaf into OpenShift.
>> 
>> Think about what is important in "cloud" - you need your pod/container
>> start as fast as possible because of all this scaling-to-demand thing.
>> Imagine lambda-functions (or whatever it's called nowadays). If a µservice
>> would spend 95% of the time building SessionFactory and 5% inserting the
>> record into database, it'd be crazy.
>> 
>> With OSGi, lots of warmup comes from bundle resolution. I know the
>> resolution state can be persisted. But still.
>> 
>> I don't have clear answers or even clear feedback to this thread. I feel
>> one thing - there are 2 critical and fundamental OSGi aspects:
>> - module layer (bundles, manifests, caps-reqs)
>> - service layer (service registry)
>> 
>> And while the service layer (supported by e.g., SCR annotations/runtime) is
>> *the synonym of µservices* (see blog from 2010 when no one talked about it
>> yet: https://blog.osgi.org/2010/03/services.html), the module layer is
>> what
>> may be a problem here.
>> 
>> All the effort with felix-connect, Atomos (which I've just checked covers
>> SubstrateVM scenarios - I wasn't aware of this) is about making
>> module-layer more cloud friendly.
>> 
>> I feel a little confused. Having worked 1

Re: Atomos - Winegrower

[Jean-Baptiste Onofre]

Hi Tom,

Basically, Winegrower idea is to bring the OSGi programming model (activator, 
service, etc) with a "flat" class loader.

So, Winegrower is scanning the provided jar gathering in a single classloader.

I’m adding new examples to show use cases.

I’m open to any new ideas/features ;)

Regards
JB

> Le 17 avr. 2020 à 16:35, Thomas Watson  a écrit :
> 
> Hi JB
> 
> Changing subject to start new thread ...
> 
> I have taken a look at Winegrower, but have not played around with it yet.
> I am curious if something like Winegrower would be interested in using OSGi
> Connect to back it with an OSGi R8 framework implementation or perhaps use
> Atomos for bundle discovery?
> 
> Tom
> 
> On Fri, Apr 17, 2020 at 9:15 AM Jean-Baptiste Onofre 
> wrote:
> 
>> Hi Thomas,
>> 
>> Did you take a look on Winegrower ? (Just curious):
>> 
>> https://github.com/apache/karaf-winegrower <
>> https://github.com/apache/karaf-winegrower>
>> 
>> Regards
>> JB
>> 
>>> Le 17 avr. 2020 à 15:47, Thomas Watson  a écrit :
>>> 
>>> I just want to clarify a bit on Atomos and OSGi Connect.  While OSGi
>>> Connect does allow some more flexibility in the Module Layer of OSGi, it
>> is
>>> not entirely getting rid of it.  There is still a resolution, there are
>>> still bundle wirings and the powerful requirement/capability model, there
>>> are still bundle events and so on.  What it does allow is loading of
>>> bundles from alternative formats/sources to allow the usage of OSGi
>>> technology in environments not previously possible (such as Graal
>>> native-image).  If you have issues today getting resolution to work for a
>>> particular deployment of OSGi bundles then these same resolution issues
>>> will be present when using Atomos.  On the other hand, if you find value
>> in
>>> the OSGi development model then you can continue to develop your bundles
>> as
>>> you do today but then have the flexibility to deploy your bundles in
>>> environments not previously possible.  The fact that we continue to do a
>>> resolution of connect bundles is an effort to make sure all the things
>> your
>>> bundle needs to be functional is available and accessible from your
>> connect
>>> bundle.
>>> 
>>> Tom
>>> 
>>> On Wed, Apr 15, 2020 at 1:11 AM Grzegorz Grzybek 
>>> wrote:
>>> 
>>>> Hello
>>>> 
>>>> First, I'm not good at telling what should be done or providing visions
>> for
>>>> something new and revolutionary. I'm experienced with checking what
>> SHOULD
>>>> NOT be done and how to polish/stabilize/cleanup existing things,
>> created by
>>>> much clever people than me.
>>>> 
>>>> [...] such as graalvm or quarkus. (I know so little about this that I
>> could
>>>>> be wrong about what these are).
>>>>> 
>>>> 
>>>> I can provide a little explanation, but I'm not core Quarkus dev. When
>>>> talking about "cloud", the above are very important.
>>>> 
>>>> GraalVM is based on HotSpot with these (roughly) differences:
>>>> - through JVMCI interface (https://openjdk.java.net/jeps/243) the
>> normal
>>>> _compiler_ of hotspot (the bytecode -> native code compiler, not the
>> source
>>>> -> bytecode one) is replaced by Graal compiler
>>>> - Graal compiler is written in Java, so it's JITted itself
>>>> - Graal claims to create better native code
>>>> - *Graal allows ahead-of-time compilation*
>>>> - SubstrateVM being part of Graal has `native-image` tool, so you can
>> get
>>>> ELF binary from a Jar
>>>> 
>>>> Quarkus leverages the above, and brings many dev-friendly aspects to it
>>>> (it's developed by Red Hat and it's kind of similar situation as with
>>>> Kubernetes - OpenShift) - mind that I'm not much experienced with it yet
>>>> - brings new tools to the dev toolkit (mostly maven plugins)
>>>> - brings an API to expose the ahead-of-time aspects of Graal -
>> generally,
>>>> you can mark methods/classes of your code (through annotations) as
>> "running
>>>> in build phase"
>>>> - "build phase" is executed before even starting the VM. Imagine
>>>> HIbernate. When you create Hibernate based µservice and you start it,
>> lots
>>>> of time is spent

Re: [VOTE] Release Apache Felix cm.json 1.0.2

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 20 avr. 2020 à 12:38, Carsten Ziegeler  a écrit :
> 
> Hi,
> we solved two issues
> 
> https://issues.apache.org/jira/browse/FELIX-6264?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20cm.json-1.0.2
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1335
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1335 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Proposal to contribute OSGi application metrics bundles

[Jean-Baptiste Onofre]

Hi,

Healthcheck can be a place.

Karaf Decanter can be another option as well.

Regards
JB

> Le 21 avr. 2020 à 14:25, Robert Munteanu  a écrit :
> 
> Hi,
> 
> I have been working on collecting startup metrics for OSGi
> applications.  I am interested in finding potentials for optimising
> startup time, so created a set of bundles that record:
> 
> - total startup time
> - bundles that are slow to start
> - OSGi services that are restarted during startup
> 
> I think the functionality would be useful for the wider community and
> would like to ask whether the Felix project would be interested in
> hosting it.
> 
> The 'project' consists of two bundles:
> 
> - one that starts as early as possible and collects startup metrics
> - one that contains some out-of-the-box consumers of metrics
>  - Dropwizard metrics
>  - slf4j logging
>  - JSON output to disk
> 
> The bundles are in the Apache Sling whiteboard for now [1], so no
> releases were cut, no documentation to change, no backwards
> compatibility to consider.
> 
> Do you think this functionality has its place in Felix? I would be
> happy to contribute it, if the community agrees.
> 
> Thanks,
> Robert
> 
> 
> [1]: https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics
> 

Re: Proposal to contribute OSGi application metrics bundles

[Jean-Baptiste Onofre]

Definitely I agree with you. I would love to create a new collector in Decanter 
;)

Regards
JB

> Le 23 avr. 2020 à 15:10, Robert Munteanu  a écrit :
> 
> Hi JB,
> 
> On Tue, 2020-04-21 at 16:21 +0200, Jean-Baptiste Onofre wrote:
>> Hi,
>> 
>> Healthcheck can be a place.
> 
> This indeed related to the HealthCheck module. It only consumes the
> API, so I would say this should not necessarily be bundled/included in
> the HC.
> 
>> 
>> Karaf Decanter can be another option as well.
> 
> Reading on the Decanter, I can see that it's a monitoring solution. I
> think there is a link here, as these metrics I'm gathering can be
> wrapped as a Decanter collector and then the output pushed through any
> kind of appender.
> 
> I would still prefer to make this solution generic, as I'm not
> currently using Decanter.
> 
> Thanks,
> Robert
> 
>> 
>> Regards
>> JB
>> 
>>> Le 21 avr. 2020 à 14:25, Robert Munteanu  a
>>> écrit :
>>> 
>>> Hi,
>>> 
>>> I have been working on collecting startup metrics for OSGi
>>> applications.  I am interested in finding potentials for optimising
>>> startup time, so created a set of bundles that record:
>>> 
>>> - total startup time
>>> - bundles that are slow to start
>>> - OSGi services that are restarted during startup
>>> 
>>> I think the functionality would be useful for the wider community
>>> and
>>> would like to ask whether the Felix project would be interested in
>>> hosting it.
>>> 
>>> The 'project' consists of two bundles:
>>> 
>>> - one that starts as early as possible and collects startup metrics
>>> - one that contains some out-of-the-box consumers of metrics
>>> - Dropwizard metrics
>>> - slf4j logging
>>> - JSON output to disk
>>> 
>>> The bundles are in the Apache Sling whiteboard for now [1], so no
>>> releases were cut, no documentation to change, no backwards
>>> compatibility to consider.
>>> 
>>> Do you think this functionality has its place in Felix? I would be
>>> happy to contribute it, if the community agrees.
>>> 
>>> Thanks,
>>> Robert
>>> 
>>> 
>>> [1]: 
>>> https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics
>>> 
> 

Re: [VOTE] Accept the application metrics bundles contribution

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 30 avr. 2020 à 17:22, Karl Pauls  a écrit :
> 
> I think the discussion of the "application metrics bundles" contribution
> (https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics)
> by Robert Munteanu has died down by now. It looks like there is some
> interest in the idea and
> given that Robert is willing to maintain it we should bring it to a vote.
> 
> This vote is about officially accepting the donation. As this has been
> developed in Apache already we don't have to sort out the IP
> clearance.
> 
> Please cast your votes:
> 
> [ ] +1 Accept the contribution into Felix
> [ ] -1 Do not

Re: [VOTE] Release Apache Felix WebConsole 4.5.2

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 5 mai 2020 à 08:54, Carsten Ziegeler  a écrit :
> 
> Hi,
> we solved two issues in this release:
> 
> https://github.com/apache/felix-dev/blob/master/webconsole/changelog.txt
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1337
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1337 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: What is the status of latest gogo/jline in master branch ?

[Jean-Baptiste Onofre]

Hi,

FYI it works fine in Karaf as we "wrap" gogo in Karaf console (with our own 
activator).

I will take a look on the PR (for "standalone" use).

Regards
JB

> Le 10 juin 2020 à 18:48, Pierre De Rop  a écrit :
> 
> Hi Arnoud,
> 
> thanks ! indeed, adding the Activator makes all working fine. I guess we
> can now just merge your pull request ?
> 
> thanks & regards
> /Pierre
> 
> 
> 
> 
> 
> On Wed, Jun 10, 2020 at 6:03 PM Arnoud Glimmerveen 
> wrote:
> 
>> Hi Pierre,
>> 
>> I believe this is due to a missing Bundle-Activator header. I have opened
>> a PR [1] for this a couple of weeks ago, but this has not been picked up
>> yet.
>> 
>> Best regards,
>> 
>> Arnoud.
>> 
>> [1] https://github.com/apache/felix-dev/pull/16 <
>> https://github.com/apache/felix-dev/pull/16>
>> 
>>> On 10 Jun 2020, at 17:59, Pierre De Rop  wrote:
>>> 
>>> Hi all,
>>> 
>>> I'm trying to run the latest gogo bundles which I have built from the
>>> master branch (using java8). So I have the following bundles in my felix
>> 6.0.3
>>> bundle directory:
>>> 
>>> org.apache.felix.gogo.command-1.1.1-SNAPSHOT.jar
>>> org.apache.felix.gogo.jline-1.1.7-SNAPSHOT.jar
>>> org.apache.felix.gogo.runtime-1.1.3-SNAPSHOT.jar
>>> jline-3.13.2.jar
>>> jansi-1.17.1.jar
>>> 
>>> But when starting felix, I don't see any gogo prompt, and nothing is
>>> displayed.
>>> 
>>> What is the status of the gogo bundles in the master branch ? am I
>> missing
>>> something ? maybe some more bundles should now be added ?
>>> 
>>> Note that if I replace org.apache.felix.gogo.jline-1.1.7-SNAPSHOT.jar
>>> by org.apache.felix.gogo.shell-1.1.3-SNAPSHOT.jar, then it works fine
>>> (either using java8 or java11).
>>> for example, using OpenJDK Runtime Environment (AdoptOpenJDK)(build
>>> 1.8.0_252-b09):
>>> 
>>> java -jar bin/felix.jar
>>> 
>>> Welcome to Apache Felix Gogo
>>> 
>>> g! lb
>>> START LEVEL 1
>>> ID|State  |Level|Name
>>>  0|Active |0|System Bundle (6.0.3)|6.0.3
>>>  1|Active |1|jansi (1.17.1)|1.17.1
>>>  2|Active |1|JLine Bundle (3.13.2)|3.13.2
>>>  3|Active |1|Apache Felix Bundle Repository (2.0.10)|2.0.10
>>>  4|Active |1|Apache Felix Gogo Command
>>> (1.1.1.SNAPSHOT)|1.1.1.SNAPSHOT
>>>  5|Active |1|Apache Felix Gogo Runtime
>>> (1.1.3.SNAPSHOT)|1.1.3.SNAPSHOT
>>>  6|Active |1|Apache Felix Gogo Shell
>>> (1.1.3.SNAPSHOT)|1.1.3.SNAPSHOT
>>> 
>>> thanks & regards
>>> /pierre
>> 
>> 

Re: [VOTE] Release Felix maven-bundle-plugin version 5.1.1

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 9 juil. 2020 à 18:50, Raymond Auge  a 
> écrit :
> 
> Hi,
> 
> We've updated the maven-bundle-plugin to use bnd 5.1.1.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1338/
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1338 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)

Re: [VOTE] Release Felix Health Check API 2.0.4, Felix Health Check Core 2.0.8, Felix Health Check General Checks 2.0.6, Felix Health Check Webconsole Plugin 2.0.2

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 10 juil. 2020 à 18:27, Georg Henzler  a écrit :
> 
> Hi,
> 
> We solved 8 issues in this release:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20fixVersion%20in%20(%22healthcheck.api%202.0.4%22%2C%20%22healthcheck.core%202.0.8%22%2C%20%22healthcheck.generalchecks%202.0.6%22%2C%20%22healthcheck.webconsole%202.0.2%22)
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1339/
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1339 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> -Georg

Re: [VOTE] Release Apache Felix Http Jetty 4.0.20

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 17 juil. 2020 à 08:30, Carsten Ziegeler  a écrit :
> 
> Hi,
> we solved one issue in this release:
> https://issues.apache.org/jira/browse/FELIX-6306
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1340
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1340 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix Webconsole 4.5.4

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 17 juil. 2020 à 08:31, Carsten Ziegeler  a écrit :
> 
> Hi,
> we solved two issues in this release:
> https://issues.apache.org/jira/projects/FELIX/versions/12348561
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1342
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1342 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix Configadmin 1.9.18

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 17 juil. 2020 à 08:31, Carsten Ziegeler  a écrit :
> 
> Hi,
> we solved three issues in this release:
> https://issues.apache.org/jira/projects/FELIX/versions/12345955
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1341
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1341 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[VOTE] Apache Felix FileInstall 3.6.8 release

[Jean-Baptiste Onofre]

Hi everyone,

We fixed an important issue in Felix FileInstall introduced in 3.6.6 release: 
the configuration are bound to a bundle preventing "global" visibility, 
impacting lot of user bundles (SCR, etc).

Felix FileInstall 3.6.8 fixes that.

Please, take a look on Release Notes for details.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348457
 


Staging Repository:
https://repository.apache.org/content/repositories/orgapachefelix-1343/ 


Staging Dist:
https://dist.apache.org/repos/dist/dev/felix/fileinstall/3.6.8/ 


Git Tag:
org.apache.felix.fileinstall-3.6.8

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB

Re: bar support in felix fileinstall?

[Jean-Baptiste Onofre]

Hi Scott,

I’m currently working on FileInstall but I don’t see any change related to bar 
support. AFAIR, I saw a Jira about that. I think it’s worth to plan this for 
FileInstall 3.7.0.

Regards
JB

> Le 18 juil. 2020 à 22:21, Scott Lewis  a écrit :
> 
> Apologies for being out of date, but some months ago there was a proposal 
> (from Neil Bartlett I think) to add bundle archive (bar) support to Apache 
> Felix fileinstall.  Did that ever make it into fileinstall?
> 
> If so, is there some usage documentation available for it?
> 
> Thanks,
> 
> Scott
> 

Re: [VOTE] Apache Felix FileInstall 3.6.8 release

[Jean-Baptiste Onofre]

+1 (binding)

Gentle reminder for the PMC members ;) Thanks !

Regards
JB

> Le 18 juil. 2020 à 08:25, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> We fixed an important issue in Felix FileInstall introduced in 3.6.6 release: 
> the configuration are bound to a bundle preventing "global" visibility, 
> impacting lot of user bundles (SCR, etc).
> 
> Felix FileInstall 3.6.8 fixes that.
> 
> Please, take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348457
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348457>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1343/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1343/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/fileinstall/3.6.8/ 
> <https://dist.apache.org/repos/dist/dev/felix/fileinstall/3.6.8/>
> 
> Git Tag:
> org.apache.felix.fileinstall-3.6.8
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB

Re: [VOTE] Release Apache Felix Configurator 1.0.12

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 20 juil. 2020 à 16:12, Carsten Ziegeler  a écrit :
> 
> Hi,
> we solved two issues in this 
> release:https://issues.apache.org/jira/browse/FELIX-6256?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20configurator-1.0.12
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1344
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1344 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[RESULT][VOTE] Apache Felix FileInstall 3.6.8 release

[Jean-Baptiste Onofre]

Hi everyone,

This vote passed with the following result:

+1 (binding): Ray Auge, JB Onofré, Carsten Ziegeler
+1 (non binding): Grzegorz Grzybek

I’m promoting the artifacts on Maven Central and dist, and I will update jira.

Thanks all for your vote.

Regards
JB

> Le 18 juil. 2020 à 08:25, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> We fixed an important issue in Felix FileInstall introduced in 3.6.6 release: 
> the configuration are bound to a bundle preventing "global" visibility, 
> impacting lot of user bundles (SCR, etc).
> 
> Felix FileInstall 3.6.8 fixes that.
> 
> Please, take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348457
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348457>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1343/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1343/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/fileinstall/3.6.8/ 
> <https://dist.apache.org/repos/dist/dev/felix/fileinstall/3.6.8/>
> 
> Git Tag:
> org.apache.felix.fileinstall-3.6.8
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB

Re: SCR Release

[Jean-Baptiste Onofre]

Hi Amit,

Let me take a look on Jira and I can cut a SCR release.

Regards
JB

> Le 17 août 2020 à 09:32, Amit Mondal  a écrit :
> 
> Hi,
> 
> Since there are some important fixes got merged recently, could anyone of the 
> Felix core developers build a release of the SCR bundle?
> 
> I am looking forward to your further assistance.
> 
> Thanks and Regards,
> Amit

Re: SCR Release

[Jean-Baptiste Onofre]

Any specific issues you want to include in next release ?

Regards
JB

> Le 17 août 2020 à 09:56, Amit Mondal  a écrit :
> 
> Thanks a lot JB for looking into it.
> 
> Best Regards,
> Amit
> ____
> Von: Jean-Baptiste Onofre 
> Gesendet: Montag, 17. August 2020 09:43 Uhr
> An: dev@felix.apache.org 
> Cc: Peter Kriens 
> Betreff: Re: SCR Release
> 
> Hi Amit,
> 
> Let me take a look on Jira and I can cut a SCR release.
> 
> Regards
> JB
> 
>> Le 17 août 2020 à 09:32, Amit Mondal  a écrit :
>> 
>> Hi,
>> 
>> Since there are some important fixes got merged recently, could anyone of 
>> the Felix core developers build a release of the SCR bundle?
>> 
>> I am looking forward to your further assistance.
>> 
>> Thanks and Regards,
>> Amit
> 

Re: SCR Release

[Jean-Baptiste Onofre]

Catcha, thanks !

I’m checking Jira content to see if I can include other issues.

Regards
JB

> Le 17 août 2020 à 10:15, Amit Mondal  a écrit :
> 
> Hi JB,
> 
> I am primarily looking forward to the following changes:
> 
> 
>  1.  
> https://github.com/apache/felix-dev/pull/39<https://github.com/apache/felix-dev/pull/39/files>
>  2.  
> https://github.com/apache/felix-dev/pull/38<https://github.com/apache/felix-dev/pull/38/files>
>  3.  https://github.com/apache/felix-dev/pull/36
> 
> Best Regards,
> Amit
> 
> Von: Jean-Baptiste Onofre 
> Gesendet: Montag, 17. August 2020 10:00 Uhr
> An: dev@felix.apache.org 
> Cc: Peter Kriens 
> Betreff: Re: SCR Release
> 
> Any specific issues you want to include in next release ?
> 
> Regards
> JB
> 
>> Le 17 août 2020 à 09:56, Amit Mondal  a écrit :
>> 
>> Thanks a lot JB for looking into it.
>> 
>> Best Regards,
>> Amit
>> 
>> Von: Jean-Baptiste Onofre 
>> Gesendet: Montag, 17. August 2020 09:43 Uhr
>> An: dev@felix.apache.org 
>> Cc: Peter Kriens 
>> Betreff: Re: SCR Release
>> 
>> Hi Amit,
>> 
>> Let me take a look on Jira and I can cut a SCR release.
>> 
>> Regards
>> JB
>> 
>>> Le 17 août 2020 à 09:32, Amit Mondal  a écrit :
>>> 
>>> Hi,
>>> 
>>> Since there are some important fixes got merged recently, could anyone of 
>>> the Felix core developers build a release of the SCR bundle?
>>> 
>>> I am looking forward to your further assistance.
>>> 
>>> Thanks and Regards,
>>> Amit
>> 
> 

Re: SCR Release

[Jean-Baptiste Onofre]

Hi Thomas,

Thanks for the update, I’m doing the Jira triage.

Regards
JB

> Le 17 août 2020 à 14:50, Thomas Watson  a écrit :
> 
> +1 to moving forward with a release.  I did check the latest set of issues
> last week.  One I was considering was
> https://issues.apache.org/jira/browse/FELIX-6315
> 
> I did run that change through the latest CT that will be for R8, but there
> seemed to be a failure related to the change with the existing R7 CT.  I
> haven't had enough time to investigate and it is not obvious enough to me
> that it is the correct change to do at this point.
> 
> Tom
> 
> On Mon, Aug 17, 2020 at 3:18 AM Jean-Baptiste Onofre 
> wrote:
> 
>> Catcha, thanks !
>> 
>> I’m checking Jira content to see if I can include other issues.
>> 
>> Regards
>> JB
>> 
>>> Le 17 août 2020 à 10:15, Amit Mondal  a écrit :
>>> 
>>> Hi JB,
>>> 
>>> I am primarily looking forward to the following changes:
>>> 
>>> 
>>> 1.  https://github.com/apache/felix-dev/pull/39<
>> https://github.com/apache/felix-dev/pull/39/files>
>>> 2.  https://github.com/apache/felix-dev/pull/38<
>> https://github.com/apache/felix-dev/pull/38/files>
>>> 3.  https://github.com/apache/felix-dev/pull/36
>>> 
>>> Best Regards,
>>> Amit
>>> 
>>> Von: Jean-Baptiste Onofre 
>>> Gesendet: Montag, 17. August 2020 10:00 Uhr
>>> An: dev@felix.apache.org 
>>> Cc: Peter Kriens 
>>> Betreff: Re: SCR Release
>>> 
>>> Any specific issues you want to include in next release ?
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 17 août 2020 à 09:56, Amit Mondal  a écrit :
>>>> 
>>>> Thanks a lot JB for looking into it.
>>>> 
>>>> Best Regards,
>>>> Amit
>>>> 
>>>> Von: Jean-Baptiste Onofre 
>>>> Gesendet: Montag, 17. August 2020 09:43 Uhr
>>>> An: dev@felix.apache.org 
>>>> Cc: Peter Kriens 
>>>> Betreff: Re: SCR Release
>>>> 
>>>> Hi Amit,
>>>> 
>>>> Let me take a look on Jira and I can cut a SCR release.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>>> Le 17 août 2020 à 09:32, Amit Mondal  a écrit :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Since there are some important fixes got merged recently, could anyone
>> of the Felix core developers build a release of the SCR bundle?
>>>>> 
>>>>> I am looking forward to your further assistance.
>>>>> 
>>>>> Thanks and Regards,
>>>>> Amit
>>>> 
>>> 
>> 
>> 

Re: SCR Release

[Jean-Baptiste Onofre]

Hi Thomas,

Thanks for the update, I plan to submit the release to vote during the week end 
or early next week.

So, I will follow this Jira.

Regards
JB

> Le 19 août 2020 à 21:35, Thomas Watson  a écrit :
> 
> I just discovered an issue with the logging in SCR that I need to address
> before we cut a release: https://issues.apache.org/jira/browse/FELIX-6321
> 
> I hope to have something to merge today.
> 
> Tom
> 
> On Mon, Aug 17, 2020 at 8:01 AM Jean-Baptiste Onofre 
> wrote:
> 
>> Hi Thomas,
>> 
>> Thanks for the update, I’m doing the Jira triage.
>> 
>> Regards
>> JB
>> 
>>> Le 17 août 2020 à 14:50, Thomas Watson  a écrit :
>>> 
>>> +1 to moving forward with a release.  I did check the latest set of
>> issues
>>> last week.  One I was considering was
>>> https://issues.apache.org/jira/browse/FELIX-6315
>>> 
>>> I did run that change through the latest CT that will be for R8, but
>> there
>>> seemed to be a failure related to the change with the existing R7 CT.  I
>>> haven't had enough time to investigate and it is not obvious enough to me
>>> that it is the correct change to do at this point.
>>> 
>>> Tom
>>> 
>>> On Mon, Aug 17, 2020 at 3:18 AM Jean-Baptiste Onofre 
>>> wrote:
>>> 
>>>> Catcha, thanks !
>>>> 
>>>> I’m checking Jira content to see if I can include other issues.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>>> Le 17 août 2020 à 10:15, Amit Mondal  a écrit :
>>>>> 
>>>>> Hi JB,
>>>>> 
>>>>> I am primarily looking forward to the following changes:
>>>>> 
>>>>> 
>>>>> 1.  https://github.com/apache/felix-dev/pull/39<
>>>> https://github.com/apache/felix-dev/pull/39/files>
>>>>> 2.  https://github.com/apache/felix-dev/pull/38<
>>>> https://github.com/apache/felix-dev/pull/38/files>
>>>>> 3.  https://github.com/apache/felix-dev/pull/36
>>>>> 
>>>>> Best Regards,
>>>>> Amit
>>>>> 
>>>>> Von: Jean-Baptiste Onofre 
>>>>> Gesendet: Montag, 17. August 2020 10:00 Uhr
>>>>> An: dev@felix.apache.org 
>>>>> Cc: Peter Kriens 
>>>>> Betreff: Re: SCR Release
>>>>> 
>>>>> Any specific issues you want to include in next release ?
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>>> Le 17 août 2020 à 09:56, Amit Mondal  a écrit :
>>>>>> 
>>>>>> Thanks a lot JB for looking into it.
>>>>>> 
>>>>>> Best Regards,
>>>>>> Amit
>>>>>> 
>>>>>> Von: Jean-Baptiste Onofre 
>>>>>> Gesendet: Montag, 17. August 2020 09:43 Uhr
>>>>>> An: dev@felix.apache.org 
>>>>>> Cc: Peter Kriens 
>>>>>> Betreff: Re: SCR Release
>>>>>> 
>>>>>> Hi Amit,
>>>>>> 
>>>>>> Let me take a look on Jira and I can cut a SCR release.
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>>> Le 17 août 2020 à 09:32, Amit Mondal  a écrit
>> :
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Since there are some important fixes got merged recently, could
>> anyone
>>>> of the Felix core developers build a release of the SCR bundle?
>>>>>>> 
>>>>>>> I am looking forward to your further assistance.
>>>>>>> 
>>>>>>> Thanks and Regards,
>>>>>>> Amit
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: SCR Release

[Jean-Baptiste Onofre]

Hi,

If there’s no objection, I will prepare the release tonight/tomorrow morning.
If you have specific Jira to include, please let me know.

Regards
JB

> Le 20 août 2020 à 06:43, Jean-Baptiste Onofre  a écrit :
> 
> Hi Thomas,
> 
> Thanks for the update, I plan to submit the release to vote during the week 
> end or early next week.
> 
> So, I will follow this Jira.
> 
> Regards
> JB
> 
>> Le 19 août 2020 à 21:35, Thomas Watson  a écrit :
>> 
>> I just discovered an issue with the logging in SCR that I need to address
>> before we cut a release: https://issues.apache.org/jira/browse/FELIX-6321
>> 
>> I hope to have something to merge today.
>> 
>> Tom
>> 
>> On Mon, Aug 17, 2020 at 8:01 AM Jean-Baptiste Onofre 
>> wrote:
>> 
>>> Hi Thomas,
>>> 
>>> Thanks for the update, I’m doing the Jira triage.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 17 août 2020 à 14:50, Thomas Watson  a écrit :
>>>> 
>>>> +1 to moving forward with a release.  I did check the latest set of
>>> issues
>>>> last week.  One I was considering was
>>>> https://issues.apache.org/jira/browse/FELIX-6315
>>>> 
>>>> I did run that change through the latest CT that will be for R8, but
>>> there
>>>> seemed to be a failure related to the change with the existing R7 CT.  I
>>>> haven't had enough time to investigate and it is not obvious enough to me
>>>> that it is the correct change to do at this point.
>>>> 
>>>> Tom
>>>> 
>>>> On Mon, Aug 17, 2020 at 3:18 AM Jean-Baptiste Onofre 
>>>> wrote:
>>>> 
>>>>> Catcha, thanks !
>>>>> 
>>>>> I’m checking Jira content to see if I can include other issues.
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>>> Le 17 août 2020 à 10:15, Amit Mondal  a écrit :
>>>>>> 
>>>>>> Hi JB,
>>>>>> 
>>>>>> I am primarily looking forward to the following changes:
>>>>>> 
>>>>>> 
>>>>>> 1.  https://github.com/apache/felix-dev/pull/39<
>>>>> https://github.com/apache/felix-dev/pull/39/files>
>>>>>> 2.  https://github.com/apache/felix-dev/pull/38<
>>>>> https://github.com/apache/felix-dev/pull/38/files>
>>>>>> 3.  https://github.com/apache/felix-dev/pull/36
>>>>>> 
>>>>>> Best Regards,
>>>>>> Amit
>>>>>> 
>>>>>> Von: Jean-Baptiste Onofre 
>>>>>> Gesendet: Montag, 17. August 2020 10:00 Uhr
>>>>>> An: dev@felix.apache.org 
>>>>>> Cc: Peter Kriens 
>>>>>> Betreff: Re: SCR Release
>>>>>> 
>>>>>> Any specific issues you want to include in next release ?
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>>> Le 17 août 2020 à 09:56, Amit Mondal  a écrit :
>>>>>>> 
>>>>>>> Thanks a lot JB for looking into it.
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Amit
>>>>>>> 
>>>>>>> Von: Jean-Baptiste Onofre 
>>>>>>> Gesendet: Montag, 17. August 2020 09:43 Uhr
>>>>>>> An: dev@felix.apache.org 
>>>>>>> Cc: Peter Kriens 
>>>>>>> Betreff: Re: SCR Release
>>>>>>> 
>>>>>>> Hi Amit,
>>>>>>> 
>>>>>>> Let me take a look on Jira and I can cut a SCR release.
>>>>>>> 
>>>>>>> Regards
>>>>>>> JB
>>>>>>> 
>>>>>>>> Le 17 août 2020 à 09:32, Amit Mondal  a écrit
>>> :
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Since there are some important fixes got merged recently, could
>>> anyone
>>>>> of the Felix core developers build a release of the SCR bundle?
>>>>>>>> 
>>>>>>>> I am looking forward to your further assistance.
>>>>>>>> 
>>>>>>>> Thanks and Regards,
>>>>>>>> Amit
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
> 

[VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

Hi guys,

As discussed on the mailing list, I submit Apache Felix SCR 2.1.21 release to 
your vote.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
 


Staging Repository:
https://repository.apache.org/content/repositories/orgapachefelix-1345/ 


Staging Dist:
https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ 


Git tag:
org.apache.felix.scr-2.1.21

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB

Re: [VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

Thanks for the update Carsten.

I tested successfully in Karaf but let me do a new run.

I will keep you posted asap.

Regards
JB

> Le 31 août 2020 à 09:10, Carsten Ziegeler  a écrit :
> 
> Didn't investigate further, but the SCR bundle does not resolve for us:
> 
> https://issues.apache.org/jira/browse/FELIX-6323
> 
> Regards
> Carsten
> 
> Am 30.08.2020 um 20:45 schrieb Jean-Baptiste Onofre:
>> Hi guys,
>> As discussed on the mailing list, I submit Apache Felix SCR 2.1.21 release 
>> to your vote.
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>>  
>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094>
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1345/ 
>> <https://repository.apache.org/content/repositories/orgapachefelix-1345/>
>> Staging Dist:
>> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ 
>> <https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/>
>> Git tag:
>> org.apache.felix.scr-2.1.21
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>> This vote will be open for at least 72 hours.
>> Thanks,
>> Regards
>> JB
> 
> -- 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

Just tested on Karaf (with JDK 11), SCR bundle is resolved and active:

47 x Active   x  30 x 2.1.21 x Apache Felix Declarative Services

The scr:* commands are available:

karaf@root()> scr:list
ServiceComponentRuntimeMBean in bundle 48 
(org.apache.karaf.scr.management:4.3.0.SNAPSHOT) enabled, 1 instance.
Id: 1, State:ACTIVE
ServiceComponentRuntimeBundleStateService in bundle 49 
(org.apache.karaf.scr.state:4.3.0.SNAPSHOT) enabled, 1 instance.
Id: 0, State:ACTIVE

I tested Decanter (which heavily use SCR), and it’s fine:

52 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: API
53 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: Appender 
:: Log
54 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
Marshaller :: CSV
55 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
Marshaller :: Json
56 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
Marshaller :: Raw
57 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: Parser 
:: Identity
58 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: Parser 
:: Regex
59 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: Parser 
:: Split
60 │ Active   │  80 │ 1.1.4  │ JSR 374 (JSON Processing) Default 
Provider
61 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
Collector :: OSHI

scr:list
ServiceComponentRuntimeMBean in bundle 48 
(org.apache.karaf.scr.management:4.3.0.SNAPSHOT) enabled, 1 instance.
Id: 1, State:ACTIVE
ServiceComponentRuntimeBundleStateService in bundle 49 
(org.apache.karaf.scr.state:4.3.0.SNAPSHOT) enabled, 1 instance.
Id: 0, State:ACTIVE
org.apache.karaf.decanter.appender.log in bundle 53 
(org.apache.karaf.decanter.appender.log:2.5.0) enabled, 1 instance.
Id: 7, State:ACTIVE, PID(s): [org.apache.karaf.decanter.appender.log]
org.apache.karaf.decanter.marshaller.csv in bundle 54 
(org.apache.karaf.decanter.marshaller.csv:2.5.0) enabled, 1 instance.
Id: 6, State:ACTIVE
org.apache.karaf.decanter.marshaller.json in bundle 55 
(org.apache.karaf.decanter.marshaller.json:2.5.0) enabled, 1 instance.
Id: 2, State:ACTIVE
org.apache.karaf.decanter.marshaller.json.JsonUnmarshaller in bundle 55 
(org.apache.karaf.decanter.marshaller.json:2.5.0) enabled, 1 instance.
Id: 3, State:ACTIVE
org.apache.karaf.decanter.marshaller.raw.RawMarshaller in bundle 56 
(org.apache.karaf.decanter.marshaller.raw:2.5.0) enabled, 1 instance.
Id: 4, State:ACTIVE
org.apache.karaf.decanter.marshaller.raw.RawUnmarshaller in bundle 56 
(org.apache.karaf.decanter.marshaller.raw:2.5.0) enabled, 1 instance.
Id: 5, State:ACTIVE
org.apache.karaf.decanter.parser.identity in bundle 57 
(org.apache.karaf.decanter.parser.identity:2.5.0) enabled, 1 instance.
Id: 10, State:ACTIVE
org.apache.karaf.decanter.parser.regex in bundle 58 
(org.apache.karaf.decanter.parser.regex:2.5.0) enabled, 1 instance.
Id: 9, State:ACTIVE, PID(s): [org.apache.karaf.decanter.parser.regex]
org.apache.karaf.decanter.parser.split in bundle 59 
(org.apache.karaf.decanter.parser.split:2.5.0) enabled, 1 instance.
Id: 8, State:ACTIVE, PID(s): [org.apache.karaf.decanter.parser.split]
org.apache.karaf.decanter.collector.oshi in bundle 61 
(org.apache.karaf.decanter.collector.oshi:2.5.0) enabled, 1 instance.
Id: 11, State:ACTIVE, PID(s): [org.apache.karaf.decanter.collector.oshi]

I also tested with JDK8, and it’s good as well.

Let me take a look in the stack trace you attached in the Jira.

Regards
JB

> Le 31 août 2020 à 09:10, Carsten Ziegeler  a écrit :
> 
> Didn't investigate further, but the SCR bundle does not resolve for us:
> 
> https://issues.apache.org/jira/browse/FELIX-6323
> 
> Regards
> Carsten
> 
> Am 30.08.2020 um 20:45 schrieb Jean-Baptiste Onofre:
>> Hi guys,
>> As discussed on the mailing list, I submit Apache Felix SCR 2.1.21 release 
>> to your vote.
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>>  
>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094>
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1345/ 
>> <https://repository.apache.org/content/repositories/orgapachefelix-1345/>
>> Staging Dist:
>> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ 
>> <https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/>
>> Git tag:
>> org.apache.felix.scr-2.1.21
>> Please vote to approve this release:
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>> This vote will be open for at least 72 hours.
>> Thanks,
>> Regards
>> JB
> 
> -- 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

Hi,

Yes, it’s what I found as well.

I think we can keep the SCR release running. We would need a new Felix Log 
release including the fix.

Regards
JB

> Le 31 août 2020 à 10:00, Karl Pauls  a écrit :
> 
> This seems to be a problem with the log service. In 1.2.2 (IIRC,
> latest release) we have:
> 
> https://github.com/apache/felix-dev/blob/org.apache.felix.log-1.2.2/src/main/java/org/apache/felix/log/LogServiceImpl.java#L151
> 
> which is missing a case that gets triggered here - namely, Bundle.STARTING.
> 
> Looks like Ray removed that code as part of FELIX-6281 but there
> hasn't been any release. @Raymond Auge, did you remove this check
> because of this problem?
> 
> regards,
> 
> Karl
> 
> On Mon, Aug 31, 2020 at 9:54 AM Jean-Baptiste Onofre  
> wrote:
>> 
>> Just tested on Karaf (with JDK 11), SCR bundle is resolved and active:
>> 
>> 47 x Active   x  30 x 2.1.21 x Apache Felix Declarative Services
>> 
>> The scr:* commands are available:
>> 
>> karaf@root()> scr:list
>> ServiceComponentRuntimeMBean in bundle 48 
>> (org.apache.karaf.scr.management:4.3.0.SNAPSHOT) enabled, 1 instance.
>>Id: 1, State:ACTIVE
>> ServiceComponentRuntimeBundleStateService in bundle 49 
>> (org.apache.karaf.scr.state:4.3.0.SNAPSHOT) enabled, 1 instance.
>>Id: 0, State:ACTIVE
>> 
>> I tested Decanter (which heavily use SCR), and it’s fine:
>> 
>> 52 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: API
>> 53 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Appender :: Log
>> 54 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Marshaller :: CSV
>> 55 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Marshaller :: Json
>> 56 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Marshaller :: Raw
>> 57 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Parser :: Identity
>> 58 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Parser :: Regex
>> 59 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Parser :: Split
>> 60 │ Active   │  80 │ 1.1.4  │ JSR 374 (JSON Processing) Default 
>> Provider
>> 61 │ Active   │  80 │ 2.5.0  │ Apache Karaf :: Decanter :: 
>> Collector :: OSHI
>> 
>> scr:list
>> ServiceComponentRuntimeMBean in bundle 48 
>> (org.apache.karaf.scr.management:4.3.0.SNAPSHOT) enabled, 1 instance.
>>Id: 1, State:ACTIVE
>> ServiceComponentRuntimeBundleStateService in bundle 49 
>> (org.apache.karaf.scr.state:4.3.0.SNAPSHOT) enabled, 1 instance.
>>Id: 0, State:ACTIVE
>> org.apache.karaf.decanter.appender.log in bundle 53 
>> (org.apache.karaf.decanter.appender.log:2.5.0) enabled, 1 instance.
>>Id: 7, State:ACTIVE, PID(s): [org.apache.karaf.decanter.appender.log]
>> org.apache.karaf.decanter.marshaller.csv in bundle 54 
>> (org.apache.karaf.decanter.marshaller.csv:2.5.0) enabled, 1 instance.
>>Id: 6, State:ACTIVE
>> org.apache.karaf.decanter.marshaller.json in bundle 55 
>> (org.apache.karaf.decanter.marshaller.json:2.5.0) enabled, 1 instance.
>>Id: 2, State:ACTIVE
>> org.apache.karaf.decanter.marshaller.json.JsonUnmarshaller in bundle 55 
>> (org.apache.karaf.decanter.marshaller.json:2.5.0) enabled, 1 instance.
>>Id: 3, State:ACTIVE
>> org.apache.karaf.decanter.marshaller.raw.RawMarshaller in bundle 56 
>> (org.apache.karaf.decanter.marshaller.raw:2.5.0) enabled, 1 instance.
>>Id: 4, State:ACTIVE
>> org.apache.karaf.decanter.marshaller.raw.RawUnmarshaller in bundle 56 
>> (org.apache.karaf.decanter.marshaller.raw:2.5.0) enabled, 1 instance.
>>Id: 5, State:ACTIVE
>> org.apache.karaf.decanter.parser.identity in bundle 57 
>> (org.apache.karaf.decanter.parser.identity:2.5.0) enabled, 1 instance.
>>Id: 10, State:ACTIVE
>> org.apache.karaf.decanter.parser.regex in bundle 58 
>> (org.apache.karaf.decanter.parser.regex:2.5.0) enabled, 1 instance.
>>Id: 9, State:ACTIVE, PID(s): [org.apache.karaf.decanter.parser.regex]
>> org.apache.karaf.decanter.parser.split in bundle 59 
>> (org.apache.karaf.decanter.parser.split:2.5.0) enabled, 1 instance.
>>Id: 8, State:ACTIVE, PID(s): [org.apache.karaf.decanter.parser.split]
>> org.apache.karaf.decanter.collector.oshi in bundle 61 
>> (org.apache.karaf.decanter.collector.oshi:2.5.0) enabled, 1 instance.
>>Id: 11, State:ACTIVE, PID(s): [org.apache.karaf.decanter.collector.oshi]
>> 
>> I also tested with JDK

Re: [VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

+1 (binding)

Casting my own vote.

Regards
JB

> Le 30 août 2020 à 20:45, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> As discussed on the mailing list, I submit Apache Felix SCR 2.1.21 release to 
> your vote.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1345/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1345/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ 
> <https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/>
> 
> Git tag:
> org.apache.felix.scr-2.1.21
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB

Re: release Felix log 1.2.4

[Jean-Baptiste Onofre]

Hi Ray,

Up to know, I can cut Felix Log release if you want.

Let me know.

Regards
JB

> Le 31 août 2020 à 15:16, Raymond Auge  a 
> écrit :
> 
> Hello All,
> 
> Given the fact that the in-flight vote of SCR appears to need a new Felix
> log, we should release it.
> 
> Shall I proceed with the release or is someone already taking care of it?
> 
> - Ray

Re: release Felix log 1.2.4

[Jean-Baptiste Onofre]

No problem, let me prepare the release then ;)

The vote thread will start shortly.

Thanks
Regards
JB

> Le 31 août 2020 à 15:21, Raymond Auge  a 
> écrit :
> 
> Hey JB,
> 
> It's up to you but I can leave it in your hands.
> 
> Sincere thanks,
> - Ray
> 
> On Mon, Aug 31, 2020 at 9:17 AM Jean-Baptiste Onofre 
> wrote:
> 
>> Hi Ray,
>> 
>> Up to know, I can cut Felix Log release if you want.
>> 
>> Let me know.
>> 
>> Regards
>> JB
>> 
>>> Le 31 août 2020 à 15:16, Raymond Auge 
>> a écrit :
>>> 
>>> Hello All,
>>> 
>>> Given the fact that the in-flight vote of SCR appears to need a new Felix
>>> log, we should release it.
>>> 
>>> Shall I proceed with the release or is someone already taking care of it?
>>> 
>>> - Ray
>> 
>> 
> 
> -- 
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)

Re: [VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

No, 2.1.21, I saw that SCR unitary increment, so, I follow the same for this 
release.

> Le 31 août 2020 à 16:09, Thomas Watson  a écrit :
> 
> One clarification question, the actual release of SCR will be an even
> release (2.1.22), correct?  I believe the Felix project uses even numbered
> releases and odd numbered snapshots IIRC.
> 
> Tom
> 
> On Sun, Aug 30, 2020 at 1:45 PM Jean-Baptiste Onofre 
> wrote:
> 
>> Hi guys,
>> 
>> As discussed on the mailing list, I submit Apache Felix SCR 2.1.21 release
>> to your vote.
>> 
>> Release Notes:
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>> <
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>>> 
>> 
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1345/ <
>> https://repository.apache.org/content/repositories/orgapachefelix-1345/>
>> 
>> Staging Dist:
>> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ <
>> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/>
>> 
>> Git tag:
>> org.apache.felix.scr-2.1.21
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>> 
>> This vote will be open for at least 72 hours.
>> 
>> Thanks,
>> Regards
>> JB

[VOTE] Apache Felix Log 1.2.4 release

[Jean-Baptiste Onofre]

Hi everyone,

Following the discussion on the mailing list, I submit Apache Felix Log 1.2.4 
to your vote.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348344
 


Staging Repository:
https://repository.apache.org/content/repositories/orgapachefelix-1346/ 


Staging Dist:
https://dist.apache.org/repos/dist/dev/felix/log/1.2.4/ 


Git tag:
org.apache.felix.log-1.2.4

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB

Re: [VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

Oh my bad, I didn’t double check.

Let me cancel this vote to cut 2.1.22.

Sorry about that.

Regards
JB

> Le 31 août 2020 à 16:51, Thomas Watson  a écrit :
> 
> I only see even releases out in maven:
> https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr
> 
> Tom
> 
> 
> On Mon, Aug 31, 2020 at 9:27 AM Jean-Baptiste Onofre 
> wrote:
> 
>> No, 2.1.21, I saw that SCR unitary increment, so, I follow the same for
>> this release.
>> 
>>> Le 31 août 2020 à 16:09, Thomas Watson  a écrit :
>>> 
>>> One clarification question, the actual release of SCR will be an even
>>> release (2.1.22), correct?  I believe the Felix project uses even
>> numbered
>>> releases and odd numbered snapshots IIRC.
>>> 
>>> Tom
>>> 
>>> On Sun, Aug 30, 2020 at 1:45 PM Jean-Baptiste Onofre 
>>> wrote:
>>> 
>>>> Hi guys,
>>>> 
>>>> As discussed on the mailing list, I submit Apache Felix SCR 2.1.21
>> release
>>>> to your vote.
>>>> 
>>>> Release Notes:
>>>> 
>>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>>>> <
>>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>>>>> 
>>>> 
>>>> Staging Repository:
>>>> https://repository.apache.org/content/repositories/orgapachefelix-1345/
>> <
>>>> https://repository.apache.org/content/repositories/orgapachefelix-1345/
>>> 
>>>> 
>>>> Staging Dist:
>>>> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ <
>>>> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/>
>>>> 
>>>> Git tag:
>>>> org.apache.felix.scr-2.1.21
>>>> 
>>>> Please vote to approve this release:
>>>> 
>>>> [ ] +1 Approve the release
>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>> 
>>>> This vote will be open for at least 72 hours.
>>>> 
>>>> Thanks,
>>>> Regards
>>>> JB
>> 
>> 

[CANCEL][VOTE] Apache Felix SCR 2.1.21 release

[Jean-Baptiste Onofre]

Due to a mistake in the version (Jira versioning confused me), I cancel this 
vote to cut a new release with the correct version.

Sorry about that.

Regards
JB

> Le 30 août 2020 à 20:45, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> As discussed on the mailing list, I submit Apache Felix SCR 2.1.21 release to 
> your vote.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1345/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1345/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ 
> <https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/>
> 
> Git tag:
> org.apache.felix.scr-2.1.21
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB

[VOTE] Apache Felix SCR 2.1.22 release

[Jean-Baptiste Onofre]

Hi guys,

As discussed on the mailing list, I submit Apache Felix SCR 2.1.22 release to 
your vote (after the mistake in 2.1.21 versioning).

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
 


Staging Repository:
https://repository.apache.org/content/repositories/orgapachefelix-1347/ 


Staging Dist:
https://dist.apache.org/repos/dist/dev/felix/scr/2.1.22/ 


Git tag:
org.apache.felix.scr-2.1.22

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB

Re: [VOTE] Apache Felix Log 1.2.4 release

[Jean-Baptiste Onofre]

+1 (binding)

Casting my own vote.

Regards
JB

> Le 31 août 2020 à 16:42, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> Following the discussion on the mailing list, I submit Apache Felix Log 1.2.4 
> to your vote.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348344
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348344>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1346/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1346/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/log/1.2.4/ 
> <https://dist.apache.org/repos/dist/dev/felix/log/1.2.4/>
> 
> Git tag:
> org.apache.felix.log-1.2.4
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB

Re: [VOTE] Apache Felix SCR 2.1.22 release

[Jean-Baptiste Onofre]

+1 (binding)

Casting my own vote.

Regards
JB

> Le 31 août 2020 à 18:21, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> As discussed on the mailing list, I submit Apache Felix SCR 2.1.22 release to 
> your vote (after the mistake in 2.1.21 versioning).
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1347/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1347/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.22/ 
> <https://dist.apache.org/repos/dist/dev/felix/scr/2.1.22/>
> 
> Git tag:
> org.apache.felix.scr-2.1.22
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

Board report this month

[Jean-Baptiste Onofre]

Hi guys,

We have to send the board report this month.

@Karl do you have time to tackle this (helped by reporter.apache.org 
) ? If you are busy, I can help. Please let me 
know.

Thanks,
Regards
JB

[RESULT][VOTE] Apache Felix Log 1.2.4 release

[Jean-Baptiste Onofre]

Hi guys,

This vote passed with the following result:

+1 (binding): Ray Augé, David Bosschaert, Carsten Ziegeler, Karl Pauls, Tom 
Watson, JB Onofré, Pierre De Rop

I’m promoting the artifacts on Maven Central and dist.a.o, and update Jira.

Thanks all for your vote !

Regards
JB

> Le 31 août 2020 à 16:42, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> Following the discussion on the mailing list, I submit Apache Felix Log 1.2.4 
> to your vote.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348344
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348344>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1346/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1346/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/log/1.2.4/ 
> <https://dist.apache.org/repos/dist/dev/felix/log/1.2.4/>
> 
> Git tag:
> org.apache.felix.log-1.2.4
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB

[RESULT][VOTE] Apache Felix SCR 2.1.22 release

[Jean-Baptiste Onofre]

Hi guys,

This vote passed with the following result:

+1 (binding): Carsten Ziegeler, Ray Augé, Tom Watson, JB Onofré, Pierre De Rop

I’m promoting the artifacts on Maven Central and dist.a.o, and update Jira.

Thanks all for your vote !

Regards
JB

> Le 31 août 2020 à 18:21, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> As discussed on the mailing list, I submit Apache Felix SCR 2.1.22 release to 
> your vote (after the mistake in 2.1.21 versioning).
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1347/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1347/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.22/ 
> <https://dist.apache.org/repos/dist/dev/felix/scr/2.1.22/>
> 
> Git tag:
> org.apache.felix.scr-2.1.22
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

Re: Application metrics bundles contribution (was: [RESUL][VOTE] Accept the application metrics bundles contribution)

[Jean-Baptiste Onofre]

Hi Robert,

Thanks for the update.

I saw the PR, I will take a look.

Thanks again,
Regards
JB

> Le 3 sept. 2020 à 16:51, Robert Munteanu  a écrit :
> 
> Hi,
> 
> On Fri, 2020-07-03 at 13:01 +0200, Karl Pauls wrote:
>> The vote is successful. I will follow-up with Robert to get it in.
> 
> It's been two months ( give or take a couple of hours ) so it may be
> time to actually finish contributing the code.
> 
>  https://github.com/apache/felix-dev/tree/master/metrics/osgi
> 
> Compared to the initial proposal I moved the modules under the
> org.apache.felix namespace.
> 
> Thanks,
> Robert
> 

Potential issue in Felix SCR 2.1.22

[Jean-Baptiste Onofre]

Hi guys,

I tested (during the vote) Felix SCR 2.1.22 without problem in Karaf 
4.3.0-SNAPSHOT (using Pax Logging 2.x).

This morning I tested SCR 2.1.22 on Karaf 4.2.10-SNAPSHOT (with Pax Logging 
1.x), and I have the issue: the activator doesn’t start at all:

org.osgi.framework.BundleException: Activator start error in bundle 
org.apache.felix.scr [48].
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
at 
org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1153)
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1036)
... 6 more
Caused by: java.lang.NoClassDefFoundError: 
org/osgi/service/log/LoggerFactory
at 
org.apache.felix.scr.impl.logger.LogManager.(LogManager.java:59)
at 
org.apache.felix.scr.impl.logger.ScrLogManager.(ScrLogManager.java:62)
at 
org.apache.felix.scr.impl.logger.ScrLogManager.scr(ScrLogManager.java:58)
at org.apache.felix.scr.impl.Activator.start(Activator.java:119)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
... 12 more
Caused by: java.lang.ClassNotFoundException: 
org.osgi.service.log.LoggerFactory not found by org.apache.felix.scr [48]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 18 more

So, it seems that org.osgi.service.log.LoggerFactory is now a strong 
requirement, whereas the org.osgi.service.log package is optional in 
Import-Package:

org.osgi.service.log;resolution:=optional;version="[1.4,2)"

This import is not satisfied in Karaf 4.2.x as Pax Logging exports 1.3.0 
version.

This requirement has been introduced by this commit:

commit 18d37af0cc3b6a1392dc2053ae97a5577adfa0e5
Author: Peter Kriens 
Date:   Thu Jul 23 16:39:40 2020 +0200

[scr] Logging Extension


So basically, I have several questions:

1. If org.osgi.service.log package is required, we should not flag as optional 
in Import-Package right ?
2. It sounds like a non backward compatible change to me, so, maybe it would 
have been better to bump version to 2.2.0 instead of 2.1.22. Thoughts ?
3. Do you think it’s a problem to extend the range to [1.3,2) ?

Anyway, I gonna take a deeper look to see if I can find a fix for Karaf 4.2.x 
(testing extending the range and/or upgrading Pax Logging).

Regards
JB

Re: Potential issue in Felix SCR 2.1.22

[Jean-Baptiste Onofre]

By the way, checking if ds.log.extension=false helps.

I will keep you posted.

Regards
JB

> Le 4 sept. 2020 à 11:04, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> I tested (during the vote) Felix SCR 2.1.22 without problem in Karaf 
> 4.3.0-SNAPSHOT (using Pax Logging 2.x).
> 
> This morning I tested SCR 2.1.22 on Karaf 4.2.10-SNAPSHOT (with Pax Logging 
> 1.x), and I have the issue: the activator doesn’t start at all:
> 
> org.osgi.framework.BundleException: Activator start error in bundle 
> org.apache.felix.scr [48].
>at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
>at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
>at 
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
>at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1153)
>at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1036)
>... 6 more
>Caused by: java.lang.NoClassDefFoundError: 
> org/osgi/service/log/LoggerFactory
>at 
> org.apache.felix.scr.impl.logger.LogManager.(LogManager.java:59)
>at 
> org.apache.felix.scr.impl.logger.ScrLogManager.(ScrLogManager.java:62)
>at 
> org.apache.felix.scr.impl.logger.ScrLogManager.scr(ScrLogManager.java:58)
>at 
> org.apache.felix.scr.impl.Activator.start(Activator.java:119)
>at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>... 12 more
>Caused by: java.lang.ClassNotFoundException: 
> org.osgi.service.log.LoggerFactory not found by org.apache.felix.scr [48]
>at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
>at 
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>at 
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>... 18 more
> 
> So, it seems that org.osgi.service.log.LoggerFactory is now a strong 
> requirement, whereas the org.osgi.service.log package is optional in 
> Import-Package:
> 
> org.osgi.service.log;resolution:=optional;version="[1.4,2)"
> 
> This import is not satisfied in Karaf 4.2.x as Pax Logging exports 1.3.0 
> version.
> 
> This requirement has been introduced by this commit:
> 
> commit 18d37af0cc3b6a1392dc2053ae97a5577adfa0e5
> Author: Peter Kriens 
> Date:   Thu Jul 23 16:39:40 2020 +0200
> 
>[scr] Logging Extension
> 
> 
> So basically, I have several questions:
> 
> 1. If org.osgi.service.log package is required, we should not flag as 
> optional in Import-Package right ?
> 2. It sounds like a non backward compatible change to me, so, maybe it would 
> have been better to bump version to 2.2.0 instead of 2.1.22. Thoughts ?
> 3. Do you think it’s a problem to extend the range to [1.3,2) ?
> 
> Anyway, I gonna take a deeper look to see if I can find a fix for Karaf 4.2.x 
> (testing extending the range and/or upgrading Pax Logging).
> 
> Regards
> JB

Re: Potential issue in Felix SCR 2.1.22

[Jean-Baptiste Onofre]

By the way, the SCR README.md doesn’t include the ds.log.extension property 
documentation. I will fix that.

Regards
JB

> Le 4 sept. 2020 à 13:47, Jean-Baptiste Onofre  a écrit :
> 
> By the way, checking if ds.log.extension=false helps.
> 
> I will keep you posted.
> 
> Regards
> JB
> 
>> Le 4 sept. 2020 à 11:04, Jean-Baptiste Onofre  a écrit :
>> 
>> Hi guys,
>> 
>> I tested (during the vote) Felix SCR 2.1.22 without problem in Karaf 
>> 4.3.0-SNAPSHOT (using Pax Logging 2.x).
>> 
>> This morning I tested SCR 2.1.22 on Karaf 4.2.10-SNAPSHOT (with Pax Logging 
>> 1.x), and I have the issue: the activator doesn’t start at all:
>> 
>> org.osgi.framework.BundleException: Activator start error in bundle 
>> org.apache.felix.scr [48].
>>   at 
>> org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
>>   at 
>> org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>>   at 
>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>>   at 
>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
>>   at 
>> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
>>   at 
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1153)
>>   at 
>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1036)
>>   ... 6 more
>>   Caused by: java.lang.NoClassDefFoundError: 
>> org/osgi/service/log/LoggerFactory
>>   at 
>> org.apache.felix.scr.impl.logger.LogManager.(LogManager.java:59)
>>   at 
>> org.apache.felix.scr.impl.logger.ScrLogManager.(ScrLogManager.java:62)
>>   at 
>> org.apache.felix.scr.impl.logger.ScrLogManager.scr(ScrLogManager.java:58)
>>   at 
>> org.apache.felix.scr.impl.Activator.start(Activator.java:119)
>>   at 
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>>   at 
>> org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>>   ... 12 more
>>   Caused by: java.lang.ClassNotFoundException: 
>> org.osgi.service.log.LoggerFactory not found by org.apache.felix.scr [48]
>>   at 
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
>>   at 
>> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>>   at 
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>>   at 
>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>   ... 18 more
>> 
>> So, it seems that org.osgi.service.log.LoggerFactory is now a strong 
>> requirement, whereas the org.osgi.service.log package is optional in 
>> Import-Package:
>> 
>> org.osgi.service.log;resolution:=optional;version="[1.4,2)"
>> 
>> This import is not satisfied in Karaf 4.2.x as Pax Logging exports 1.3.0 
>> version.
>> 
>> This requirement has been introduced by this commit:
>> 
>> commit 18d37af0cc3b6a1392dc2053ae97a5577adfa0e5
>> Author: Peter Kriens 
>> Date:   Thu Jul 23 16:39:40 2020 +0200
>> 
>>   [scr] Logging Extension
>> 
>> 
>> So basically, I have several questions:
>> 
>> 1. If org.osgi.service.log package is required, we should not flag as 
>> optional in Import-Package right ?
>> 2. It sounds like a non backward compatible change to me, so, maybe it would 
>> have been better to bump version to 2.2.0 instead of 2.1.22. Thoughts ?
>> 3. Do you think it’s a problem to extend the range to [1.3,2) ?
>> 
>> Anyway, I gonna take a deeper look to see if I can find a fix for Karaf 
>> 4.2.x (testing extending the range and/or upgrading Pax Logging).
>> 
>> Regards
>> JB
> 

Re: Potential issue in Felix SCR 2.1.22

[Jean-Baptiste Onofre]

Yes, ds.log configuration doesn’t help :/

About the versioning, my point is more that with log package version change, we 
are more R7 only and not compliant with R6 anymore.
That’s not a big deal but a bit "surprising", especially the fact that log 
package is not really optional anymore.

I’m also taking on look on SCR to find a potential solution.

Regards
JB

> Le 4 sept. 2020 à 15:18, Thomas Watson  a écrit :
> 
> As the code is today the import for log has to be mandatory.  I'll take a
> quick look to see if we can make this optional again, but I suspect it will
> be a bit of work.  I'll let you know the feasibility today.
> I'm fine with bumping the version to 2.2.0 if we think that is required
> when we update the minor version for an import range.
> 
> Tom
> 
> On Fri, Sep 4, 2020 at 4:05 AM Jean-Baptiste Onofre  wrote:
> 
>> Hi guys,
>> 
>> I tested (during the vote) Felix SCR 2.1.22 without problem in Karaf
>> 4.3.0-SNAPSHOT (using Pax Logging 2.x).
>> 
>> This morning I tested SCR 2.1.22 on Karaf 4.2.10-SNAPSHOT (with Pax
>> Logging 1.x), and I have the issue: the activator doesn’t start at all:
>> 
>> org.osgi.framework.BundleException: Activator start error in bundle
>> org.apache.felix.scr [48].
>>at
>> org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
>>at
>> org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>>at
>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>>at
>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
>>at
>> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
>>at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1153)
>>at
>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1036)
>>... 6 more
>>Caused by: java.lang.NoClassDefFoundError:
>> org/osgi/service/log/LoggerFactory
>>at
>> org.apache.felix.scr.impl.logger.LogManager.(LogManager.java:59)
>>at
>> org.apache.felix.scr.impl.logger.ScrLogManager.(ScrLogManager.java:62)
>>at
>> org.apache.felix.scr.impl.logger.ScrLogManager.scr(ScrLogManager.java:58)
>>at
>> org.apache.felix.scr.impl.Activator.start(Activator.java:119)
>>at
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>>at
>> org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>>... 12 more
>>Caused by: java.lang.ClassNotFoundException:
>> org.osgi.service.log.LoggerFactory not found by org.apache.felix.scr [48]
>>at
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
>>at
>> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>>at
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>>at
>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>... 18 more
>> 
>> So, it seems that org.osgi.service.log.LoggerFactory is now a strong
>> requirement, whereas the org.osgi.service.log package is optional in
>> Import-Package:
>> 
>> org.osgi.service.log;resolution:=optional;version="[1.4,2)"
>> 
>> This import is not satisfied in Karaf 4.2.x as Pax Logging exports 1.3.0
>> version.
>> 
>> This requirement has been introduced by this commit:
>> 
>> commit 18d37af0cc3b6a1392dc2053ae97a5577adfa0e5
>> Author: Peter Kriens 
>> Date:   Thu Jul 23 16:39:40 2020 +0200
>> 
>>[scr] Logging Extension
>> 
>> 
>> So basically, I have several questions:
>> 
>> 1. If org.osgi.service.log package is required, we should not flag as
>> optional in Import-Package right ?
>> 2. It sounds like a non backward compatible change to me, so, maybe it
>> would have been better to bump version to 2.2.0 instead of 2.1.22. Thoughts
>> ?
>> 3. Do you think it’s a problem to extend the range to [1.3,2) ?
>> 
>> Anyway, I gonna take a deeper look to see if I can find a fix for Karaf
>> 4.2.x (testing extending the range and/or upgrading Pax Logging).
>> 
>> Regards
>> JB

Re: Potential issue in Felix SCR 2.1.22

[Jean-Baptiste Onofre]

I would have expected Felix SCR 2.2.0 R7 compliant and SCR 2.1.x R6 compliant ;)

Just my $0.01 ;)

Regards
JB

> Le 4 sept. 2020 à 16:03, Thomas Watson  a écrit :
> 
> Continuing to support the R6 LogService made the logging in SCR way more
> complicated, but yes I agree the impl now requires an R7 log service impl
> and that could be surprising.
> 
> Tom
> 
> On Fri, Sep 4, 2020 at 8:40 AM Jean-Baptiste Onofre  wrote:
> 
>> Yes, ds.log configuration doesn’t help :/
>> 
>> About the versioning, my point is more that with log package version
>> change, we are more R7 only and not compliant with R6 anymore.
>> That’s not a big deal but a bit "surprising", especially the fact that log
>> package is not really optional anymore.
>> 
>> I’m also taking on look on SCR to find a potential solution.
>> 
>> Regards
>> JB
>> 
>>> Le 4 sept. 2020 à 15:18, Thomas Watson  a écrit :
>>> 
>>> As the code is today the import for log has to be mandatory.  I'll take a
>>> quick look to see if we can make this optional again, but I suspect it
>> will
>>> be a bit of work.  I'll let you know the feasibility today.
>>> I'm fine with bumping the version to 2.2.0 if we think that is required
>>> when we update the minor version for an import range.
>>> 
>>> Tom
>>> 
>>> On Fri, Sep 4, 2020 at 4:05 AM Jean-Baptiste Onofre 
>> wrote:
>>> 
>>>> Hi guys,
>>>> 
>>>> I tested (during the vote) Felix SCR 2.1.22 without problem in Karaf
>>>> 4.3.0-SNAPSHOT (using Pax Logging 2.x).
>>>> 
>>>> This morning I tested SCR 2.1.22 on Karaf 4.2.10-SNAPSHOT (with Pax
>>>> Logging 1.x), and I have the issue: the activator doesn’t start at all:
>>>> 
>>>> org.osgi.framework.BundleException: Activator start error in bundle
>>>> org.apache.felix.scr [48].
>>>>   at
>>>> org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
>>>>   at
>>>> org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
>>>>   at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
>>>>   at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
>>>>   at
>>>> 
>> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
>>>>   at
>>>> 
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1153)
>>>>   at
>>>> 
>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1036)
>>>>   ... 6 more
>>>>   Caused by: java.lang.NoClassDefFoundError:
>>>> org/osgi/service/log/LoggerFactory
>>>>   at
>>>> org.apache.felix.scr.impl.logger.LogManager.(LogManager.java:59)
>>>>   at
>>>> 
>> org.apache.felix.scr.impl.logger.ScrLogManager.(ScrLogManager.java:62)
>>>>   at
>>>> 
>> org.apache.felix.scr.impl.logger.ScrLogManager.scr(ScrLogManager.java:58)
>>>>   at
>>>> org.apache.felix.scr.impl.Activator.start(Activator.java:119)
>>>>   at
>>>> 
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
>>>>   at
>>>> org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
>>>>   ... 12 more
>>>>   Caused by: java.lang.ClassNotFoundException:
>>>> org.osgi.service.log.LoggerFactory not found by org.apache.felix.scr
>> [48]
>>>>   at
>>>> 
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
>>>>   at
>>>> 
>> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>>>>   at
>>>> 
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>>>>   at
>>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>   ... 18 more
>>>> 
>>>> So, it seems that org.osgi.service.log.LoggerFactory is now a strong
>>>> requirement, whereas the org.osgi.service.log package is optional in
&g

[VOTE] Apache Felix SCR 2.1.24 release

[Jean-Baptiste Onofre]

Hi guys,

As discussed on the mailing list, I submit Apache Felix SCR 2.1.24 release to 
your vote.
This release avoid the requirement to log service, potential 
NoSuchElementException when services are removed, and fix factory component 
eager deactivation.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348738

Staging Repository:
https://repository.apache.org/content/repositories/orgapachefelix-1348/

Staging Dist:
https://dist.apache.org/repos/dist/dev/felix/scr/2.1.24/

Git tag:
org.apache.felix.scr-2.1.24

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB

Re: [VOTE] Apache Felix SCR 2.1.24 release

[Jean-Baptiste Onofre]

+1 (binding)

Casting my own +1

Regards
JB

> Le 17 sept. 2020 à 10:58, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> As discussed on the mailing list, I submit Apache Felix SCR 2.1.24 release to 
> your vote.
> This release avoid the requirement to log service, potential 
> NoSuchElementException when services are removed, and fix factory component 
> eager deactivation.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348738
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1348/
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.24/
> 
> Git tag:
> org.apache.felix.scr-2.1.24
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

[RESULT][VOTE] Apache Felix SCR 2.1.24 release

[Jean-Baptiste Onofre]

Hi everyone,

This vote passed with the following result:

+1 (binding): Ray Augé, David Bosschaert, Carsten Ziegeler, Thomas Watson, 
Pierre De Rop, JB Onofré
+1 (non binding): Peter Kriens, François Papon, Grzegorz Grzybek

I’m promoting the artifacts to Maven Central and dist.a.o, and updating Jira.

Thanks all for your vote !

Regards
JB

> Le 17 sept. 2020 à 10:58, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> As discussed on the mailing list, I submit Apache Felix SCR 2.1.24 release to 
> your vote.
> This release avoid the requirement to log service, potential 
> NoSuchElementException when services are removed, and fix factory component 
> eager deactivation.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348738
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1348/
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/felix/scr/2.1.24/
> 
> Git tag:
> org.apache.felix.scr-2.1.24
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

Re: [VOTE] Release Apache Felix Http Base 4.1.0, Bridge 4.1.0 and Jetty 4.1.0

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 23 sept. 2020 à 09:57, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> we solved three issues for http jetty:
> https://issues.apache.org/jira/browse/FELIX-6333?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20http.jetty-4.1.0
> 
> and two issues for bridge 4.1.0 and base 4.1.0:
> https://issues.apache.org/jira/browse/FELIX-6334?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20http.base-4.1.0
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1349
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1349 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Release Apache Felix Gogo - Runtime 1.1.4, Shell 1.1.4, Command 1.1.2, BOM 1.0.4

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 5 oct. 2020 à 19:02, Thomas Watson  a écrit :
> 
> Hi,
> 
> We solved 2 issues in Gogo Runtime this
> release:https://issues.apache.org/jira/browse/FELIX-2355?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20gogo.runtime-1.1.4
> 
> 
> We solved 2 issues in Gogo Shell this release:
> 
> https://issues.apache.org/jira/browse/FELIX-2340?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20gogo.shell-1.1.4
> 
> 
> We solved 1 issue in Gogo Command this release:
> 
> https://issues.apache.org/jira/browse/FELIX-6038?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20gogo.command-1.1.2
> 
> 
> We updated the Gogo BOM to use the latest released Gogo artifacts this 
> release.
> 
> 
> Staging 
> repository:https://repository.apache.org/content/repositories/orgapachefelix-1351/
> 
> You can use this UNIX script to download the release and verify the
> signatures:https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1351 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> 
> Thanks
> 
> Tom

Re: [VOTE] Release Apache Felix Http Jetty 4.1.2, Http Bridge 4.1.2 and Http Base 4.1.2

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 5 oct. 2020 à 10:14, Carsten Ziegeler  a écrit :
> 
> Hi,
> 
> We solved 2 issues in http.jetty 4.1.2:
> 
> https://issues.apache.org/jira/browse/FELIX-6343?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20http.jetty-4.1.2
> 
> and one issue in http.base 4.1.2 and http.bridge 4.1.2
> https://issues.apache.org/jira/browse/FELIX-6342
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1350
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1350 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Felix Gogo, jline version 1.1.8 and bom version 1.0.6

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 13 oct. 2020 à 18:39, Thomas Watson  a écrit :
> 
> Hi,
> 
> As promised here is the release of jline and bom to address this issue in 
> jlink:
> https://issues.apache.org/jira/browse/FELIX-6058
> 
> 
> Staging 
> repository:https://repository.apache.org/content/repositories/orgapachefelix-1352/
> 
> You can use this UNIX script to download the release and verify the
> signatures:https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> 
> Tom

Re: [VOTE] Release Apache Felix Utils 1.11.6

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 24 nov. 2020 à 10:06, dav...@apache.org a écrit :
> 
> Hi all,
> 
> I would like to release org.apache.felix.utils-1.11.6
> 
> We solved the following issue:
> https://issues.apache.org/jira/projects/FELIX/versions/12348849
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1353
> 
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1353 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote remains open for at least 72 hours.
> 
> Best regards,
> 
> David Bosschaert

Re: [VOTE] Release Apache Felix Http Jetty 4.1.4

[Jean-Baptiste Onofre]

+1 (binding)

Thanks !

Regards
JB

> Le 25 nov. 2020 à 07:29, Carsten Ziegeler  a écrit :
> 
> Hi all,
> 
> I would like to release org.apache.felix.http.jetty.41.4
> 
> We solved one issue in this release:
> https://issues.apache.org/jira/browse/FELIX-6364
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1354
> 
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1354 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote remains open for at least 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Apache Felix Framework 6.0.4 and related subproject releases

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 12 déc. 2020 à 00:02, Karl Pauls  a écrit :
> 
> I would like to call a vote on the following subproject releases:
> 
> framework 6.0.4
> main 6.0.4
> main.distribution 6.0.4
> resolver 2.0.2
> 
> The main changelogs are in jira and at:
> https://github.com/apache/felix-dev/blob/org.apache.felix.resolver-2.0.2/resolver/doc/changelog.txt
> https://github.com/apache/felix-dev/blob/org.apache.felix.framework-6.0.4/framework/doc/changelog.txt
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1355/
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1355 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)

Re: [VOTE] Release Apache Felix Webconsole 4.6.0

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 14 déc. 2020 à 09:23, Carsten Ziegeler  a écrit :
> 
> I would like to call a vote on the webconsole 4.6.0 release
> 
> We solved five issues:
> https://github.com/apache/felix-dev/blob/org.apache.felix.webconsole-4.6.0/webconsole/changelog.txt
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1356/
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1356 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix EventAdmin 1.6.0

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 14 déc. 2020 à 14:15, Carsten Ziegeler  a écrit :
> 
> I would like to call a vote on the eventadmin 1.6.0 release
> 
> We solved three issues:
> 
> https://github.com/apache/felix-dev/blob/org.apache.felix.eventadmin-1.6.0/eventadmin/impl/changelog.txt
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1357
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1357 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix Configadmin 1.9.20

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 4 janv. 2021 à 07:21, Carsten Ziegeler  a écrit :
> 
> I would like to call a vote on the configadmin 1.9.20 release
> 
> We solved two issues:
> 
> https://github.com/apache/felix-dev/blob/org.apache.felix.configadmin-1.9.20/configadmin/changelog.txt
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1360
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1360 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix Eventadmin 1.6.2

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 6 janv. 2021 à 13:55, Carsten Ziegeler  a écrit :
> 
> I would like to call a vote on the eventadmin 1.6.2 release
> 
> We solved one issue (caused by the maven bundle plugin 5.1.1):
> 
> https://issues.apache.org/jira/browse/FELIX-6373
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1361
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1361 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Apache Felix Dependency Manager Release r16

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 20 janv. 2021 à 16:16, Pierre De Rop  a écrit :
> 
> Hello everyone;
> 
> I would like to call for a vote on the Dependency Manager top level release
> r16.
> 
> Release notes:
> 
> ** Bug
>   * [FELIX-6180] - Component initialization error message get's printed to
> sysout instead of logged to LogService
> 
> ** Improvement
>   * [FELIX-6278] - Update Dependency Manager with latest bndtools version
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> 
> https://github.com/apache/felix-dev/blob/master/dependencymanager/release/check_staged_release.sh
> 
> Usage:
> 
>  sh check_staged_release.sh r16 /tmp/felix-staging
> 
> This script, unlike the original Felix check_stage_release.sh, is specific
> to the Dependency Manager release process (see FELIX-4818) and will
> download staging from https://dist.apache.org/repos/dist/dev/felix instead
> of http://repository.apache.org/content/repositories.
> 
> To rebuild the DM binaries from the source, jdk8 must be used, and you can
> refer to:
> 
> https://github.com/apache/felix-dev/blob/master/dependencymanager/release/resources/src/README.src
> 
> Please cast your votes to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> thanks & regards;
> /Pierre

Re: [VOTE] Release Apache Felix cm.json 1.0.4

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 26 janv. 2021 à 12:18, Carsten Ziegeler  a écrit :
> 
> 
> I would like to call a vote on the cm.json 1.0.4 release
> 
> We solved one issue:
> 
> https://issues.apache.org/jira/browse/FELIX-6380
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1367
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1367 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix cm.json 1.0.6

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 31 janv. 2021 à 13:17, Carsten Ziegeler  a écrit :
> 
> I would like to call a vote on the cm.json 1.0.6 release
> 
> We solved one regression:
> 
> https://issues.apache.org/jira/browse/FELIX-6383
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1368
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1368 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Soliciting feedback before calling a 1.0 release of Atomos

[Jean-Baptiste Onofre]

Thanks Tom for the reminder !

I should have time to test by the end of the week.

Regards
JB

> Le 9 févr. 2021 à 02:01, Thomas Watson  a écrit :
> 
> Hi,
> 
> I would like to give you a chance to provide feedback before calling a vote
> for a 1.0 release of Atomos.  I've done a few modifications over the past
> week or so and have improved the project readme to make it easier to
> understand what Atomos is and how to use it:
> 
> https://github.com/apache/felix-atomos
> 
> Please let me know what you think and provide any improvements that you
> think may be needed before we call for a 1.0 release.
> 
> Thanks
> 
> Tom

Re: [VOTE] Release Apache Felix org.apache.felix.configadmin.plugin.interpolation 1.1.2

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 17 févr. 2021 à 17:03, dav...@apache.org a écrit :
> 
> Hi all,
> 
> I would like to call a vote on
> the org.apache.felix.configadmin.plugin.interpolation 1.1.2 release
> 
> We fixed one issue:
> https://issues.apache.org/jira/browse/FELIX-6384
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1369
> 
> You can use this UNIX script to download the release and verify the
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1369 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote remains open for at least 72h
> 
> Best regards,
> 
> David Bosschaert

Re: [VOTE] Release Felix Atomos version 1.0

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 18 févr. 2021 à 19:31, Thomas Watson  a écrit :
> 
> Hi,
> 
> As mentioned before, we have been working toward a 1.0 release of Atomos.
> 
> 
> I've staged the 1.0 candidate and we are ready to vote for
> 
> the first release. Atomos has two main components
> 
> 
> 1) The Atomos library itself (org.apache.felix.atomos)
> 
> 2) The Atomos maven plugin (atomos-maven-plugin)
> 
> 
> The Atomos library is being released at version 1.0.0 while the
> 
> atomos-maven-plugin is released at version 0.9.0.
> 
> 
> Staging 
> repository:https://repository.apache.org/content/repositories/orgapachefelix-1372/
> 
> The source for this release is this:
> 
> https://repository.apache.org/content/repositories/orgapachefelix-1372/org/apache/felix/atomos-distribution/1.0.0/atomos-distribution-1.0.0-source-release.zip
> 
> You can use this UNIX script to download the release and verify the
> signatures:https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1372 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 
> 
> Tom

Re: [VOTE] Release Apache Felix Configurator 1.0.14

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 3 mars 2021 à 07:10, Carsten Ziegeler  a écrit :
> 
> I would like to call a vote on the configurator release
> 
> We solved one regression:
> 
> https://issues.apache.org/jira/browse/FELIX-6386
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1373
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1373 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix Http Jetty 4.1.6

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 15 mars 2021 à 07:48, Carsten Ziegeler  a écrit :
> 
> I would like to call a vote on the http jetty 4.1.6 release
> 
> We solved two issues in this release:
> 
> https://issues.apache.org/jira/browse/FELIX-6391?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20http.jetty-4.1.6
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1374
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1374 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[VOTE] Apache Felix maven-bundle-plugin 5.1.2 release

[Jean-Baptiste Onofre]

Hi everyone,

I submit maven-bundle-plugin 5.1.2 to your vote.

This release fixes two important issues:
- maven-bundle-plugin doesn’t cleanly create some headers, especially 
Provide-Capability headers. It has a major impact on several use cases, I’m 
thinking about OSGi CDI, etc.
- maven-bundle-plugin doesn’t "preserve" some MANIFEST entries created by the 
maven-jar-plugin. It’s the case especially for the Multi-Release entry and 
other.

You can find some details in the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12350026
 


Staging Repository:
https://repository.apache.org/content/repositories/orgapachefelix-1375/ 


Staging dist:
https://dist.apache.org/repos/dist/dev/felix/maven-bundle-plugin/5.1.2/ 


Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards
JB

Re: [VOTE] Apache Felix maven-bundle-plugin 5.1.2 release

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 23 mars 2021 à 15:19, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit maven-bundle-plugin 5.1.2 to your vote.
> 
> This release fixes two important issues:
> - maven-bundle-plugin doesn’t cleanly create some headers, especially 
> Provide-Capability headers. It has a major impact on several use cases, I’m 
> thinking about OSGi CDI, etc.
> - maven-bundle-plugin doesn’t "preserve" some MANIFEST entries created by the 
> maven-jar-plugin. It’s the case especially for the Multi-Release entry and 
> other.
> 
> You can find some details in the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12350026
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12350026>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1375/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1375/>
> 
> Staging dist:
> https://dist.apache.org/repos/dist/dev/felix/maven-bundle-plugin/5.1.2/ 
> <https://dist.apache.org/repos/dist/dev/felix/maven-bundle-plugin/5.1.2/>
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

[VOTE] Apache Felix Utils 1.11.8 release

[Jean-Baptiste Onofre]

Hi everyone,

I submit Utils 1.11.8 to your vote.

This release fixes FELIX-6397 allowing to export java.* packages by the 
ResourceBuilder. This change in ResourceBuilder is require since the framework 
should export java.* packages in system packages (since R7).

You can find some details in the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12349425
 


Staging Repository:
https://repository.apache.org/content/repositories/orgapachefelix-1376/ 


Staging dist:
https://dist.apache.org/repos/dist/dev/felix/utils/1.11.8/ 


Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards
JB

Re: [VOTE] Apache Felix Utils 1.11.8 release

[Jean-Baptiste Onofre]

My own +1 (binding) ;)

Regards
JB

> Le 26 mars 2021 à 10:26, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit Utils 1.11.8 to your vote.
> 
> This release fixes FELIX-6397 allowing to export java.* packages by the 
> ResourceBuilder. This change in ResourceBuilder is require since the 
> framework should export java.* packages in system packages (since R7).
> 
> You can find some details in the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12349425
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12349425>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1376/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1376/>
> 
> Staging dist:
> https://dist.apache.org/repos/dist/dev/felix/utils/1.11.8/ 
> <https://dist.apache.org/repos/dist/dev/felix/utils/1.11.8/>
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

[RESULT][VOTE] Apache Felix maven-bundle-plugin 5.1.2 release

[Jean-Baptiste Onofre]

Hi everyone,

This vote passed with the following result:

+1 (binding): Carsten Ziegeler, David Bosschaert, JB Onofré, Ray Augé, Pierre 
De Rop

I’m promoting the artifacts on Maven Central, and dist.apache.org 
<http://dist.apache.org/>. I will update the Jira as well.

Thanks all for your vote !

Regards
JB

> Le 23 mars 2021 à 15:19, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit maven-bundle-plugin 5.1.2 to your vote.
> 
> This release fixes two important issues:
> - maven-bundle-plugin doesn’t cleanly create some headers, especially 
> Provide-Capability headers. It has a major impact on several use cases, I’m 
> thinking about OSGi CDI, etc.
> - maven-bundle-plugin doesn’t "preserve" some MANIFEST entries created by the 
> maven-jar-plugin. It’s the case especially for the Multi-Release entry and 
> other.
> 
> You can find some details in the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12350026
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12350026>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1375/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1375/>
> 
> Staging dist:
> https://dist.apache.org/repos/dist/dev/felix/maven-bundle-plugin/5.1.2/ 
> <https://dist.apache.org/repos/dist/dev/felix/maven-bundle-plugin/5.1.2/>
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

[RESULT][VOTE] Apache Felix Utils 1.11.8 release

[Jean-Baptiste Onofre]

Hi everyone,

This vote passed with the following result:

+1 (binding): David Bosschaert, Carsten Ziegeler, Karl Pauls, JB Onofré, Ray 
Augé, Pierre de Rop

I’m promoting the artifacts on Maven Central and dist.apache.org 
<http://dist.apache.org/>, and I will update Jira.

Thanks all for your vote !

Regards
JB

> Le 26 mars 2021 à 10:26, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit Utils 1.11.8 to your vote.
> 
> This release fixes FELIX-6397 allowing to export java.* packages by the 
> ResourceBuilder. This change in ResourceBuilder is require since the 
> framework should export java.* packages in system packages (since R7).
> 
> You can find some details in the Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12349425
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12349425>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1376/ 
> <https://repository.apache.org/content/repositories/orgapachefelix-1376/>
> 
> Staging dist:
> https://dist.apache.org/repos/dist/dev/felix/utils/1.11.8/ 
> <https://dist.apache.org/repos/dist/dev/felix/utils/1.11.8/>
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: New Release for Gogo Runtime

[Jean-Baptiste Onofre]

Hi Amit,

Let me check. I will tackle that.

Regards
JB

> Le 29 mars 2021 à 11:55, Amit Mondal  a écrit :
> 
> Hi Felix Developers,
> 
> Could anyone of you kindly build a release for the latest version of Gogo 
> Runtime bundle? I am actually looking forward to these changes [1].
> 
> Thanks in advance for your support.
> 
> Best Regards,
> Amit
> 
> [1] - https://github.com/apache/felix-dev/pull/48
> [https://avatars.githubusercontent.com/u/47359?s=400&v=4]
> [io] Refactor of ThreadIO by pkriens · Pull Request #48 · 
> apache/felix-dev
> The ThreadIO service replaces the System streams so that the output and input 
> on a thread associated with a command can be captured. Unfortunately, this 
> occupies the singletons of System.in/out/err...
> github.com
> 

Re: New Release for Gogo Runtime

[Jean-Baptiste Onofre]

Hi Amit,

Yes, I saw that as well. I also have couple of improvements that I need for 
Karaf.

So, I would need a release anyway.
Please let me know we it’s OK to submit the release to vote.

Regards
JB

> Le 29 mars 2021 à 14:51, Amit Mondal  a écrit :
> 
> Hi Jean-Baptiste,
> 
> I just noticed that the PR has been closed. I don't know why Peter closed it 
> since the functionality would have been very useful to extend the 
> functionality of ThreadIO.
> 
> I will check with Peter and will keep you posted.
> 
> Thanks a lot.
> 
> Best Regards,
> Amit
> ____
> From: Jean-Baptiste Onofre 
> Sent: 29 March 2021 14:35
> To: dev@felix.apache.org 
> Subject: Re: New Release for Gogo Runtime
> 
> Hi Amit,
> 
> Let me check. I will tackle that.
> 
> Regards
> JB
> 
>> Le 29 mars 2021 à 11:55, Amit Mondal  a écrit :
>> 
>> Hi Felix Developers,
>> 
>> Could anyone of you kindly build a release for the latest version of Gogo 
>> Runtime bundle? I am actually looking forward to these changes [1].
>> 
>> Thanks in advance for your support.
>> 
>> Best Regards,
>> Amit
>> 
>> [1] - https://github.com/apache/felix-dev/pull/48
>> [https://avatars.githubusercontent.com/u/47359?s=400&v=4]<https://github.com/apache/felix-dev/pull/48>
>> [io] Refactor of ThreadIO by pkriens · Pull Request #48 · 
>> apache/felix-dev<https://github.com/apache/felix-dev/pull/48>
>> The ThreadIO service replaces the System streams so that the output and 
>> input on a thread associated with a command can be captured. Unfortunately, 
>> this occupies the singletons of System.in/out/err...
>> github.com
>> 
> 

Re: [VOTE] Release Apache Felix Http 4.1.8

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 4 mai 2021 à 09:21, Carsten Ziegeler  a écrit :
> 
> Hi
> 
> I would like to call a vote on the http jetty 4.1.8 release
> 
> We solved one issue in this release:
> 
> https://issues.apache.org/jira/browse/FELIX-6405
> 
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1378
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1378 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org