Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime

[Ephemeris Lappis]

+1

I think this could be a good solution to get a "ready to use" platform 
as SMX was. Many customers and I had been using SMX for years, for this 
rich integrated quality.


Nevertheless, I'm not sure this will be a "miracle" solution. My last 
and current works are all about migrating a customer's applications 
system from a very old RedHat Fuse (some kind of complex system based on 
SMX) to a "hand made" platform based on the last Karaf and Camel 
versions (ActiveMQ is also used, but will be deployed as a separate 
middle-ware), building our own features to provide what was, more or 
less, out of the shelf in SMX.


This is a rather painful work, but doing that we aim to be able to 
maintain Karaf, Camel  and other components depending on out needs, 
upgrading what is necessary when kit's necessary.


I remember in the past having working on a failed project for replacing 
the Camel version in SMX, that was not so easy as it looked like.


What upgrading strategy do you imagine for Karaf, Camel, CXF, etc. ? 
Migrating from our old Camel 2.X to 3.X we discovered a lot of 
differences (small ones or bigger ones), deprecated or removed 
components... Do you plan to provide with each last Karaf, the last Camel ?


I'm going to follow up your discussion on this topic...


Ephemeris Lappis

Le 18/01/2023 à 13:44, Jean-Baptiste Onofré a écrit :

Hi guys,

The ServiceMix community is discussing about moving most of the SMX
parts into Karaf (the useful parts ;) ).

As part of this move, the "main" ServiceMix distribution is mainly a
Karaf assembly.

Currently, we have two distributions: "standard"
(apache-karaf-x.x.x.tar.gz) and "minimal"
(apache-karaf-minimal-x.x.x.tar.gz).

I propose to add a new distribution (in assemblies):
apache-karaf-integration-x.x.x.tar.gz containing ready to go
Karaf/Camel/CXF/ActiveMQ smooth integration.
Concretely, it means:
- we will have integration features repository XML
- we will have a distribution based on this features repository
- we will have itest on this distribution with the best coverage we can

If there is no objection, I will create the Jira and create a PR (as I
have almost all ready :)).

Thoughts ?

Regards
JB


--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Andrea Cosentino]

As a side note, it's not only aligning the features, it's also upgrading
the servicemix bundles to be able to align, JB knows what I'm talking about.

I helped there a lot too (less in the last year or so) and it's really a
mess.

Il mer 18 gen 2023, 20:43 Romain Manni-Bucau  ha
scritto:

