Re: [PROPOSAL] Apache Karaf 4.5.x with Java 17+

[luke]

Its good to lift bar for new release line. We still have option to release 
4.4.x for these who will be stuck with Java 11 for any reason.

Cheers,
Łukasz

On 7.04.2024 18:50, Robert Varga  wrote:

On 07/04/2024 08.47, Jean-Baptiste Onofré wrote:
> Hi folks,
>
> I'm preparing the Karaf 4.4.6 release using Java 11+. It will provide
> Spring 6.x features requiring Java 17. As Karaf 4.4.x still uses Camel
> 3.2.x (Java 11+), it will be up to the user to choose Java 11 (with
> Camel working) or Java 17+ (with Spring working).
>
> With the effort ongoing for camel-karaf 4.x (with Java 17+ support), I
> propose to target Karaf 4.5.x to Java 17+ and remove support of Java
> 11.
> If it's OK for you, I will update Jenkinsfile to use Java 17 by
> default on main (instead of Java 11 today), and update the resources
> to target Java 17.

It is a huge jump in terms of requirements, but certainly fine by me! :)

Regards,
Robert

Apache Karaf hackathon, 4-5 May, Brussels

[luke]

Dear Karaf user and dev subscribers,
I would like to share information about free Apache Karaf hackathon which will 
take a place in Brussels within few days (4-5 May 2019). If you are interested 
in Apache Karaf or other Apache projects which will be presented during these 
two days please register using below form. [1]
We also encourage you to promote Apache Karaf presence via media social 
channels such twitter [2] and linkedin [3].

Thanks to Apache marketing team and organisers I will be able to personally 
participate in this event. I will present Apache Karaf (up to 60 minutes) and 
surrounding ecosystem. As part of my presentation you will learn present state 
of Karaf, you will also see it compared to present trends in software industry. 
I will be more than happy to help you to help you with your projects and boost 
its adoption to Apache Karaf as runtime.

To give you a brief idea of what whole event is about. There is a EU-FOSSA [4] 
program was launched by European Union institutions with primary aim to 
organise bug bounty for selected Apache projects (Tomcat & Kafka). Over time a 
scope of program was extended to other Apache communities.
If you are security researcher you might win a nice reward for finding an 
vulnerability. For details please follow last link. [4] Remember, its not only 
about bug bounties, but about moving Open Source projects forward.

Your sincerely,
Łukasz Dywicki
—
Apache Karaf commiter
Twitter: @ldywicki
http://connectorio.com | http://code-house.org

[1] https://bma-events.typeform.com/to/UfDIeW 

[2] https://twitter.com/TheASF/status/1123093398787899394 

[3] https://www.linkedin.com/feed/update/urn:li:activity:6528859694201651201 

[4] https://joinup.ec.europa.eu/collection/eu-fossa-2/about 



https://twitter.com/TheASF/status/1123093398787899394
https://twitter.com/TheASF/status/1123093398787899394


signature.asc
Description: Message signed with OpenPGP

Mojos and pax-url configurations

[luke]

Hey,
I’ve run into trap which I unintentionally left as part of fixes I made a while 
ago. I found that Paul (@kemitix) solved problem by reverting back change in 
master. There is no issue registered for that (couldn’t find any so far) - so I 
created a new one: KARAF-5994 which I will use to back port his change to 
4.0.10 and 4.1.6 as master is fine. 

Anyhow, we few ways how pax-url is being used and I think we lost a bit track 
of all places where it is used leading to situations where one patch breaks 
another place.

Cheers,
Lukasz

Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

[luke]

Just as an side note - there is an inconsistency in naming of features and 
their location in repository which doesn’t make whole thing easier.

Given example of static assemblies we have two URIs: 
org.apache.karaf.features/framework
org.apache.karaf.features/static
where first one contains "framework” feature but second delivers 
"static-framework”. Such small thing makes it harder to spot how whole thing 
works. I placed “framework-static” couple of times in my attempts and plugin 
didn’t protest.

If we could align these it would make users life a bit easier I guess.

Cheers,
Lukasz

