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*
