Re: [VOTE] Apache Karaf OSGi runtime 4.4.6 release

[Robert Varga]

On 09/04/2024 15.33, Jean-Baptiste Onofré wrote:

Hi folks,

I submit Apache Karaf OSGi runtime 4.4.6 release to your vote.



[snip]


Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)


+1, thanks a ton!

Passes basic ODL checks with both Java 17 and 21.

Regards,
Robert


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Robert Varga]

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


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf OSGi runtime 4.4.5 release

[Robert Varga]

+1.

Thanks,
Robert

On 07/01/2024 19.02, Jean-Baptiste Onofré wrote:

Hi guys,

I submit Apache Karaf OSGi runtime 4.4.5 release to your vote.

This release is a maintenance release bringing fixes and dependency
updates, especially:
- isolate config shell commands in a dedicated bundle to avoid refresh
and race condition at startup
- better JDK21 support with new ASM version (9.6)
- upgrade to Jetty 9.4.53.v20231009 and Pax Web 8.0.24
- fix webconsole plugins loading
- upgrade to sshd 2.11.0 fixing ecdsa key support

You can take a look on the Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12353604

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1190/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/karaf/4.4.5/

Git tag:
karaf-4.4.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


OpenPGP_signature.asc
Description: OpenPGP digital signature

RE: [UPDATE] Karaf WebConsole has issues with Karaf 4.4.4

[Robert Varga]

Hey JB,Can you also look at including aries-proxy-1.1.14? It needs the usual 
ASM bump to not fail when run on Java 21.Thanks,Robert Sent from my Galaxy
 Original message From: Jean-Baptiste Onofré 
 Date: 10/1/23  07:33  (GMT+01:00) To: dev 
, user  Subject: [UPDATE] Karaf 
WebConsole has issues with Karaf 4.4.4 Hi guys,I created 
https://issues.apache.org/jira/browse/KARAF-7769Since the Felix WebConsole 
update, the Karaf WebConsole plugins(features, gogo, ...) don't load 
correctly.I'm fixing that and I will quickly submit Karaf 4.4.5 to vote.Sorry 
for the inconvenience;RegardsJB

Re: jre.properties vs. JEP220?

[Robert Varga]

On 27/09/2023 08.30, Jean-Baptiste Onofré wrote:

Hi

It makes sense to me (it’s something that I wanted to explore).
So definitely worth to investigate.


Cool. I think we can tuck this under 
https://issues.apache.org/jira/browse/KARAF-7765, if you are okay with that.


Regards,
Robert



Regards
JB

Le dim. 24 sept. 2023 à 21:45, Robert Varga  a écrit :


Hello everyone,