> Le mer. 18 janv. 2023 à 20:17, Andrea Cosentino  a
> écrit :
>
> > Il mer 18 gen 2023, 20:06 Romain Manni-Bucau  ha
> > scritto:
> >
> > > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino  a
> > > écrit :
> > >
> > > > Hello,
> > > >
> > > > The point is just one in relation to OSGi metadata. The components
> will
> > > be
> > > > consumed, also, by runtimes that don't need OSGi metadata, so why all
> > the
> > > > components should be with OSGi metadata and packaged as bundles?
> > > >
> > >
> > > I'm maybe a bit dumb but why all the work and meta for quarkus and
> spring
> > > boot if the reasoning is right?
> > > I perfectly understand spring or quarkus have their own programming
> > > model/runtime so need specific code and meta but then how is OSGi
> > > different?
> > >
> > > A simple example is that you should be able to drop most jandex indices
> > if
> > > your statement is true.
> > >
> >
> > My point is related more to have the components as bundles with OSGi
> > metadata. To me they should be just JAR.
> >   Mainly the reason I'm saying this about supporting camel-karaf because
> > the work wi be on the shoulders of 1 developer and this is not right for
> me
> > and for the community.
> >
>
> Sure but osgi bundles always had been designed to be just jars as much as a
> jar with a jandex index or even with a custom manifest metadata or a json
> containing the pom description ;).
>
> But I fully share with you the ownership point.
> Any bundle (more generally meta maintenance) should be owned by the core
> code writer otherwise we end in weird state all the time, in particular
> when parts are optionals or need some specific loading mecanism
> (serviceloader for ex). The lifecycle is also an issue in time, we already
> are there with features around whiteboards for ex and camel itself has a
> hard time ensuring  components work together so fear camel can be a bit big
> to have this enrichment work done properly outside camel in a project with
> less task force than camel itself.
>
>
> > Just this.
> >
> > >
> > >
> > > >
> > > > I don't see the reason why. At least the OSGi metadata should be
> > > generated
> > > > under camel Karaf project, instead of being part of the core
> components
> > > >
> > >
> > > I think the exact opposite since handling metadata in a 3rd always got
> > > proven not working very well for end user.
> > > SMix did a bunch of forks for that reason - which was enabling users
> but
> > > also a big constrait since users were not able to use the actual
> binaries
> > > for ex.
> > > Having metada on the fly is a neat solution but does not work very
> long,
> > > even when you have a bunch of people to maintain is - graalvm metadata
> > > repository is poorly usable for that reason today so for the camel
> > > ecosystem it sounds impossible to do with a good quality and being able
> > to
> > > say "next release" at each release for end users is just not an option
> -
> > > but what it would mean concretely to not handle it in camel.
> > >
> > >
> > > >
> > > > I see there is a veto about moving to apache Karaf. It was already a
> > mess
> > > > before to maintain the features and release camel-karaf with Camel 3,
> > in
> > > > the end there were one contributor (myself) taking care of them, with
> > > some
> > > > sporadic help. I really don't have the capacity in the future.
> > > >
> > >
> > > Guess it joins my previous point and actually justifies it should be in
> > > camel project or not at the end since it looks like the status of the
> > > camel-osgi ecosystem as of today - inter projects.
> > >
> > >
> > > >
> > > > If the situation is this, as Camel PMC we'll need to discuss this and
> > > > eventually discontinue, deprecating or make the camel-karaf releases
> > > > optional.
> > > >
> > >
> > > +1 if there is no real ownership, better to go to attic than have a not
> > > living project IMHO
> > >
> > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > >
> > > > Il mer 18 gen 2023, 19:27 Matt Pavlovich  ha
> > > scritto:
> > > >
> > > > > I have a similar question on this point--
> > > > >
> > > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki <
> l...@code-house.org>
> > > > > wrote:
> > > > > >
> > > > > > 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?
> > > > >
> > > > > How is maintaining OGSI metadata in Camel a concern?
> > > > >
> > > > > Thanks,
> > > > > Matt Pavlovich
> > > >
> > >
> >
>

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Romain Manni-Bucau]

Le mer. 18 janv. 2023 à 20:17, Andrea Cosentino  a
écrit :

> Il mer 18 gen 2023, 20:06 Romain Manni-Bucau  ha
> scritto:
>
> > Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino  a
> > écrit :
> >
> > > Hello,
> > >
> > > The point is just one in relation to OSGi metadata. The components will
> > be
> > > consumed, also, by runtimes that don't need OSGi metadata, so why all
> the
> > > components should be with OSGi metadata and packaged as bundles?
> > >
> >
> > I'm maybe a bit dumb but why all the work and meta for quarkus and spring
> > boot if the reasoning is right?
> > I perfectly understand spring or quarkus have their own programming
> > model/runtime so need specific code and meta but then how is OSGi
> > different?
> >
> > A simple example is that you should be able to drop most jandex indices
> if
> > your statement is true.
> >
>
> My point is related more to have the components as bundles with OSGi
> metadata. To me they should be just JAR.
>   Mainly the reason I'm saying this about supporting camel-karaf because
> the work wi be on the shoulders of 1 developer and this is not right for me
> and for the community.
>

Sure but osgi bundles always had been designed to be just jars as much as a
jar with a jandex index or even with a custom manifest metadata or a json
containing the pom description ;).

But I fully share with you the ownership point.
Any bundle (more generally meta maintenance) should be owned by the core
code writer otherwise we end in weird state all the time, in particular
when parts are optionals or need some specific loading mecanism
(serviceloader for ex). The lifecycle is also an issue in time, we already
are there with features around whiteboards for ex and camel itself has a
hard time ensuring  components work together so fear camel can be a bit big
to have this enrichment work done properly outside camel in a project with
less task force than camel itself.


