Tamaya Activity ("Board's eye view")

[Werner Keil <we...@gmail.com>]

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

Re: Tamaya Activity ("Board's eye view")

[Werner Keil <we...@gmail.com>]

On Wed, Jul 20, 2016 at 12:53 PM, Anatole Tresch <at...@gmail.com> wrote:

> 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 <rm...@gmail.com>:
>
> > 2016-07-20 11:31 GMT+02:00 Werner Keil <we...@gmail.com>:
> >
> > 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 ;)​
>
>
>
That's where I suggested, that the minimum an SPI must provide is the
equivalent to PropertySource and maybe PropertySourceProvider. Allowing
those extensions to still work with a future design.


>
> > > 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
>
>
>
Having a consensus and new incubator release before e.g. JavaOne (and
subsequent ApacheCon EU) sounds good. At least JavaOne, possibly also other
events (DevoXX, Codemotion maybe Java2Days/Cloud2Days) should they invite
someone for a Tamaya talk this year often include hackathons or
Hackergarten. That can't replace regular contribution and one or more
strong Spec Leads who have enough time to drive it forward, take e.g. JSR
377 (the only one where the Spec Lead isn't Oracle that is stalled or going
nowhere;-|) but it often helped to exchange ideas with more than just the
immediate contributors and meet members of the community in person. While
it's often given to people inside Oracle neither Star Spec Lead nor JCP
Award(s) Anatole and his predecessor Victor won for no reason.

Other JSRs and Spec Leads not all of them embracing a democratic,
collaborative way of running their projects and specs were nominated but so
far haven't won anything.

Cheers,
Werner


>
> --
> *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*
>

Re: Tamaya Activity ("Board's eye view")

[Anatole Tresch <at...@gmail.com>]

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 <rm...@gmail.com>:

> 2016-07-20 11:31 GMT+02:00 Werner Keil <we...@gmail.com>:
>
> 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*

Re: Tamaya Activity ("Board's eye view")

[Romain Manni-Bucau <rm...@gmail.com>]

2016-07-20 11:31 GMT+02:00 Werner Keil <we...@gmail.com>:

> 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".
>
>
Well not yesterday and I think it is time to speak with concrete examples
and no more with words


> 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;-)
>
>
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.


> 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.
>
>
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


> 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
>

Re: Tamaya Activity ("Board's eye view")

[Werner Keil <we...@gmail.com>]

Or take a myriad of JSRs I help one way or the other. Not every EG member
always commits the same amounts of code, some probably never do, especially
if the driving companies (Red Hat, Oracle or IBM on the EE side) mostly
prefer to do that by themselves.
The last time you (Mark) seem to have committed to CDI must have been 1.1
or so (up to 4 years ago) since then John was probably a notable non-Red
Hat EG member who did. Both Anatole, myself or e.g. Otavio are in the EG
but we have not touched the code. Nevertheless at least I try to join calls
as often as I can. And participate on the mailing list.

You'll find plenty of other JSRs e.g. both ME 8 JSRs where I was the only
Individual you saw contribute to design decisions and join EG calls in most
cases. Similar with JSRs on the EE side including the EE Umbrella, JPA,
JSF, JSON-P or JMS.
With Security (375) next to countless effort by Arjan I did most work not
only speaking. I see, Mark you even made 3 commits over a year ago to its
"sandbox". I'm afraid the Spec Lead isn't too responsive, but if they pick
up again, I'm sure the JSR was more than happy to list that in the new
"Contributor" section.

If JSR 375 created the impression one can simply fork or do "your own JSR"
then sorry for that on behalf of Alex or David who started this "sandbox".

It's a bit of a "jigsaw puzzle" and having Soteria contain an "embedded
API" is more than sad, but some members of the EG like Arjan, Ivar myself
and occasionally others spreading the word and trying to get it to a
working shape is not easy with a "Spec Lead Emeritus" until Oracle decides
what it wants to do.
That's why we should wait before proposing new JSRs how the life of
existing ones goes, especially those Java EE relevant (and as much as CDI2
or Tamaya/Config should work for desktop/RCP they play their biggest role
in the Enterprise, so they're both EE-relevant if not possible parts of
future EE umbrella distros)

Werner

Re: Tamaya Activity ("Board's eye view")

[Werner Keil <we...@gmail.com>]

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 <st...@yahoo.de.invalid>
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 <we...@gmail.com>:
> >
> > 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
>
>

Re: Tamaya Activity ("Board's eye view")

[Mark Struberg <st...@yahoo.de.INVALID>]

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 <we...@gmail.com>:
> 
> 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