Re: [PROPOSAL] Apache Karaf runtime releases and roadmap

[Matt Pavlovich]

Hi JB-

Makes sense, I figured I’d make the pitch for the pax-* merger in that there is 
a lot of good use cases, stability and performance scenarios already handled 
there.

I look forward to assisting with the new karaf-* services.

Thanks,
Matt Pavlovich

> On Jun 11, 2024, at 3:45 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> I would like to clarify the PAX * questions. It would be still
> possible to use PAX * projects in Karaf 5.x, via the features (as
> today), but optional (not boot features anymore).
> 
> As an alternative, we will have opinionated Karaf services features.
> 
> For instance, pax-web will still be available (if people want to use
> it), but Karaf will provide a web feature (as alternative).
> 
> For URL and logging, Karaf will provide simplified mvn and wrap url
> handlers, and opinionated Karaf logging service (only supporting slf4j
> and log4j2). If users still want to use Pax URL and Pax Logging, they
> will still be able to do so via custom distribution.
> 
> The reasons to provide Karaf opinionated services are:
> 1. Karaf services are governed by the ASF rule, as Karaf, which is not
> the case for Pax
> 2. Pax * projects are great as "generic" OSGi services. On the other
> hand, it brings some complexity to be abstract enough for OSGi use
> cases and compliant with the OSGi specs. Karaf services will really be
> Karaf centric, not necessarily respecting the OSGi specs, but focusing
> on users' needs.
> 3. Facilitate Karaf tooling around to improve the developer experience.
> 
> Regards
> JB
> 
> On Tue, Jun 11, 2024 at 8:48 AM Francois Papon
>  wrote:
>> 
>> Hi Serge,
>> 
>> You can already build a static Karaf custom definition ready to start
>> without downloading all the dependencies at startup and create a docker
>> image with that.
>> 
>> The most complex part with GraalVM in our case is all the 3rd party
>> dependencies and the OSGi framework. I'm afraid that it will not be
>> possible to be GraalVM compatible.
>> 
>> I'm not sure to understand your thoughts about "full OSGi for dev", what
>> to you mean?
>> 
>> regards,
>> 
>> François
>> 
>> On 08/06/2024 08:31, Serge Huber wrote:
>>> Hi François,
>>> 
>>> I understand not everything has to be native, but for example for Apache
>>> Unomi the default deployment is now mostly in containers, and extensions
>>> are usually deployed mostly in development environments and then statically
>>> packaged for production deployments.
>>> 
>>> Having the option to then use Karaf 5 to leverage the benefits of GraalVM
>>> Native Image would be very interesting I believe. I think other
>>> applications might be interested in these types of scenarios: full OSGi for
>>> development, maybe pre-production and testing, and possibility to have a
>>> more « static » deployment for production that could be compatible with
>>> native image.
>>> 
>>> WDYT ?
>>> 
>>> Regards,
>>>Serge…
>>> 
>>> Le jeu. 6 juin 2024 à 11:09, Francois Papon 
>>> a écrit :
>>> 
>>>> Hi Serge,
>>>> 
>>>> I don't think there is a benefit about GraalVM for long running process
>>>> like Karaf. All java things doesn't need to be GraalVM native :)
>>>> 
>>>> Another problem is that the community edition of GraalVM doesn't bring
>>>> all the improvement as the commercial one (GC, PGO...)
>>>> 
>>>> regards,
>>>> 
>>>> François
>>>> 
>>>> On 05/06/2024 15:13, Serge Huber wrote:
>>>>> Hi JB thanks for the proposal,
>>>>> 
>>>>> Sounds great to me. For me Karaf 5 should really be a natural fit for
>>>>> containerized deployments, making it super easy to package applications
>>>>> that can then easily be scaled up (and down), so making it more
>>>> predictable
>>>>> and possibly more static can be a good thing.
>>>>> 
>>>>> Is a goal also to make it compatible with GraalVM Native Image ?
>>>>> 
>>>>> Best regards,
>>>>>Serge.
>>>>> 
>>>>> On Tue, Jun 4, 2024 at 11:18 AM Jean-Baptiste Onofré 
>>>>> wrote:
>>>>> 
>>>>>> Hi folks,
>>>>>> 
>>>>>> I think it's time to prepare a new milestone for the project :)
>>>>>> 
>>>>>> Short term (and first step) is t

Re: [PROPOSAL] Apache Karaf runtime releases and roadmap

[Matt Pavlovich]

I think this summarizes a core maintenance issue with pax+karaf today

> I am not sure how many people travel between PAX and Karaf and vice versa, 
> but lets be honest - contribution criteria for PAX is lower than for Karaf.

I suggest we take a look at migrating pax-* (pax-logging. pax-url, pax-web, 
etc) into karaf for a couple of practical benefits (perhaps for Karaf 4.5?):

1. Less repositories to manage and preform releases
2. Artifacts (jars, configs, services) are less confusing to users (ie.  
org.apache.karaf.web makes more sense vs org.ops4j.pax.web .. etc)

This would also give us an opportunity to see how this gels before finalizing 
what is supported in Karaf 5 (jetty, tomcat, etc).

Thoughts?

Matt Pavlovich

Re: [PROPOSAL] Apache Karaf runtime releases and roadmap

[Matt Pavlovich]

1. Sounds good 

2. I think Jetty 12 / pax-web support in v4.5.x is important. I started working 
on a PR for it, but there are significant Jetty API changes. (Jetty 12 support 
would provide a LTS-like support timeframe while Karaf 5.x gets going.)

3. +1 on JUnit 5 Extension / Runner instead of pax-exam
+1 on simplified default logger — One thing pax-logging’s wrapping provides 
reload of config. Is the thought here to drop runtime reload of logging 
configuration change?.

Regarding replacing pax-web — this seems like a large effort. There are a 
*ton* of unit tests of various use cases there and lots of value covering a ton 
of web-deployment scenarios. Are you thinking of dropping http whiteboard or 
other deploy scenarios in favor of servlet-only?  If the other scenarios are 
required, perhaps keep pax-web and only go wtih Jetty/Tomcat support? I don’t 
see a lot of demand / usage of Undertow.

4. Configuration and Encryption service (and encryption of config keys and 
values) as first-class services instead of jasypt add-on. (JDK crypto 
out-of-the-box).

My $0.02.

Thanks,
Matt Pavlovich

> On Jun 4, 2024, at 4:17 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi folks,
> 
> I think it's time to prepare a new milestone for the project :)
> 
> Short term (and first step) is to prepare the coming release:
> 
> 1. Apache Karaf 4.4.7 will be submitted to vote next week. It will include:
>   * Improvement on the spring features repository (providing both
> Spring 5 and Spring 6 features)
>   * Dependencies updates and minor fixes found on the 4.4.6 release
> 
> 2. Apache Karaf 4.5.0 will be submitted to vote by the end of the
> month. It will include (mainly):
>   * New spec features repository with Jakarta specs
>   * Bigger fixes for 4.5.0
> 
> 3. Apache Karaf 5.0.0
>  That's the big milestone, and I propose to have big and opinionated
> changes here. OSGi is an implementation detail of the runtime, still
> exposed to the experimented users.
>  Be opinionated means that I propose to remove PAX * dependencies,
> and provide Karaf services instead, very simple and opinionated (for
> instance, instead of PAX Web, a simple Tomcat based service, instead
> of PAX Logging, a simple slf4j/log4j only service, Pax Exam replaced
> by JUnit 5 simple extensions, etc).
>  Another goal of Karaf 5 is to bring new tooling to improve dev
> experience (annotation based distributions generation, etc).
>  Also, users will be able to smoothly deploy Spring powered or
> Servlet applications without knowing/leveraging OSGi (especially the
> import/export pattern).
> 
> Thoughts ?
> 
> Regards
> JB

Re: [VOTE] Apache Karaf OSGi runtime 4.4.6 release

[Matt Pavlovich]

+1 (non-binding)

- Download distribution
- Tested installing various features

Thanks,
Matt Pavlovich

> On Apr 9, 2024, at 8:33 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi folks,
> 
> I submit Apache Karaf OSGi runtime 4.4.6 release to your vote.
> 
> This release is a maintenance release on the 4.4.x series bringing
> fixes and dependency updates, especially:
> - new Spring 6.x features (NB: you would need Java 17+ to use it)
> - Upgrade to Pax Web 8.0.27 / Jetty 9.4.54.v20240208
> - Upgrade to Bouncycastle 1.77
> - Upgrade to sshd 2.12.1
> - and much more!
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12354057
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1191/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.4.6/
> 
> Git tag:
> karaf-4.4.6
> 
> 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: [PROPOSAL] Migrate to GitHub Issues/Actions

[Matt Pavlovich]

A little late but thought I’d put in my $0.02 

+1 for GitHub issues. There are APIs avail to migrate, so I”m not super 
concerned about lock-in.

Also, there is thing saying we can’t use GH actions and Apache Jenkins CI at 
the same time. 

GH actions seem to have more runner nodes vs Apache Jenkins infra and are great 
for when there are a lot of PR’s lined up. 

I use both GH Actions and Jenkins for jaxb-tools.

-Matt