> Just this.
>
> >
> >
> > >
> > > I don't see the reason why. At least the OSGi metadata should be
> > generated
> > > under camel Karaf project, instead of being part of the core components
> > >
> >
> > I think the exact opposite since handling metadata in a 3rd always got
> > proven not working very well for end user.
> > SMix did a bunch of forks for that reason - which was enabling users but
> > also a big constrait since users were not able to use the actual binaries
> > for ex.
> > Having metada on the fly is a neat solution but does not work very long,
> > even when you have a bunch of people to maintain is - graalvm metadata
> > repository is poorly usable for that reason today so for the camel
> > ecosystem it sounds impossible to do with a good quality and being able
> to
> > say "next release" at each release for end users is just not an option -
> > but what it would mean concretely to not handle it in camel.
> >
> >
> > >
> > > I see there is a veto about moving to apache Karaf. It was already a
> mess
> > > before to maintain the features and release camel-karaf with Camel 3,
> in
> > > the end there were one contributor (myself) taking care of them, with
> > some
> > > sporadic help. I really don't have the capacity in the future.
> > >
> >
> > Guess it joins my previous point and actually justifies it should be in
> > camel project or not at the end since it looks like the status of the
> > camel-osgi ecosystem as of today - inter projects.
> >
> >
> > >
> > > If the situation is this, as Camel PMC we'll need to discuss this and
> > > eventually discontinue, deprecating or make the camel-karaf releases
> > > optional.
> > >
> >
> > +1 if there is no real ownership, better to go to attic than have a not
> > living project IMHO
> >
> >
> > >
> > > Thanks.
> > >
> > >
> > >
> > > Il mer 18 gen 2023, 19:27 Matt Pavlovich  ha
> > scritto:
> > >
> > > > I have a similar question on this point--
> > > >
> > > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki 
> > > > wrote:
> > > > >
> > > > > 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?
> > > >
> > > > How is maintaining OGSI metadata in Camel a concern?
> > > >
> > > > Thanks,
> > > > Matt Pavlovich
> > >
> >
>

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Andrea Cosentino]

Il mer 18 gen 2023, 20:06 Romain Manni-Bucau  ha
scritto:

> Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino  a
> écrit :
>
> > Hello,
> >
> > The point is just one in relation to OSGi metadata. The components will
> be
> > consumed, also, by runtimes that don't need OSGi metadata, so why all the
> > components should be with OSGi metadata and packaged as bundles?
> >
>
> I'm maybe a bit dumb but why all the work and meta for quarkus and spring
> boot if the reasoning is right?
> I perfectly understand spring or quarkus have their own programming
> model/runtime so need specific code and meta but then how is OSGi
> different?
>
> A simple example is that you should be able to drop most jandex indices if
> your statement is true.
>

My point is related more to have the components as bundles with OSGi
metadata. To me they should be just JAR.
  Mainly the reason I'm saying this about supporting camel-karaf because
the work wi be on the shoulders of 1 developer and this is not right for me
and for the community.

Just this.

