Hello,
To be fair, I am a bit surprised by idea of dropping pax projects,
because this is the area where Karaf as a project, have at least slight
chance to share workload with other OSGi users.
I agree, that pax-exam is burden, and it doesn't fit very well to JUnit
5. I've made an attempt to port some portions of its logic to junit 5
extension, but many parts of its bootstrap logic is written in very
specific way, which reflects junit 4 philosophy. For that reason I
completely abandoned testing with pax-exam and switched to
test-containers [1].
Coming back to pax issue - OSGi is not most popular stack, having even
small amount of work shared with others helps to keep projects going. I
am not sure how many people travel between PAX and Karaf and vice versa,
but lets be honest - contribution criteria for PAX is lower than for Karaf.
I am really not sure what benefit we can bring to people, who prefer
running other tech stacks. Given that other ecosystems are much bigger
(spring / jee / servlet), often more complex, we will need to
accommodate their complexities into Karaf. Making hibernate, spring-aop
and so on load time waving is never ending source of troubles with OSGi
class loaders. Can we make this complex issue less trouble with OSGi?
While we might pretend that we can, and that it will open window of
opportunity to grow community, I personally doubt it will ever happen.
OSGi is best suited for systems which needs plugins running within
single JVM process. If someone's use case happens outside of these
boundaries, costs caused by investment in OSGi often will outweigh final
profits. I do believe that serving community we have is fair, cause what
profit we could give people who wish to run a servlet? Will we make it
simpler than Tomcat or Jetty? Or spring-boot?
Application development model shifted so much that even application
servers struggle to keep their community. I am afraid, that staying
inline with principles of OSGi, will make it even less probable. If
someone insist to run other stack he can always pick a WAR which will
get isolated from OSGi. Or Karaf Minho which promised to bring solution
for modulith.
Without doubt, there are certain complexities embedded in pax projects
(logging, web, jdbc), however many of these come from fairly basic
assumptions, such as possibility to swap backing implementation
(log4j/logback, jetty/tomcat/undertow), which (I can just suppose) often
come out from people who used Karaf. Once we do karaf-logging-log4j, I
am quite sure there will be one or two people who will ask about
karaf-logging-logback. What we going to do then?
These who don't like pax way, might always pick simpler implementations
for Apache Felix. All this without dropping osgi, and without our
reinventing the wheel.
To summarize all above:
Lets serve niche we have with tools we made.
Best,
Łukasz
[1] https://github.com/ConnectorIO/connectorio-testcontainers/
On 4.06.2024 11:17, Jean-Baptiste Onofré wrote:
Hi folks,
I think it's time to prepare a new milestone for the project :)
Short term (and first step) is to prepare the coming release:
1. Apache Karaf 4.4.7 will be submitted to vote next week. It will include:
* Improvement on the spring features repository (providing both
Spring 5 and Spring 6 features)
* Dependencies updates and minor fixes found on the 4.4.6 release
2. Apache Karaf 4.5.0 will be submitted to vote by the end of the
month. It will include (mainly):
* New spec features repository with Jakarta specs
* Bigger fixes for 4.5.0
3. Apache Karaf 5.0.0
That's the big milestone, and I propose to have big and opinionated
changes here. OSGi is an implementation detail of the runtime, still
exposed to the experimented users.
Be opinionated means that I propose to remove PAX * dependencies,
and provide Karaf services instead, very simple and opinionated (for
instance, instead of PAX Web, a simple Tomcat based service, instead
of PAX Logging, a simple slf4j/log4j only service, Pax Exam replaced
by JUnit 5 simple extensions, etc).
Another goal of Karaf 5 is to bring new tooling to improve dev
experience (annotation based distributions generation, etc).
Also, users will be able to smoothly deploy Spring powered or
Servlet applications without knowing/leveraging OSGi (especially the
import/export pattern).
Thoughts ?
Regards
JB