> On Feb 5, 2024, at 12:56 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> Yeeah, that would help. As said, my priority is the 4.5.0 release this
> week. The move to GH will happen after.
> 
> Thanks !
> Regards
> JB
> 
> On Mon, Feb 5, 2024 at 7:33 AM Grzegorz Grzybek  wrote:
>> 
>> Hello
>> 
>> JBO - we can discuss on slack later if you decide to migrate - we can use 
>> the scripts I used to migrate Pax projects.
>> 
>> regards
>> Grzegorz Grzybek
>> 
>> sob., 3 lut 2024 o 06:39 Jean-Baptiste Onofré  napisał(a):
>>> 
>>> Hi guys,
>>> 
>>> it seems we have a consensus here.
>>> 
>>> I propose to complete Karaf 4.5.0 release first and then I will move
>>> forward on the switch to GH Issues (and also GH Actions).
>>> 
>>> Thanks,
>>> Regards
>>> JB
>>> 
>>> On Tue, Oct 31, 2023 at 9:27 AM Jean-Baptiste Onofré  
>>> wrote:
 
 Hi guys,
 
 I would like to propose to move from Jira to GH Issues and from
 Jenkins to GH Actions.
 
 As we have several sub-projects, each sub-project will have its own
 space, like we do for Karaf Minho
 (https://github.com/apache/karaf-minho).
 
 The migration should be "smooth" and I will work on it if you agree.
 
 Thoughts ?
 
 Regards
 JB

Re: [PROPOSAL] Migrate to GitHub Issues/Actions

[Matt Pavlovich]

+1 

> On Nov 21, 2023, at 3:12 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys
> 
> Any comments on that one ?
> 
> If there are no objections, I will move forward with that.
> 
> Regards
> JB
> 
> On Tue, Oct 31, 2023 at 9:27 AM Jean-Baptiste Onofré  
> wrote:
>> 
>> Hi guys,
>> 
>> I would like to propose to move from Jira to GH Issues and from
>> Jenkins to GH Actions.
>> 
>> As we have several sub-projects, each sub-project will have its own
>> space, like we do for Karaf Minho
>> (https://github.com/apache/karaf-minho).
>> 
>> The migration should be "smooth" and I will work on it if you agree.
>> 
>> Thoughts ?
>> 
>> Regards
>> JB

Re: Karaf + SOAP + JDK 21

[Matt Pavlovich]

Hi Mark-

Glad to hear it’s working for you! 

-Matt

> On Nov 15, 2023, at 3:58 PM, Mark Derricutt  wrote:
> 
> Hi Matt - that's both sad, and great to hear.
> 
> Updated the dependency and working like a charm.  Cheers!
> 
> On 16/11/23 3:44 am, Matt Pavlovich wrote:
>> The maven-jaxb2-plugin, jaxb2-basics and other jaxb2 commons plugins
>> have been modernized for jakarta (I’m now the project lead, since the
>> maintainer sadly passed away).

Re: Karaf + SOAP + JDK 21

[Matt Pavlovich]

Hi Mark-

The maven-jaxb2-plugin, jaxb2-basics and other jaxb2 commons plugins have been 
modernized for jakarta (I’m now the project lead, since the maintainer sadly 
passed away).

The Maven plugin, jaxb-basics (now called jaxb-plugins) and several of the 
ancillary projects have all been collapsed into a single repo ‘jaxb-tools' 


See version: 4.0.0 

https://github.com/highsource/jaxb-tools/

Thanks,
Matt Pavlovich

> On Nov 15, 2023, at 3:10 AM, Mark Derricutt  wrote:
> 
> and updated cxf-codegen-plugin to 4.0.3. Interestingly, I couldn't find any 
> suitable replacements/updates for org.jvnet.jaxb2_commons:jaxb2-fluent-api 
> it's sibling XCJ extensions so had to rewrite one wrapper service to match 
> the changed code-gen.

Re: The meaning of karaf-bom

[Matt Pavlovich]

+1 for JB’s 2-bom approach where the main bom reflects what is in the karaf 
dist, and a secondary bom for tests

karaf-bom  (should list all shipped jars from karaf, and jars from 
dependencies (or import _the dependency's bom_) installed in the dist.. felix, 
pax-logging, pax-web, etc
karaf-bom-test   (import karaf-bom, add test jars, etc)

Matt Pavlovich

> On Sep 28, 2023, at 8:57 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> I like the proposal of having different BOMs different of the use (for
> instance Quarkus has two different boms: one for application, one for
> test).
> 
> I can definitely create a bom module containing:
> - bom/stack
> - bom/application
> 
> If it works for you, I can create a Jira and then prepare this for Karaf 
> 4.5.0.
> 
> Thoughts ?
> 
> Regards
> JB
> 
> On Wed, Sep 27, 2023 at 9:46 PM Steven Huypens  
> wrote:
>> 
>> Hi Robert,
>> 
>> Thank you for clarifying the difference between both BOMs. I believe that
>> the current Karaf BOM incorporates elements from both types, whereas you
>> only require the library BOM.
>> 
>> In my opinion, it would be beneficial to create a distinct stack BOM. This
>> approach would enhance clarity for consumers. Additionally, by
>> consolidating all Maven version properties within this 'stack BOM,'
>> projects utilizing Karaf could easily synchronize their dependency versions
>> with those of Karaf, without the need to reference the entire Karaf parent
>> POM.
>> 
>> 
>> Kind regards,
>> Steven
>> 
>> On Wed, Sep 27, 2023 at 5:18 PM Robert Varga  wrote:
>> 
>>> On 27/09/2023 08.35, Jean-Baptiste Onofré wrote:
>>>> Hi
>>> 
>>> Hello,
>>> 
>>>> Not really imho : each project does the way it considers the best.
>>>> 
>>>> For instance, quarkus is using a bop approach similar to Karaf: it
>>> exposes
>>>> all dependencies in the BOM as a guarantee about the versions working
>>> fine.
>>>> 
>>>> The idea in Karaf bom is to clearly state the versions verified in Karaf.
>>>> Users can always override the versions, but the BOM guarantees the
>>>> qualified versions.
>>> 
>>> Right, and nowadays there are lot more BOM-related resources on the web.
>>> 
>>> Researching what Maven4 will do (for the other email), I came across
>>> this: https://www.infoq.com/news/2023/06/maven-puzzlers-devoxxuk/
>>> 
>>> Which makes a distinction, making both our views correct:
>>> 
>>>>The library BOM - defines projects that are related to a single
>>> library. For example, the JUnit or Jackson BOM defines everything related
>>> to JUnit and nothing more
>>>>The stack BOM - Spring or Quarkus BOM bring all dependencies of
>>> various projects required for the given project to function. Each BOM
>>> contains a combination of versions that work best together
>>> 
>>> I meant to former while Karaf is doing the latter. Count myself educated :)
>>> 
>>> It might make sense to somehow also provide just a library BOM, but I
>>> struggle to define the use case where I would really need it :)
>>> 
>>> Thanks,
>>> Robert
>>> 
>>> 
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> Le dim. 24 sept. 2023 à 22:54, Robert Varga  a écrit :
>>>> 
>>>>> Hello,
>>>>> 
>>>>> One thing that strikes me is "Bill of Materials" as perceived by
>>> karaf-bom.
>>>>> 
>>>>> As it currently stands, karaf-bom includes all declarations of
>>>>> karaf.git/pom.xml.
>>>>> 
>>>>> As I understand the bill-of-materials concept under Maven, it should
>>>>> only list artifacts provided by a particular project, nothing more,
>>>>> nothing less.
>>>>> 
>>>>> In the latter regard, we should be only declaring org.apache.karaf
>>>>> artifacts in karaf-bom.
>>>>> 
>>>>>  From a downstream's perspective, there is a difference between
>>>>> importing karaf-bom (in which case the downstream takes the
>>>>> resposibility to align any shared depdendencies) and karaf.git/pom.xml
>>>>> (in which case I am trusting Karaf with a ton of dependencies).
>>>>> 
>>>>> Currently, there is no distinction between those two.
>>>>> 
>>>>> Is it fair to align karaf-bom with the above expectation (and hence not
>>>>> leak things like org.slfj4.api's version)?
>>>>> 
>>>>> As it stands there is no distinction, with this proposal current
>>>>> downstreams wishing to retain current state would scope=import
>>>>> karaf.git/pom.xml instead of karaf-bom (a change of maven coordinates)
>>>>> with no otherwise-observable change.
>>>>> 
>>>>> Does this make sense?
>>>>> 
>>>>> Regards,
>>>>> Robert
>>>>> 
>>>> 
>>> 

Re: [INFO] main branch has been updated to 4.5.0-SNAPSHOT

[Matt Pavlovich]

Hi JB-

For Jakarta-based Karaf, should we go ahead and call it Karaf 5.0.0?

-Matt

> On Sep 21, 2023, at 10:45 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> now that we released Karaf OSGi runtime 4.4.4 and 4.3.10:
> - I updated main branch to use 4.5.0-SNAPSHOT branch
> - I created karaf-4.4.x branch
> 
> As a reminder, karaf-4.3.x will move "not active" when the first 4.5.0
> version will be released.
> 
> Regards
> JB

Re: [VOTE] Apache Karaf OSGi runtime 4.3.10 release

[Matt Pavlovich]

+1 (non-binding)

> On Sep 14, 2023, at 11:33 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Karaf OSGi runtime 4.3.10 release to your vote.
> 
> This release is a maintenance release bringing fixes and dependency updates.
> Especially this release includes:
> - fix race condition between the FeaturesService and FeatureDeploymentListener
> - fix --patch-module on Instance startup
> - add exec:groovy shell command
> - dependency updates including CVE fixes (Johnzon, BouncyCastle,
> Commons FileUpload)
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352694
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1188/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.10/
> 
> Git tag:
> karaf-4.3.10
> 
> 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 Karaf OSGi runtime 4.4.4 release

[Matt Pavlovich]

+1 (non-binding)

> On Sep 12, 2023, at 10:06 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> After long weeks of wait, I submit Apache Karaf OSGi runtime 4.4.4
> release to your vote.
> 
> This release is a maintenance release bringing fixes and dependency updates.
> Especially this release includes:
> - fix race condition between the FeaturesService and FeatureDeploymentListener
> - fix --patch-module on Instance startup
> - add exec:groovy shell command
> - dependency updates including CVE fixes (Johnzon, BouncyCastle,
> Commons FileUpload)
> - better JDK20 support
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352693
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1186/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.4.4/
> 
> Git tag:
> karaf-4.4.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.
> 
> Regards
> JB

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Matt Pavlovich]

> On Jan 18, 2023, at 12:43 PM, Andrea Cosentino  wrote:
> 
> Hello,
> 
> The point is just one in relation to OSGi metadata. The components will be
> consumed, also, by runtimes that don't need OSGi metadata, so why all the
> components should be with OSGi metadata and packaged as bundles?

Hi Andrea-

This is really the gist of my inquiry — What is the level of effort involved in 
maintaining OSGi metadata for Camel? From the high level it appears to be 
handled automatically at this point.

Thanks,
Matt Pavlovich

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Matt Pavlovich]

I have a similar question on this point--

> On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki  wrote:
> 
> 6) I do not see any sign of what is going to happen with OSGi metadata which 
> is present for Apache Camel 3.x components. Is Camel 4.x going to retain OSGi 
> metadata?

How is maintaining OGSI metadata in Camel a concern?

Thanks,
Matt Pavlovich

Re: [DISCUSS] Apache Karaf subprojects Roadmap

[Matt Pavlovich]

Hi François-

I recall the discussion about removing the OSGi support from Camel, but I do 
not see it listed on the ROADMAP to Camel 4 link.

Did OSGi header support for camel jars officially get dropped?  Seems like such 
a minor thing to keep around.

-Matt