>
>
> >
> > I don't see the reason why. At least the OSGi metadata should be
> generated
> > under camel Karaf project, instead of being part of the core components
> >
>
> I think the exact opposite since handling metadata in a 3rd always got
> proven not working very well for end user.
> SMix did a bunch of forks for that reason - which was enabling users but
> also a big constrait since users were not able to use the actual binaries
> for ex.
> Having metada on the fly is a neat solution but does not work very long,
> even when you have a bunch of people to maintain is - graalvm metadata
> repository is poorly usable for that reason today so for the camel
> ecosystem it sounds impossible to do with a good quality and being able to
> say "next release" at each release for end users is just not an option -
> but what it would mean concretely to not handle it in camel.
>
>
> >
> > I see there is a veto about moving to apache Karaf. It was already a mess
> > before to maintain the features and release camel-karaf with Camel 3, in
> > the end there were one contributor (myself) taking care of them, with
> some
> > sporadic help. I really don't have the capacity in the future.
> >
>
> Guess it joins my previous point and actually justifies it should be in
> camel project or not at the end since it looks like the status of the
> camel-osgi ecosystem as of today - inter projects.
>
>
> >
> > If the situation is this, as Camel PMC we'll need to discuss this and
> > eventually discontinue, deprecating or make the camel-karaf releases
> > optional.
> >
>
> +1 if there is no real ownership, better to go to attic than have a not
> living project IMHO
>
>
> >
> > Thanks.
> >
> >
> >
> > Il mer 18 gen 2023, 19:27 Matt Pavlovich  ha
> scritto:
> >
> > > I have a similar question on this point--
> > >
> > > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki 
> > > wrote:
> > > >
> > > > 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?
> > >
> > > How is maintaining OGSI metadata in Camel a concern?
> > >
> > > Thanks,
> > > Matt Pavlovich
> >
>

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Matt Pavlovich]

> On Jan 18, 2023, at 12:43 PM, Andrea Cosentino  wrote:
> 
> Hello,
> 
> The point is just one in relation to OSGi metadata. The components will be
> consumed, also, by runtimes that don't need OSGi metadata, so why all the
> components should be with OSGi metadata and packaged as bundles?

Hi Andrea-

This is really the gist of my inquiry — What is the level of effort involved in 
maintaining OSGi metadata for Camel? From the high level it appears to be 
handled automatically at this point.

Thanks,
Matt Pavlovich

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Romain Manni-Bucau]

Le mer. 18 janv. 2023 à 19:43, Andrea Cosentino  a
écrit :

> Hello,
>
> The point is just one in relation to OSGi metadata. The components will be
> consumed, also, by runtimes that don't need OSGi metadata, so why all the
> components should be with OSGi metadata and packaged as bundles?
>

I'm maybe a bit dumb but why all the work and meta for quarkus and spring
boot if the reasoning is right?
I perfectly understand spring or quarkus have their own programming
model/runtime so need specific code and meta but then how is OSGi different?

A simple example is that you should be able to drop most jandex indices if
your statement is true.


>
> I don't see the reason why. At least the OSGi metadata should be generated
> under camel Karaf project, instead of being part of the core components
>

I think the exact opposite since handling metadata in a 3rd always got
proven not working very well for end user.
SMix did a bunch of forks for that reason - which was enabling users but
also a big constrait since users were not able to use the actual binaries
for ex.
Having metada on the fly is a neat solution but does not work very long,
even when you have a bunch of people to maintain is - graalvm metadata
repository is poorly usable for that reason today so for the camel
ecosystem it sounds impossible to do with a good quality and being able to
say "next release" at each release for end users is just not an option -
but what it would mean concretely to not handle it in camel.


>
> I see there is a veto about moving to apache Karaf. It was already a mess
> before to maintain the features and release camel-karaf with Camel 3, in
> the end there were one contributor (myself) taking care of them, with some
> sporadic help. I really don't have the capacity in the future.
>

Guess it joins my previous point and actually justifies it should be in
camel project or not at the end since it looks like the status of the
camel-osgi ecosystem as of today - inter projects.


>
> If the situation is this, as Camel PMC we'll need to discuss this and
> eventually discontinue, deprecating or make the camel-karaf releases
> optional.
>

+1 if there is no real ownership, better to go to attic than have a not
living project IMHO


>
> Thanks.
>
>
>
> Il mer 18 gen 2023, 19:27 Matt Pavlovich  ha scritto:
>
> > I have a similar question on this point--
> >
> > > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki 
> > wrote:
> > >
> > > 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?
> >
> > How is maintaining OGSI metadata in Camel a concern?
> >
> > Thanks,
> > Matt Pavlovich
>

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Andrea Cosentino]

Hello,

The point is just one in relation to OSGi metadata. The components will be
consumed, also, by runtimes that don't need OSGi metadata, so why all the
components should be with OSGi metadata and packaged as bundles?

