You asked about what should be in the SPI multiple times and based on the numerous modules (at least some I also saw work in real life when I joined Anatole in Budapest or visited his talk at JavaLand, where you there btw, I believe I saw you in the "Java EE Standup" with Heather and Ed Burns)
Right now (we got PFD last night, another JSR I actively contribute to that will go Final before JavaOne, the only "non Process" one in all of 2016 btw, in 2015 that was 354;-) I focus on getting the existing and active JSR 363 out. Beside speaking about it (but I'm not the only one, aside from Apache Big Data I spoke at DevoXX we won a JCP Award, Otavio and Leonardo must have spoken twice at JavaOne Brazil and Leo did with Chris in London) we already see major players in Open Source like Red Hat apply it in Parfait/Performance Co-Pilot. Tamaya as use case for configuration similar to Typesafe HOCON is also mentioned in the PFD, check it out: https://jcp.org/aboutJava/communityprocess/pfd/jsr363/index.html Unless extensibility with Date/Time (either Java SE 8 or JodaTime like the existing extension) Units (JSR 363) or say Money (JSR 354) are completely ripped-out based on what "everybody" wants, I intend to create such module similar to the Joda one. I admit I have not been touching the codebase due to other responsibilities but I was always active on the mailing list or in JIRA. Take other projects like Eclipse STEM. I have not committed code and mostly came across it when my active involvement in Eclipse Babel (as language and translation committer and "Language Champion" aka Spell checker for German) came to their attention and they needed help with localizing STEM. I am not an epidemiology expert myself thus I also did not push to its repo but next to Jamie and a few others at IBM or BFR in Berlin I held most STEM talks all across the world from JavaPolis (yes, still named that way then) to a major SouJava event in Sao Paulo (at IBM Brazil) Bangalore in India, EclipseCon US and multiple occasions in Europe also both EclipseCon France and what's now EclipseCon Europe. You can also help projects by spreading the word and STEM did not just get exposure and interest because of the Swine Flu, Ebola or Zika virus;-) So far about Tamaya other than Anatole (and I was co-speaker at least once or twice) nobody gave a Tamaya talk I recall. Eitehr his or my talks to DevoXX Morocco or Geecon both didn't work mostly due to time conflicts, I had DevoXX BE and Anatole was in Vancouver during Geecon while I had a mandatory EC F2F responsibility in Berlin that week) Why wasn't anybody able to step in for us or speak about it elsewhere??? Cheers, Werner On Wed, Jul 20, 2016 at 1:50 PM, Mark Struberg <[email protected]> wrote: > Werner, I slowly wonder whether we both are writing on the same topic or > list. > > Where in the whole original thread and other recent threads did you > propose an API? > The only thing I could find is links to other existing configuration > libraries. > You also didn’t do any code on the tamaya API. > Did I miss something or what are you talking about? > > Anatole committed code. Code is better than many words. But _not_ if there > are already quite a few -1 for the proposed design. > In that case Code is _still_ better. But let’s not commit it to the > official ASF repo if it is felt as premature by the community. > Ship patches, code in a mail or showcase the ideas on github. > There is a chance that the ones who initially don’t like the code still > don’t get it yet and first need to see it. > But what if they were right and it is not good enough? Then we have all > those changes in our history and need to do all sorts of ugly cleanup. > > And no, it’s not a ‚boards view‘. Nowhere in Tamaya is the ASF board > involved yet. And be happy about that, because IF they feel that there is > something to fix, then this usually doesn’t happen by using a band-aid but > an axe… > > LieGrue, > strub > > > > Am 20.07.2016 um 11:31 schrieb Werner Keil <[email protected]>: > > > > 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 > >