> On Jan 9, 2023, at 3:19 AM, fpapon  wrote:
> 
> Hi JB,
> 
> Make sense for Cave and Winegrower.
> 
> About Camel-Karaf, as it was announced by the Camel team in the roadmap to 
> Camel 4, I was thinking that it was already acted:
> 
> https://camel.apache.org/blog/2023/01/camel4roadmap/
> 
> I asked the question about the OSGi bundle still provide or not by Camel team 
> but no clear decision, Camel team don't want to provide OSGi bundle for Camel 
> core anymore.
> 
> regards,
> 
> François
> 
> On 09/01/2023 10:13, Jean-Baptiste Onofré wrote:
>> Hi François,
>> 
>> Thanks for bringing this discussion.
>> 
>> Here's my personal standpoint:
>> 1. Decanter: I started to work on Decanter 3.x (refactoring). I think
>> we can do a release now with just updates on the collectors/appenders
>> before moving forward on decanter 3.x. I propose to cut new Decanter
>> release asap.
>> 2. Cellar: quite the same as Decanter. I plan a refactoring, but it is
>> worth doing an updated version (new hazelcast, kubernetes client,
>> karaf version). Same: I propose to cut new Cellar release asp.
>> 3. Cave: I think we don't have many users on Cave, maybe it's worth to
>> move the project to "attic" ?
>> 4. Winegrower: same as Cave, I don't think we have a lot of users,
>> maybe it's worth to move the project to "attic" ?
>> 5. Minho:
>> 6. For SMX bundles, the objective is not to move as it is. The
>> objective it's to use the new bundle descriptor I started in Pax URL.
>> Karaf "Bundles" will host just the descriptor to create the bundle on
>> the fly (and eventually cached). The other part of SMX (assembly +
>> spec) can be moved in Karaf subproject.
>> 7. For camel-karaf, I'm open to community proposals. If it's better to
>> have it in Karaf, I'm OK with it (same question about jclouds-karaf).
>> 
>> Regards
>> JB
>> 
>> On Mon, Jan 9, 2023 at 10:07 AM fpapon  wrote:
>>> Hi,
>>> 
>>> I want to start a thread about Apache Karaf subprojects roadmap and
>>> maintainability.
>>> 
>>> Today we have:
>>> 
>>> - Decanter: last release on Feb. 2022
>>> 
>>> - Cellar: last release on Aug. 2020
>>> 
>>> - Cave: last release on Nov. 2019
>>> 
>>> We also have:
>>> 
>>> - Winegrower: last release on Nov. 2020
>>> 
>>> - Minho: last release on Jan. 2023 (but plan to move to dedicated TLP
>>> project)
>>> 
>>> There is also some discussion about moving SMX bundle and Camel-Karaf as
>>> Karaf subprojects so I think it will be nice to see what we would/could
>>> maintain.
>>> 
>>> regards,
>>> 
>>> --
>>> --
>>> François
>>> 
> -- 
> --
> François
> 

Re: [VOTE] Apache Karaf OSGi runtime 4.3.9 release

[Matt Pavlovich]

+1 non-binding

> On Jan 10, 2023, at 11:41 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Karaf OSGi runtime 4.3.9 release to your vote.
> 
> This release is a maintenance release bringing a lot of dependency
> updates and fixes.
> Especially, this release includes:
> - fix threads leak in karaf-maven-plugin (in verify feature goal)
> - fix on JMX stub IP address assignation (especially on different
> docker networks)
> - re-add shell:alias command
> - fix ssh client on Windows
> - and several dependency updates !
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352383
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1183/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.9/
> 
> Git tag:
> karaf-4.3.9
> 
> 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: Issue with KARAF 4.4.1 And OpenJDK 11 (JAX-WS)

[Matt Pavlovich]

You need to install a bundle that provides javax.ws interface and 
implementation. Are you using Apache CXF? The CXF feature has xml-specs feature 
that it installs by default that covers this for you.

-Matt

> On Dec 7, 2022, at 1:33 AM, Vamsikrishna Koka 
>  wrote:
> 
> Hi Team,
> 
> I have tried to migrating from KARAF 4.2.15 to KARAF 4.4.1 version along with 
> OpenJDK also. From OpenJDK 8 to OpenJDK 11 (JAX-WS).
> 
> In OpenJDK 11 removed support of JAX-WS, So I have added explicitly in pom 
> xml.  After adding I'm getting the above wiring issue. which is given below.
> 
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to 
> resolve adapter/51.0.0.SNAPSHOT: missing requirement 
> [adapter/51.0.0.SNAPSHOT] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=javax.jws).
> 
> Please can anyone take look at once.
> 
> Thanks,
> Vamsi Krishna.
> 

Re: [VOTE] Adopt new Apache Karaf "generic" logo

[Matt Pavlovich]

+1 cool!

> On Nov 15, 2022, at 2:56 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> As discussed on the other thread, here's a vote for the new Karaf logo 
> proposal.
> 
> As a reminder, this logo is the generic one, used on the main
> karaf.apache.org website. Each Karaf subproject (Minho, OSGi, etc)
> will have its own "sub-website", with dedicated content and eventually
> its own logo.
> 
> Please vote:
> +1 to adopt Karaf generic logo
> 0 I don't care
> -1 for Karaf generic logo and work on a new one
> 
> NB: I would like to move forward pretty fast on the logo just to
> promote the new website and announce Karaf Minho.
> 
> Thanks,
> Regards
> JB
> 

Re: [DISCUSS] Adopt new Karaf logo

[Matt Pavlovich]

-1 (non-binding)

My $0.02 —

1. The cloud logo is not friendly to be turned into a font
2. I prefer the alternative hexagon logo is simpler (even if similar to others) 
and better suited for the things logos are used for — stickers, font, ascii 
art, etc.

Thanks,
Matt Pavlovich

> On Nov 13, 2022, at 1:47 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys
> 
> I did a review on twitter and linkedin feedback about Karaf logo (the « cloud 
> » one). 
> 
> To summarize, we only have +1 and two « comments » like « cloud is not 
> related to Karaf ». 
> 
> So, I wonder to make a call and formal vote:
> 
> +1 to adopt Karaf cloud logo
> -1 for Karaf cloud logo and work on a new one
> 
> The reason I’m asking is because I’m working on website proposal. So I would 
> like to integrate the logo. 
> 
> Regards
> JB
> 
> Le mar. 1 nov. 2022 à 14:11, Jean-Baptiste Onofré  <mailto:j...@nanthrax.net>> a écrit :
> Hi guys,
> 
> as discussed on a previous thread, I'm working on a new website
> proposal with the following objectives:
> 
> 1. Use docusaurus instead of jekyll to build. The good thing is that
> it supports md syntax, blog, etc.
> 2. Give the same space/visibility to the subprojects (Karaf Minho,
> Karaf OSGi, Karaf Decanter, Karaf Cellar, Karaf Cave, Karaf
> Winegrower)
> 3. Add blog feature to announce and provide details about Karaf projects
> 
> Related to that, I created a new "generic" logo for Karaf (each
> project can have its own logo).
> 
> You can see the logo proposal attached.
> 
> Basically the idea is:
> - boxes populating the cloud represent Karaf projects
> - we can assembly Karaf projects to create a cloud solution
> 
> Thoughts ?
> 
> If we agree with this logo, I would like to prepare some goodies using
> it (probably on https://www.redbubble.com/en/ 
> <https://www.redbubble.com/en/>).
> 
> Regards
> JB

Re: [VOTE] Apache Karaf OSGi runtime 4.3.8 release

[Matt Pavlovich]

+1 (non-binding)

> On Oct 19, 2022, at 7:02 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Karaf OSGi runtime 4.3.8 release to your vote.
> 
> This release is a maintenance release bringing a lot of dependency
> updates and fixes.
> Especially, this release includes:
> - new feature:status command
> - new --repository option on feature:list command
> - improved Kar service about bundles refresh
> - a bunch of dependencies updates
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351577
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1178/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.8/
> 
> Git tag:
> karaf-4.3.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 Karaf OSGi runtime 4.4.2 release

[Matt Pavlovich]

+1 (non-binding)

> On Oct 18, 2022, at 11:04 PM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Karaf OSGi runtime 4.4.2 release to your vote.
> 
> This release is a maintenance release bringing a lot of dependency
> updates and fixes.
> Especially, this release includes:
> - new feature:status command
> - new --repository option on feature:list command
> - improved Kar service about bundles refresh
> - a bunch of dependencies updates
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12352048
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1177/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.4.2/
> 
> Git tag:
> karaf-4.4.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] Accept Apache Karaf Minho in Apache Karaf

[Matt Pavlovich]

+1 (non-binding)

Thanks, JB!

> On Oct 13, 2022, at 1:46 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> As discussed on the mailing list, I would like to start a formal vote
> to accept Apache Karaf Minho in Apache Karaf.
> 
> The proposal is:
> - create karaf-minho repository on github
> - use github issues/actions for Minho
> - rework the website to have all projects at the same level, Karaf
> runtime becoming Karaf OSGi. Each project will have its own
> subwebsite, like https://jbonofre.github.io/karaf5/.
> 
> In the meantime, I will change all resources to use
> org.apache.karaf.minho namespace on my github before donation.
> 
> Please vote to approve this donation/change:
> 
> [ ] +1 Approve Minho donation and proposed plan
> [ ] -1 Don't approve the donation/changes (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: [DISCUSS] Accepting K5 in the Karaf ecosystem

[Matt Pavlovich]

+1 on bringing Karaf 5 into the Apache Karaf project.

My $0.02 on naming is that perhaps the ‘5’ should drop off, since it’ll have 
its own version number and in case w/ need a Karaf Runtime v5.x to support all 
the OSGi + Jakarta + JDK changes coming.

Regarding name ideas— I think short and simple is best!  Boot, Blend, etc.

Perhaps whittle it down to 2 or 3 ideas?

Thanks,
Matt Pavlovich

> On Oct 6, 2022, at 8:59 AM, Jean-Baptiste Onofré  wrote:
> 
> It sounds good too !
> 
> Regards
> JB
> 
> On Thu, Oct 6, 2022 at 3:57 PM Jamie G.  wrote:
>> 
>> Perhaps something like Apache Karaf Sustineri ?
>> 
>> - The sustainably sourced modulith runtime
>> 
>> On Thu, Oct 6, 2022 at 11:22 AM Serge Huber  wrote:
>>> 
>>> Thanks for the contribution JB.
>>> 
>>> Personally I think we should maybe look into having a new name for it to
>>> make it easy to distinguish from Karaf ?
>>> 
>>> I'm especially worried if there ever is a Karaf 5 and K5 it's going to
>>> become very confusing.
>>> 
>>> I don't have great alternative solutions for the moment but maybe something
>>> like Alembic, Cauldron, ...
>>> 
>>> Regards,
>>>  Serge...
>>> 
>>> On Thu, Oct 6, 2022 at 3:38 PM Francois Papon 
>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> May be yes, we should find a project name more not old Karaf related to
>>>> not lost the users.
>>>> 
>>>> Regards,
>>>> 
>>>> On 06/10/2022 15:25, Jean-Baptiste Onofré wrote:
>>>>> Hi,
>>>>> 
>>>>> I don't use Karaf5, but K5 ;)
>>>>> 
>>>>> And yes, the first release would be K5 1.0 (for instance, 1.1, 2.0,
>>>>> 2.1, 2.2, 3.0, etc, etc).
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>> On Thu, Oct 6, 2022 at 3:12 PM Jamie G. 
>>>> wrote:
>>>>>> Agreed that proper naming and transition/migration guides will be
>>>>>> necessary then to guide users.
>>>>>> 
>>>>>> A question on the name "Karaf5" - what would its first release version
>>>>>> be? 1.0.0? 5.0.0?
>>>>>> It may be a little awkward to search Karaf5 2.0 or Karaf5 6.0. as it
>>>>>> matures/evolves.
>>>>>> 
>>>>>> On Thu, Oct 6, 2022 at 10:10 AM Jean-Baptiste Onofré 
>>>> wrote:
>>>>>>> Hi Jamie,
>>>>>>> 
>>>>>>> Correct: we can imagine having the karaf-k4 module providing the same
>>>>>>> support as Karaf (4): OSGi, features service, etc.
>>>>>>> 
>>>>>>> To be honest, that's not my intention (I don't want to have K4 and K5
>>>>>>> coupled somehow together), but possible.
>>>>>>> 
>>>>>>> IMHO, we will have Karaf users and K5 users, different usage.
>>>>>>> 
>>>>>>> Regards
>>>>>>> JB
>>>>>>> 
>>>>>>> On Thu, Oct 6, 2022 at 2:21 PM Jamie G. 
>>>> wrote:
>>>>>>>> To my understanding it doesn't prevent OSGi, it just does not require
>>>>>>>> it (very much in the spirit of Karaf letting you choose what you want
>>>>>>>> to run Equinox/Felix, Log4j/SLF4j, etc).
>>>>>>>> 
>>>>>>>> In theory can an end user take their well formed application
>>>>>>>> (features) and directly deploy them into K5 without refactoring?
>>>>>>>> 
>>>>>>>> I've worked on numerous projects which started at Karaf 2, and have
>>>>>>>> updated progressively to K3, K4. Does K5 represent a roadblock to
>>>>>>>> evolution?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Oct 6, 2022 at 9:36 AM Łukasz Dywicki 
>>>> wrote:
>>>>>>>>> Hello,
>>>>>>>>> Looking forward towards donation of it as a subproject with clear
>>>> name.
>>>>>>>>> Tehhnically speaking it is not Karaf 5 since it is not based on
>>>> earlier principles. Dropping osgi is large change which will confuse
>>>> existing users.
>>>>>>>>> Hence following the ActiveMQ Artemis story we should be clear

