You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Oliver B. Fischer" <o....@swe-blog.net> on 2014/12/16 08:55:12 UTC
Use case discussion and examples?
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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Use case discussion and examples?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+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 <at...@gmail.com>:
> 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 <rm...@gmail.com>:
>>
>> 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 <at...@gmail.com>:
>> > 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 <o....@swe-blog.net>:
>> >>
>> >> 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 o.b.fischer@swe-blog.net
>> >> S oliver.b.fischer
>> >> J oliver.b.fischer@jabber.org
>> >> 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*
Re: Use case discussion and examples?
Posted by Anatole Tresch <at...@gmail.com>.
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 <rm...@gmail.com>:
>
> 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 <at...@gmail.com>:
> > 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 <o....@swe-blog.net>:
> >>
> >> 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 o.b.fischer@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fischer@jabber.org
> >> 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*
Re: Use case discussion and examples?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <at...@gmail.com>:
> 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 <o....@swe-blog.net>:
>>
>> 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 o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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*
Re: Use case discussion and examples?
Posted by Anatole Tresch <at...@gmail.com>.
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 <o....@swe-blog.net>:
>
> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> 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*