I don't see the reason why. At least the OSGi metadata should be generated
under camel Karaf project, instead of being part of the core components

I see there is a veto about moving to apache Karaf. It was already a mess
before to maintain the features and release camel-karaf with Camel 3, in
the end there were one contributor (myself) taking care of them, with some
sporadic help. I really don't have the capacity in the future.

If the situation is this, as Camel PMC we'll need to discuss this and
eventually discontinue, deprecating or make the camel-karaf releases
optional.

Thanks.



Il mer 18 gen 2023, 19:27 Matt Pavlovich  ha scritto:

> I have a similar question on this point--
>
> > On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki 
> wrote:
> >
> > 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?
>
> How is maintaining OGSI metadata in Camel a concern?
>
> Thanks,
> Matt Pavlovich

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Matt Pavlovich]

I have a similar question on this point--

> On Jan 18, 2023, at 12:02 PM, Łukasz Dywicki  wrote:
> 
> 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?

How is maintaining OGSI metadata in Camel a concern?

Thanks,
Matt Pavlovich

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Łukasz Dywicki]

-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 

[GitHub] [karaf-minho] jbonofre opened a new issue, #44: Improve message when spring-boot application is not found

[GitBox]

jbonofre opened a new issue, #44:
URL: https://github.com/apache/karaf-minho/issues/44

   With the `minho-spring-boot` application manager, the user can load several 
spring-boot application via the `ConfigService#Applications`. For instance, he 
can define spring-boot applications via `minho.json` file:
   
   ```json
   {
 "applications": [
   {
 "name": "one-app",
 "type": "spring-boot",
 "url": "file:./app/my-spring-boot-app-1.0-SNAPSHOT.jar",
 "properties": {
   "args": "--server.port=8181"
 }
   }
 ]
   }
   ```
   
   If the `minho-spring-boot` application manager doesn't find the jar on the 
provided `url`, the user get this error:
   
   ```
   INFO: Starting Spring Boot module 
file:./app/my-spring-boot-app-1.0-SNAPSHOT.jar
   Exception in thread "main" java.lang.IllegalStateException: Can't start 
lifecycle service
   at 
org.apache.karaf.minho.boot.service.LifeCycleService.start(LifeCycleService.java:66)
   at 
org.apache.karaf.minho.boot.service.ServiceRegistry.lambda$start$2(ServiceRegistry.java:128)
   at java.base/java.util.Optional.ifPresent(Optional.java:178)
   at 
org.apache.karaf.minho.boot.service.ServiceRegistry.start(ServiceRegistry.java:126)
   at org.apache.karaf.minho.boot.Minho.start(Minho.java:59)
   at org.apache.karaf.minho.boot.Main.main(Main.java:63)
   Suppressed: java.lang.RuntimeException: Can't start Spring Boot 
module file:./app/my-spring-boot-app-1.0-SNAPSHOT.jar
   at 
org.apache.karaf.minho.springboot.SpringBootApplicationManagerService.lambda$onRegister$0(SpringBootApplicationManagerService.java:57)
   at java.base/java.lang.Iterable.forEach(Iterable.java:75)
   at 
org.apache.karaf.minho.springboot.SpringBootApplicationManagerService.lambda$onRegister$1(SpringBootApplicationManagerService.java:53)
   at 
org.apache.karaf.minho.boot.service.LifeCycleService.lambda$start$0(LifeCycleService.java:69)
   at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
   at 
org.apache.karaf.minho.boot.service.LifeCycleService.start(LifeCycleService.java:67)
   ... 5 more
   Caused by: java.lang.ClassNotFoundException: 
org.springframework.boot.loader.JarLauncher
   at 
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
   at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
   at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
   at 
org.apache.karaf.minho.springboot.SpringBootApplicationManagerService.start(SpringBootApplicationManagerService.java:106)
   at 
org.apache.karaf.minho.springboot.SpringBootApplicationManagerService.lambda$onRegister$0(SpringBootApplicationManagerService.java:55)
   ... 10 more
   ```
   
   It could be confusing as the problem is not really `ClassNotFoundException: 
org.springframework.boot.loader.JarLauncher` but actually the application jar 
file is not found.
   
   The `minho-spring-boot` application manager should first check if the jar 