> On 13 Sep 2018, at 14:18, Grzegorz Grzybek  wrote:
> 
> Hello
> 
> Thanks JBO for the idea. True - custom distro generation isn't that
> intuitive as it could be. Personally I missed the flexibility, not
> simplicity, that's why I added custom in
> "[KARAF-5468] Cleaning up AssemblyMojo, Profiles and profile Builder".
> 
> Without it, the implied value for "framework" property was "framework" or
> "static-framework" depending on whether you had dependency on
> mvn:org.apache.karaf.features/framework/VERSION/kar or
> mvn:org.apache.karaf.features/static/VERSION/kar in your POM. The
> discovered "framework" property was added as "startup feature" which was
> very confusing (mixing "framework" and "feature" concepts).
> 
> I can't tell much about improvements for
> karaf-maven-plugin:features-generate-descriptor, because I always preferred
> manual creation of feature XMLs.
> 
> However having dependency on existing karaf distro ("standard" apache-karaf
> or apache-karaf-minimal) is good idea! karaf-maven-plugin:assembly could
> search zip or tar.gz or tgz kind of dependencies (with "provided" or any
> other scope) and:
> - unpack it
> - check etc/profile.cfg
> 
> etc/profile.cfg is (since 4.2.0) nicely written as (official
> apache-karaf-minimal distro):
> 
> #
> # Profile generated by Karaf Assembly Builder
> #
> 
> # Parent profiles
> attribute.parents = generated-startup generated-boot generated-installed
> 
> # Attributes
> attribute.overlay = true
> 
> # Feature XML repositories
> repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
> mvn:org.apache.karaf.features/framework/4.2.0/xml/features
> repository.mvn\:org.apache.karaf.features/standard/4.2.0/xml/features =
> mvn:org.apache.karaf.features/standard/4.2.0/xml/features
> repository.mvn\:org.apache.karaf.features/spring/4.2.0/xml/features =
> mvn:org.apache.karaf.features/spring/4.2.0/xml/features
> 
> # Features
> feature.framework = framework
> feature.jaas = jaas
> feature.shell = shell
> feature.feature = feature
> feature.ssh = ssh
> feature.bundle = bundle
> feature.config = config
> feature.log = log
> 
> However, with complex distros it can look like this (my distro) - see all
> the blacklisted items and even special configuration options - these are
> all generated from pom.xml:
> 
> #
> # Profile generated by Karaf Assembly Builder
> #
> 
> # Parent profiles
> attribute.parents = generated-startup generated-boot generated-installed
> 
> # Attributes
> attribute.overlay = true
> 
> # Feature XML repositories
> repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
> mvn:org.apache.karaf.features/framework/4.2.0/xml/features
> ...
> # Features
> feature.framework = framework
> feature.patch-management = patch-management
> ...
> feature.pax-jms-config = pax-jms-config
> feature.pax-jms-pool-narayana = pax-jms-pool-narayana
> feature.pax-jms-pool-transx = pax-jms-pool-transx
> 
> # Bundles
> ...
> bundle.mvn\:org.bouncycastle/bcprov-jdk15on/1.60 =
> mvn:org.bouncycastle/bcprov-jdk15on/1.60
> bundle.mvn\:org.bouncycastle/bcpkix-jdk15on/1.60 =
> mvn:org.bouncycastle/bcpkix-jdk15on/1.60
> 
> # Configuration properties for etc/config.properties
> config.karaf.delay.console = true
> 
> # Blacklisted repositories
> blacklisted.repository.mvn\:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
> = mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
> ...
> 
> # Blacklisted features
> blacklisted.feature.httplite = httplite
> blacklisted.feature.jetty/[8,9) = jetty/[8,9)
> blacklisted.feature.pax-*jetty* = pax-*jetty*
> blacklisted.feature.cxf-*-jetty = cxf-*-jetty
> ...
> 
> # Blacklisted bundles
> blacklisted.bundle.mvn\:org.ops4j.pax.cdi/pax-cdi-jetty-weld =
> mvn:org.ops4j.pax.cdi/pax-cdi-jetty-weld
> 
> This etc/profile.cfg can be treated simply as it was added in
> karaf-maven-plugin:assembly configuration itself!
> 
> 
>
>path/to/profile.cfg
>
> 
> 
> best regards
> Grzegorz Grzybek
> 
> czw., 13 wrz 2018 o 13:51 Jean-Baptiste Onofré  napisał(a):
> 
>> Hi guys,
>> 
>> Recently, we received a lot of questions around how to create Karaf
>> custom distribution based on karaf-maven-plugin, and how to use the
>> static profile to create "standalone/static" distribution.
>> 
>> If the plugin works fine, it's not easy to understand some "details",
>> like the dependency scope impact, or providing