Re: Board report for September 22

[Matt Pavlovich]

+1 looks good

> On Sep 11, 2022, at 12:23 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I prepared the board report for September 22:
> 
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
> 
> Please take a look and let me know if I missed anything.
> I would like to send the board report asap.
> 
> Thanks !
> Regards
> JB

Re: Jasypt update or replace?

[Matt Pavlovich]

JB/FP- 

Sounds good. With Shiro being an Apache project, that should help with 
integration into Karaf.

Its not a high-priority on anyone’s radar, but jasypt is slowly aging on us 
dependency and with integrations.

Thanks,
Matt Pavlovich

> On Jul 18, 2022, at 7:25 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi Matt,
> 
> That's a good point. I think Shiro could be an alternative if we bring
> some new features in Shiro.
> 
> Worth to chat with Shiro team imho.
> 
> Regards
> JB
> 
> On Fri, Jul 15, 2022 at 9:26 PM Matt Pavlovich  wrote:
>> 
>> Hi All-
>> 
>> Jasypt has not been updated in quite a while, and it does not appear to be 
>> an active community. There are a couple things that need to be cleaned up 
>> and modernized.
>> 
>> Anyone here have ties to the jasypt project or has there been thought to 
>> re-implementing something to replace it for Karaf (maybe ActiveMQ as well)?
>> 
>> Thanks,
>> Matt Pavlovich

Jasypt update or replace?

[Matt Pavlovich]

Hi All-

Jasypt has not been updated in quite a while, and it does not appear to be an 
active community. There are a couple things that need to be cleaned up and 
modernized.

Anyone here have ties to the jasypt project or has there been thought to 
re-implementing something to replace it for Karaf (maybe ActiveMQ as well)? 

Thanks,
Matt Pavlovich

Re: [VOTE] Apache Karaf runtime 4.4.1 release

[Matt Pavlovich]

+1 (non-binding)

> On Jul 10, 2022, at 12:24 PM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Karaf runtime 4.4.1 release to your vote.
> 
> This release is a maintenance release bringing a lot of dependency
> updates and fixes.
> Especially, this release includes:
> - fix on the exported system packages
> - fix on the config management in features service
> - upgrade to Pax Web 8.0.6, Pax URL 2.6.11, Pax Logging 2.1.3
> - upgrade to OSGi frameworks (both Felix Framework 7.0.5 and Equinox 3.18.0)
> - upgrade to Spring 5.3.21 and 5.2.22.RELEASE
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351548
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1176/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.4.1/
> 
> Git tag:
> karaf-4.4.1
> 
> 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 Karaf runtime 4.2.16 release

[Matt Pavlovich]

+1 (non-binding)

> On Jun 10, 2022, at 8:11 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> As requested by some users, I submit Apache Karaf runtime 4.2.16
> release to your vote.
> 
> This release includes important updates, especially Pax URL 1.11.15.
> 
> NB: 4.2.16 should be the last release on the 4.2.x series. Again, we
> strongly encourage users to upgrade to 4.3.x or 4.4.x series.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351218
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1175/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.16/
> 
> Git tag:
> karaf-4.2.16
> 
> 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: The state of Pax Web

[Matt Pavlovich]

Hi Grzegorz-

Great work on this refactor, it was quite an undertaking!  Saying “much 
appreciated” seems like not enough =).

We have a JMeter test suite that we’ll run against Karaf + Pax Web v8.0.3 and 
report back in the few couple weeks for functionality and performance —covers 
REST and Web app servlet functionality.

Thank you,
Matt Pavlovich

From: op...@googlegroups.com  on behalf of Grzegorz 
Grzybek 
Date: Friday, April 29, 2022 at 4:36 AM
To: OPS4J , Karaf Dev 
Subject: The state of Pax Web
Hello

I'm planning to release Pax Web 8.0.3 with 6 issues fixed, including:

  *   Keycloak integration tweaks (see 
https://issues.redhat.com/browse/KEYCLOAK-19939)
  *   refined session management (session per Osgi Context with single 
JSESSIONID cookie per Servlet Context)
  *   two deadlocks fixes (Aries CDI)
  *   gzip encoding configuration and Jetty RewriteHandler support
With the above fixes, I think my long term plan to refactor Pax Web ends. It 
doesn't mean I quit, it simply means I don't plan anything new to add to Pax 
Web if there's no request to do so.

IMO, the compliance with chapters 102 (Http Service), 128 (Web Applications) 
and 140 (Whiteboard Service) of OSGi CMPN specification (R7, but should be the 
same for R8) is sufficiently complete. I didn't run the TCKs, because I didn't 
have much time to understand how to run it in proper way ;)

There's one obvious violation of Whiteboard specification wrt to context 
handling. See 140.2 The Servlet 
Context<https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext>[1]:

For example, if two ServletContextHelper services are registered as follows

osgi.http.whiteboard.context.path = /foo
osgi.http.whiteboard.context.path = /foo/bar

Then a request for http://localhost/foo/bar/someServlet is looked up in the 
following order:

  1.  /foo/bar context looking for a pattern to match /someServlet
  2.  /foo context looking for a pattern to match /bar/someServlet
According to JavaServlet specification, context selection happens first and 
further resolution of servlets is performed within the found context. The above 
Whiteboard requirement mandates searching for servlets in other contexts. I've 
consciously NOT implemented the Whiteboard behavior, sticking to JavaServlet 
recommendation.

Anyway - I hope Pax Web 8 is stable and fast enough to be used in production. 
There are much more tests than we had in Pax Web 7 and I've added complex WAR 
scenarios involving CDI, JSF and complex ServletContainerInitializer scenarios, 
including web-fragment.xml integration tests.

I'll of course be releasing new versions if there's new Jetty, Tomcat or 
Undertow release - in Pax Web 8 we no longer require TIPI releases for Tomcat.

If you see any problems or have nice feature requests, please create a GitHub 
issue at usual place<https://github.com/ops4j/org.ops4j.pax.web/issues>[2].

kind regards
Grzegorz Grzybek
===
[1]: 
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext
[2]: https://github.com/ops4j/org.ops4j.pax.web/issues
--
--
--
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
ops4j+unsubscr...@googlegroups.com<mailto:ops4j+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com<https://groups.google.com/d/msgid/ops4j/CAAdXmhobbxcXUFnNQ_AiK-b04MCQR_QAXdMRG47MbmKKakNjpg%40mail.gmail.com?utm_medium=email_source=footer>.

Re: [VOTE] Apache Karaf runtime 4.3.7 release

[Matt Pavlovich]

+1 (non-binding)

Downloaded, started and installed a few bundles
Installed ActiveMQ 5.17.0 broker and verified

Thanks JB!
Matt Pavlovich

> On Apr 19, 2022, at 8:42 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Karaf runtime 4.3.7 to your vote.
> This release is a maintenance release on the 4.3.x series, bringing
> dependency updates and fixes.
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351181
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1174/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.7/
> 
> Git tag:
> karaf-4.3.7
> 
> 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 Karaf runtime 4.4.0 release

[Matt Pavlovich]

Excited about getting going w/ Karaf 4.4.x and Pax Web 8!

+1 (non-binding)

> On Apr 19, 2022, at 1:24 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I submit Apache Karaf runtime 4.4.0 release to your vote.
> This release is a new milestone, starting the 4.4.x series.
> 
> This release includes:
> - OSGi R8 support
> - Pax Web 8.x upgrade
> - Pax Logging 2.1.x upgrade
> - and much much more !
> 
> You can take a look on the Release Notes for details:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349243
> 
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1173/
> 
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.4.0/
> 
> Git tag:
> karaf-4.4.0
> 
> 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: Apache Karaf board report for March 22

[Matt Pavlovich]

+1 looks good.

I see you have the note about all CVE’s are clear. Maybe add a specific line 
item to mention log4shell related issues have been addressed? (Log2j, reload4j, 
etc)

Matt Pavlovich

> On Mar 1, 2022, at 4:43 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi guys,
> 
> I prepared the board report for this month:
> 
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
> 
> Can you please take a look ?
> I would like to send the report to board asap.
> 
> Thanks !
> Regards
> JB

Re: [PROPOSAL] Apache Karaf 4.4.0 release

[Matt Pavlovich]

+1 for v4.4.x and to have latest pax web