exists on the provided URL and throw a clean message if not.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@karaf.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Freeman Fang]

+1 (binding as Karaf PMC member)

Freeman


On Wed, Jan 18, 2023 at 5:03 AM 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
>

Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime

[Nicolas Filotto]

+1 (non-binding)

From: Jean-Baptiste Onofr? 
Sent: Wednesday, January 18, 2023 13:44
To: dev ; user ; 
d...@servicemix.apache.org ; 
us...@servicemix.apache.org 
Subject: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf 
OSGi runtime

Hi guys,

The ServiceMix community is discussing about moving most of the SMX
parts into Karaf (the useful parts ;) ).

As part of this move, the "main" ServiceMix distribution is mainly a
Karaf assembly.

Currently, we have two distributions: "standard"
(apache-karaf-x.x.x.tar.gz) and "minimal"
(apache-karaf-minimal-x.x.x.tar.gz).

I propose to add a new distribution (in assemblies):
apache-karaf-integration-x.x.x.tar.gz containing ready to go
Karaf/Camel/CXF/ActiveMQ smooth integration.
Concretely, it means:
- we will have integration features repository XML
- we will have a distribution based on this features repository
- we will have itest on this distribution with the best coverage we can

If there is no objection, I will create the Jira and create a PR (as I
have almost all ready :)).

Thoughts ?

Regards
JB

As a recipient of an email from Talend, your contact personal data will be on 
our systems. Please see our privacy notice. 

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[fpapon]

+1 (binding)

regards,

François

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


--
--
François

Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime

[fpapon]

Sounds good.

+1

regards,

François

On 18/01/2023 13:44, Jean-Baptiste Onofré wrote:

Hi guys,

The ServiceMix community is discussing about moving most of the SMX
parts into Karaf (the useful parts ;) ).

As part of this move, the "main" ServiceMix distribution is mainly a
Karaf assembly.

Currently, we have two distributions: "standard"
(apache-karaf-x.x.x.tar.gz) and "minimal"
(apache-karaf-minimal-x.x.x.tar.gz).

I propose to add a new distribution (in assemblies):
apache-karaf-integration-x.x.x.tar.gz containing ready to go
Karaf/Camel/CXF/ActiveMQ smooth integration.
Concretely, it means:
- we will have integration features repository XML
- we will have a distribution based on this features repository
- we will have itest on this distribution with the best coverage we can

If there is no objection, I will create the Jira and create a PR (as I
have almost all ready :)).

Thoughts ?

Regards
JB


--
--
François

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Claus Ibsen]

+1 (binding)

On Wed, Jan 18, 2023 at 11:03 AM 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
>


-- 
Claus Ibsen
-
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Zineb Bendhiba]

+1 (binding)


Le mer. 18 janv. 2023 à 11:03, Jean-Baptiste Onofré  a
écrit :

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

Regards,

-- 
Zineb Bendhiba

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Andrea Cosentino]

+1 (binding)

--
Andrea Cosentino 
--
Apache Camel PMC Chair
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd






On Wednesday, January 18, 2023 at 11:03:27 AM GMT+1, 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

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Romain Manni-Bucau]

Any hope to evaluate the "bunch" of users which would move to this new
project and not spring-boot/quarkus/anything-hype-cause-$$?

Can be great to see if the community wants to focus on karaf or aggregation
on the long run due to available/active resources.

If we have proofs there is a need and community supporters I would be
+1else it can be a good bad idea as we say soletimes.


Just my 2cts

Le mer. 18 janv. 2023 à 13:46, Jean-Baptiste Onofré  a
écrit :

