as mentionned in another answer I think we can remove it from the API
and add it in our default *implementation* of "configuration
providers". I agree this feature is nice but I also agree with Mark:
this is nota first citizen of the API.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-12-24 10:07 GMT+01:00 Anatole Tresch <[email protected]>:
> Hi Oliver
>
> basic legit arguments, and I agree of the formats mentioned are not the
> ultimate winners. So the question goes to all: what do the other here on
> the list think on a default configuration formats...
>
> Cheers,
> Anatole
>
> 2014-12-24 9:56 GMT+01:00 Oliver B. Fischer <[email protected]>:
>
>> See inline...
>> Am 24.12.14 um 02:07 schrieb Anatole Tresch:
>>
>>> 3.) Should we define any configuration formats, and if so which one?
>>> *-> I would like to see a minimal set of formats in core, so we can
>>> provide a minimal dependency version that fits most needs.
>>> .properties,
>>> .xml(properties) and .ini I think is a good set, but definitively not
>>> more.*
>>> *-> We can then leverage apache commons config with bridges in the
>>> extension modules for suporting additional formats ;). *
>>>
>>
>> At my company we use mostly https://github.com/typesafehub/config/blob/
>> master/HOCON.md and YAML. For me only property files and the other
>> mentioned formats feel a little bit outdated. Not only because they exist
>> already for a long time but for their usability.
>>
>> Writing large configurations is mostly about structuring the information
>> you provide. In this area are property files weak and no one wants XML
>> again. If I would tell this someone around me the answer would be: "Come
>> back if you have something more usefull."
>>
>> --
>> 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*

Reply via email to