> On Feb 3, 2022, at 2:45 PM, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> I will ping you tomorrow about Pax Web 8.0.1 and will help on some issues.
> 
> +1 to include Pax Web 8.0.1 in Karaf 4.4.0.
> 
> Regards
> JB
> 
> On 03/02/2022 18:07, Grzegorz Grzybek wrote:
>> Hello
>> Pax Web 8.0.1 is almost ready (20 issues closed[1]) and I wanted to fix one
>> more thing - "Unify handling of TRACE + OPTIONS methods across
>> runtimes"[2], but this can wait.
>> You can check pax-web's todo.txt[3].
>> The biggest addition to 8.0.1 is a set of Karaf commands I wrote a blog
>> about[4], where you can see some nice additions to Karaf web commands - and
>> also I wanted (at least to check) to move the commands from Karaf (as they
>> rely on Pax Web SPI anyway) to Pax Web itself - I hope with good result.
>> I'd definitely like to include Pax Web 8.0.1 starting with first Karaf
>> 4.4.0 release - what do you think?
>> I was super busy (still am) with log4j CVEs, that's why Pax Web 8.0.1 is
>> not yet ready ;(
>> kind regards
>> Grzegorz Grzybek
>> ===
>> [1]: https://github.com/ops4j/org.ops4j.pax.web/milestone/201?closed=1
>> [2]: https://github.com/ops4j/org.ops4j.pax.web/issues/1664
>> [3]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
>> [4]:
>> https://ggrzybek.blogspot.com/2021/11/pax-web-8-whiteboard-services-and-karaf.html
>> czw., 3 lut 2022 o 17:24 Jean-Baptiste Onofré  napisał(a):
>>> Hi guys,
>>> 
>>> I would like to release Apache Karaf 4.4.0 (currently main branch).
>>> 
>>> I'm doing a pass on Jira right now. I would like to submit this release
>>> to vote probably during the weekend.
>>> 
>>> No objection ?
>>> 
>>> Regards
>>> JB
>>> 

Re: [VOTE] Apache Karaf runtime 4.2.15 release

[Matt Pavlovich]

+1 installed various features— CXF 3.3.9, war, jetty, ActiveMQ 5.16.3 and 
verified things looked good

> On Jan 11, 2022, at 2:59 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> I submit Apache Karaf 4.2.15 to your vote.
> 
> This version includes:
> - upgrade to Pax Logging 1.11.13 upgrading to log4j 2.17.1 (fixing 
> CVE-2021-44832)
> - upgrade to Apache Felix FileInstall 3.7.4 fixing deployment issue
> - and other improvements/fixes!
> 
> Please take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351124
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1171/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.15/
> 
> Git tag:
> karaf-4.2.15
> 
> 
> 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
> 

[PROPOSAL] Change log4j2 default config to xml (or json)

[Matt Pavlovich]

I’ve created a proposal JIRA KARAF-7307 
(https://issues.apache.org/jira/browse/KARAF-7307 
) to track any specifics.

As the subject mentions— I think it would be beneficial to users to change the 
default configuration for log4j2 to XML (or maybe JSON). 

Notes:

1. Documentation for the properties format is fragmented and incomplete— 
especially for advanced features such as routing, etc
2. XML format is the more natural format for log4j2
3. Allow for developers targeting karaf runtime to use the same log4j2.xml 
config file in their dev projects that is used in karaf runtime (using a 
org.ops4j.pax.logging.cfg requires developers to add add’l configuration to 
their code projects)

Thoughts?

Thanks,
Matt

Re: [VOTE] Apache Karaf runtime 4.2.14 release

[Matt Pavlovich]

+1 (non-binding)

> On Dec 20, 2021, at 4:48 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> I submit Apache Karaf 4.2.14 to your vote.
> 
> This version upgrades to Pax Logging 1.11.12 with:
> - logback 1.2.9 fixing CVE-2021-42550
> - log4j 2.16.0 fixing CVE-2021-45105
> 
> Please take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351061
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1168/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.14/
> 
> Git tag:
> karaf-4.2.14
> 
> 
> 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 Karaf runtime 4.3.5 release

[Matt Pavlovich]

+1 (non-binding)

> On Dec 19, 2021, at 3:33 PM, Jean-Baptiste Onofré  wrote:
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.5 to your vote.
> This release includes Pax Logging 2.0.13 update:
> - with logback 1.2.9 upgrade, fixing CVE-2021-42550
> - with log4j 2.17.0 upgrade, fixing CVE-2021-45105
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1167/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.5/
> 
> Git tag:
> karaf-4.3.5
> 
> 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: Logback CVE-2021-42550

[Matt Pavlovich]

PR created for pax-logging against main: 
https://github.com/ops4j/org.ops4j.pax.logging/pull/425 
<https://github.com/ops4j/org.ops4j.pax.logging/pull/425>


> On Dec 17, 2021, at 9:23 AM, Matt Pavlovich  wrote:
> 
> I summarized notes on the Logback CVE-2021-42550 . While significantly less 
> critical, we probably need to consider another round of releases to address 
> and bring in logback 1.2.9.
> 
> notes here: https://issues.apache.org/jira/browse/KARAF-7299 
> <https://issues.apache.org/jira/browse/KARAF-7299>
> 
> Thoughts?

Logback CVE-2021-42550

[Matt Pavlovich]

I summarized notes on the Logback CVE-2021-42550 . While significantly less 
critical, we probably need to consider another round of releases to address and 
bring in logback 1.2.9.

notes here: https://issues.apache.org/jira/browse/KARAF-7299 


Thoughts?

Re: [VOTE] Apache Karaf runtime 4.2.13 release

[Matt Pavlovich]

+1 (non-binding)

> On Dec 16, 2021, at 8:02 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi all,
> 
> I submit Apache Karaf 4.2.13 to your vote.
> 
> This version includes 8 fixes and improvements. Especially, it includes Pax 
> Logging 1.11.11 update, upgrading to log4j 2.16.0 fixing CVE-2021-44228 and 
> CVE-2021-45046.
> 
> Please take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350548
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1166/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.13/
> 
> Git tag:
> karaf-4.2.13
> 
> 
> 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 Karaf runtime 4.3.4 release (take #3)

[Matt Pavlovich]

+1 (non-binding)

> On Dec 14, 2021, at 10:43 PM, JB Onofré  wrote:
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.4 to your vote (take #3). 
> 
> This release includes dependency upgrades, fixes, and improvements, 
> especially:
> 
> - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing important 
> security issue (CVE-2021-44228) and fixing JNDI issue
> - align dependencies versions between Karaf and Pax *
> - fix missing system export packages
> - fix on Karaf features json support
> - fix features autoRefresh configuration handling
> - fix on sshd session handling
> - update to sshd 2.8.0
> - lot of pax * updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1165/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> 
> Git tag:
> karaf-4.3.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.
> 
> Regards
> JB
> 

Re: [VOTE] Apache Karaf runtime 4.3.4 release

[Matt Pavlovich]

+1 (non-binding)

[x] Verified sha512 sum 
[x] Started, added staging repo, installed a few features including ActiveMQ 
5.16.3
[x] Verified ssh acces

Thanks JB!

Matt Pavlovich

> On Dec 6, 2021, at 10:55 PM, Jean-Baptiste Onofré  wrote:
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.4 to your vote.
> 
> This release includes dependency upgrades, fixes, and improvements, 
> especially:
> 
> - align dependencies versions between Karaf and Pax *
> - fix missing system export packages
> - fix on Karaf features json support
> - fix features autoRefresh configuration handling
> - fix on sshd session handling
> - update to sshd 2.8.0
> - lot of pax * updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1162/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> 
> Git tag:
> karaf-4.3.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.
> 
> Regards
> JB

Re: Preparing Karaf runtime 4.3.4

[Matt Pavlovich]

Sounds good, JB. Thanks!

> On Oct 12, 2021, at 7:43 AM, JB Onofré  wrote:
> 
> Hi guys
> 
> I’m working on Felix FileInstall release fixing the first losing issue. I 
> will include couple of other important fixes. 
> 
> I would like to submit Karaf 4.3.4 to vote during the week end or early next 
> week. 
> 
> Thoughts ?
> 
> Regards 
> JB

Re: Main updated to 4.4.0-SNAPSHOT and karaf-4.3.x branch

[Matt Pavlovich]

+1  looking forward to all the pax-web 8 goodies =)

> On Sep 21, 2021, at 1:44 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi guys,
> 
> I have almost finished the main branch update with:
> 
> - OSGi R8 (Felix Framework 7.0.1)
> - remove of OSGi cmpn and use of single spec bundle now (recommended now)
> - update to Pax Web 8.0.0
> 
> You can take a look on the working branch here:
> 
> https://github.com/jbonofre/karaf/tree/K44
> 
> I’m running several builds now to verify all tests are OK, etc.
> 
> If there’s no objection, I would like to push:
> 
> - create karaf-4.3.x branch with the current main HEAD
> - update main branch with K44 branch
> 
> Thoughts ?
> 
> Thanks
> Regards
> JB

Re: [VOTE] Apache Karaf runtime 4.3.3 release

[Matt Pavlovich]

+1 

- Installed, started and ran smoke tests
- Verified JMX MP with authentication (after adding the jmxmp jar to lib/boot)

Thanks JB!

> On Sep 2, 2021, at 3:33 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.3 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - first round of the specs features repository. This repository use will 
> spread (in Karaf and third party projects) and we will improve it, but this 
> first round introduces the skeleton we need.
> - ssh fix new closing socket cleanly
> - memory leak fix on the blueprint state service
> - fix on JMX exception push back to the client
> - bunch of dependency updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350142
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1157/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.3/
> 
> Git tag:
> karaf-4.3.3
> 
> 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 Karaf runtime 4.3.3 release

[Matt Pavlovich]

Robert-

Install the pax-web feature. It installs 9.4.43.v20210629:

75 │ Active   │  30 │ 9.4.43.v20210629   │ Jetty :: Server Core

The release notes show multiple Jetty versions, b/c jetty is releasing so fast 
there are multiple merges to upgrade jetty.

-Matt Pavlovich

> On Sep 2, 2021, at 11:44 AM, Robert Varga  wrote:
> 
> On 02/09/2021 10:33, Jean-Baptiste Onofré wrote:
>> Hi everyone,
> 
> Hello JB, everyone,
> 
>> I submit Apache Karaf runtime 4.3.3 to your vote.
>> 
>> This release includes bunch of dependency upgrades, fixes, and
>> improvements, especially:
>> 
>> - first round of the specs features repository. This repository use will
>> spread (in Karaf and third party projects) and we will improve it, but
>> this first round introduces the skeleton we need.
>> - ssh fix new closing socket cleanly
>> - memory leak fix on the blueprint state service
>> - fix on JMX exception push back to the client
>> - bunch of dependency updates
>> - and much more !
>> 
>> Please take a look on Release Notes for details !
>> 
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350142
>> 
>> 
>> Staging Maven Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-1157/
>> 
>> Staging Dist Repository:
>> https://dist.apache.org/repos/dist/dev/karaf/4.3.3/
>> 
>> Git tag:
>> karaf-4.3.3
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
> 
> A quick ODL smoke test passed, but I really would like a release with
> https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.43.v20210629,
> which is fixing a CVE.
> 
> Regards,
> Robert
> 

Re: Pax Web 8 - 2 more tasks before GA

[Matt Pavlovich]

Awesome! 

> On Aug 31, 2021, at 1:41 AM, Grzegorz Grzybek  wrote:
> 
> Hello
> 
> I'd like to present the state of Pax Web 8. I hope to release Pax Web
> 8.0.0.GA in mid-September.
> 
> I maintain a todo.txt[1] file where I present the issues I'd like to
> implement in given milestones.
> 
> The priority is to have R7 compliance, though without running the TCK[2],
> because I didn't have time to find out an easy way to actually run the TCK
> :) However I'm glad it's public now.
> 
> So summarizing, these R7 features were implemented recently:
> - Whiteboard preprocessors
> - RegEx filter mapping
> - Listener ordering according to ranking
> - Session per OsgiContextModel / OsgiServletContext (including proper
> javax.servlet.context.tempdir handling)
> - org.osgi.framework.ServiceObjects and proper service management (unget,
> prototype, singleton, bundle scopes)
> 
> Also I've implemented (or ensured the stability and consistency between
> Jetty, Tomcat and Undertow) for these:
> - Whiteboard WebSockets - they work both through WABs, Whiteboard and even
> WebContainer (HttpService)
> - Karaf integration tests - all tests work for all three runtimes. In Pax
> Web 7 the tests were running mostly on Jetty
> 
> The remaining *two* tasks are:
> - Mixing (in different order) WAB and Whiteboard contexts, so we can
> install a WAB and Whiteboard/HttpService alter it by registering for
> example Preprocessors
> - Whiteboard DTOs
> 
> kind regards
> Grzegorz Grzybek
> ===
> [1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
> [2]: https://github.com/osgi/osgi/

Re: State of Pax Web 8

[Matt Pavlovich]

Great work!  Thank you for all the effort you’ve put forth

On Jul 27, 2021, at 1:00 AM, Grzegorz Grzybek  wrote:


Hello

I'd just like to let you know that everything is under control and I didn't 
abandon the effort.

I've added a todo.txt file[1] to Pax Web's main branch (I didn't create 
separate GH issues for the tasks yet, as the scope may change, but at some 
point I'll translate the remaining items to GH issues).

So currently (and for some time already) I'm patiently making existing (Pax Web 
7) integration tests work with Pax Web 8.

The remaining integration tests cover (~10 tests):
 - HttpContext processing[2] (that's beyond CMPN specifications)
 - Whiteboard websockets (beyond CMPN specifications)
 - DTO tests
 - JAX-RS tests
 - Jetty/Tomcat/Undertow bundles tests
 - Jetty Handlers/Connectors OSGi services
 - VirtualHosts
 - CRLs
 - Jasypt

The already working (much faster due to better listeners!) tests include 
(almost 200 per container runtime):
 - external jetty.xml/tomcat-server.xml/undertow.xml configuration
 - HttpService/WebContainer tests (CMPN chapter 102)
 - JSP tests (custom tags, directives, includes, ...)
 - WABs (including SCIs, WebSockets, scanning and fragments)
 - JSF
 - Vaadin (new!)
 - Whiteboard (much improved, including SCR and standard services)

The most important aspects of chapters 102 (Http Service), 128 (Web 
Applications) and 140 (Whiteboard) are implemented including the most important 
one - 1:N mapping between web elements and _contexts_.

The other most important aspect, not related to CMPN specifications is the 
consistency of behavior between Jetty, Tomcat and Undertow containers - only 
ONE integration test has container specific behavior - the test checking HTTP 
response when POST size (container-specific configuration) is exceeded.

I roughly plan to release Pax Web 8 around mid of September.

kind regards
Grzegorz Grzybek
===
[1]: https://github.com/ops4j/org.ops4j.pax.web/blob/main/todo.txt
[2]: 
https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing

--
--
--
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CAAdXmhpg%3Dn_LizOosNYnt43MZh_01CNU%2BZ0zfPFF4a9JaaQOvQ%40mail.gmail.com.

Re: [VOTE] Apache Karaf runtime 4.3.2 release

[Matt Pavlovich]

+1 (non-binding)

Booted offline (no access to any mvn repo or network)
Enabled and tested JMXMP
Installed pax-jetty and scr features

Thanks,
Matt Pavlovich

> On May 9, 2021, at 12:18 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.2 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - upgrade to xbean 4.19 fixing JDK9 style war file
> - improvements on scheduler to support array configuration
> - fix on the JSON configuration to support array
> - improvement on JSON configuration to support R7 factory style
> - fix on the default pax-logging layout pattern
> - fix on the JMX RMI to use the configured host
> - fix race condition on SSHd startup
> - improvement on ShellTable
> - bunch of dependency updates for fixes and CVE
> - and much more !
> 
> *NOTE: for security reason, the default karaf user is commented in 
> etc/users.properties file. Please uncomment and change password if you want 
> to use it (for remote access like ssh, jmx, …).*
> 
> Please take a look on Release Notes for details !
> 
> Release Notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968>
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1156/ 
> <https://repository.apache.org/content/repositories/orgapachekaraf-1156/>
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.2/ 
> <https://dist.apache.org/repos/dist/dev/karaf/4.3.2/>
> 
> Git tag:
> karaf-4.3.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 Karaf runtime 4.3.1 release

[Matt Pavlovich]

+1 

- Downloaded and started unix dist release (no errors, no ‘online’ artifacts 
required)
- Added dist repo as a mvn repo
- Installed a few karaf features successfully (scr, etc)

Matt Pavlovich

> On Mar 29, 2021, at 8:14 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.1 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - java.* now exported by system packages (as expected since R7)
> - fixed on configuration with json format
> - jetty alias feature for backward compatibility
> - resolver parallelism default value fixed (to run on Kubernetes by default)
> - fix on SSH, log commands
> - improvement on the JMX layer (especially JMXMP)
> - env/prop interpolation support on the SSH client
> - add property to disable auto refresh in features service
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1155/ 
> <https://repository.apache.org/content/repositories/orgapachekaraf-1155/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.1/ 
> <https://dist.apache.org/repos/dist/dev/karaf/4.3.1/>
> 
> Git tag:
> karaf-4.3.1
> 
> 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 Karaf runtime 4.2.11 release

[Matt Pavlovich]

+1 (non-binding) 

- downloaded and started
- confirmed jmxmp w/ SASL Plain works
- confirmed ssh client

Thank you!
Matt Pavlovich

> On Mar 9, 2021, at 5:56 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.2.11 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - fix on SSH stream
> - fix on log:* commands
> - improvement on the JMX layer (especially JMXMP)
> - env/prop interpolation support on the SSH client
> - add property to disable auto refresh in features service
> - stronger JAAS encryption algorithms support
> - updated Spring versions
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348692
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1154/
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.11/
> 
> Git tag:
> karaf-4.2.11
> 
> 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: Board report March '21

[Matt Pavlovich]

Report looks good, thanks JB

> On Mar 5, 2021, at 1:54 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi guys,
> 
> I prepared the Karaf board report for this month:
> 
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports 
> 
> 
> Can you please take a look and let me know if I forgot something or if you 
> wanna make some updates ?
> 
> I would like to subit the report tomorrow (or tonight if there’s no changes 
> to perform).
> 
> Thanks,
> Regards
> JB

Re: OPS4J projects migration from OPS4J (cloud) Jira to GitHub issues

[Matt Pavlovich]

Thanks! 

> On Feb 25, 2021, at 3:41 AM, Grzegorz Grzybek  wrote:
> 
> Hello
> 
> I'm proud to announce that I've just finished the migration of OPS4J Jira
> issues to GitHub. We were discussing this ~half a year ago.
> 
> For each Jira issue I've migrated:
> - description and comments preserving html (converted to markdown),
> creation dates and authors (although not pointing to GH users, which is
> obvious)
> - Jira statuses, issue types, components and labels as GitHub labels
> - Jira fix versions as GitHub milestones with due date and closed status
> - Images
> - Attachments
> - Jira inter-project references as real GitHub references - cross project!
> (i.e., PAXWEB issues referencing PAXLOGGING issues are changed to working
> GitHub issue references between org.ops4j.pax.web to org.ops4j.pax.logging
> projects)
> 
> These projects were fully migrated:
> - TOOLS = ops4j/org.ops4j.tools
> - PAXJMS = ops4j/org.ops4j.pax.jms
> - PAXTRANSX = ops4j/org.ops4j.pax.transx
> - PAXJDBC = ops4j/org.ops4j.pax.jdbc
> - PAXTIPI = ops4j/org.ops4j.pax.tipi
> - PAXLOGGING = ops4j/org.ops4j.pax.logging
> - PAXEXAM = ops4j/org.ops4j.pax.exam2
> - PAXURL = ops4j/org.ops4j.pax.url
> - PAXTB = ops4j/org.ops4j.pax.tinybundles
> - BASE = ops4j/org.ops4j.base
> - PAXSB = ops4j/org.ops4j.pax.swissbox
> - PAXCDI = ops4j/org.ops4j.pax.cdi
> - PAXRUNNER = ops4j/org.ops4j.pax.runner
> - PAXSCANNER = ops4j/org.ops4j.pax.scanner
> - PAXCONSTRUCT = ops4j/org.ops4j.pax.construct
> - PAXSHIRO = ops4j/org.ops4j.pax.shiro
> - PAXWEB = ops4j/org.ops4j.pax.web
> 
> These GitHub projects have not their issues migrated from Jira to GitHub
> (usually they're inactive, or I simply didn't work on them before), though
> if you like, I may migrate them:
> - ops4j/exam-eclipse
> - ops4j/git-helpers
> - ops4j/ops4j.github.io
> - ops4j/ops4j-infra
> - ops4j/org.ops4j.dadl
> - ops4j/org.ops4j.mpjp
> - ops4j/org.ops4j.orient
> - ops4j/org.ops4j.pax.ace-maven-plugin
> - ops4j/org.ops4j.pax.carrot
> - ops4j/org.ops4j.pax.clapper
> - ops4j/org.ops4j.pax.confman
> - ops4j/org.ops4j.pax.exam1
> - ops4j/org.ops4j.pax.jmx
> - ops4j/org.ops4j.pax.jpa
> - ops4j/org.ops4j.pax.monitoradmin
> - ops4j/org.ops4j.pax.remote
> - ops4j/org.ops4j.pax.useradmin
> - ops4j/org.ops4j.pax.vaadin
> - ops4j/org.ops4j.pax.warp
> - ops4j/org.ops4j.pax.wicket
> - ops4j/org.ops4j.ramler
> - ops4j/org.ops4j.resources
> - ops4j/org.ops4j.xvisitor
> - ops4j/pax-repository
> - ops4j/peaberry
> 
> Kind regards and I invite you to contribute to OPS4J projects at GitHub ;)
> Grzegorz Grzybek

Re: Coming releases

[Matt Pavlovich]

Hey JB-

I would appreciate it if you’d get a minute to look at the JMXMP patch I 
provided (KARAF-6888) for inclusion in 4.2.11.

Thanks,
Matt

> On Feb 18, 2021, at 6:17 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi guys,
> 
> Quick update about the releases.
> 
> Aries Proxy and Blueprint releases are on vote. I should be able to close the 
> vote tomorrow.
> 
> Regarding PAX * releases, I did a new PAX URL release, and I’m on PAX Web now 
> (couple of issues to address). I will move forward on other PAX releases to 
> have all dependencies aligned.
> Greg is on some other PAX releases (Pax JDBC, …).
> 
> The first target is Karaf 4.2.11. I’m still targeting end of this week for 
> 4.2.11.
> 
> However, I’m postponing 4.3.1 for end of next week as I have some code change 
> on the way.
> 
> I will keep you posted.
> 
> Regards
> JB
> 
>> Le 13 févr. 2021 à 06:46, Jean-Baptiste Onofre  a écrit :
>> 
>> Hi guys,
>> 
>> Just to let you know that I’m working on dependencies releases (Aries Proxy, 
>> Aries Blueprint, PAX *, …) for Karaf 4.3.1 and 4.2.11.
>> 
>> I should have the votes submitted during the week end.
>> 
>> I will keep you posted.
>> 
>> Regards
>> JB
>> 
>>> Le 9 févr. 2021 à 05:55, Jean-Baptiste Onofre  a écrit :
>>> 
>>> Hi everyone,
>>> 
>>> Just a quick update about the release schedule:
>>> 
>>> - Apache Karaf Decanter 2.7.0 will be on vote tonight or tomorrow morning. 
>>> I’m preparing the latest PR (adding HDFS and S3 appenders).
>>> - Apache Karaf 4.3.1 and 4.2.11 should be on vote during next week end. I’m 
>>> doing the Jira triage right now.
>>> 
>>> I will keep you posted soon !
>>> 
>>> Thanks,
>>> Regards
>>> JB
>>> 
 Le 24 janv. 2021 à 17:44, Jean-Baptiste Onofre  a écrit 
 :
 
 Hi guys,
 
 I was busy with ActiveMQ 5.16.1 release.
 
 So, new update about coming releases and some teasing ;)
 
 1. I’m working on Decanter 2.7.0 release, I should be able to submit to 
 vote by the end of the week
 2. In the meantime, I’m preparing 4.3.1. Vote time target is in about 10 
 days
 
 About Karaf 5, I did good progress and I’m preparing a complete README.md 
 in the repo as base for discussion.
 I will sync with François this week but I don’t want to hold the 
 presentation for too long.
 
 Stay tuned !
 
 Regards
 JB
 
