Hi Cameleers, I'm for splitting, I think in mid to long term this will enable us to run checks on pull requests and allow us to iterate faster.
I think we should rethink release process, in a sense that I think we should try to release from several repositories at the same time. Not sure if there's a way to ease the effort for the release manager, but perhaps we should try to invest into that as well. zoran On Fri, Mar 13, 2020 at 11:06 AM Jean-Baptiste Onofre <j...@nanthrax.net> wrote: > > Hi Andrea, > > It makes sense to "mimic" spring-boot. > > I have some WIP on Camel Karaf (not directly related to OSGi). I also have > some non-OSGi Karaf support, but it will be similar to some starter/BOM > similar to spring-boot. > > Regards > JB > > > Le 13 mars 2020 à 10:00, Andrea Cosentino <ancosen1...@yahoo.com.INVALID> a > > écrit : > > > > Hello, > > > > We already moved the Spring Boot code and all the SB starters into a > > separated git repository for convenience and to make the core independent. > > And the same was done for Camel Quarkus, which started as a separated sub > > project from the beginning. And we also recently moved the examples out > > into its own git repository. > > > > We should do the same for Karaf/OSGi support for multiple reasons: > > - Having a separated repository will make easier and faster to release new > > stuff and fixes without rebuilding the core part (this would be something > > really useful) > > - We could have separated documentation as we already have for Spring Boot > > - We could make the main camel repository lighter > > - It’s much easier to find code related to OSGi/Karaf as its all together in > > - We can then add Karaf as a sub project to the Camel website (see projects > > menu item) > > - We can have separated documentation on the website for Karaf/OSGi > > - We can generate a list of components that are supported in Karaf/OSGi and > > also publish this on the website > > > > If we follow this path, we could be able to add new supported platforms in > > the future without having to modify the core part. > > > > We envision that we only need to move core/camel-core-osgi, and all the > > osgi components, and together with the karaf features and karaf commands, > > and the itests. We will continue to generate OSGi MANIFEST.MF in the JARs > > from the main Camel so they are still OSGi bundles. > > > > The end result would essentially be the same as today. Camel will continue > > to be supported and work on Karaf. > > > > And we think we should do this before the first LTS release of Apache > > Camel, which is planned to be Camel 3.3.0. So ideally we get this done for > > Camel 3.2.0 so more people in the community can get their hands on a > > release and provide feedback. > > > > This will require some effort but we do believe it’s worth the work. > > > > Thoughts? > > > > -- > > Andrea Cosentino > > ---------------------------------- > > Apache Camel PMC Chair > > Apache Karaf Committer > > Apache Servicemix PMC Member > > Email: ancosen1...@yahoo.com > > Twitter: @oscerd2 > > Github: oscerd > -- Zoran Regvart