with karaf-4.5.0 requiring Java 11
(https://issues.apache.org/jira/browse/KARAF-7754), there are a number
of places where we can safely forget about how JVM < 9 did things, which
could lead to simplifications.

One of these is Karaf's jre.properties, which (as I understand it)
define the set of packages which are to be advertised by the OSGi
framework (bundle 0, or somesuch, sorry, I am quite rusty on the spec).

JEP 220 (https://openjdk.org/jeps/220), integrated in Java 9, exposes
the set of runtime-available packages as jrt:/packages/ (see
https://bugs.openjdk.org/browse/JDK-8066492).

This would mean we can figure out the set of packages at runtime, would
make jre.properties (and our adding a new jre-XY entry every 6 months),
superfluous.

There is one wrinkle, which is javax.transaction.xa, but, with my all of
no knowledge of J2EE, I think this a problem we need to deal with only
until we transition to the jakarta namespaces (karaf-5?)[0]

Does this effort sound reasonable, or am I missing something?

Thanks,
Robert

[0] I think it might make sense to list Karaf, and perhaps Pax Web,
somewhere searchable, like
https://jakarta.ee/blogs/javax-jakartaee-namespace-ecosystem-progress/ .





OpenPGP_signature
Description: OpenPGP digital signature

Re: Questions about KARAF-5680

[Robert Varga]

On 27/09/2023 08.32, Jean-Baptiste Onofré wrote:

Hi Robert


Hey JB,


You are right. Reason of this « xml workaround » is that the service loader
spec didn’t exist before OSGi r8.

So now that Karaf 4.5 is OSGi r8 we can revisit some impl we did.


Cool, I have filed https://issues.apache.org/jira/browse/KARAF-7768 to 
track this.


I'll try to circle back to it as I find some free cycles.

Thanks,
Robert



Regards
JB

Le dim. 24 sept. 2023 à 22:41, Robert Varga  a écrit :


Hello,

now that we are going for Java 11, we need to deal with JPMS and the
migration is showing some friction I have not seen in OpenDaylight.

OpenDaylight is a Karaf downstream, which requires Java 17 and is in a
shape I would expect it to Just Work(tm) sans Karaf.

One of such points of friction is karaf.git/specs/java.xml -- which is
overriding JVM classes.

As I understand it the point of this package override is to perform
resolution to OSGi registry in service of
https://issues.apache.org/jira/browse/KARAF-5680.

If my understanding is correct, everything we are overriding here could
be just resolved via an OSGi-service loader. For example
XMLInputFactory.newInstance() says, among JVM-defaults, this:

"Use the service-provider loading facility, defined by the ServiceLoader
class, to attempt to locate and load an implementation of the service
using the default loading mechanism: the service-provider loading
facility will use the current thread's context class loader to attempt
to load the service. If the context class loader is null, the system
class loader will be used."

As I see it, we can satisfy the requirements of KARAF-5680 by saying the
Karaf container always implements Service Loader Mediator Specification
(https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.loader.html).

In karaf.git terms, spifly is not a separate feature, but is always
included in Karaf.

I mean, with JPMS, ServiceLoader is the platform-acknowledged extension
mechanism, hence we should be integrating no matter what...

I this a sensible direction, or am I missing something?

Regards,
Robert





OpenPGP_signature
Description: OpenPGP digital signature

Re: The meaning of karaf-bom

[Robert Varga]

On 25/09/2023 23.14, Steven Huypens wrote:

Hi Robert,


Hello Stephen,


Seems like a fair point to me, I agree the Karaf BOM should only list Karaf
dependencies. It would be nice though to be able to 'use' the library
versions Karaf is using for third party dependencies, without having to
import karaf.git/pom.xml. Any ideas for that?


Please keep in mind that starting from Maven 4.0, a new specific BOM
packaging

has been introduced. I have not looked into it, but it might be worth
looking at before making any changes.


Thanks for the pointer. That piece of maven documentation seems to have 
vastly improved since I last read everything there was on "scope=import" :)


As I understand, the forward compatibility warning is regarding the 
layout and relaxes the "BOM must be a parent" model outlined in the 
documentation. The interplay goes toward 
https://www.youtube.com/watch?v=KDAmlNKZJto (the best I could find off 
the top my head) and there was some implication with the new POM XSD -- 
I saw a presentation somewhere, where a lot of ceremony was removed from 
a multi-module pom.xml, but I don't have that handy.


Regards,
Robert





OpenPGP_signature
Description: OpenPGP digital signature

Re: The meaning of karaf-bom

[Robert Varga]

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





OpenPGP_signature
Description: OpenPGP digital signature

The meaning of karaf-bom

[Robert Varga]

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


OpenPGP_signature
Description: OpenPGP digital signature

Questions about KARAF-5680

[Robert Varga]

Hello,

now that we are going for Java 11, we need to deal with JPMS and the 
migration is showing some friction I have not seen in OpenDaylight.


OpenDaylight is a Karaf downstream, which requires Java 17 and is in a 
shape I would expect it to Just Work(tm) sans Karaf.


One of such points of friction is karaf.git/specs/java.xml -- which is 
overriding JVM classes.


As I understand it the point of this package override is to perform 
resolution to OSGi registry in service of 
https://issues.apache.org/jira/browse/KARAF-5680.


If my understanding is correct, everything we are overriding here could 
be just resolved via an OSGi-service loader. For example 
XMLInputFactory.newInstance() says, among JVM-defaults, this:


"Use the service-provider loading facility, defined by the ServiceLoader 
class, to attempt to locate and load an implementation of the service 
using the default loading mechanism: the service-provider loading 
facility will use the current thread's context class loader to attempt 
to load the service. If the context class loader is null, the system 
class loader will be used."


As I see it, we can satisfy the requirements of KARAF-5680 by saying the 
Karaf container always implements Service Loader Mediator Specification 
(https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.loader.html). 
In karaf.git terms, spifly is not a separate feature, but is always 
included in Karaf.


I mean, with JPMS, ServiceLoader is the platform-acknowledged extension 
mechanism, hence we should be integrating no matter what...


I this a sensible direction, or am I missing something?

Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

jre.properties vs. JEP220?

[Robert Varga]

Hello everyone,

with karaf-4.5.0 requiring Java 11 
(https://issues.apache.org/jira/browse/KARAF-7754), there are a number 
of places where we can safely forget about how JVM < 9 did things, which 
could lead to simplifications.


One of these is Karaf's jre.properties, which (as I understand it) 
define the set of packages which are to be advertised by the OSGi 
framework (bundle 0, or somesuch, sorry, I am quite rusty on the spec).


JEP 220 (https://openjdk.org/jeps/220), integrated in Java 9, exposes 
the set of runtime-available packages as jrt:/packages/ (see 
https://bugs.openjdk.org/browse/JDK-8066492).


This would mean we can figure out the set of packages at runtime, would 
make jre.properties (and our adding a new jre-XY entry every 6 months), 
superfluous.


There is one wrinkle, which is javax.transaction.xa, but, with my all of 
no knowledge of J2EE, I think this a problem we need to deal with only 
until we transition to the jakarta namespaces (karaf-5?)[0]


Does this effort sound reasonable, or am I missing something?

Thanks,
Robert

[0] I think it might make sense to list Karaf, and perhaps Pax Web, 
somewhere searchable, like 
https://jakarta.ee/blogs/javax-jakartaee-namespace-ecosystem-progress/ .


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf OSGi runtime 4.4.4 release

[Robert Varga]

On 12/09/2023 17.06, Jean-Baptiste Onofré wrote:

Hi guys,


Hey JB,


After long weeks of wait, I submit Apache Karaf OSGi runtime 4.4.4
release to your vote.


Thanks a lot!


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


So there are a few third party upgrades missing:
- wagon-1.5.3
- jline-3.23.0
- commons-compress-1.24.0

but I do not believe they are worth a respin. I have this upgrade 
passing basic upgrade tests in ODL.



Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)


+1, non-binding.

Thanks again,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: karaf-4.5.x?

[Robert Varga]

On 08/01/2023 08:33, Mark Derricutt wrote:

On 8 Jan 2023, at 20:14, Jean-Baptiste Onofré wrote:


Java 11 is not a point as it's already used on Karaf 4.4.x.


Altho it seems we can run Karaf 4.4.x under JDK 8 - so now I'm curious. 
I assume nothings being targeting JDK 9+ byte code then.


Right, the karaf-4.4 contract is "YMMV". My proposal here is to switch 
to "./bin/karaf will refuse to run unless you have a JAVA_HOME that 
points to Java 11+".


Regards,
Robert

Re: pax-web-8: handling security for non-existent resources?

[Robert Varga]

On 17/08/2022 08:31, Grzegorz Grzybek wrote:

Hello


Hello Grzegorz,

sorry for the late reply. I needed some time to get into this entire 
business.



Is this expected behaviour? I would have expected to hit

ServiceAuthenticationHttpContext only when servicing /jolokia...



/jolokia/* mapping (actually a one-element array of URL patterns) is a
mapping for org.jolokia.osgi.servlet.JolokiaServlet registered into "/"
(default), ROOT) context. See this in logs:

Adding servlet

ServletModel{id=ServletModel-3,name='org.jolokia.osgi.servlet.JolokiaServlet',alias='/jolokia',urlPatterns=[/jolokia/*],servlet=org.jolokia.osgi.servlet.JolokiaServlet@2d7892f6
,contexts=[{HS,OCM-4,context:570736934,/}]}



Right, and this I think is actually a bug in Jolokia. I think it should 
set its context path to /jolokia and use urlPatterns=/*, right?


That way...



toString() method for ServletModel shows the associated (as in Whiteboard
specification) _contexts_. The single associated context is:

{HS,OCM-4,context:570736934,/}




HS means "Http Service", OCM-4 is an internal ID of the context and
"context:570736934" is generated name, because Jolokia's provided
"ServiceAuthenticationHttpContext"
is wrapped to match the API consistency internally. This
"ServiceAuthenticationHttpContext" is used by Jolokia to register the
servlet:

 service.registerServlet(getServletAlias(),
 new
JolokiaServlet(context,restrictor),
 getConfiguration(),
 getHttpContext());

(see 4th parameter - result of getHttpContext()).

What's more important is that such context replaces default "/" context
from Whiteboard specification:


it would just not do this...


2022-08-16T08:09:51,804 | INFO  | paxweb-config-1-thread-1 |
JettyServerWrapper   | 474 - org.ops4j.pax.web.pax-web-jetty -
8.0.2 | Changing default OSGi context model for
o.o.p.w.s.j.i.PaxWebServletContextHandler@14729e2e{/,null,STOPPED}

2022-08-16T08:09:51,804 | INFO  | paxweb-config-1-thread-1 |

OsgiServletContext   | 477 - org.ops4j.pax.web.pax-web-spi -
8.0.2 | Unegistering
OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
as OSGi service for "/" context path

2022-08-16T08:09:51,804 | INFO  | paxweb-config-1-thread-1 |

OsgiServletContext   | 477 - org.ops4j.pax.web.pax-web-spi -
8.0.2 | Registering
OsgiServletContext{model=OsgiContextModel{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
[166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126}}}
as OSGi service for "/" context path



See
{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}

was replaced b:
{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
[166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126}}}


So the context (in terms of org.osgi.service.http.HttpContext and
org.osgi.service.http.context.ServletContextHelper) was switched from the
one provided (by default) by org.ops4j.pax.web.pax-web-extender-whiteboard
bundle to the one provided by Jolokia.


... and then the context for '/' ...


And now the final part of the explanation - what is used to handle
/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology
URL? Pax Web delegates to the underlying container (Jetty, Tomcat and
Undertow) to handle the mapping - and according to Servlets specification,
first, the context is chosen using the longest possible path.

 From the logs you've provided, I see that in addition to "/" context (now
managed by Jolokia) you have two more contexts:

- /auth - {WB,id=OCM-8,name='/auth.id

',path='/auth',bundle=org.opendaylight.aaa.shiro,ref={org.osgi.service.http.context.ServletContextHelper}={
service.id=464, osgi.http.whiteboard.context.name=/auth.id,
service.bundleid=181, service.scope=singleton,
osgi.http.whiteboard.context.path=/auth}}
- /yanglib - {WB,id=OCM-13,name='/yanglib.id

',path='/yanglib',bundle=org.opendaylight.netconf.yanglib,ref={org.osgi.service.http.context.ServletContextHelper}={
service.id=472, osgi.http.whiteboard.context.name=/yanglib.id,
service.bundleid=370, service.scope=singleton,
osgi.http.whiteboard.context.path=/yanglib}}

There are no contexts with paths like:

- /restconf/operational/network-topology:network-topology
- /restconf/operational
- /restconf


Right, and the answer is 404, no matter auth result, because the 
endpoint has been removed (same development iteration, previous patch, 
but since it 

karaf-4.5.x?

[Robert Varga]

Hello everyone,

are there any plans for a karaf-4.5.x release?

I think there is a number of breaking changes out there to warrant a 
rather major step:


- Java 11+
- slf4j-2.0.x
- logback-1.4.x (Java 11, slf4j-2)
- pax-web-9.0.x (Java 11, jetty-10.x)

Also, I think it is time to plan for jetty-11, i.e. jakarta.ee 
namespace, as it is invariably coming down the pike, but that is a thing 
of its own.


Key drivers here for me are slf4j-2 (finally out) and jetty-10 (9.4 is 
EOSL). Most of my projects are already on Java 17, all are on Java 11, 
so yeah, I am biased :)


Thanks,
Robert

Re: [VOTE] Apache Karaf OSGi runtime 4.4.3 release (take #2)

[Robert Varga]

On 07/01/2023 06:43, Jean-Baptiste Onofré wrote:

Hi guys,

I submit Apache Karaf OSGi runtime 4.4.3 release to your vote (take #2).

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
- upgrade to Aries JAX RS Whiteboard 2.0.2
- upgrade to Pax Web 8.0.15
- 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=12352267

Maven Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1182/

Dist Staging Repository:
https://dist.apache.org/repos/dist/dev/karaf/4.4.3/

Git tag:
karaf-4.4.3

Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)


+1, non-binding, based on basic tests.

Thanks,
Robert

Re: [VOTE] Apache Karaf OSGi runtime 4.3.8 release

[Robert Varga]

On 19/10/2022 14:02, 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)


+1, non-binding.

Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf OSGi runtime 4.4.2 release

[Robert Varga]

On 19/10/2022 06:04, 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


Thanks, overall looks good, so +1 (non-binding).

One thing to consider, though, is upgrade to jackson-2.13.4: 
https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.13.4 as 
fixes a CVE in databind.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: osgi.wiring.package; filter:="(osgi.wiring.package=java.io)" for JDK upgrade from 8 to 11

[Robert Varga]

On 07/09/2022 11:10, Siano, Stephan wrote:

Hi,


Hello,


I thing there is a difference in the OSGi specs about importing java.* packages.
The OSGI core spec 6.0 says in section 3.4:
Bundles do not import the java.* packages and can therefore not specify their 
dependencies on
these variations in the environment using the Import-Package header. The OSGi 
Execution Environment defines how frameworks can inform bundles about the 
available execution environments. The
primary purpose of an execution environment is to define the variations in the 
java.* namespace,
an execution environment can also include packages in other namespaces.

The OSGi core spec 7.0 says in section 3.4:
For Java platform versions prior to Java SE 9, the Framework must also set the 
org.osgi.framework.system.packages launching property to the list of Java 
platform packages generally known to be available at runtime. Since there is no 
standard way to interrogate the Java platform for the packages currently 
available at runtime, a Framework implementation may use a predefined list of 
packages for the Java platform version.

In additional to specifying the version of the execution environment via an 
osgi.ee requirement, see osgi.ee Namespace, a Bundle may also import java.* 
packages using the Import-Package header. Imports of java.* packages by a 
bundle will be used during the resolution process, see Resolving Process, to 
ensure the bundle has visibility to the requested packages by wiring the 
bundle's import of a java.* package to the export of the java.* package by the 
Framework's system bundle. However, a bundle always loads classes in java.* 
packages via parent delegation. See Parent Delegation. Therefore, a bundle is 
not required to import a java.* package to have visibility to the classes in 
the package, if the package is present in the current runtime. It only needs to 
import a java.* package to have the resolution process ensure the package is 
available from the execution environment. This can avoid a NoClassDefFoundError 
during execution of the bundle due to a missing java.* package required by the 
bundle.

Is it possible that importing a java.* package is only valid for OSGi 7.0 
upwards. Doesn't karaf 4.2 only implement the OSGi 6.0 spec? AFAIK 7.0 is 
implemented in Karaf 4.3 and 8.0 is implemented in 4.4.


Not only that, but bnd's default behaviour depends on Java/OSGi 
requirements discovered at compile-time: 
https://github.com/bndtools/bnd/issues/2507


Regards,
Robert



Best regards
Stephan

-Original Message-
From: Jean-Baptiste Onofré 
Sent: Wednesday, 7 September 2022 10:44
To: dev 
Subject: Re: osgi.wiring.package; filter:="(osgi.wiring.package=java.io)" for 
JDK upgrade from 8 to 11

I would check what's in etc/jre.properties for java.io. It could also depends 
to the maven-bundle-plugin version you are using to build your bundle (and OSGi 
R).

If you have a simple test case in order for me to reproduce it, I can take a 
look.

Regards
JB

On Wed, Sep 7, 2022 at 10:28 AM Munish Gupta 
 wrote:


Thanks for the reply JB.

I am getting it while our product using KARAF runtime (4.2.15) is starting with 
Open JDK 11. It was coming when KARAF is trying to deploy our application 
specific bundle.
Later I downloaded KARAF binary distribution from website and tried to do KAR 
install for examples shared there. It happened again there as well.

Is there anything specific need to be mentioned as export OR import for these 
java specific (Java.IO package) while using it with OpenJDK 11. I also might be 
doing something wrong but some sort of clue can help here.

Regards
Munish

-Original Message-
From: Jean-Baptiste Onofré 
Sent: Wednesday, September 7, 2022 1:34 PM
To: dev 
Subject: Re: osgi.wiring.package;
filter:="(osgi.wiring.package=java.io)" for JDK upgrade from 8 to 11

Hi,

Can you explain where you got this error ? Just starting the runtime ?

Regards
JB

On Tue, Sep 6, 2022 at 3:47 PM Munish Gupta  
wrote:


Hi Team,



I’m using Karaf 4.2.15 in my project and when I’m trying to run the
Karaf.bat command in the bin file I’m getting the below error log.



osgi.wiring.package; filter:="(osgi.wiring.package=java.io)"



I have upgraded my JDK from 8 to 11 and then on I’m getting this issue.



I have tried with plain karaf(4.2.15) and tried to install (
feature:install ) some examples which are provided in the karaf
directory. Done the Maven build as per the directions given in the
Read.Md document. Tried to install the feature:install
karaf-servlet-example-registration . There also I am getting the
same error.



Please find the attached image for more information.



I have tried with both JDK 1.8 and OpenJDK 11, both are yielding the
same output.



Can you help me find the issue here?



Best Regards,

*Munish Gupta*

Technical Delivery Manager

Mob: +91 9533735490

[image: Logo Description automatically generated]

*[image: Logo Description automatically generated]*

*[image: 

jre-properties past Java 9

[Robert Varga]

Hello JB, everyone,

I would like to raise the question of Karaf handles packages exposed 
from the Java runtime.


Since the advent of jlink(1), the enumeration of available packages is 
very much a subject to change between environments.


I have recently raised https://github.com/apache/karaf/pull/1537, which 
added packages based on the proper JRE version, which is not perfect, 
but certainly better than what was merged as a resolution of 
https://issues.apache.org/jira/browse/KARAF-7431 afterwards: 
https://github.com/apache/karaf/pull/1555


I would like to understand more about what made you change the patch -- 
it seems it was something CI-related, certainly looking like an 
environment issue at a first glance.


I mean, if Java versions do not matter (as done in the merged patch), 
and given Karaf supports only Java 8+, does that version number in 
jre.properties matter at all at this point?!


Given that we need to raise patches again and again just to keep Karaf 
working with newer Java versions, which are now appearing with much 
faster cadence than before, I wonder if we should have a better 
mechanism in place, somehow.


At the end of the day, the use case is: if I have have static distro, 
with karaf-4.4 (OSGi R8), I should be able to pull the packaging down to 
JRE level (and hence subject to jlink!) and have Karaf lauch an OSGi 
runtime where all bundles are provided by the Java/JPMS layer via OSGi 
Connect -- thus being subject to goodies like CDS... how well is this 
currently supported?


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

pax-web-8: handling security for non-existent resources?

[Robert Varga]

Hello,

while integrating karaf-4.4.0 into OpenDaylight I ran across a bit of 
strangeness.


We are using Jetty as the implementation and register things through 
both HTTP Service and also via HTTP Whiteboard, with Shiro in the mix 
for good measure (via a an indirection, but let's not go into that for 
sanity's sake).


Due to the way system works together, we end up with Jolokia registering 
via HttpService, which prompts the creation of a default Jetty context:



2022-08-16T08:09:51,791 | INFO  | features-3-thread-1 | FeaturesServiceImpl 
 | 16 - org.apache.karaf.features.core - 4.4.0 |   
org.jolokia.osgi/1.7.1
2022-08-16T08:09:51,793 | INFO  | features-3-thread-1 | 
StoppableHttpServiceFactory  | 476 - org.ops4j.pax.web.pax-web-runtime - 
8.0.2 | Binding HTTP Service for bundle: [org.jolokia.osgi_1.7.1 [166]]
2022-08-16T08:09:51,802 | INFO  | paxweb-config-1-thread-1 | HttpServiceEnabled 
  | 476 - org.ops4j.pax.web.pax-web-runtime - 8.0.2 | Registering 
ServletModel{id=ServletModel-3,name='org.jolokia.osgi.servlet.JolokiaServlet',alias='/jolokia',urlPatterns=[/jolokia/*],servlet=org.jolokia.osgi.servlet.JolokiaServlet@2d7892f6,contexts=[{HS,OCM-4,context:570736934,/}]}
2022-08-16T08:09:51,803 | INFO  | paxweb-config-1-thread-1 | JettyServerController
| 474 - org.ops4j.pax.web.pax-web-jetty - 8.0.2 | Receiving Batch{"Registration 
of 
ServletModel{id=ServletModel-3,name='org.jolokia.osgi.servlet.JolokiaServlet',alias='/jolokia',urlPatterns=[/jolokia/*],servlet=org.jolokia.osgi.servlet.JolokiaServlet@2d7892f6,contexts=null}",
 size=3}
2022-08-16T08:09:51,803 | INFO  | paxweb-config-1-thread-1 | JettyServerWrapper 
  | 474 - org.ops4j.pax.web.pax-web-jetty - 8.0.2 | Adding 
OsgiContextModel{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
 
[166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126}}
 to o.o.p.w.s.j.i.PaxWebServletContextHandler@14729e2e{/,null,STOPPED}
2022-08-16T08:09:51,804 | INFO  | paxweb-config-1-thread-1 | JettyServerWrapper 
  | 474 - org.ops4j.pax.web.pax-web-jetty - 8.0.2 | Changing 
default OSGi context model for 
o.o.p.w.s.j.i.PaxWebServletContextHandler@14729e2e{/,null,STOPPED}
2022-08-16T08:09:51,804 | INFO  | paxweb-config-1-thread-1 | OsgiServletContext   
| 477 - org.ops4j.pax.web.pax-web-spi - 8.0.2 | Unegistering 
OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
 as OSGi service for "/" context path
2022-08-16T08:09:51,804 | INFO  | paxweb-config-1-thread-1 | OsgiServletContext   
| 477 - org.ops4j.pax.web.pax-web-spi - 8.0.2 | Registering 
OsgiServletContext{model=OsgiContextModel{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
 
[166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126}}}
 as OSGi service for "/" context path
2022-08-16T08:09:51,805 | INFO  | paxweb-config-1-thread-1 | JettyServerWrapper 
  | 474 - org.ops4j.pax.web.pax-web-jetty - 8.0.2 | Adding servlet 
ServletModel{id=ServletModel-3,name='org.jolokia.osgi.servlet.JolokiaServlet',alias='/jolokia',urlPatterns=[/jolokia/*],servlet=org.jolokia.osgi.servlet.JolokiaServlet@2d7892f6,contexts=[{HS,OCM-4,context:570736934,/}]}
2022-08-16T08:09:51,808 | INFO  | paxweb-config-1-thread-1 | JettyServerWrapper   
| 474 - org.ops4j.pax.web.pax-web-jetty - 8.0.2 | Starting Jetty context 
"/" with default Osgi Context 
OsgiContextModel{HS,id=OCM-4,name='context:570736934',path='/',bundle=org.jolokia.osgi,context=WebContainerContextWrapper{bundle=org.jolokia.osgi_1.7.1
 
[166],contextId='context:570736934',delegate=org.jolokia.osgi.security.ServiceAuthenticationHttpContext@2204c126}}


This is driven by this bit of code: 
https://github.com/rhuss/jolokia/blob/33ee8be04aedacf9af2d1ca917dd6c89b119c628/agent/osgi/src/main/java/org/jolokia/osgi/JolokiaActivator.java#L322-L325


We then proceed to start a ton of other services, like:


2022-08-16T08:09:57,729 | INFO  | paxweb-config-1-thread-1 | JettyServerWrapper   
| 474 - org.ops4j.pax.web.pax-web-jetty - 8.0.2 | Starting Jetty context 
"/auth" with default Osgi Context 
OsgiContextModel{WB,id=OCM-8,name='/auth.id',path='/auth',bundle=org.opendaylight.aaa.shiro,ref={org.osgi.service.http.context.ServletContextHelper}={service.id=464,
 osgi.http.whiteboard.context.name=/auth.id, service.bundleid=181, 
service.scope=singleton, osgi.http.whiteboard.context.path=/auth}}
2022-08-16T08:09:57,738 | INFO  | paxweb-config-1-thread-1 | JettyServerWrapper   
| 474 - org.ops4j.pax.web.pax-web-jetty - 8.0.2 | Starting Jetty context 
"/yanglib" with default Osgi 

Re: [VOTE] Apache Karaf runtime 4.4.1 release

[Robert Varga]

+1, non-binding

Regards,
Robert

On 10/07/2022 19:24, 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


OpenPGP_signature
Description: OpenPGP digital signature

javax. vs jakarta. ?

[Robert Varga]

Hello,

I'd like to ask what is the plan for the javax->jakarta transition in 
Karaf-land.


Specifically, it seems that the transition is mostly complete with 
4.4.0, but there are two outliers:


- javax.annotation-api-1.3.2 is still exposed from bom, instead of 1.3.5 
(which is jakarta)


- examples/karaf-rest-example uses javax.ws.rs instead of jakarta.ws.rs

Are these bugs, or am I missing a larger picture? (noob here :))

Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.3.7 release

[Robert Varga]

On 19/04/2022 15:42, Jean-Baptiste Onofré wrote:

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)


+1, non-binding.

Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [UPDATE] Apache Karaf runtime 4.4.0 during the week end

[Robert Varga]

On 21/03/2022 13:54, Jean-Baptiste Onofré wrote:

Hi guys,


Hello JB,


I found a couple of minor issues that I'm working on right now.
I will submit 4.4.0 release to vote asap.


sorry to be a bother, but is there an update on this effort?

The reason I am asking is we need KARAF-7401 to be able to require JDK17 
in OpenDaylight. Unless there is a Karaf release with that fix (4.3.x or 
4.4.x, either works) available in about a week (integration deadline is 
15.4., we can push that out by a week or two, but not more) we will need 
to push that transition out by 6 months :(


Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [DISCUSSION] Move PAX projects to Apache Karaf ?

[Robert Varga]

On 24/02/2022 16:48, Jean-Baptiste Onofré wrote:

Hi Achim

Just wanted to share concerns I received. Basically, PAX projects are
"free fields", without strong guarantee in the release (not formal
staging/vote/review).

It doesn't mean we don't do that, it's just not strongly enforced;)


Hello,

I think this is a matter of perception and communication.

As a downstream of a number of ASF projects as well being a committer of 
a number under-staffed FOSS project myself, I can see only one benefit 
here -- which is migration of issues to ASF JIRA.


None of the technical details will change, nor will responsiveness, nor 
the release cadence/quality, really -- unless Karaf committers actually 
take interest in that codebase. Those aspects are driven by community 
participants and not by the umbrella under which the project operates.


I have two examples for ASF projects:

1. https://issues.apache.org/jira/browse/ARIES-1826 has been sitting 
there for better part of three years without a release


2. SSHD is very responsive, with people rotating, but it is at ~6 months 
release cadence and those releases have caused regressions in the past 
-- i.e. as a downstream we had to hold back and/or apply workarounds 
like 
https://github.com/opendaylight/netconf/commit/f25f45ff27c8a7c7df780df609ec33f6662ea61e#diff-15197c97491b43d179750a5b8ea9ab1f141373544171185da9170a773faee414R21


So, with due respect to whoever has that concerns, my message is clear: 
changing governance and/or the umbrella will not address them. Boots on 
the ground will.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PROPOSAL] Apache Karaf 4.4.0 release

[Robert Varga]

On 03/02/2022 17:24, Jean-Baptiste Onofré wrote:

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 ?


None at all, actually can't wait for R8 goodies and the corresponding 
OSGi JPMS modules :)


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #3)

[Robert Varga]

On 15/12/2021 05:43, JB Onofré wrote:

Please vote to approve this release:

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


+1, non-binding.

Thanks.
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

[Robert Varga]

On 13/12/2021 16:24, Jean-Baptiste Onofré wrote:


Please vote to approve this release:

[ ] +1 Approve the release


OpenDaylight basics seem to be okay with this release, +1 (non-binding).

Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: Preparing Karaf runtime 4.3.4

[Robert Varga]

On 12/11/2021 10:23, Paul Stanley wrote:

Thanks JB.


Hello Paul,


I would have though that OSGI R8 is backwards compatible with R7, as I
didn't see any breaking changes in the spec.


True, but the artifact packaging with R8 broken up to support JPMS -- 
i.e. no osgi.cmpn anymore. That is a breaking change from build system 
perspective.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: Preparing Karaf runtime 4.3.4

[Robert Varga]

On 18/10/2021 18:34, JB Onofré wrote:

Hi guys


Hey JB,


Just to let you know that I will submit Felix FileInstall to vote tomorrow (I’m 
finishing the tests now).

So the plan is to submit Karaf 4.3.4 end of this week.


thanks for pulling it together!

Can I ask you take a look at 
https://github.com/ops4j/org.ops4j.pax.exam2/pull/1046, please?


It would be nice to have a Karaf release properly aligned. The 
misalignment is problematic when you:

- run build with an empty .m2 repo
- have karaf-bom-4.3.3 imported
- nothing in your build pulls in geronimo-atinject_1.0_spec-1.0.jar
- run pax-exam-based tests based on latest release with Karaf configured 
to only use local repositories


I see pax-exam's build is failing for all pulls, so if that's too much 
to ask, I completely understand :)


I detected the above only in one job as it seems all other jobs end up 
(somehow, I will investigate) pulling both versions, so it's nothing major.


btw. I tried to make it work by configuring etc/overrides.properties 
through pax-exam to correct it, but that did not work... not sure why.


Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: Preparing Karaf runtime 4.3.4

[Robert Varga]

On 12/10/2021 14:43, 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 ?


Fixes are always welcome, thanks :)

Proposed timeline is a bit tight to make it the next OpenDaylight 
service release (due to be out on 28th), but that's okay, there is 
always a release after that :)


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.3.3 release

[Robert Varga]

On 02/09/2021 19:00, Jean-Baptiste Onofre wrote:
> Karaf 4.3.3 already ships Jetty 9.4.43:
> 
> https://github.com/apache/karaf/blob/karaf-4.3.3/assemblies/features/standard/src/main/feature/feature.xml#L902
> 
> And Pax Web does as well (I did the release specifically).

Yeah, sorry, it was mess on my end. That is what I get for rushing and
multitasking :(

+1 for the release, non-binding.

Thanks,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.3.3 release

[Robert Varga]

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: Nice if OSGi and OSGi compendium versions were part of the karaf BoM

[Robert Varga]

On 31/05/2021 16:50, Jean-Baptiste Onofre wrote:
> These dependencies are not necessary as they come with cmpn.

True, but you need the split out artifacts to make JPMS work reasonably:

https://github.com/opendaylight/yangtools/blob/master/xpath/yang-xpath-impl/src/main/java/module-info.java#L26
https://github.com/opendaylight/yangtools/blob/master/xpath/yang-xpath-impl/pom.xml#L60-L63

I do not remember the details anymore, but this setup ended up being the
most reasonable thing to do.

I also have no idea how R8 changes the interop picture here -- osgi.core
has an Automatic-Module-Name manifest entry  (finally!), not sure how
others will look like.

Regards,
Robert


> 
> Regards
> JB
> 
>> Le 31 mai 2021 à 15:08, Steinar Bang  a écrit :
>>
>>> Jean-Baptiste Onofre :
>>
>>> Hi Steinar,
>>> I just checked and both osgi.core and osgi.cmpn are part of the Karaf BoM 
>>> (as I thought ;) ):
>>
>>> https://github.com/apache/karaf/blob/main/bom/pom.xml#L39 
>>> 
>>
>> Hm... that one should be correct.  But the artifactId changed here
>> between OSGi 6 and 7 and I started using the BoM in karaf 4.2.11 and
>> just filled up with versions for those dependencies that couldn't find
>> their so I may have been confused here.
>>
>> But this should work for me, so I'll correct this in my projects.  Thanks!
>>
>>> https://github.com/apache/karaf/blob/main/bom/pom.xml#L525 
>>> 
>>
>> I'm thinking of stuff that is part of the compendium, e.g. (for OSGi 7)
>> The log service:
>>
>>  org.osgi
>>  org.osgi.service.log
>>  1.4.0
>>  provided
>>
>>
>> the SCR annotations:
>>
>>  org.osgi
>>  org.osgi.service.component.annotations
>>  1.4.0
>>  provided
>>
>>
>> the OSGi 7 web whiteboard annotations:
>>
>>  org.osgi
>>  org.osgi.service.http.whiteboard
>>  1.1.0
>>  provided
>>
>>
>> (these are the ones I use, but there is probably a lot of others for
>> stuff I don't know about. Also, I'm not sure of the OSGi 7 web
>> whiteboard maven dependency?  I found that one by digging around on
>> maven central and it seems to have the correct contents and a publishing
>> date matching the rest of the OSGi 7 stuff...?)
>>
> 



OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.3.1 release

[Robert Varga]

On 29/03/2021 15:14, Jean-Baptiste Onofre wrote:
> Hi everyone,

Hello JB,

> I submit Apache Karaf runtime 4.3.1 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:

ODL smoke tests look good. Version alignment is on par with 4.2.11, so
also okay.

I noticed the candidate is still using Jackson 2.11.3 in the enterprise
feature. Would it be possible to bump to
https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.11.4 ?

Thanks,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf runtime 4.2.11 release

[Robert Varga]

On 09/03/2021 12:56, Jean-Baptiste Onofre wrote:
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.2.11 to your vote.

[snip]

I ran smoke tests with odlparent-7.0.x.

There are two new misalignments between karaf-4.2.11 and pax-web-7.2.23:
- javax.interceptor-api/1.2.2 vs 1.2
- org.apache.servicemix.bundles.javax-inject/1_3 vs 1_2

I found nothing obviously wrong and we can monkey-patch this
inconsistency downstream.

+1, non-binding.

Regards,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Robert Varga]

On 08/01/2021 09:07, Grzegorz Grzybek wrote:
> But summarizing, I'd keep autoRefresh=true in all the scenarios, where
> Karaf is used as "application server" and switch it to autoRefresh=false in
> µservices / custom distro / single start mode. And looking forward Karaf 5
> and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5...

+1.

I would advise against changing behavior of 4.3.x -- it is exactly these
sorts of changes which make even minor Karaf bumps a major uncertainty
-- and have historically inflicted more frustration than I care to
remember :(

Regards,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

Re: Coming releases

[Robert Varga]

On 15/12/2020 14:40, Jean-Baptiste Onofre wrote:
> Hi guys,

Hey JB,

> 
> 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.

awesome news :)

Any chance of getting KARAF-6573 sorted out, or is it something that
needs a larger-scale effort?

Thanks,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

Re: Thinking about Karaf 5 modulith runtime

[Robert Varga]

On 04/11/2020 20:29, Steinar Bang wrote:
>> Jean-Baptiste Onofre :
>> My thinking now is more to still use OSGi internally (and let people
>> do OSGi on Karaf if they want) but open the scope to other
>> framework/approach (spring boot, micro profile, etc). We would embrace
>> a wider community and expend our use cases.
> FWIW what drew me to karaf was to finally see OSGi deliver on its
> promise.
> 
> OSGi that actually worked like people said it was *supposed* to work,
> back in the mid-late 00s...
> 
> I would hate to see that go.
> 
> (Spring boot is not a priority for me.  I try to run quickly the other
> way when someone mentions Spring or Spring boot...:-) )

Same sentiment here in general, but with a very libertarian twist :)

With my various OpenDaylight hats on, let me summarize our project-wide
view, with history going back to the project was officially announced
(early 2013).

From the get go, our *architectural* requirement was OSGi compatibility,
i.e. every single production (not maven-plugin obviously) artifact has
to be a proper bundle. This, highly technical and
implementation-specific, requirement was set down because of two things:

1) what OSGi brings to MANIFEST.MF in terms of headers and intended
wiring, incl. Private-Package

2) typical OSGi implementation (we inherited Equinox and are still using
it) uses multiple class loaders and utterly breaks on split packages

This serves as an architectural requirement that translates to an
unbreakable design requirement how the code must be structured.

We started up with home-brew OSGi container, which we quickly replaced
for karaf-3.0.x (6?), massively enjoying it being properly integrated,
with shell, management and all that. Also feature:install.

At the end of day, though, OpenDaylight is a toolkit of a bunch of
components which you throw together and they work.

Our initial thinking was far removed from the current world of
containers when operations goes. The deployment was envisioned more like
an NMS with a dedicated admin team (to paint a picture), providing a
flexible platform.

The world has changed a lot, and the focus nowadays is containers
providing a single, hard-wired use-case.

We now provide out-of-the-box use-case wiring using both dynamic Karaf
and Guice (at least for one use case). We have an external project which
shows the same can be done with pure Java, Spring Boot and Quarkus.

We now also require Java 11, hence we have JPMS -- and it can fulfill
our architectural requirement just as well as OSGi and, thanks to OSGi,
we have zero split packages :)

We do not expect to ditch Karaf anytime soon, but rather leverage
static-framework for a light-weight OSGi environment, as that is clearly
the best option for us short-to-medium term, and definitely something we
will continue supporting for the foreseeable future.

The shift to nimble single-purpose wirings is not going away and hence
we will be expanding there anyway.

To achieve that, we will not be looking for a framework-of-frameworks,
we will do that through native integration ourselves.

If Karaf can do the same, i.e. have its general-purpose pieces available
as components, easily thrown together with @Singletons or @Components,
with multiple frameworks, and nicely jlinkable, I grinning silly :)

Regards,
Robert


OpenPGP_0x537D744B0A1E3F45.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: wrap: protocol for static assembly?

[Robert Varga]

On 03/11/2020 14:25, Jean-Baptiste Onofre wrote:
> Do you have a chance to be on slack ? I would love to have your help (at 
> least for the tests) about that (and your use case).

No Slack here, but I'll look at setting up -- but it is low prio.
Meanwhile I am IRC (but mostly not paying attention).

I can test-drive patches asynchronously, no problem :)

Regards,
Robert


OpenPGP_0x537D744B0A1E3F45.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: wrap: protocol for static assembly?

[Robert Varga]

On 03/11/2020 13:42, Jean-Baptiste Onofre wrote:
> Hi Robert,

Hey JB,

> Yes, the problem is about prerequisite and static.
> 
> I described the problem
> here: https://issues.apache.org/jira/browse/KARAF-6573
> 
> 
> I will work on a improvement/fix.

Thanks for confirming, I'll park my efforts until that fix then.

Regards,
Robert

Re: wrap: protocol for static assembly?

[Robert Varga]

On 03/11/2020 07:30, Jean-Baptiste Onofre wrote:
> Hi,
> 
> Do you have static-framework feature in your pom dependencies ? With which 
> scope ?

This is pretty much a copy of karaf-docker-example-static-dist, hence I
have:

https://git.opendaylight.org/gerrit/c/odlparent/+/93414/10/karaf/test-static/pom.xml

The thing is: 'wrap' itself passes okay, the trouble is if a feature
requires it -- i.e. the above works,  it is enough to add this line
https://git.opendaylight.org/gerrit/c/odlparent/+/93414/10..11/karaf/test-static/pom.xml
to break it.

odl-jung-2.1 is a simple feature:
https://repo1.maven.org/maven2/org/opendaylight/odlparent/odl-jung-2.1/8.0.0/odl-jung-2.1-8.0.0-features.xml

It looks as though 'prerequisite' might be a problem?

Regards,
Robert

wrap: protocol for static assembly?

[Robert Varga]

Hello,

attempting to add 'wrap' or anything that pulls it into a static
distribution results in:

> [ERROR] Failed to execute goal 
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.0:assembly 
> (process-resources) on project test-static: Unable to build assembly: Unable 
> to resolve root: missing requirement [root] osgi.identity; 
> osgi.identity=wrap; type=karaf.feature; version=0; 
> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=0.0.0))" [caused 
> by: Unable to resolve wrap/2.6.2: missing requirement [wrap/2.6.2] 
> osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle; 
> version="[2.6.2,2.6.2]"; resolution:=mandatory [caused by: Unable to resolve 
> org.ops4j.pax.url.wrap/2.6.2: missing requirement 
> [org.ops4j.pax.url.wrap/2.6.2] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.slf4j)(version>=1.6.0)(!(version>=2.0.0)))"]]
>  -> [Help 1]

which is weird, as that requirement should be satisfied by
static-framework's pax-logging-api (exports it at version=1.7.30).

The configuration is:

> 
> 
> static-framework
> scr
> http-whiteboard
> shell
> 
> odl-jung-2.1
> 
> 11
> static
> true
> static
> 

odl-jung-2.1 has a dependency on wrap and uses wrap: protocol.

Am I missing something?

Thanks,
Robert

Re: Static wiring of jakarta.activation-api/1.2.2

[Robert Varga]

On 29/10/2020 14:09, Jean-Baptiste Onofre wrote:
> Cool, happy it works.
> 
> And +1 for documentation update.

https://github.com/apache/karaf/pull/1245 adds that.

Regards,
Robert

Re: Static wiring of jakarta.activation-api/1.2.2

[Robert Varga]

On 29/10/2020 06:57, Jean-Baptiste Onofre wrote:
> Hi Robert,

Hey JB,

> Do you have  define in your pom ?

You are spot on.  No, I did not, now I have and it works just fine.

I will push a patch to documentation to mention it in
https://karaf.apache.org/manual/latest/#_instances_and_distributions_goals
:)

Thanks,
Robert

> 
> Regards
> JB
> 
>> Le 28 oct. 2020 à 13:35, Robert Varga  a écrit :
>>
>> Hello,
>>
>> I am giving the static distro a try and it works quite well, except one
>> problem.
>>
>> Running karaf-4.3.0 RC with Java 11, attempting to include
>> jakarta.activation-api/1.2.2 fails with:
>>
>>> [ERROR] Failed to execute goal 
>>> org.apache.karaf.tooling:karaf-maven-plugin:4.3.0:assembly 
>>> (process-resources) on project test-static: Unable to build assembly:
>>> Unable to resolve root: missing requirement [root] osgi.identity; 
>>> osgi.identity=odl-jackson-2.11; type=karaf.feature; version=8.0.1.SNAPSHOT; 
>>> filter:="(&(osgi.identity=odl-jackson-2.11)(type=karaf.feature)(version>=8.0.1.SNAPSHOT))"
>>>  [caused by:
>>> Unable to resolve odl-jackson-2.11/8.0.1.SNAPSHOT: missing requirement 
>>> [odl-jackson-2.11/8.0.1.SNAPSHOT] osgi.identity; 
>>> osgi.identity=odl-jakarta-activation-api; type=karaf.feature; 
>>> version="[8.0.1.SNAPSHOT,8.0.1.SNAPSHOT]" [caused by:
>>> Unable to resolve odl-jakarta-activation-api/8.0.1.SNAPSHOT: missing 
>>> requirement [odl-jakarta-activation-api/8.0.1.SNAPSHOT] osgi.identity; 
>>> osgi.identity=jakarta.activation-api; type=osgi.bundle; 
>>> version="[1.2.2,1.2.2]"; resolution:=mandatory [
>>> caused by: Unable to resolve jakarta.activation-api/1.2.2: missing 
>>> requirement [jakarta.activation-api/1.2.2] osgi.ee; 
>>> filter:="(&(osgi.ee=JavaSE)(version=9.0))"]]] -> [Help 1]
>>
>> i.e. static resolver seems to not consider JavaSE=9.0 to be available,
>> whereas the dynamic resolver works just fine.
>>
>> Any ideas where to fix or suppress this?
>>
>> Thanks,
>> Robert
> 

Static wiring of jakarta.activation-api/1.2.2

[Robert Varga]

Hello,

I am giving the static distro a try and it works quite well, except one
problem.

Running karaf-4.3.0 RC with Java 11, attempting to include
jakarta.activation-api/1.2.2 fails with:

> [ERROR] Failed to execute goal 
> org.apache.karaf.tooling:karaf-maven-plugin:4.3.0:assembly 
> (process-resources) on project test-static: Unable to build assembly:
> Unable to resolve root: missing requirement [root] osgi.identity; 
> osgi.identity=odl-jackson-2.11; type=karaf.feature; version=8.0.1.SNAPSHOT; 
> filter:="(&(osgi.identity=odl-jackson-2.11)(type=karaf.feature)(version>=8.0.1.SNAPSHOT))"
>  [caused by:
> Unable to resolve odl-jackson-2.11/8.0.1.SNAPSHOT: missing requirement 
> [odl-jackson-2.11/8.0.1.SNAPSHOT] osgi.identity; 
> osgi.identity=odl-jakarta-activation-api; type=karaf.feature; 
> version="[8.0.1.SNAPSHOT,8.0.1.SNAPSHOT]" [caused by:
> Unable to resolve odl-jakarta-activation-api/8.0.1.SNAPSHOT: missing 
> requirement [odl-jakarta-activation-api/8.0.1.SNAPSHOT] osgi.identity; 
> osgi.identity=jakarta.activation-api; type=osgi.bundle; 
> version="[1.2.2,1.2.2]"; resolution:=mandatory [
> caused by: Unable to resolve jakarta.activation-api/1.2.2: missing 
> requirement [jakarta.activation-api/1.2.2] osgi.ee; 
> filter:="(&(osgi.ee=JavaSE)(version=9.0))"]]] -> [Help 1]

i.e. static resolver seems to not consider JavaSE=9.0 to be available,
whereas the dynamic resolver works just fine.

Any ideas where to fix or suppress this?

Thanks,
Robert

Re: [VOTE] Apache Karaf (runtime) 4.3.0 release

[Robert Varga]

On 27/10/2020 11:27, Grzegorz Grzybek wrote:
>> On 26/10/2020 17:22, Jean-Baptiste Onofre wrote:
>>> Hi guys,
>>>
>> What is the story with servlet-api, though? pax-web-features references
>> 4.0.1 while karaf defines it at 3.1.0 -- leading to duplicate packaging.
>> Seems strange, as Jetty 10 (servlet-4) is not yet released...
>>
> Pax Web 7.3.x is using Undertow 2 and Tomcat 9 (both Servlet API 4) and
> Jetty 9 (still Servlet API 3).
> 
> Even Pax Web 8 will use the same combination (Jetty 9, Undertow 2, Tomcat
> 9) and jetty will be associated with "servlet-api compatibility bundle"
> that adds package exports for javax.servlet.* to provide 3.1.x version.
> 
> For now I think Pax Web 7.3.x needs both versions of servlet API...

Ah, makes sense, thanks!

Another question: could we align pax.cdi dependency versions with
pax.web? I am currently detecting:

[WARNING] Duplicate versions for
org.apache.xbean:xbean-bundleutils::jar, 4.12 and 4.17
[WARNING] Duplicate versions for org.ops4j.pax.jdbc:pax-jdbc::jar, 1.3.4
and 1.4.4
[WARNING] Duplicate versions for org.jboss.logging:jboss-logging::jar,
3.3.2.Final and 3.4.1.Final

(in features/enterprise is also using 3.3.2.Final).

Thanks,
Robert

Re: [VOTE] Apache Karaf (runtime) 4.3.0 release

[Robert Varga]

On 26/10/2020 17:22, Jean-Baptiste Onofre wrote:
> Hi guys,
> 
> After several weeks of work, I’m happy to submit Apache Karaf (runtime) 4.3.0 
> release to your vote.
> 
> I’m preparing a blog post for some details. Here’s a highlight of some key 
> points:
> 
> - OSGi R7
> - JDK 11+
> - JSON configuration format support
> - Better features definition (using requirements/capabilities)
> - BoM to simplify your dependencies
> - and bunch of dependencies updates and bug fixes
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12343304
>  
> 
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1149/ 
> 
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.0 
> 
> 
> Git tag:
> karaf-4.3.0
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)

Basic test with ODL passed, so +1 (non-binding) from me.

What is the story with servlet-api, though? pax-web-features references
4.0.1 while karaf defines it at 3.1.0 -- leading to duplicate packaging.
Seems strange, as Jetty 10 (servlet-4) is not yet released...

Regards,
Robert

Re: More often releases/back on regular pace

[Robert Varga]

On 07/10/2020 08:55, Romain Manni-Bucau wrote:
> Hi JB,
> 
> Think one key point for this ambition is to be able to ensure releases
> don't depend on a single man (whatever his quality is ;)).
> Checking on apache index it seems around 3-4 PMC are active (I can be wrong
> since I don't follow the list accurately from very long so happy if it is
> more), what about having planned (each two months?) releases and rotating
> in the PMC for the releases?

Another thing is that coming up with a template timeline of what the
release looks like would be nice.

For OpenDaylight we have 6 months release cadence, which is planned out
here:
https://docs.opendaylight.org/en/latest/release-process/release-schedule.html.
The accuracy of releases depend, but I think we have a decent success rate.

Obviously Karaf is much smaller in terms of codebase and number of
independent repositories, so something more nimble might make sense.

For individual projects (such as YANG Tools, etc.) we are doing
something more light-weight and predictable:

- major release every 6 months, has to happen to meet "Release
Integrated Deadline" in the above plan
- minor releases occur periodically in between, roughly every 3-4 weeks,
irrespective of content -- even if it means just realigning upstream
dependency versions
- artifact staging and release is very much automated

We also support up to 3 concurrent streams with increasing bar for
backports. For the oldest release a patch needs to be quite a critical
fix, or have an extremely good risk/benefit ration to land.
Release-to-EOL for a particular major release is 18 months.


To make all of this work, there are a few things that have to happen:
- target issues to a release realistically, keep list of deliverables short
- assign issues only when they are actively being worked on
- re-eval issue targets periodically, it is fair for an issue to not
have a fix-by release
- resist the urge fit 'just this little bit' into a release :)

Hope this helps in the ideas department :)

Regards,
Robert

Re: More often releases/back on regular pace

[Robert Varga]

On 07/10/2020 10:39, Jean-Baptiste Onofre wrote:
> Hi,
> 
> Thanks for your kind words ;)
> 
> It’s actually a good idea. And in addition of the release by itself, help on 
> Jira triage would be very helpful as well ;)
> 
> About more fine grained repo, according we find a good balance (between not 
> too small and clever grouping), it could be helpful. I’m not sure it will 
> reduce the release time in term of content (when I see the third party 
> releases like Felix or Pax …), it can increase the release "parallelism".

With the number of upstreams, I think the granularity is okay-ish. One
thing that might help on technical side of tracking is cross-linking
Jira issues to at least Apache projects. That way there is some
understanding what upstream things need to happen.

Regards,
Robert

Re: Exceptions seen when using Karaf 4.2.9/Java 11/PaxExam

[Robert Varga]

On 13/08/2020 17:59, Eric Lilja wrote:
> Hello, when attempting to move our existing code base from Java 8 to Java
> 11, we noticed exceptions appearing in the Karaf log in our automated tests
> (using Pax Exam).
> 
> I've made a minimal test project available on github show-casing the issue:
> https://github.com/elilja/java-11-runtime-issue
> 
> Make sure JAVA_HOME is set to Java 11 JDK and simply execute "mvn clean
> test" (we're using Maven 3.6.3 by the way)
> 
> maven.compiler.source/target for this project is currently set java 11
> target, but can be set to java 8, and the issue will still appear if
> using a Java 11 runtime.
> 
> The karaf log can be found under the target folder, where the karaf
> distribution is unpacked, and the exception looks like this:
> 
> $ cat target/38ed3633-4936-4894-9334-0d1849833602/data/log/karaf.log
> aug. 13, 2020 5:36:48 EM org.apache.karaf.main.Main launch
> INFO: Installing and starting initial bundles
> aug. 13, 2020 5:36:49 EM org.apache.karaf.main.Main launch
> INFO: All initial bundles installed and set to start
> aug. 13, 2020 5:36:49 EM org.apache.karaf.main.lock.SimpleFileLock lock
> INFO: Trying to lock
> C:\projects\java-11-runtime-issue\target\38ed3633-4936-4894-9334-0d1849833602\lock
> aug. 13, 2020 5:36:49 EM org.apache.karaf.main.lock.SimpleFileLock lock
> INFO: Lock acquired
> aug. 13, 2020 5:36:49 EM org.apache.karaf.main.Main$KarafLockCallback
> lockAcquired
> INFO: Lock acquired. Setting startlevel to 100
> 2020-08-13T17:36:53,355 | ERROR | features-3-thread-1 | Felix
>  | 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.6 | Bundle
> org.apache.felix.framework [0] EventDispatcher: Error during dispatch.
> (java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator)
> java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator
> at

You'll need a couple of VM options, see
https://github.com/opendaylight/odlparent/blob/master/features-test/src/main/java/org/opendaylight/odlparent/featuretest/SingleFeatureTest.java#L238-L239
for an example.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: [DISCUSSION] Apache Karaf 4.3.0 and Pax Web

[Robert Varga]

On 07/07/2020 11:18, Jean-Baptiste Onofre wrote:
> Hi everyone,
> 
> It’s more than a year now that we started Apache Karaf 4.3.0 release process, 
> fully supporting OSGi R7.
> 
> If the 4.3.0 distribution is ready, we are blocked by Pax Web. I’m concerned 
> about that as R8 will be there and we will have issue in Pax Web again.
> 
> Greg started a huge effort heading to Pax Web 8.0.0 with a large refactoring.
> However, the process is long and painful.
> So, I think it’s fair to have a discussion about the HTTP service in Karaf 
> and "relationship" with Pax Web.

Hello,

from OpenDaylight perspective, there are four main factors that would
drive karaf-4.3.0 adoption:

1) OSGi DS 1.4, for constructor injection
This is just nice-to-have to clean up some (small) amount of duplication.

2) Java 14+ support
This is for testing, we certainly can do a fair amount of that without
Karaf anyway.

3) HTTP Whiteboard 1.1
This is of real interest, as we could ditch our home-grown 'solution' to
servlets.

4) JAX-RS Whiteboard 1.0
Just as HTTP, this would allow us to have a clean solution to JAX-RS
integration, which we cudgeled to work, but has been a constant source
of pain.

Based on this, karaf-4.3.0 without R7-compliant HTTP/JAX-RS has very
little going for it from our perspective.

Also, we do use Equinox as the framework implementation -- perhaps for
historical reasons, but it works well and we do not have the cycles to
spend on qualifying Felix.

Regards,
Robert

Re: jclouds use of gson

[Robert Varga]

On 06/07/2020 14:59, Andrew Gaul wrote:
> A contributor recently submitted a pull request to jclouds which
> proposes unshadowing gson, part of our efforts to modernizing our
> dependencies:
> 
> https://github.com/apache/jclouds/pull/78
> 
> However, our team lacks the OSGi expertise to review this change.  Could
> someone from the Karaf team help us out?  The Karaf project took over
> maintenance of jclouds-karaf last year and we prefer not to break any
> users:
> 
> https://www.mail-archive.com/dev@karaf.apache.org/msg13623.html
> 

Hello,

I cannot contribute to an explicit review, sorry.

I would suggest steering clear of 2.8.6 due to a number of OSGi
packaging mistakes:
https://github.com/google/gson/issues/1601
https://github.com/google/gson/issues/1602

We are using non-shaded gson-2.8.5 in OpenDaylight for a few years now
without any issues -- the latest packaged features.xml lives here:
https://repo1.maven.org/maven2/org/opendaylight/odlparent/odl-gson/7.0.3/odl-gson-7.0.3-features.xml

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

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

[Robert Varga]

On 05/05/2020 23:38, Łukasz Dywicki wrote:
> With regard to failure scenario from Grzegorz - I think I've ran into
> one. Lately I migrated some features and resolver blew up - it did
> because conditional feature was defined in two feature sets causing
> stack overflow. I solved it by removal of duplicated feature.

This sounds very familiar, in the sense of
https://issues.apache.org/jira/browse/KARAF-5395.

> The faulty condition is this one:
> https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/region/Subsystem.java#L385
> I wasn't sure if that's a bug or not, so I didn't register it and didn't
> test against it.

An identity check, neat.

As mentioned in the above issue, I do believe the equality contracts of
all classes in
https://github.com/apache/karaf/tree/master/features/core/src/main/java/org/apache/karaf/features/internal/model
are not taking into account scenarios they are used in -- which could
explain the need for an identity check here.

Unfortunately I do not have the cycles to contribute the fixes for this :(

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: VerifyMojo performance improvement ticket

[Robert Varga]

On 28/04/2020 05:42, Jan Fetyko wrote:
> Hi,

Hello Jan,

> I'd like to create a PR for a VerifyMojo performance enhancement. As per
> your guide, I need a JIRA ticket and based on that create a PR. Can
> somebody please create a ticket for me or tell me how to create a JIRA
> ticket.

https://issues.apache.org/jira/login.jsp?os_destination=%2Fbrowse%2FKARAF should
get yout started -- just sign up, login and you should be ready to go :)

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: Jdk9plus: materialize it or not

[Robert Varga]

On 27/01/2020 09:26, Grzegorz Grzybek wrote:
> Thanks for explanation. I told you - I've never used anything above JDK8...
> 
> And I know this Jigsaw thing brings more trouble than benefits... Anyone of
> you using JDK9+ modules at all? Or only making workarounds for them? :)

Well, there is a project tracking JPMS modules in Central here:
https://github.com/sormuras/modules :)

OpenDaylight current development release does require JDK11 (for
VarHandles mostly) and we do have a number of automatic modules and a
few explicit modules.

This is low-priority work as we are waiting for OSGi R7-compliant Karaf
(due to
https://blog.osgi.org/2018/02/osgi-r7-highlights-java-9-support.html and
SCR annotation improvements). Once we have that, I expect the pace of
JPMS adoption to pick up. With
https://blog.osgi.org/2019/09/osgi-connect-revisited.html it may
actually be useful in the future :)

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: Setting security provider for Karaf 4.3.0-SNAPSHOT

[Robert Varga]

On 15/01/2020 16:25, Benjamin Graf wrote:
> Hi,
> 
> I'm actually playing around with the latest 4.3.0-SNAPSHOT. I recognize
> that the ssh bundle is using bouncycastle for reading pem files right
> now (KARAF-6383). The "issue" I'm facing is that if I like to set
> bouncycastle as the security provider via
> "org.apache.karaf.security.providers =
> org.bouncycastle.jce.provider.BouncyCastleProvider" I have to distribute
> the same bundle twice or otherwise have to remove it from system and add
> needed packages to "org.osgi.framework.bootdelegation".
> 
> Anybody seeing a better solution? 

Not sure, but in OpenDaylight we have two fragment bundles which attach
to framework bundle and expose all of BouncyCastle to OSGi:

https://github.com/opendaylight/odlparent/tree/master/karaf/bcpkix-framework-ext
https://github.com/opendaylight/odlparent/tree/master/karaf/bcprov-framework-ext

perhaps these should be upstreamed (but then we upgrade BC much more
quickly than we upgrade Karaf).

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: Merry Christmas & releases on the way

[Robert Varga]

On 25/12/2019 10:13, Jean-Baptiste Onofré wrote:
> Hi guys,

Hey JB,

> 
> on behalf of the Karaf team, I wish a Merry Christmas to the whole Karaf
> community.

... thanks, hope it was merry for you as well :)

> Let me use this mail to give you an update about releases:
> - Karaf 4.2.8 is planned before the end of this year (this week or early
> beginning of next week).

Awesome, let me know if there's anything I can do to help with KARAF-6345 :)

Regards,
Robert

Re: [HEADS UP] Apache Karaf 4.2.7 on the way

[Robert Varga]

On 16/09/2019 07:50, Jean-Baptiste Onofré wrote:
> Hi Robert,
> 
> just to let you know that I updated ASM OpCodes in Aries Proxy and it
> works now.
> 
> I will cut the Aries Proxy Impl release today.

Awesome, thank you! Sorry about delaying karaf...

Regards,
Robert

Re: [HEADS UP] Apache Karaf 4.2.7 on the way

[Robert Varga]

On 15/09/2019 07:45, Jean-Baptiste Onofré wrote:
> Hi guys,

Hey JB,

> Now I'm back from ApacheCon NA (it was a nice event by the way), I'm
> moving forward on Karaf 4.2.7 release.

Does that mean https://issues.apache.org/jira/browse/ARIES-1923 will be
taken care of at some later point in time?

Thanks,
Robert

Re: R7 Configurator Spec. 1.0: start level

[Robert Varga]

On 24/08/2019 11:03, Markus Rathgeb wrote:
> IIRC SPI Fly does not depend on any other bundle (except the core
> framework), so it could make sense to start it earlier (e.g. 20)

+1.

>> In Karaf 4.3.x, you will have Configurator as part of the config feature.
> I don't know which JSON-P implementation you are choosing, because I
> cannot find the config feature using the configurator in the master
> branch, but Johnzon Core also just depend on the API bundle.
> 
> The question for me has been if it would make sense to use e.g. 25 for
> the configurator, so user provided configuration (custom distribution)
> can choose a startlevel between 26 (inclusive) and 29 (inclusive) to
> inject a configuration before the other "Karaf inner features" are
> started (so the configuration is already used).

+1 as well.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: Karaf start up taking a lot of memry

[Robert Varga]

On 14/08/2019 14:29, musician wrote:
> The heapdump is accessible at
> https://drive.google.com/file/d/17r34T8l8DB8oO2c8RDGDsGwokr9lNKw4/view?usp=sharing

The heap dump looks just like what I saw in
https://issues.apache.org/jira/browse/KARAF-5395 ...

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Optional imports resolution between karaf-4.2.2 and karaf-4.2.6?

[Robert Varga]

Hello,

we are facing a weird problem in OpenDaylight, trying to upgrade from
4.2.2 to 4.2.6.

The problem manifests as Akka's failure to find a class via reflection
when a one-shot installation of the entire stack (which is a tree of
features) is performed.

I was able to narrow it down to what looks like a failure to wire
optional dependencies during feature:install and those taking effect
only after the next install.

This is using
https://nite.hq.sk/distribution.opendaylight-karaf-1.13.0-SNAPSHOT.tar.gz,
as otherwise the distro is quite cumbersome to build due to multiple
projects being involved.

1) feature:install odl-akka-persistence-2.5

> 2019-06-21T13:27:33,725 | INFO  | pipe-feature:install 
> odl-akka-persistence-2.5 | FeaturesServiceImpl  | 9 - 
> org.apache.karaf.features.core - 4.2.6 | Adding features: 
> odl-akka-persistence-2.5/[5.0.1.SNAPSHOT,5.0.1.SNAPSHOT]
> 2019-06-21T13:27:34,124 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 | Changes to perform:
> 2019-06-21T13:27:34,124 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   Region: root
> 2019-06-21T13:27:34,124 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 | Bundles to 
> install:
> 2019-06-21T13:27:34,124 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.google.guava/guava/27.1-jre
> 2019-06-21T13:27:34,124 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.google.guava/failureaccess/1.0.1
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.typesafe.akka/akka-actor_2.12/2.5.23
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.typesafe.akka/akka-osgi_2.12/2.5.23
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.typesafe.akka/akka-persistence_2.12/2.5.23
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.typesafe.akka/akka-protobuf_2.12/2.5.23
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.typesafe.akka/akka-slf4j_2.12/2.5.23
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:com.typesafe/config/1.3.3
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:org.fusesource.leveldbjni/leveldbjni-all/1.8-odl
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:org.scala-lang.modules/scala-java8-compat_2.12/0.8.0
> 2019-06-21T13:27:34,125 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:org.scala-lang/scala-library/2.12.8
> 2019-06-21T13:27:34,126 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> mvn:org.scala-lang/scala-reflect/2.12.8
> 2019-06-21T13:27:34,126 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> wrap:mvn:com.google.errorprone/error_prone_annotations/2.3.3
> 2019-06-21T13:27:34,126 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> wrap:mvn:com.google.guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava
> 2019-06-21T13:27:34,126 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> wrap:mvn:com.google.j2objc/j2objc-annotations/1.1
> 2019-06-21T13:27:34,126 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> wrap:mvn:org.checkerframework/checker-qual/2.5.8
> 2019-06-21T13:27:34,126 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> wrap:mvn:org.codehaus.mojo/animal-sniffer-annotations/1.17
> 2019-06-21T13:27:34,126 | INFO  | features-3-thread-1 | FeaturesServiceImpl   
>| 9 - org.apache.karaf.features.core - 4.2.6 |   
> wrap:mvn:org.iq80.leveldb/leveldb/0.10
> 2019-06-21T13:27:34,127 | INFO  | 

Re: [VOTE] Apache Karaf (runtime) 4.2.6 release

[Robert Varga]

On 07/06/2019 13:13, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Apache Karaf (runtime) 4.2.6 to your vote. This is a
> maintenance release on the 4.2.x series, bringing some improvements and
> bug fixes (scr with equinox, dependencies updates, and much more !).
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12345365
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1132/
> 
> Git Tag:
> karaf-4.2.6
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)

+1, non-binding, based on very basic validation with OpenDaylight.

One question: pax-web-features-7.2.10 still references
commons-beanutils/1.8.3, which trips up vuln scanners, is this intentional?

Thanks,
Robert

Re: How to resolve ServiceUnavailableException

[Robert Varga]

On 04/03/2019 11:37, Jean-Baptiste Onofré wrote:
> Hi Vikram,

Hello JB,

> 
> When using Blueprint, you don't directly relay on the service, but
> Blueprint creates a proxy for the reference.
> 
> The "timeout" is what we name the grace period and it happens at startup.
> Once the startup is done, and the actual service is not there, the proxy
> can fail with such kind of exception.
> 
> To better understand your use case, I have to take a look on your impl.
> 
> Is it on OpenDaylight master ?

Based on the stack trace, this is Boron SR3, a rather old version of
OpenDaylight, which shipped in April 2017 and was based on Karaf 3.0.7.

The proxy seems to be pointing to an implementation of
org.opendaylight.controller.md.sal.binding.api.NotificationPublishService --
a wild guess would be to look at what went down with sal-binding-broker.jar.

Regards,
Robert

> 
> Regards
> JB
> 
> 
> On 04/03/2019 08:27, Vikram Darsi wrote:
>> Hi Team
>>
>> Our application is using Blueprint to inject the services exposed by a bean 
>> to the other bean and in some application runs, we see below exceptions. 
>> After browsing online articles, the highlighted exception indicates that the
>> backend service implementation is not available in the OSGi registry.
>>
>> Just wondering how a bundle can be in active state when the backend 
>> implementation(i.e., dependent service) is not available during Karaf start 
>> up?
>>
>> Is there a case, the backend implementation can be un-registered from OSGi 
>> registry without stopping the bundle exposed the service during runtime? As 
>> we are sure that none of the bundles is stopped.
>>
>> Are there any recovery mechanisms? Is it correct to attempt reading the 
>> service from the OSGi registry for a definite number of times? Bundle 
>> ordering issues leads to these exceptions?
>> We are assuming the ordering will be taken care by the blueprint (If a 
>> dependent service is not available, it waits till 5 minutes(default), post 
>> which it throws timeout exceptions, we do not see any timeout exceptions 
>> during start up)
>>
>> 2017-09-19 11:41:53,886 | ERROR | -dispatcher-9722 | 
>> DataTreeChangeListenerActor  | 212 - 
>> org.opendaylight.controller.sal-distributed-datastore - 1.4.3.Boron-SR3 | 
>> Error notifying listener 
>> org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataTreeChangeListenerAdapter@72586e4e
>> org.osgi.service.blueprint.container.ServiceUnavailableException: The 
>> Blueprint container is being or has been destroyed: 
>> (objectClass=org.opendaylight.controller.md.sal.binding.api.NotificationPublishService)
>> at 
>> org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:241)[15:org.apache.aries.blueprint.core:1.6.1]
>> at 
>> org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:56)[15:org.apache.aries.blueprint.core:1.6.1]
>> at 
>> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:306)[15:org.apache.aries.blueprint.core:1.6.1]
>> at 
>> Proxy45e3a4cb_f3e4_4016_8f9f_bd0a4c6df5b8.putNotification(Unknown Source)[:]
>> at 
>> com.adva.ensemble.controller.eventmgr.impl.EventHistoryTreeChangeListner.onDataTreeChanged(EventHistoryTreeChangeListner.java:57)[392:com.adva.ensemble.controller.event-mgr-impl:17.1.1.339]
>> at 
>> org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataTreeChangeListenerAdapter.onDataTreeChanged(BindingDOMDataTreeChangeListenerAdapter.java:41)[182:org.opendaylight.controller.sal-binding-broker-impl:1.4.3.Boron-SR3]
>> at 
>> org.opendaylight.controller.cluster.datastore.DataTreeChangeListenerActor.dataChanged(DataTreeChangeListenerActor.java:58)[212:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3]
>> at 
>> org.opendaylight.controller.cluster.datastore.DataTreeChangeListenerActor.handleReceive(DataTreeChangeListenerActor.java:40)[212:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3]
>> at 
>> org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:26)[206:org.opendaylight.controller.sal-clustering-commons:1.4.3.Boron-SR3]
>> at 
>> akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:165)[194:com.typesafe.akka.actor:2.4.7]
>> at 
>> akka.actor.Actor$class.aroundReceive(Actor.scala:484)[194:com.typesafe.akka.actor:2.4.7]
>> at 
>> akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:95)[194:com.typesafe.akka.actor:2.4.7]
>> at 
>> akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)[194:com.typesafe.akka.actor:2.4.7]
>> at 
>> 

Re: [HEADS UP] Releases schedule

[Robert Varga]

On 20/01/2019 07:23, Grzegorz Grzybek wrote:
> Hello
> 
> Some time ago, I prepared this table
> 
> with JavaEE spec mapping (still work in progress wrt implementations).
> Hibernate 5.3 == JPA 2.2 == JavaEE 8 thus → Servlets 4.0.

Cool table, I am saving the link :)

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature

Re: [HEADS UP] Releases schedule

[Robert Varga]

On 18/01/2019 15:45, Grzegorz Grzybek wrote:
> Also check http://people.apache.org/~ggrzybek/bundle-report-full-karaf.xml
> report - it's perfectly aligned, not including hibernate features (which we
> use directly from upstream hibernate projects) - but nothing that can't be
> tweaked using etc/org.apache.karaf.features.xml.

Without knowing anything about this: would it be possible to refresh the
hibernate version? 5.2.9 seems to be rather ancient, with 5.2.18 out
there... Plus there is 5.3.x, which seems to trim down the feature
content, too.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: [HEADS UP] Releases schedule

[Robert Varga]

On 14/01/2019 13:14, Jean-Baptiste Onofré wrote:
> Good point.
> 
> Greg or I will tackle this.


Hello guys,

while you are looking at this, would it make sense to align
commons-codec at upgraded 1.11 release?

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature

Re: Apache Karaf Pom Missing from Maven Central

[Robert Varga]

On 02/01/2019 18:47, Williams, Kyle [USA] wrote:
> Hello!
> 
> I just wanted to give you guys a heads up that it looks like your Apache 
> Karaf pom is missing from Maven Central for version 4.2.2. Happy New Year!
> 
> http://central.maven.org/maven2/org/apache/karaf/apache-karaf/4.2.2/

Thanks, the same is true for apache-karaf-minimal.

This is most probably related to KARAF-6057, in that apache-karaf is
using maven-deploy-plugin-2.8.2, which is documented to be incompatible
with maven-install-plugin-3.0.0-M1.

The behavior also matches what I have observed with OpenDaylight, i.e.
install-3.0.0-M1 installed the artifacts correctly, but deploy plugin
failed to upload the pom into staging repo.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: [PROPOSAL] Add spotless to Karaf and subprojects

[Robert Varga]

On 30/11/2018 15:50, Jean-Baptiste Onofré wrote:
> Hi Lukasz,
> 
> I tried to use the "standard" style supported by spotless. It's also
> possible to use a custom eclipse formatter.

FWIW, in ODL we started off with Google formatting (if I remember
correctly, it's 5+ years now), but decided to tweak it:

- max columns = 120
- indent = 4
- imports: groups only for static/non-static, alpha-sorted
- curly braces are never standalone (to save vertical space)

The resulting (checkstyle) rules are at
https://github.com/opendaylight/odlparent/blob/master/checkstyle/src/main/resources/odl_checks.xml

Regards,
Robert


> 
> Does it what you are proposing ?
> 
> I can do that if you think it's a better way.
> 
> Thanks
> Regards
> JB
> 
> On 30/11/2018 14:26, Łukasz Dywicki wrote:
>> I'm not entirely sure if style which gets promoted is not too "wide". I
>> love approach as it reduces to bare minimum fights between IDEs and
>> their way of ordering imports and so on and makes PR review process just
>> simpler.
>>
>> Some points for formatter and verbosity of some elements:
>> 1. Two extra tabs after field doesn't make 80-100 margin:
>> private static final EventImpl STOP_EVENT =
>> new EventImpl(new Event("stop", Collections.emptyMap()));
>>
>>
>> 2. Extra tabs for lambdas which are just taking space:
>> return () ->
>> new Iterator() {
>>
>> 3. Double indention for case statements:
>>
>> case Event.TYPE_LOGIN:
>> {
>> append(event, "username");
>> break;
>> }
>>
>>
>> Not sure how former standard java formatting rules or Sun style was
>> made, however its a minor thing.
>> Similar approach is used within Eclipse Smarthome and its fine. At
>> beginning its a pain when maven reports you - add comment here, add
>> comment there, but once you get used to it it pays off.
>>
>> Cheers,
>> Lukasz
>>
>>
>> On 23.11.2018 06:19, Jean-Baptiste Onofré wrote:
>>> Hi guys,
>>>
>>> Thoughts about spotless ?
>>>
>>> https://github.com/apache/karaf/pull/648
>>>
>>> I will update the PR today.
>>>
>>> Agree to apply spotless or we just avoid this for now ? Shall I start a
>>> formal vote ?
>>>
>>> Thanks !
>>> Regards
>>> JB
>>>
>>> On 07/11/2018 05:43, Jean-Baptiste Onofré wrote:
 Hi team,

 I created a PR (https://github.com/apache/karaf/pull/648) to enable
 spotless in Karaf.

 Spotless is code style checker but also formatter.

 The spotless profile I added in the PR check the style and the style can
 be automatically fixed using mvn spotless:apply -Pspotless.

 I think it would be great to have this in Karaf and subprojects to have
 a consistency in our code style.

 In combination with rat, it gives us a much cleaner code.

 On the other hand, I was planning to add findbugs maven plugin as well.

 Thoughts ?

 Thanks,
 Regards
 JB

>>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [PROPOSAL] Add spotless to Karaf and subprojects

[Robert Varga]

On 07/11/2018 05:43, Jean-Baptiste Onofré wrote:
> Hi team,

Hello JB,

[...]

> On the other hand, I was planning to add findbugs maven plugin as well.

findbugs is dead, spotbugs is its replacement. A word of caution: it's
null analysis leaves quite a bit to be desired, as it simply does not
grok TYPE_USE annotations (https://github.com/spotbugs/spotbugs/issues/643).

Regards,
Robert



signature.asc
Description: OpenPGP digital signature

Re: Karaf target audience and release granularity

[Robert Varga]

On 17/08/18 15:30, Jean-Baptiste Onofré wrote:
> Hi Robert,

Hello JB,

> thanks for your feedback, and I fully agree with you.
> 
> For the release, it's largely my fault for 4.2.1: I wanted to include
> too much fixes, upgrades and new features. My bad, and apologize for
> that. That's why I wanted to propose to reduce scope of the releases and
> do it on a regular pace, much more predictable to users/devs like you.
> 
> For the changes, we are now much more "strict" in the changes we are
> doing. Any breaking changes is not allowed on a minor release.

That is absolutely fantastic.

> For the documentation, we started a huge work on this one. You can
> already see the user guide is largely better than before IMHO. Now the
> target is on the dev guide and related examples.

Awesome, that will help us immensely.

> I see your point the way you are "packaging" the features. Any reason
> why you don't manage your features repository by hand ?

There are couple of reasons for that, actually, some of which may be
historical, but have gotten us where we are. Given the history, there is
reluctance to do another big migration unless the outcome is guaranteed
to work and be easier to use than we have now.

The first problem comes from the fact that OpenDaylight is a collection
of projects, each with its own release cycle and versioning. Each of
them focuses on a problem area -- so to get OpenDaylight "core" you need
to assemble 4 projects, for "platform" it is 6-8 projects and the Karaf
distro available for download contains something like 16-20 projects.
The end result needs to be version-converged, obviously.

Hence we need to communicate versions between projects and retain strong
version requirements. This is done through bill-of-material poms
published by an upstream project and ingested by downstreams as a
scope=import dependency. We therefore need to pick up versions used in
features -- and use of properties is not an acceptable solution.

To address this, we used to have hand-written feature.xml templates,
which we processed with a rather arcane script
(https://github.com/opendaylight/odlparent/blob/stable/lithium/features-parent/pom.xml#L75).

The second problem is that the developers found it somewhere between
unfriendly and downright hostile, as features did not "just work", but
tended to fail on our SFT with a bundle resolution error of various
complexity -- ranging from simple missing imports to rather arcane class
mismatches, depending what sort of mistake the dev made.

Normal folk get scared by these and if they cannot solve them easily
they just walk away. When this is coupled with the unfamiliar paradigms
used in OpenDaylight proper, this can easily lead to the perception that
OpenDaylight/Karaf is not something mere mortals can use :(

Our hope was that we could solve this usability problem by resorting to
generated features during our migration to Karaf-4.0.x. This has the
problem of massive over-inclusion, resulting in features which
explicitly pull in bundles observed at compile-time, even when those
bundles are provided in a feature somewhere else. The generated features
are ugly, but 95-99% of the time they Just Work(tm). This allows people
to get started quickly, with the features getting eventually cleaned up.

Over the course of past of two years we (well, mostly Stephen Kitt) have
contributed the missing bits to the karaf plugin and configured our
build system in ways which make this work reasonably well.

Now we are coming to complete the circle, where for some projects we are
considering hand-written features, but to justify that migration, we
need solid documentation on how to use features to their full extent.

Even then, though, the main challenge remains: how can we on-board a
developer, who has never heard of OSGi nor features, so she can work on
their code rather than to going through a bootcamp of OSGi/Karaf pain :(

> Anyway, 4.1.6 has been released and 4.2.1 will be on vote tonight.
> Starting for there, I will send the release agenda with a release every
> two months for both Karaf Container but also the subprojects.

Great, we are targeting both those versions for inclusion in our current
release trains. I am looking for those agenda emails!

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature

Re: Karaf target audience and release granularity

[Robert Varga]

Hello Jamie, everyone,

On 16/08/18 10:46, Jamie G. wrote:
> Karaf is used / consumed heavily in the SDN world (see OpenDaylight &
> its ecosystem).
> 
> For that community they do treat Karaf as a SDK for developing their
> apps, its also of course their runtime.
> 
> The long support runs we provide for Karaf major versions is seen as a
> benefit as SDN deployments typically run major infrastructure. The
> release pace is a function of available time from the community -
> speaking from my experiences with Karaf releases they are a fare
> amount of work; more hands involved in testing, stabilizing builds,
> etc are always welcomed :)
> 
> As to how Karaf is presented; Karaf is many things to many people, I'd
> rather keep the open development possibilities than restrict them.

As one of the guys who spent countless hours pushing Karaf upgrades
through the OpenDaylight ecosystem and with m OpenDaylight Offset-0 TSC
Representative hat on, I would like to contribute the follow to the
discussion:

I whole-heartily support faster and more predictable release schedule.
OpenDaylight follows strict 6 month release cadence
(https://opendaylight.readthedocs.io/en/latest/release-process/release-schedule.html).
Third-party component upgrades are integrated in the first 6 weeks, with
only very minor adjustments being done afterwards. In this context
karaf-4.2.1 and karaf-4.1.6 having slipped as much as they did is very
bad for ability to plan ahead.

Furthermore, so far each and every Karaf upgrade has been problematic --
partly because of the technical debt present in our code base, but more
importantly due to sheer amount of changes even a x.x.1 bump in Karaf
version brings to the table. Those changes have been quite uncontrolled
in the past -- like the change in the default TransformerFactory in
3.0.6, which caused quite a lot of grief evidenced in
https://bugs.opendaylight.org/show_bug.cgi?id=5917.

While we have reasons for using Karaf in OpenDaylight, it is seen by
many developers as an unneeded complication of our platform -- to the
point that there is https://lighty.io and
https://wiki.opendaylight.org/view/Events:Neon_Dev_Forum#OpenDaylight_without_Karaf_and_OSGi.

As far as I understand the motivations, there are three drivers:
- regard of OSGi as an unnecessary complication
- the kitchen-sink nature of Karaf packaging, which brings unneeded fat,
especially considering the general move to stateless containers
- slow and painful upgrade process

Aside from the schedule, I would like to make two technical asks:

1) Thoroughly document features specification

We use features as a deployment descriptor to tie together the
components of our system, with the OpenDaylight distribution contains
around 300 individual features. While features are cool, they also seem
to be quite under-documented, especially in terms of their interplay
with the resolver -- for example, what exactly does it exactly mean to
declare a feature dependency with dependency=true and prerequisite=true
from perspective of feature/bundle lifecycle?

2) Split up feature repositories into individual features

OpenDaylight is structured as a set of individual projects, which
gradually build up the platform. We use extensively karaf-maven-plugin
to generate features and the fact that individual features in
features/standard are not available as maven artifacts forces us to
define things like
https://github.com/opendaylight/odlparent/tree/master/features/odl-karaf-feat-jetty
just to get sane features generated without pulling in all of standard.

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Karaf 3.0.7 release (take 3)

[Robert Varga]

Hello,

I do not want to side-track the vote, but would like to inquire about
https://issues.apache.org/jira/browse/KARAF-4539. We do have a workaround,
but given that this is a 3.0.5+ regression I wonder if it could be at least
evaulated.

Thanks,
Robert



--
View this message in context: 
http://karaf.922171.n3.nabble.com/VOTE-Apache-Karaf-3-0-7-release-take-3-tp4046863p4046873.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.