-1 from my side
Given the scope of work and possible improvements I do not see a strong
reason to move camel-karaf into karaf-camel hence my veto on the proposal.
This vote opens up a dangerous path where Karaf gains more fat and moves
into direction of integration product on its own while, till now, it was
always a lightweight runtime. Because Apache ServiceMix is still listed
as Apache Software Foundation project we will end up with a functional
overlap and potential release cycle between these two.
Personally I miss a problem statement which such donation would solve
and improve. Will we keep accepting other open source projects doing
similar donations. Would we accept in Apache Karaf subprojects formed
from opendaylight, opennms, atricore, openhab and more who have a
plug-in components and can run under Apache Karaf?
Going over points which Jean-Baptiste Onofré mentioned:
1) Maintenance and improvement of existing osgi related code of Apache
Camel - does it mean that Camel does not want to maintain code which
greatly contributed to its initial success? Are there any obstacles made
for people who would like to do it with *camel-karaf* which would be
gone with *karaf-camel*?
2) Roadmap - making a roadmap does not depend on place where code is
hosted but rather on release cycle and its frequency. Given that Apache
Camel has a concept of LTS releases, in some ways, it seems to be a
better candidate to constitute a roadmap.
3) Does dealing with various Camel related API changes on Apache Karaf
side is going to make it easier or harder to solve problems? Does
problem come from Karaf or Camel components? According to my knowledge
these are mostly related to third party libraries used by various
components which are not determined by Apache Karaf. This means that
moving components to Karaf has no positive effect as karaf-camel itself
will not make a problem any different than it is for camel-karaf.
4) The documentation part - since Apache Camel has support for variety
of containers and runtimes documentation might be more consistent if its
less of Karaf specific and more Camel specific. There is literally one
component which is tied to runtime version - which is "camel-karaf"
itself which ships shell commands for Karaf. Its to little to m
My additional concerns which I would like to raise are:
1) Apache Camel community is much larger and it outperforms Karaf
community by number of times. There is a significant risk of quality
degradation in karaf-camel compared to camel-karaf due to number of
people involved on both ends.
2) Number of releases performed by Camel is larger than Karaf. This
comes down to nature of things - Camel has more components which require
third party dependencies and their updates. Making release cycle
sticking to Camel is a one more reason why Karaf integration should stay
there, especially that karaf-camel version will be dictated by a Camel,
and not Karaf version.
3) Apache Camel already maintains several containers (quarkus,
spring-boot); I do not see a similar push for these containers even if
they could be donated back to ie. quarkiverse or given under spring
source supervision, why is so?
4) Troubles which claims to be solved by donation are related to OSGi
itself, almost never to Apache Karaf alone.
5) If any of camel components breaks under Karaf runtime, it is indeed a
problem, but this problem of Apache Camel component and not Apache Karaf
itself. It comes down to a dependency which is being declared by Camel
and not Karaf.
6) I do not see any sign of what is going to happen with OSGi metadata
which is present for Apache Camel 3.x components. Is Camel 4.x going to
retain OSGi metadata?
7) I saw that Apache Camel recently accepted ie. Apache PLC4X component.
What is a criteria for Camel project to acquire or shift things?
Kind regards,
Łukasz
--
Code-House
http://code-house.org
On 18.01.2023 11:03, Jean-Baptiste Onofré wrote:
Hi guys,
The Apache Camel community proposed to move Camel Karaf to the Apache
Karaf project (as a new subproject).
As a reminder, Camel Karaf provides:
- support Camel Contexts/Routes as OSGi services (camel-core-osgi)
- Camel components specific to OSGi and Karaf (camel-blueprint, camel-scr, ...)
- wrapping of Camel components as Karaf features (providing a features
repository XML)
I think there are a bunch of users using camel-karaf, so, from a
community perspective, it would be great to maintain it.
Furthermore, I already have some ideas to improve karaf-camel, like
avoiding to wrap each Camel component as an OSGi bundle, but instead
creating a kind of Uber jar to simplify deployment and have more
reliable behavior.
Concretely, accepting camel-karaf as Karaf subproject would mean:
- maintain the existing code, and improving it, preparing kind of
roadmap for camel-karaf
- deal with Camel versions and components (and all difficulties that
it could cause in an OSGi context :) )
- maintain camel-karaf specific documentation
- vote for the releases (the PMC members would be the Karaf ones, so
binding vote from Karaf PMC members)
I submit accepting camel-karaf (so karaf-camel :)) as new Karaf
subproject to your vote:
Please vote to approve this release:
[ ] +1 Approve camel-karaf as new Karaf subproject
[ ] -1 Don't approve camel-karaf as new Karaf subproject (please
provide specific comments)
This vote will be open for at least 72 hours.
Thanks,
Regards
JB
