You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Mark Struberg (JIRA)" <ji...@apache.org> on 2016/08/01 06:43:20 UTC
[jira] [Commented] (TAMAYA-169) streamline the API and work towards
a JSR proposal
[ https://issues.apache.org/jira/browse/TAMAYA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401607#comment-15401607 ]
Mark Struberg commented on TAMAYA-169:
--------------------------------------
Let's run down your questions:
* connecting to Consol or other popular config servers
Perfectly possible with my approach. Just provide a custom ConfigSourceProvider who picks up the information from Consul (which is btw not a config server but a service orchestration framework).
The bug is that the Tamaya API contains many additional concepts which blur the line, are redundant and not clearly recognizable. E.g. ConfigQuery vs ConfigOperator.
> Tamaya is a result of the JCP EC not finding enough working use cases for configuration
> to consider standardizing it when discussed by Anatole and others.
Txs, I was a very active part of it. Gerhard and I also had quite a few personal meetings with Mike back then (starting as early as 2012 or 13).
If you check the posts from the google group from back then ( https://groups.google.com/forum/#!forum/java-config ) then you will see that many of the technical discussion points are actually from me. So I'm not sure what you like to tell us?
> streamline the API and work towards a JSR proposal
> --------------------------------------------------
>
> Key: TAMAYA-169
> URL: https://issues.apache.org/jira/browse/TAMAYA-169
> Project: Tamaya
> Issue Type: Improvement
> Components: API
> Reporter: Mark Struberg
> Assignee: Mark Struberg
>
> The current Tamaya API is a tad too large to be easily understandable. It contains many nice features, but many of them are not core-features.
> I'd like to provide a very minimal set of absolutely necessary classes and interfaces.
> For a prototype see
> https://github.com/struberg/incubator-tamaya/tree/jsr-proposal/jsr/api/src/main/java/tamaya/config
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [jira] [Commented] (TAMAYA-169) streamline the API and work
towards a JSR proposal
Posted by Werner Keil <we...@gmail.com>.
Please let's not pollute JIRA again either;-O
Extensions like Consul should IMHO be in a totally separate ticket, we're
not in a company or project where for statistic reasons we're forced to
keep the number of JIRA issues to a minimum.
If Consul or Etcd support is discussed and a use case defined, please let's
add a "New Feature", "User Story" or "Wish" ticket for that first ;-)
https://issues.apache.org/jira/browse/TAMAYA-169 is about refactoring the
API. At most offer "hooks" other extensions and services may use, but we
should not elaborate every possible use case in this ticket.
Thanks,
Werner
On Mon, Aug 1, 2016 at 9:09 AM, Anatole Tresch <at...@gmail.com> wrote:
> Hi Guys
>
> Only a few points from my side:
>
> 1) focus on code. I and Mark put together a streamlined version IN CODE,
> which works well also with advanced real world use cases. Even the fact
> that my repo does not compile does not harm. Said that give feedback in
> code as well. Clone the repo or create your own, but I will only discuss
> things regardin the api in code form. If you dont find time for creating
> some code you should accept any decisions taken.
> 2) be open for compromises and respect each others experience and
> background. Withou that there will be nor tamaya nor a jsr. Or in other
> words start working together, start encouraging each other. If you see
> something that could be better, explain it by code, mentioning what is
> better. It is useless to mention why the other code is bad, it is not. At
> the end of the day people using your code decide if they like it. If your
> code is mathemarically minimized but lacks day2day features people will not
> use it. Similarly if there are too many features it is confusing. Said this
> read again the first part of this bullet point.
> 3) focus also on delivery. If we dont get the next release out until end of
> august I will fork my own on gh because I need a runnable version and I am
> not willing discussing much longer than 1 month. If we dont get an
> agreement (see also to point 2) we will never get one. In that case some
> further competition is not a bad thing😂
> 4) when is our next hangout? This evening?
>
> Thanks, have a nice day!
>
> Anatole
>
> Am 01.08.2016 08:43 schrieb "Mark Struberg (JIRA)" <ji...@apache.org>:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/TAMAYA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401607#comment-15401607
> > ]
> >
> > Mark Struberg commented on TAMAYA-169:
> > --------------------------------------
> >
> > Let's run down your questions:
> >
> > * connecting to Consol or other popular config servers
> > Perfectly possible with my approach. Just provide a custom
> > ConfigSourceProvider who picks up the information from Consul (which is
> btw
> > not a config server but a service orchestration framework).
> >
> > The bug is that the Tamaya API contains many additional concepts which
> > blur the line, are redundant and not clearly recognizable. E.g.
> ConfigQuery
> > vs ConfigOperator.
> >
> > > Tamaya is a result of the JCP EC not finding enough working use cases
> > for configuration
> > > to consider standardizing it when discussed by Anatole and others.
> > Txs, I was a very active part of it. Gerhard and I also had quite a few
> > personal meetings with Mike back then (starting as early as 2012 or 13).
> >
> > If you check the posts from the google group from back then (
> > https://groups.google.com/forum/#!forum/java-config ) then you will see
> > that many of the technical discussion points are actually from me. So I'm
> > not sure what you like to tell us?
> >
> > > streamline the API and work towards a JSR proposal
> > > --------------------------------------------------
> > >
> > > Key: TAMAYA-169
> > > URL: https://issues.apache.org/jira/browse/TAMAYA-169
> > > Project: Tamaya
> > > Issue Type: Improvement
> > > Components: API
> > > Reporter: Mark Struberg
> > > Assignee: Mark Struberg
> > >
> > > The current Tamaya API is a tad too large to be easily understandable.
> > It contains many nice features, but many of them are not core-features.
> > > I'd like to provide a very minimal set of absolutely necessary classes
> > and interfaces.
> > > For a prototype see
> > >
> >
> https://github.com/struberg/incubator-tamaya/tree/jsr-proposal/jsr/api/src/main/java/tamaya/config
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.4#6332)
> >
>
Re: [jira] [Commented] (TAMAYA-169) streamline the API and work
towards a JSR proposal
Posted by Anatole Tresch <at...@gmail.com>.
Hi Guys
Only a few points from my side:
1) focus on code. I and Mark put together a streamlined version IN CODE,
which works well also with advanced real world use cases. Even the fact
that my repo does not compile does not harm. Said that give feedback in
code as well. Clone the repo or create your own, but I will only discuss
things regardin the api in code form. If you dont find time for creating
some code you should accept any decisions taken.
2) be open for compromises and respect each others experience and
background. Withou that there will be nor tamaya nor a jsr. Or in other
words start working together, start encouraging each other. If you see
something that could be better, explain it by code, mentioning what is
better. It is useless to mention why the other code is bad, it is not. At
the end of the day people using your code decide if they like it. If your
code is mathemarically minimized but lacks day2day features people will not
use it. Similarly if there are too many features it is confusing. Said this
read again the first part of this bullet point.
3) focus also on delivery. If we dont get the next release out until end of
august I will fork my own on gh because I need a runnable version and I am
not willing discussing much longer than 1 month. If we dont get an
agreement (see also to point 2) we will never get one. In that case some
further competition is not a bad thing😂
4) when is our next hangout? This evening?
Thanks, have a nice day!
Anatole
Am 01.08.2016 08:43 schrieb "Mark Struberg (JIRA)" <ji...@apache.org>:
>
> [
> https://issues.apache.org/jira/browse/TAMAYA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401607#comment-15401607
> ]
>
> Mark Struberg commented on TAMAYA-169:
> --------------------------------------
>
> Let's run down your questions:
>
> * connecting to Consol or other popular config servers
> Perfectly possible with my approach. Just provide a custom
> ConfigSourceProvider who picks up the information from Consul (which is btw
> not a config server but a service orchestration framework).
>
> The bug is that the Tamaya API contains many additional concepts which
> blur the line, are redundant and not clearly recognizable. E.g. ConfigQuery
> vs ConfigOperator.
>
> > Tamaya is a result of the JCP EC not finding enough working use cases
> for configuration
> > to consider standardizing it when discussed by Anatole and others.
> Txs, I was a very active part of it. Gerhard and I also had quite a few
> personal meetings with Mike back then (starting as early as 2012 or 13).
>
> If you check the posts from the google group from back then (
> https://groups.google.com/forum/#!forum/java-config ) then you will see
> that many of the technical discussion points are actually from me. So I'm
> not sure what you like to tell us?
>
> > streamline the API and work towards a JSR proposal
> > --------------------------------------------------
> >
> > Key: TAMAYA-169
> > URL: https://issues.apache.org/jira/browse/TAMAYA-169
> > Project: Tamaya
> > Issue Type: Improvement
> > Components: API
> > Reporter: Mark Struberg
> > Assignee: Mark Struberg
> >
> > The current Tamaya API is a tad too large to be easily understandable.
> It contains many nice features, but many of them are not core-features.
> > I'd like to provide a very minimal set of absolutely necessary classes
> and interfaces.
> > For a prototype see
> >
> https://github.com/struberg/incubator-tamaya/tree/jsr-proposal/jsr/api/src/main/java/tamaya/config
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>