Hi Zoran, I think we can do all releases in a row using kind of meta repository. The release manager should be careful to checkout all required repositories.
Thoughts ? Regards JB > Le 13 mars 2020 à 15:02, Zoran Regvart <zo...@regvart.com> a écrit : > > 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