> Le 4 janv. 2021 à 06:08, Jean-Baptiste Onofre  a écrit 
> :
> 
> Hi guys,
> 
> Just to let you know that I have some delay for these releases, 
> especially 4.3.1. I did good progress but need some more days.
> 
> I hope to submit these releases to vote by the end of the week/beginning 
> of next week.
> 
> Regards
> JB
> 
>> Le 15 déc. 2020 à 14:40, Jean-Baptiste Onofre  a 
>> écrit :
>> 
>> Hi guys,
>> 
>> As you have probably seen, Apache Karaf Decanter 2.6.0 is in vote.
>> 
>> Now, I’m focus on Karaf 4.2.11 and 4.3.1 releases. I’m working on Pax 
>> Web releases now and then I will move forward on these releases 
>> preparation.
>> 
>> Stay tuned !
>> 
>> Regards
>> JB
> 
 
>>> 
>> 
> 

Re: Migration of OPS4J projects from Jira to Github

[Matt Pavlovich]

Grzegorz-

Nice work!  I think having the projects on GitHub will reduce efforts of the 
core contributors and will make it more accessible for new contributors as well.

-Matt Pavlovich

> On Feb 9, 2021, at 7:44 AM, Grzegorz Grzybek  wrote:
> 
> Hello
> 
> Thanks to Jürgen Schmid, I was able to set up "ops4j-issues" GitHub account
> with my current gmail address. I'll continue (if there are no objections)
> with the migration using this account.
> 
> kind regards
> Grzegorz Grzybek
> 
> wt., 9 lut 2021 o 12:51 Grzegorz Grzybek  napisał(a):
> 
>> Hello
>> 
>> I'd like to let you know that I've migrated these projects from OPS4J Jira
>> to Github:
>> - PAX TRANSX:
>> https://github.com/ops4j/org.ops4j.pax.transx/issues?q=is%3Aissue+is%3Aall
>> - PAX JMS:
>> https://github.com/ops4j/org.ops4j.pax.jms/issues?q=is%3Aissue+is%3Aall
>> - PAX JDBC:
>> https://github.com/ops4j/org.ops4j.pax.jdbc/issues?q=is%3Aissue+is%3Aall
>> 
>> These issues are taken into account:
>> - Jira components, statuses, resolutions, issue types and labels are
>> converted to Github labels
>> - Jira versions are converted to Github milestones
>> - The Jira fields that couldn't be mapped, are added below "---" line in
>> the body of the GitHub issue (like vote/watch count, affected versions,
>> fixed versions and attachments)
>> - Attachment links still point to Jira, but inline images are properly
>> displayed
>> - Jira issues received "famous last comments" pointing to relevant Github
>> issues
>> - Jira screen schemes were migrated to a scheme, were you can't create
>> new issue
>> - HTML is converted to GitHub flavored markdown
>> - all @xxx values (like @Service or @param) occurrences are properly
>> quoted in backticks to prevent unnecessary GitHub mentions
>> 
>> One remaining thing to do, which is almost ready is the conversion of Jira
>> issue references to GitHub issue references - but I want to do proper cross
>> references between Pax projects at GitHub - not only within single project.
>> 
>> I was inspired by
>> https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues
>> blog post which made me aware of few things.
>> 
>> *The biggest problem I see is that all the comments and all the issues are
>> created by me... Even if the creation dates are preserved, I simply can't
>> (and don't want to) get proper Jira - GitHub user mapping.*
>> 
>> In case of Spring migration, they created special GitHub user, but I can't
>> create another one using my gmail address. And I don't want to create weird
>> fake addresses.
>> 
>> You can check quite raw tools at
>> https://github.com/ops4j/org.ops4j.tools/blob/master/jira2github/data/readme.adoc
>> 
>> Before I proceed with "bigger" projects like Pax Logging or Pax Web, I'd
>> appreciate your feedback.
>> 
>> kind regards
>> Grzegorz Grzybek
>> 

Re: Coming releases

[Matt Pavlovich]

Thanks for the update JB! Let me know if there is anything I can assist with.

-Matt

> On Feb 8, 2021, at 10:55 PM, Jean-Baptiste Onofre  wrote:
> 
> Hi everyone,
> 
> Just a quick update about the release schedule:
> 
> - Apache Karaf Decanter 2.7.0 will be on vote tonight or tomorrow morning. 
> I’m preparing the latest PR (adding HDFS and S3 appenders).
> - Apache Karaf 4.3.1 and 4.2.11 should be on vote during next week end. I’m 
> doing the Jira triage right now.
> 
> I will keep you posted soon !
> 
> Thanks,
> Regards
> JB
> 
>> Le 24 janv. 2021 à 17:44, Jean-Baptiste Onofre  a écrit :
>> 
>> Hi guys,
>> 
>> I was busy with ActiveMQ 5.16.1 release.
>> 
>> So, new update about coming releases and some teasing ;)
>> 
>> 1. I’m working on Decanter 2.7.0 release, I should be able to submit to vote 
>> by the end of the week
>> 2. In the meantime, I’m preparing 4.3.1. Vote time target is in about 10 days
>> 
>> About Karaf 5, I did good progress and I’m preparing a complete README.md in 
>> the repo as base for discussion.
>> I will sync with François this week but I don’t want to hold the 
>> presentation for too long.
>> 
>> Stay tuned !
>> 
>> Regards
>> JB
>> 
>>> Le 4 janv. 2021 à 06:08, Jean-Baptiste Onofre  a écrit :
>>> 
>>> Hi guys,
>>> 
>>> Just to let you know that I have some delay for these releases, especially 
>>> 4.3.1. I did good progress but need some more days.
>>> 
>>> I hope to submit these releases to vote by the end of the week/beginning of 
>>> next week.
>>> 
>>> Regards
>>> JB
>>> 
 Le 15 déc. 2020 à 14:40, Jean-Baptiste Onofre  a écrit :
 
 Hi guys,
 
 As you have probably seen, Apache Karaf Decanter 2.6.0 is in vote.
 
 Now, I’m focus on Karaf 4.2.11 and 4.3.1 releases. I’m working on Pax Web 
 releases now and then I will move forward on these releases preparation.
 
 Stay tuned !
 
 Regards
 JB
