Re: Minho Qusetion
Hi JB, My project has until recently worked well using Karaf for loading new Vaadin views as OSGi jars. Changed policy at Vaadin has made the use of OSGi virtually impossible and I have been forced into the Spring Boot world. Much to my surprise, Spring Boot has turned out to be great for coding and debugging my code. Missing is the ability to add new views on the fly which karaf kindly offered. I have tried to find a way to add new views to Spring Boot during a restart but no success. Minho seems to be a possible solution to this problem but the learning curve seems to be very steep. If Minho was promoted as a way to add some OSGi functionality to Spring boot, you may have a winner. If this is possible, some examples of how to do it could lead to a more reasonable learning curve. Also, now we are venturing into java 20 and 21 it seems that Spring Boot has taken early steps to incorporate projects loom, panama etc.. OSGi may be falling behind with these projects. Paul Fraser On 18/09/2023 7:34 pm, Jean-Baptiste Onofré wrote: Hi Paul, Yes, that's the idea: having a central/shared registry gathering beans from OSGi, Spring Boot, CDI, whatever. The "dynamic" approach (adding/removing applications managed by a app manager like Spring Boot, OSGi, ...) is also a target. To be honest, currently, Minho is not moving forward due to the low interest we got. If we have clear signs that people are interested in colocation and Minho runtime paradigm, it could change :) Regards JB On Mon, Sep 18, 2023 at 6:29 AM Paul Fraser wrote: Hi, Cannot quite get my head around Apache Minho but-- Can OSGi services be somehow added to the Spring Boot application at runtime or even at Spring Boot restart? In effect having Spring Boot acting like an OSGi runtime with services being added and removed as required. Is Minho going to proceed? Paul Fraser
Re: Building custom Karaf distribution with Karaf 4.4.4 not working
Hello, I have cutted down our pom and I have found the entry which causes the build failure. We have pax-web-jetty-extras in our bootFeatures. This was needed because of this issue https://github.com/ops4j/org.ops4j.pax.web/issues/1712 . I will check if this feature is still needed. regards Andre
Re: Minho Qusetion
Hello Maybe not very constructive, but I have to add my 2¢... wt., 19 wrz 2023 o 05:16 John Taylor napisał(a): > Hi JB, > > >> . If we have clear signs that people are interested in colocation and > Minho runtime paradigm, it could change :) > This probably isn't exactly what you're referring to, but I'll express > interest as I'm concerned that I won't be able to do things like I have > preferred to and Minho might(?) somehow be a solution. My preference has > been to run all my Camel routes in the Karaf OSGi runtime and not have to > go the multiple spring boot/whatever apps for each context. It's not a > sophisticated setup for sure, but it looks like Camel on OSGi support was > dropped entirely in Camel 4 (components are no longer built with OSGi) so I > won't be able to keep doing that as simply. > You touched very important aspect of OSGi here. I work with OSGi for almost 10 years now and I joined this technology almost at the end of its popularity. You know what happened next - Kubernetes, which made Dockerfile based "application" the golden hammer. Spring Boot (IMO) is better suited to be used as flat-classpath application framework with lots of functionality that makes writing typical applications easier. On the other hand, OSGi is very well designed paradigm based on a network (not hierarchy) of classloaders. And it's OSGi's biggest value and biggest curse to be honest. While I worked on OSGi on "the provider side", I almost never used OSGi as application developer (I was working on frameworks, not applications that work on those frameworks). And yes - you can have multiple Camel contexts, each within its own bundle processed by blueprint extender. Perfectly isolated, tied using OSGi services or Camel routes. With OSGi you can install 3 versions of Jackson libraries and 13 versions of Guava (trust me - I've been there). And this is biggest OSGi problem - not only the "bundles" from Maven central have OSGi manifests because of some ancient contributions, it really requires a lot of discipline to "integrate" complex applications within OSGi - despite its great design. Camel is great example - there are hundreds of components, lots of them are external contributions added to Camel and accepted by PMCs. Some of these components were never maintained since then and were stuck with, say, Guava 13. This made this component using `Import-Package: com.google.common.base; version="[13.0,14)"` - see the problem? It CAN'T work with Guava 14. I believe (but that's my opinion) Camel 4 dropped OSGi support just because of this issue. And also moving from javax to jakarta, where OSGi still lags behind this transition... Kubernetes made most of us think in terms of µservices. But not every problem/system requirement can be solved using this "architecture"... That's just random thought... regards Grzegorz Grzybek > > Sorry, probably out in left field for the discussion. :) > > -John >
Re: Minho Qusetion
Hi JB, >> . If we have clear signs that people are interested in colocation and Minho runtime paradigm, it could change :) This probably isn't exactly what you're referring to, but I'll express interest as I'm concerned that I won't be able to do things like I have preferred to and Minho might(?) somehow be a solution. My preference has been to run all my Camel routes in the Karaf OSGi runtime and not have to go the multiple spring boot/whatever apps for each context. It's not a sophisticated setup for sure, but it looks like Camel on OSGi support was dropped entirely in Camel 4 (components are no longer built with OSGi) so I won't be able to keep doing that as simply. Sorry, probably out in left field for the discussion. :) -John
Re: Building custom Karaf distribution with Karaf 4.4.4 not working
Switching to 4.4.4 on our custom builds went smooth as. Except for my Java 20 branch which died with no longer having javax.activation - tho I suspect that’s more a JDK 20 / ME issue than anything in Karaf. Mark -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On 19/09/2023 at 1:48:24 AM, Grzegorz Grzybek wrote: > Hello > > Hmm, not much has changed between these: > - > https://repo1.maven.org/maven2/org/apache/karaf/features/specs/4.4.3/specs-4.4.3-features.xml > - > https://repo1.maven.org/maven2/org/apache/karaf/features/specs/4.4.4/specs-4.4.4-features.xml > > only the version... > > regards > Grzegorz Grzybek > > pon., 18 wrz 2023 o 15:05 Andre Schlegel-Tylla < > andre.schlegel-ty...@virtimo.de> napisał(a): > >> Hello, >> >> We are building a custom Karaf distro with the karaf-mavem-plugin. I have >> increased the Karaf version from 4.4.3 to 4.4.4. >> >> The maven build is failing with this error: [ERROR] Failed to execute >> goal org.apache.karaf.tooling:karaf-maven-plugin:4.4.4:assembly >> (default-assembly) on project karaf: Unable to build assembly: Could not >> find matching feature for spifly/0.0.0 -> [Help 1] >> >> When I switch back to Karaf 4.4.3 all is working fine. Has anyone an idea >> what the problem is? >> >> Regards >> Andre >> >
Re: Building custom Karaf distribution with Karaf 4.4.4 not working
Hello Hmm, not much has changed between these: - https://repo1.maven.org/maven2/org/apache/karaf/features/specs/4.4.3/specs-4.4.3-features.xml - https://repo1.maven.org/maven2/org/apache/karaf/features/specs/4.4.4/specs-4.4.4-features.xml only the version... regards Grzegorz Grzybek pon., 18 wrz 2023 o 15:05 Andre Schlegel-Tylla < andre.schlegel-ty...@virtimo.de> napisał(a): > Hello, > > We are building a custom Karaf distro with the karaf-mavem-plugin. I have > increased the Karaf version from 4.4.3 to 4.4.4. > > The maven build is failing with this error: [ERROR] Failed to execute goal > org.apache.karaf.tooling:karaf-maven-plugin:4.4.4:assembly > (default-assembly) on project karaf: Unable to build assembly: Could not > find matching feature for spifly/0.0.0 -> [Help 1] > > When I switch back to Karaf 4.4.3 all is working fine. Has anyone an idea > what the problem is? > > Regards > Andre >
Building custom Karaf distribution with Karaf 4.4.4 not working
Hello, We are building a custom Karaf distro with the karaf-mavem-plugin. I have increased the Karaf version from 4.4.3 to 4.4.4. The maven build is failing with this error: [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.4.4:assembly (default-assembly) on project karaf: Unable to build assembly: Could not find matching feature for spifly/0.0.0 -> [Help 1] When I switch back to Karaf 4.4.3 all is working fine. Has anyone an idea what the problem is? Regards Andre
[ANN] Apache Karaf OSGi runtime 4.4.4 has been released!
The Karaf team is pleased to announce Apache Karaf OSGi runtime 4.4.4 release. This is a a maintenance release, bringing a lot of dependency updates and fixes, especially: - fix race condition between the FeatureService and FeatureDeploymentListener - fix --patch-module on Instance startup - add exec:groovy shell command - a lot of dependency updated including CVE fixes (Johnzon, BouncyCastle, Commons FileUpload, and much more !) - better JDK20+ support - and much more! You can take a look on the Release Notes for details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12352693 You can download this release here: https://karaf.apache.org/download.html Enjoy ! The Apache Karaf team
Re: Minho Qusetion
Hi Paul, Yes, that's the idea: having a central/shared registry gathering beans from OSGi, Spring Boot, CDI, whatever. The "dynamic" approach (adding/removing applications managed by a app manager like Spring Boot, OSGi, ...) is also a target. To be honest, currently, Minho is not moving forward due to the low interest we got. If we have clear signs that people are interested in colocation and Minho runtime paradigm, it could change :) Regards JB On Mon, Sep 18, 2023 at 6:29 AM Paul Fraser wrote: > > Hi, > > Cannot quite get my head around Apache Minho but-- > > Can OSGi services be somehow added to the Spring Boot application at > runtime or even at Spring Boot restart? > > In effect having Spring Boot acting like an OSGi runtime with services > being added and removed as required. > > Is Minho going to proceed? > > Paul Fraser > >
