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)" <[email protected]>: > > [ > 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) >