> Correct, I mentioned this in my previous email (camel-karaf to
> karaf-camel).
>
> Regards
> JB
>
> On Wed, Jan 18, 2023 at 1:26 PM Claus Ibsen  wrote:
> >
> > Hi
> >
> > And the source code java package names needs to be migrated as well
> > org.apache.camel.karaf -> org.apache.karaf.camel
> >
> > And documentation is moved over to Apache Karaf, where the karaf camel
> > releases its own new set of documentation/website.
> >
> > The existing Camel Karaf 3.x will be maintained as-is until its EOL.
> >
> >
> >
> >
> >
> > On Wed, Jan 18, 2023 at 12:14 PM Claus Ibsen 
> wrote:
> >
> > > Hi
> > >
> > > This SHOULD also mean that the project should be known as karaf-camel
> > > AND that the artifacts released for download and maven central should
> have
> > > changed GAVs
> > >
> > > groupId = org.apache.karaf.camel
> > > artifactId = karaf-camel-xxx
> > > version = x.y.z
> > >
> > > For version then it may want to follow the Camel version, eg 4.0.0
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Jan 18, 2023 at 11:03 AM 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
> > >>
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -
> > > @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
> >
> >
> > --
> > Claus Ibsen
> > -
> > @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
>

Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime

[Romain Manni-Bucau]

Hi JB,

Is there a community behind or did people already moved to Karaf so this is
just about killing smix project officially.

Trying to see if it is mainly about having really itests and enriching
features.xml (theorically nothing new) or creating a new distro and almost
a subproject.


Le mer. 18 janv. 2023 à 13:44, Jean-Baptiste Onofré  a
écrit :

> Hi guys,
>
> The ServiceMix community is discussing about moving most of the SMX
> parts into Karaf (the useful parts ;) ).
>
> As part of this move, the "main" ServiceMix distribution is mainly a
> Karaf assembly.
>
> Currently, we have two distributions: "standard"
> (apache-karaf-x.x.x.tar.gz) and "minimal"
> (apache-karaf-minimal-x.x.x.tar.gz).
>
> I propose to add a new distribution (in assemblies):
> apache-karaf-integration-x.x.x.tar.gz containing ready to go
> Karaf/Camel/CXF/ActiveMQ smooth integration.
> Concretely, it means:
> - we will have integration features repository XML
> - we will have a distribution based on this features repository
> - we will have itest on this distribution with the best coverage we can
>
> If there is no objection, I will create the Jira and create a PR (as I
> have almost all ready :)).
>
> Thoughts ?
>
> Regards
> JB
>

Re: [PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime

[Grzegorz Grzybek]

Hello

I don't know much about SMX distributions (except SMX bundles), but having
a Karaf distro with ready-to-use Camel + CXF + ActiveMQ sounds like a good
idea.

regards
Grzegorz Grzybek

śr., 18 sty 2023 o 13:44 Jean-Baptiste Onofré  napisał(a):

> Hi guys,
>
> The ServiceMix community is discussing about moving most of the SMX
> parts into Karaf (the useful parts ;) ).
>
> As part of this move, the "main" ServiceMix distribution is mainly a
> Karaf assembly.
>
> Currently, we have two distributions: "standard"
> (apache-karaf-x.x.x.tar.gz) and "minimal"
> (apache-karaf-minimal-x.x.x.tar.gz).
>
> I propose to add a new distribution (in assemblies):
> apache-karaf-integration-x.x.x.tar.gz containing ready to go
> Karaf/Camel/CXF/ActiveMQ smooth integration.
> Concretely, it means:
> - we will have integration features repository XML
> - we will have a distribution based on this features repository
> - we will have itest on this distribution with the best coverage we can
>
> If there is no objection, I will create the Jira and create a PR (as I
> have almost all ready :)).
>
> Thoughts ?
>
> Regards
> JB
>

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Jean-Baptiste Onofré]

Correct, I mentioned this in my previous email (camel-karaf to karaf-camel).

Regards
JB

