about envrt 2 things: 1- proposal about [lang3] was to add to tamaya the 2-3 classes involved (not to add any dependeny, parsing is simple) 2- nothing against not having it for a 0.1 but think the topic will come back since not having a small dsl for system props and environment properties sounds quite frustrating very quickly
That said +1 to go ahead without it to start to get something concrete Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-03-03 13:13 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Oliver/Romain > > I never meant about reading things in order (ordering is done based on > ordinals), but I agree with the ordinal we are flexible enough. > We can still agg stage or test support as extension, so I will not stick to > it ;) > > Summarizing: > > - Read environment variable: question where and how to map it...? > - Read META-INF/configuration.properties available > - Read system properties > > So we have to discuss the proposal from Romain about adding dynamic > expressions for environment properties... > I am strictly against it, since > - it is not a core feature > - we can omit environment properties at all in Core > - Core should be minimalistic (no dependencies that are not ultimately > needed, so also no strsubstictutor of [lang3] ). So if we cannot agree to > add env properties somehow to a mapped namespace in the config tree (which > is common use), I would not include environment properties at all with > core. The resolver module brings basically exact the described > functionality, so if someone needs it, he can just use this module... > > WDYT? > > > 2015-03-03 12:38 GMT+01:00 Oliver B. Fischer <[email protected]>: > > > Hi Anatole, > > > > first, let us exclude the discussion on stages. In generell I think this > a > > usefull and needed feature. > > > > But why do we need to read the properties in a specific order? Futhermore > > does it help if there a many differente jars. How do we handle this? > > > > And just as a question? Why is the ordinal (priority) not enough? > > > > Just questions. > > > > Bye, > > > > Oliver > > > > > > Am 03.03.15 um 09:19 schrieb Anatole Tresch: > > > >> Dear all > >> > >> I am currently updating the site and documentation, to approach further > a > >> first release. I am not happy with the current default config setup in > >> Core. I would propose to provide the following setup (PropertySources > and > >> providers), from weakest to strongest: > >> > >> 1. Read *environment properties* and add them prefixed with "env." > >> 2. Read all files found in *META-INF/cfg/defaults.properties* > >> 3. Read all files found in* META-INF/cfg/${stage}/defaults.properties* > >> 4. Read all files found in *META-INF/cfg/config.properties* > >> 5. Read all files found in *META-INF/cfg/${stage}/config.properties* > >> 6. Read current *system properties*. > >> > >> Given that we have simple and enough powerful variant, which can be > >> implemented very easily. > >> If no stage is set, the stage specific parts are not read. The stage can > >> be > >> set by applying a > >> environment property or (overriding) system property, named > >> > >> *tamaya.stage* > >> > >> I expect the Core and API module together not exceed 100k in Java 8 ;) > >> > >> WDYT? > >> > >> Anatole > >> > >> > >> > > -- > > N Oliver B. Fischer > > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > > P +49 30 44793251 > > M +49 178 7903538 > > E [email protected] > > S oliver.b.fischer > > J [email protected] > > X http://xing.to/obf > > > > > > > -- > *Anatole Tresch* > Java Engineer & Architect, JSR Spec Lead > Glärnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > <http://javaremarkables.blogspot.ch/>* > > *Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>* >
