The meaning of karaf-bom
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
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?
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