Re: 4.1.4 release in December

[luke]

Hey Jean,
Thanks for update on release schedule. There is 

There is KARAF-5533 which affected OpenHab in very nasty way. They patched kar 
deployer internally so it works for them. Issue is related to dropping KARs 
into deploy folder. I assigned myself to it - so I will verify their patch and 
commit after confirming it works.

Cheers,
Lukasz


> On 10 Dec 2017, at 06:19, Jean-Baptiste Onofré  wrote:
> 
> Hi Lukasz,
> 
> yes, 4.1.4 is already planned and I'm preparing it. I'm planning to submit 
> 4.1.4 on vote for Friday next week.
> 
> I'm starting the Jira triage now, and I'm already working on some 
> improvements and fixes.
> 
> Can you just double check on your side if all Jira you need are with the 
> correct fixed version ?
> 
> https://issues.apache.org/jira/projects/KARAF/versions/12341702
> 
> Regards
> JB
> 
> On 12/10/2017 12:03 AM, Łukasz Dywicki wrote:
>> Hey folks,
>> I wanted to check with you if there is any work planned to be done with 
>> 4.1.x branch this month, as I would like to push some fixes & flush them out.
>> These are needed for OpenHab community, which might not be as big as ODL 
>> but, it does run into troubles from time to time.
>> As I never handled release, despite of having such possibility, I could try 
>> to do it and offload „standard” team members handling this task.
>> Cheers,
>> Łukasz Dywicki
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: 4.1.4 release in December

[luke]

Hey Jean,
Yeah, I was committing this changes and obviously I missed a file which I had 
to bring back from 4.2.x test infra to 4.1.x. I was aware that this change is 
risky, however I didn’t get any Jenkins notification about build failure which 
made me think that everything went fine. It is my fault that I didn’t check CI 
build.

Thank you very much for taking care about that, and once more - sorry for 
breaking it.

Kind regards,
Lukasz


> On 10 Dec 2017, at 07:09, Jean-Baptiste Onofré  wrote:
> 
> Just fixed it.
> 
> Regards
> JB
> 
> On 12/10/2017 06:48 AM, Jean-Baptiste Onofré wrote:
>> By the way,
>> I saw that you merged/cherry-picked the addition of LDAPPubkeyLoginModule.
>> However, I guess you didn't test on Karaf 4.1.x branch and you broke the 
>> build:
>> https://builds.apache.org/view/K/view/Karaf/job/karaf-4.1.x/361/
>> [INFO] -
>> [ERROR] COMPILATION ERROR :
>> [INFO] -
>> [ERROR] 
>> /home/jenkins/jenkins-slave/workspace/karaf-4.1.x/jaas/modules/src/test/java/org/apache/karaf/jaas/modules/ldap/LDAPPubkeyLoginModuleTest.java:[26,44]
>>  cannot find symbol
>>   symbol:   class PrincipalHelper
>>   location: package org.apache.karaf.jaas.modules
>> I'm fixing it now.
>> Please, at least run a full build before pushing.
>> Thanks,
>> Regards
>> JB
>> On 12/10/2017 12:03 AM, Łukasz Dywicki wrote:
>>> Hey folks,
>>> I wanted to check with you if there is any work planned to be done with 
>>> 4.1.x branch this month, as I would like to push some fixes & flush them 
>>> out.
>>> These are needed for OpenHab community, which might not be as big as ODL 
>>> but, it does run into troubles from time to time.
>>> 
>>> As I never handled release, despite of having such possibility, I could try 
>>> to do it and offload „standard” team members handling this task.
>>> 
>>> Cheers,
>>> Łukasz Dywicki
>>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Migrate to gitbox

[luke]

+1

One remote less :-)


> On 02 Oct 2017, at 10:02, Guillaume Nodet  wrote:
> 
> Following a few discussions we had, I'm starting a vote.
> The overall idea is to migrate our git repositories to gitbox, which allows
> a deeper integration with github features.  The first one we should
> leverage is the ability to close, merge PRs directly from github.
> 
>  [ ] +1, migrate Karaf repositories to gitbox
>  [ ] -1, keep git-wip + github mirror
> 
> 
> -- 
> 
> Guillaume Nodet