It sounds good ! Thanks for the proposal. Let me know if you need help with Jira, I will do the improvement.
Regards JB > Le 11 juin 2021 à 12:35, Łukasz Dywicki <l...@code-house.org> a écrit : > > Indeed It is the same mechanism I would love to see employed in > mentioned places. > > The way how custom.system.properties works is great. Combined with > property resolver and fallbacks we can save peoples time in > synchronizing (jre|custom).properties. > > I will try to book some time for this to register JIRA and cook an PR in > coming weeks (please don't be surprised if it will turn into a month). > > Best, > Łukasz > -- > Integrate software (Code-House) & hardware (ConnectorIO) > http://code-house.org > http://connectorio.com > > On 11.06.2021 12:25, Jean-Baptiste Onofre wrote: >> Hi Lukasz >> >> It’s a good idea for system/custom properties. It’s similar/extend of the >> custom.system.properties we already have in system.properties right ? >> >> For json/cfg files, it’s not necessary as we can already override with >> system properties or env variables (useful with docker) IMHO. >> >> Regards >> JB >> >>> Le 11 juin 2021 à 10:34, Łukasz Dywicki <l...@code-house.org> a écrit : >>> >>> Hey all, >>> >>> I recently been going over few Karaf assemblies I created in past years >>> and I realized that in many cases I had to copy entire configuration >>> shipped by Karaf distribution in order to include a new config in >>> bootstrap process. >>> Quite often my requirements were quite small, yet I had to create two >>> files and take care of updates of distro shipped file in order to keep >>> assembly well behaving. >>> >>> Looking at base resources: >>> https://github.com/apache/karaf/tree/karaf-4.3.2/assemblies/features/base/src/main/filtered-resources/resources/etc >>> >>> If distro builder wants to override or extend any of properties defined >>> in these he needs to copy a whole file. While it is not a problem for >>> custom properties it is a burden for jre and system properties which >>> vary between releases. >>> >>> This week I attempted a bit simplified approach which can be summarized as: >>> 1) Define default ${optionals} dedicated to overrides, ie. ${optionals} >>> = custom.config.properties >>> 2) Update each interesting system property to contain an placeholder >>> with fallback. For example: >>> org.osgi.framework.system.packages=\ >>> ... \ >>> org.apache.karaf.info;version="4.2.9",\ >>> ${jre-${java.specification.version}}, \ >>> ${custom.org.osgi.framework.system.packages:-} >>> >>> With this approach user who needs to add an extra import or export for >>> his environment needs to do just one thing. Create a >>> "custom.config.properties" file with a single line: >>> custom.org.osgi.framework.system.packages=jdk.internal.math >>> >>> Packager work related to overrides of distro files is completely >>> removed. More over this also leaves end user free of the need to fight >>> ordering of dependencies in maven poms to shade Karaf defaults. >>> >>> While above is quite handy there is a security consideration to be made. >>> First of all, creation of an optional file might simplify process of >>> affecting existing Karaf installations through easier injection of >>> additional options. I believe that proper file and folder permissions >>> should prevent that, however it must be noted that distro will have more >>> flexible configuration injection with all pros and cons. >>> >>> Best, >>> Łukasz >>> -- >>> Integrate software (Code-House) & hardware (ConnectorIO) >>> http://code-house.org >>> http://connectorio.com >>