>>> 
>> 
> 

Re: [X-Mas Gift] Panel discussion about Karaf 5

[Matt Pavlovich]

Yep!  This would be great, please include me on the invite.

> On Dec 15, 2020, at 11:32 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi guys,
> 
> Maybe some of you know that I started to work on Karaf 5.
> 
> I have something that it’s almost "usable".
> 
> Before sending a global discussion thread on the mailing list, I would like 
> to evaluate the ideas & big changes I did.
> 
> I would like to know if some of you would be interested by a panel discussion 
> call to introduce Karaf 5 (limited audience at first step).
> 
> The agenda of this call would be:
> 1. Pros/Cons about Karaf as it is today
> 2. Concepts in Karaf 5 (module, extension, …)
> 3. Building & running
> 4. Live demo
> 
> It could be recorded/webinar style (not necessary live call) for about 20 
> people at first step (both Karaf developers and users).
> The purpose is to evaluate the direction.
> 
> Thoughts ?
> Who would be interested ?
> 
> Thanks,
> Regards
> JB

Re: [PROPOSAL] Renaming terms

[Matt Pavlovich]

Hey JB-

Interesting point. I’ve generally used the locking to keep bundles from going 
active as a way of having the service not know anything about karaf. I suppose 
listening for the lock event could be used at the app level.

+1 Christian’s suggestion for ‘leader’ / ‘follower’.

-Matt 

> On Jul 28, 2020, at 2:55 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi,
> 
> I mean Runtime, and depending of the lock level you can have all bundles 
> active on both instances.
> 
> Standby could be fine if it’s documented, but IMHO, it’s not really a standby 
> (like ActiveMQ one for instance).
> 
> Regards
> JB
> 
>> Le 27 juil. 2020 à 20:46, Matt Pavlovich  a écrit :
>> 
>> JB-
>> 
>> Are you referring to ‘Karaf Cave’ or ‘Karaf Runtime’?
>> 
>> I think with Karaf Runtime locking, the warm boot tends to be to not have 
>> all bundles active, for things that need to be singletons, such as scheduled 
>> jobs and pollers. The Karaf Runtime is running enough to be monitored, but 
>> generally not running any active workload. This is what I was referring to 
>> as ’standby’.
>> 
>> I think ‘primary’ and ‘replica’ work great for replication use cases.
>> 
>> -Matt
>> 
>>> On Jul 27, 2020, at 12:51 PM, Jean-Baptiste Onofre  
>>> wrote:
>>> 
>>> No, I don’t think it’s accurate to Karaf.
>>> 
>>> Standby means that the instance is not "active", but actually, in the case 
>>> of Karaf, it’s active and replicate the "master/active".
>>> 
>>> That’s why I proposed primary/secondary. We can also use active/replica if 
>>> you think it’s more accurate.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 27 juil. 2020 à 18:26, Matt Pavlovich  a écrit :
>>>> 
>>>> My $0.02, the ‘primary’ ’secondary’ numeric-style terms can be misleading, 
>>>> since you can have multiple ’slave’ nodes and lock recovery is 
>>>> non-deterministic. So the ’secondary’ node doesn’t mean it is ’second’ in 
>>>> line to take over.
>>>> 
>>>> Thoughts on aligning with the proposed terms same as ActiveMQ?
>>>> 
>>>> master ->  ‘active’
>>>> slave -> ’standby'
>>>> 
>>>> -Matt Pavlovich
>>>> 
>>>>> On Jul 27, 2020, at 1:21 AM, Jean-Baptiste Onofre  
>>>>> wrote:
>>>>> 
>>>>> Hi guys,
>>>>> 
>>>>> I would like to propose new wording in some Karaf designs:
>>>>> 
>>>>> - In Karaf runtime, I would like to rename master/slave to 
>>>>> primary/secondary
>>>>> - in Cellar, I would like to rename blacklist/whitelist to allowlist and 
>>>>> deny list
>>>>> 
>>>>> Thoughts ?
>>>>> 
>>>>> Regards
>>>>> JB
>>>> 
>>> 
>> 
> 

