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*