On Wed, Jan 18, 2023 at 1:26 PM Claus Ibsen  wrote:
>
> Hi
>
> And the source code java package names needs to be migrated as well
> org.apache.camel.karaf -> org.apache.karaf.camel
>
> And documentation is moved over to Apache Karaf, where the karaf camel
> releases its own new set of documentation/website.
>
> The existing Camel Karaf 3.x will be maintained as-is until its EOL.
>
>
>
>
>
> On Wed, Jan 18, 2023 at 12:14 PM Claus Ibsen  wrote:
>
> > Hi
> >
> > This SHOULD also mean that the project should be known as karaf-camel
> > AND that the artifacts released for download and maven central should have
> > changed GAVs
> >
> > groupId = org.apache.karaf.camel
> > artifactId = karaf-camel-xxx
> > version = x.y.z
> >
> > For version then it may want to follow the Camel version, eg 4.0.0
> >
> >
> >
> >
> >
> >
> > On Wed, Jan 18, 2023 at 11:03 AM 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
> >>
> >
> >
> > --
> > Claus Ibsen
> > -
> > @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
>
> --
> Claus Ibsen
> -
> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

[PROPOSAL] Create integration (ServiceMix like) distribution in Karaf OSGi runtime

[Jean-Baptiste Onofré]

Hi guys,

The ServiceMix community is discussing about moving most of the SMX
parts into Karaf (the useful parts ;) ).

As part of this move, the "main" ServiceMix distribution is mainly a
Karaf assembly.

Currently, we have two distributions: "standard"
(apache-karaf-x.x.x.tar.gz) and "minimal"
(apache-karaf-minimal-x.x.x.tar.gz).

I propose to add a new distribution (in assemblies):
apache-karaf-integration-x.x.x.tar.gz containing ready to go
Karaf/Camel/CXF/ActiveMQ smooth integration.
Concretely, it means:
- we will have integration features repository XML
- we will have a distribution based on this features repository
- we will have itest on this distribution with the best coverage we can

If there is no objection, I will create the Jira and create a PR (as I
have almost all ready :)).

Thoughts ?

Regards
JB

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Claus Ibsen]

Hi

This SHOULD also mean that the project should be known as karaf-camel
AND that the artifacts released for download and maven central should have
changed GAVs

groupId = org.apache.karaf.camel
artifactId = karaf-camel-xxx
version = x.y.z

For version then it may want to follow the Camel version, eg 4.0.0






On Wed, Jan 18, 2023 at 11:03 AM 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
>


-- 
Claus Ibsen
-
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Jean-Baptiste Onofré]

Hi Andrea,

yes, thanks. I forgot to mention that the move if for Camel 4.x (not
the existing branch/version).

Regards
JB

On Wed, Jan 18, 2023 at 11:05 AM Andrea Cosentino  wrote:
>
> As as side note to what JB just wrote:
>
> as Apache Camel community we'll still maintain the 3.x side of the
> projects, for continuity, Karaf-camel will be the house for the Camel 4.x
> OSGi support.
>
> Thanks.
>
> Il giorno mer 18 gen 2023 alle ore 11:03 Jean-Baptiste Onofré <
> j...@nanthrax.net> ha scritto:
>
> > 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
> >

Re: [VOTE] Accept karaf-camel as new Apache Karaf subproject

[Andrea Cosentino]

As as side note to what JB just wrote:

as Apache Camel community we'll still maintain the 3.x side of the
projects, for continuity, Karaf-camel will be the house for the Camel 4.x
OSGi support.

Thanks.

Il giorno mer 18 gen 2023 alle ore 11:03 Jean-Baptiste Onofré <
j...@nanthrax.net> ha scritto:

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

[VOTE] Accept karaf-camel as new Apache Karaf subproject

[Jean-Baptiste Onofré]

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

[GitHub] [karaf-minho] jbonofre closed issue #42: `minho-spring-boot` application manager should look for `spring-boot` type

[GitBox]

jbonofre closed issue #42: `minho-spring-boot` application manager should look 
for `spring-boot` type
URL: https://github.com/apache/karaf-minho/issues/42


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@karaf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [karaf-minho] jbonofre merged pull request #43: [42] Change application type handling in spring-boot application manager

[GitBox]

jbonofre merged PR #43:
URL: https://github.com/apache/karaf-minho/pull/43


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@karaf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org