Romain/all, About your question, have you read the whole thread. (I agree it's long with several of us contributed to it)?
I was the only one who proposed a minimal content of an SPI package while everyone else just kept asking questions or saying "it's hard" or "it's impossible to standardize". Start with what's working already. If as Anatole suggested concrete solutions for Consul, Etcd and others work based on a minimal API interface, then let's focus on making some of those demos work. What exactly do you mean with "github demo"? If it's a concrete use case showing how end users or applications may use Tamaya great, I guess it can use it and Anatole (with a little help by me at some events) shouldn't be the only one touring and being able to talk about it;-) I was hoping to contribute to extension and integration modules mostly at first, but if the "core" needs help or everyone thinks that refactoring is necessary and healthy, then I'm happy to help. Without mostly 3 EG members (Anatole, myself and Otavio) JSR 354 would not exist or the EC would have long shut it down. I am also the only person in the PMC who actively commits code to Apache DeviceMap or talks about it on occasions. Not to mention Spec Lead of a JSR, but there while I do a lot others also help and we work in an Agile manner with regular "sprints" and also exchange a bit like a retrospective. It can be done in a distributed team if you are experienced and got enough discipline for it. The next phase of JCP.next should likely take a look at more transparency, e.g. not only if deadlines are met, but if people work open and transparently in the meantime, e.g. by looking at mailing list archives, Commit stats or similar, just take a usual Apache board report ;-) For Tamaya https://github.com/apache/incubator-tamaya/graphs/contributors neither you nor Mark have pushed code for over a year. You made a single commit with a single line of code !!! While Mark initially did help quite a bit and next to Anatole was the second most active person taking at least the number of lines he added or removed. It's a pity having to do "board duties" here, but happy to help, I don't seem the only one thinking the industry can use standardization in this area. And similar to "Money" every single project and enterprise keeps reinventing the wheel for more than 15 years in Java while other platforms (take .NET) have got a default way to approach that. So do very popular frameworks and environments like Spring or Play (that's why Typesafe Config was born;-) The key reason why Tamaya was "born" is to create an open source "PoC" in a collaborative environment for a possible future JSR. The EC (check https://jcp.org/en/resources/EC_summaries don't know the exact date, maybe Anatole does) recommended to so so after none of the "Usual Suspects" (Oracle, Red Hat or maybe IBM) were able or willing to help continue what Oracle's Mike Keith had originally started. And e.g. Anatole found it useful based on what his then company and others keep doing over and over again. Nobody would blame or prevent some of you if you prefer to create another PoC, the EC and ecosystem does not mind. Otherwise let's try to make and keep it useful. If a neat and "lean" API can no longer be used by all the various use cases it fails and trying to standardize it would make even less sense. If you can get a demo out, maybe even something along the lines of that Microservice PoC (some at Tomitribe contribute, I guess it's mostly David) rather than hidden in your own private repositories, that would be useful and bring Tamaya closer to shaping a possible standard. Cheers, Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | Eclipse UOMo Lead, Babel Language Champion | Apache Committer Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap | #DevOps | #EclipseUOMo Skype werner.keil | Google+ gplus.to/wernerkeil