Re: [PROPOSAL] Renaming terms

[Matt Pavlovich]

JB-

Are you referring to ‘Karaf Cave’ or ‘Karaf Runtime’?

I think with Karaf Runtime locking, the warm boot tends to be to not have all 
bundles active, for things that need to be singletons, such as scheduled jobs 
and pollers. The Karaf Runtime is running enough to be monitored, but generally 
not running any active workload. This is what I was referring to as ’standby’.

I think ‘primary’ and ‘replica’ work great for replication use cases.

-Matt

> On Jul 27, 2020, at 12:51 PM, Jean-Baptiste Onofre  wrote:
> 
> No, I don’t think it’s accurate to Karaf.
> 
> Standby means that the instance is not "active", but actually, in the case of 
> Karaf, it’s active and replicate the "master/active".
> 
> That’s why I proposed primary/secondary. We can also use active/replica if 
> you think it’s more accurate.
> 
> Regards
> JB
> 
>> Le 27 juil. 2020 à 18:26, Matt Pavlovich  a écrit :
>> 
>> My $0.02, the ‘primary’ ’secondary’ numeric-style terms can be misleading, 
>> since you can have multiple ’slave’ nodes and lock recovery is 
>> non-deterministic. So the ’secondary’ node doesn’t mean it is ’second’ in 
>> line to take over.
>> 
>> Thoughts on aligning with the proposed terms same as ActiveMQ?
>> 
>> master ->  ‘active’
>> slave -> ’standby'
>> 
>> -Matt Pavlovich
>> 
>>> On Jul 27, 2020, at 1:21 AM, Jean-Baptiste Onofre  wrote:
>>> 
>>> Hi guys,
>>> 
>>> I would like to propose new wording in some Karaf designs:
>>> 
>>> - In Karaf runtime, I would like to rename master/slave to primary/secondary
>>> - in Cellar, I would like to rename blacklist/whitelist to allowlist and 
>>> deny list
>>> 
>>> Thoughts ?
>>> 
>>> Regards
>>> JB
>> 
> 

Re: [PROPOSAL] Renaming terms

[Matt Pavlovich]

My $0.02, the ‘primary’ ’secondary’ numeric-style terms can be misleading, 
since you can have multiple ’slave’ nodes and lock recovery is 
non-deterministic. So the ’secondary’ node doesn’t mean it is ’second’ in line 
to take over.

Thoughts on aligning with the proposed terms same as ActiveMQ?

master ->  ‘active’
slave -> ’standby'

-Matt Pavlovich

> On Jul 27, 2020, at 1:21 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi guys,
> 
> I would like to propose new wording in some Karaf designs:
> 
> - In Karaf runtime, I would like to rename master/slave to primary/secondary
> - in Cellar, I would like to rename blacklist/whitelist to allowlist and deny 
> list
> 
> Thoughts ?
> 
> Regards
> JB

Re: [HEADS UP] Three new features proposal this week

[Matt Pavlovich]

Right, I meant to suggest defining a standard convention is useful to provide 
clarity.

> On May 7, 2020, at 11:09 AM, Steinar Bang  wrote:
> 
>>>>>> Matt Pavlovich :
> 
>> Have you looked at using local-repo?
> 
> I don't think it matters too much where things are loaded from at karaf
> boot, as much as what's put into that repo.
> 
> I.e. I would like to specify a feature I want to add to the start set,
> and then resolve everything needed to that feature (but nothing else, to
> keep the image size down), and add it to an internal repo in the docker
> image.
> 

Re: [HEADS UP] Three new features proposal this week

[Matt Pavlovich]

Yes, I was referring to the tooling. Specifically, does it make sense for 
tooling to use local-repo for application coded artifacts, vs system/ which 
seems to be for karaf itself.

> On May 6, 2020, at 10:40 PM, Jean-Baptiste Onofre  wrote:
> 
> Hi Matt,
> 
> Local repo is not a problem, but it doesn’t help a lot for resolution.
> 
> The resolution state at build time would simplify and speed up a lot the 
> bootstrapping.
> 
> Regards
> JB
> 
>> Le 6 mai 2020 à 20:05, Matt Pavlovich  a écrit :
>> 
>> 
>> 
>>> On May 6, 2020, at 10:45 AM, Steinar Bang  wrote:
>>> 
>>>> 2. Improve build tool (part of devx) for build time resolution
>>> 
>>> Hm... can this be used to fill up the system directory when creating a
>>> docker image on top of the official image?
>>> 
>> 
>> Have you looked at using local-repo?  We’ve had good success copying 
>> artifacts into the local-repo to ship an all-in-one, vs applying on top of 
>> system. Not married to one way or the other, but might be good to talk it 
>> through as far as the default tooling behavior and if there is a suggested 
>> convention on what should be in “system/“ vs “local-repo/“.
>> 
>> etc/org.ops4j.pax.url.mvn.cfg:
>> ...
>>   file:${karaf.home}/local-repo@snapshots@id=karaf.local-repo
>> 
>> 
> 

Re: [HEADS UP] Three new features proposal this week

[Matt Pavlovich]

> On May 6, 2020, at 10:45 AM, Steinar Bang  wrote:
> 
>> 2. Improve build tool (part of devx) for build time resolution
> 
> Hm... can this be used to fill up the system directory when creating a
> docker image on top of the official image?
> 

Have you looked at using local-repo?  We’ve had good success copying artifacts 
into the local-repo to ship an all-in-one, vs applying on top of system. Not 
married to one way or the other, but might be good to talk it through as far as 
the default tooling behavior and if there is a suggested convention on what 
should be in “system/“ vs “local-repo/“.

etc/org.ops4j.pax.url.mvn.cfg:
...
file:${karaf.home}/local-repo@snapshots@id=karaf.local-repo

Re: [HEADS UP] Three new features proposal this week

[Matt Pavlovich]

Long time user, non-committer chiming in.

1. +1. I’ve got some dev cycles to pitch in on this.

2. Suggest: Add a jsonType field to fully qualify the version of the feature 
file in JSON, since last I checked JSON doesn’t have a standardized namespace 
mechanism (ie. jsonType=“org.apache.karaf.features.v130.Features”). I’ve got 
some dev cycles to pitch in on this.

3. I don’t see an issue w/ having a non-default simple resolver as a 
configurable option

4. +1

5. Override with an env or sys property, or both? I think with the advent of 
containers the preferred resolution order has been flipped from cfg -> sys -> 
env vs env -> sys -> cfg previously. Perhaps an option to set a resolution 
order would be a way to capture all scenarios?

Thanks,
-Matt

> On May 4, 2020, at 12:31 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi guys,
> 
> I’m working on several improvements this week where I would need your review 
> and thoughts.
> 
> 1. JAXB remove
> We have a JAXB dependency in Karaf core just for the features service. As the 
> features model is "static" (we don’t change features model at runtime), I 
> would like to remove the JAXB dependency and generate the parser at build 
> time with SXC for instance. I will add a build profile to generate the parse 
> when the model change (it doesn’t happen very often to be honest).
> The purpose is to provide a even lighter Karaf runtime. About that, I would 
> like also to promote a bit the minimal distribution and do it even lighter. I 
> propose to push minimal as official docker image, allowing people to start 
> from minimal to create their own docker image (we will provide improved tools 
> about that).
> 
> 2. Features JSON
> As an alternative to features XML repo, I’ve working on features JSON repo. 
> It’s similar in term of content, but you will now have the choice between XML 
> and JSON.
> 
> 3. Simple resolver
> Several users complained about the features resolver: it might be seen as 
> complex (you have to understand req/caps, etc), it’s not always predictable 
> (due to refresh with optional import, etc). I would like to propose an 
> alternative: the simple resolver. It’s pretty simple: it just takes what you 
> have in features definition. It’s an optional resolver, meaning that the 
> default will be still the regular resolver. The simple resolver can be 
> enabled in etc/org.apache.karaf.features.cfg.
> 
> 4. Spec features and cleanup
> As already discussed, I would like to remove the lib/jdk9plus folder and all 
> spec packages from etc/jre.properties to use spec features instead.
> That will give us more control in the specs version and support of JDK.
> 
> 5. ConfigAdmin persistence repository overwrite with env var
> It will be possible now to overwrite configuration with env var. For 
> instance, if you have a property foo in my.config pid, you will be able to 
> overwrite this property with -Dmy.config:foo=bar at bootstrap.
> 
> If you agree, I would like to include those improvements in coming release 
> (4.2.9 and 4.3.0.RC2).
> 
> Regards
> JB
> 
> 

Re: [RESULT][VOTE] Apache Karaf Runtime 4.2.8 release (take #2)

[Matt Pavlovich]

Thank you everyone!

> On Jan 23, 2020, at 2:05 AM, Jean-Baptiste Onofré  wrote:
> 
> Hi everyone,
> 
> this vote passed with the following result:
> 
> +1 (binding): Grzegorz Grzybek, François Papon, Freeman Fang, Jamie
> Goodyear, Achim Nierbeck, JB Onofré
> +1 (non binding): Romain Manni-Bucau, Fabian Lange, Markus Rathgeb,
> Roedl Lukas
> 
> I'm promoting the artifacts on Maven Central and dist.a.o. I'm also
> updating Jira and preparing the announcement on mailing lists and website.
> 
> Thanks all for your vote.
> 
> Now, my target (highest priority) is 4.3.0.RC1 ;)
> 
> Regards
> JB
> 
> On 19/01/2020 22:49, Jean-Baptiste Onofré wrote:
>> Hi all,
>> 
>> I submit Apache Karaf runtime 4.2.8 to your vote. This is a
>> maintenance release on the 4.2.x series, bringing updates, improvements
>> and fixes.
>> 
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100
>> 
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-1138
>> 
>> Staging Dist:
>> https://dist.apache.org/repos/dist/dev/karaf/4.2.8/
>> 
>> Git Tag:
>> karaf-4.2.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
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [DISCUSS] Gogo commands completion data

[Matt Pavlovich]

+1 etc/scripts

+1 being able to use  element


On 10/12/16 10:57 AM, Guillaume Nodet wrote:

I'm working on trying to nicely integrate gogo commands.
The new gogo-jline bundle has a very nice way to allow external
configuration for command completion. For example, one need to execute the
script at https://gist.github.com/gnodet/18de68d57fc959efb7f9e4766415ff5e
to add full completion to the Karaf shell once you have the scr bundle
installed (it always provides gogo commands).  Other examples are available
at
https://github.com/apache/felix/blob/trunk/gogo/jline/src/main/resources/gosh_profile

The question is : how to provide such a script.
One possibility would be to have a dedicated folder such as etc/scripts/
where all scripts would be loaded when a session is started. We could then
reference those files in features so that they are copied when features are
installed.
This would allow leveraging the  feature xml element.

Do you guys have better ideas ?

Seeking karma

[Matt Pavlovich]

Hello-

I'd like to work towards becoming a Karaf committer. I've been active in the 
community and on the implementation side of things for many years, and would 
like to take a bigger role on the dev, documentation and user support side of 
things.

My CLA is on file, I'm requesting Wiki and Jira karma (just to assign myself 
tickets).

Thanks!
Matt Pavlovich