+1
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-16 11:47 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Romain > > actually the question is legitimate. Basically the idea of property source > is to have a minimal easy to implement interface. Configuration extends it > with additional features. Originally I was thinking on combining property > sources in different ways to at the end build a configuration decorator > around it. Obviously from a user perspective this creates some confusion. > On the other hand we might want to keep the basic builder that is able to > work with property sources only (we can move it e.g. into the spi part). > Additionally add the same thing dealing with Configuration as a > ConfigurationBuilder to the API? > > WDYT? > > > 2014-12-16 10:27 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> >> Surely stupid question (sorry if I missed the reason) but why >> PropertySourceBuilder and not ConfigurationBuilder? >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-16 9:59 GMT+01:00 Anatole Tresch <[email protected]>: >> > Hi Oliver >> > >> > Configuration cfg = Configuration.current(); >> > >> > MyTemplate template = Configuration.getConfiguration(template); >> > >> > MyAnnotatedClass cl = new MyAnnotatedClass(); >> > configuration.configure(cl); >> > >> > Environment env = Environment.current(); >> > >> > *That is the main API and nothing more.* Hereby the Environment part even >> > can be hidden to users and moved to the SPI part, if we like. What could >> be >> > simpler? >> > The other aspects discussed basically can also be used from an API side, >> > but typically things are more happening in the back side typically, when >> > implementing ConfigurationProvider. >> > *Users *will add and provide their configuration files or resources, when >> > building their projects. Or manage a configuration database, but they >> will >> > NOT care about the inner workings. And this is good so! >> > >> > But also looking at the SPI side: >> > >> > Configuration config = >> > >> PropertySourceBuilder.of("MyPropertyConfig").addPaths("META-INF/myCOnfig.properties").build().toConfiguration(); >> > >> > Do you want to read and search the classpath manually? I don't see much >> > room to do it more simpler. Always remember: we design here for >> enterprise >> > environments as well. Thinking on system property level only will not be >> > enough. Despite the functionality and flexibitiliy we have, I think the >> API >> > is really easy to use. >> > >> > Related to *Environment *I am currently preparing a follow up post, >> since I >> > think this is a part we can do more easily. >> > >> > Next in row I will catch up on the relationship between Configuration and >> > Environment (the ConfigurationProvider). As a use case, I will use a Java >> > EE application there, with classpath and domain file configuration. >> > >> > Adding an example subproject is definitively worth while. Some example >> will >> > be easily doable with JUnits. But more complex stuff, will require >> running >> > servers such as Jetty, Tomcat or even a EE container. >> > >> > Finally, and this is the upper most important for me: please *write >> > explicitly, where things should be improved and why (be constructive)*. I >> > am pleased to discuss your ideas. >> > >> > Best, >> > Anatole >> > >> > >> > 2014-12-16 8:55 GMT+01:00 Oliver B. Fischer <[email protected]>: >> >> >> >> Hi all, >> >> >> >> IMHO the improvement of the bootstrapping process was a big step >> forward. >> >> But I still have some problems with the API. From my point of view we >> miss >> >> a simple entry point. Maybe I still haven't got and this might be my >> fault, >> >> but from an enduser perspective it is important to have an 'dumb' and >> easy >> >> to grasp API. >> >> >> >> Some weeks ago we startet with a discussion of use cases. I found this >> >> approach very usefull and would like to continue with this approach. I >> even >> >> think we should add an examples/usecase module to Tamaya. >> >> >> >> A usecase should be writen as normal unit test. So we can ensure that >> the >> >> given example is working with the current implementation. >> >> >> >> Additionally each use case should be come with an good JavaDoc (via >> >> Asciidoctor) documentation, which explains the usecase and the >> mechanisms >> >> behind it. >> >> >> >> WDYT? >> >> >> >> Oliver >> >> >> >> -- >> >> 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* >> > > > -- > *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*
