Just a few side notes from my side, not with the intention to fire up things...
2016-07-20 12:05 GMT+02:00 Romain Manni-Bucau <[email protected]>: > 2016-07-20 11:31 GMT+02:00 Werner Keil <[email protected]>: > > Well not yesterday and I think it is time to speak with concrete examples > and no more with words > > It is alkways good to use examples. They are more precise than natural language. That is the reason why I simply implemented things. But being honest, the feedback of especially you, Romain, was IMO often not really usable, due to language issues, half backed sentences or lack of time to provide real examples of code, not only some non compilable snippets that most people here on the list did not understand. So I am looking forward to have a better communication so we understand each other. But blaming the other you were not heard IMO is not reflecting things correctly ;) > > > 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. > We can do that easily, since their are already extensions present doing this, so the basic integration code required is already there ;) > > 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;-) > Why not use the examples area in our project? > this is to start building something and discuss maybe with pull request on > the API > > > > 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. > Yep cause project quickly become unusable for me or too complicated > compared to alternatives - said it several times but ever has been ack-ed. > As I said your feedback was unclear. I also asked you for some code/examples to explain your ideas better. Nothing came back. As I said it is easy to blame others, but in that case I would stop blaming others and ask myself, why my feedback was not taken up. If their are use cases and user feedback that certain functionality is eanted it is useless to argument on mathematical precision, users dont care. If you dont provide examples, it is useless to argue, your arguments were not heard. If you your feedback is not constructrive (just saying it is bad what others did so far) it is useless as well. If you keep that in mind and continue, as you started now for the last couple of days, I am looking forward to get our project to success. Honestly speaking on the other side, if we are discussing around for another month, without any usable results, and not are able also for going on compromises as well, we should stop waste our time ;) > 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. > I could tell you much things you will never believe they happened, but I will not. The only thing important for me is that there are really good reasons, why I say, we should go for a super-simple solutions and keep our attackable space at a ultimate minimum. Given that for me it is clear, and I will not stop to say that, that the API should not propose any kind of organization aspects, beside a super simple default implementation, which can be exchanged completely if necessary. And forget "portability", it is a buzz word, which does not work in reality. Name it "vendor lock-in" and you are much nearer to the reality, at least for classical appservers. Good thing is that with recent things evolved in the infrastructure automation part (docker, mesos etc) lots of this pane areas now are moving into the infrastructure part, so they are not handled anymore in Java... But that is another topic of discussions more related to long dinner or coffee round table. > 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. > Question is: how do we move forward? branch? Github? other? Working on > master will likely not work since we will contradict each others quickly > without being able to discuss > GH is always an option, there everybody can do whatever he/she wants and share it easily. For me personally we should have a voted API until end of August, because I will have talks at conferences starting in September. But looking at the current discussion with about 4-6 artifacts, this should be doable. BTW one reason more for not including the property source stuff into the core API... J A -- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf*
