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*
