Re: [VOTE] fundamental goals of Tamaya

[Gerhard Petracek <gp...@apache.org>]

in addition:
compared to other topics in this thread it isn't even OT to talk about
ds-config, because the suggested API is heavily influenced by it and we
already have a reality-check for ds-config. if there is no concrete and
common use-case (which isn't possible), there is no valid point against
ds-config (and therefore against the suggested api) imo.
general statements like "project xyz couldn't use it, but it isn't possible
to provide details" don't provide any useful feedback.
it should be always possible to show aspects/limitations/... in general. if
it isn't possible then the project (which couldn't use it) is that special
that it isn't representative for the majority and therefore it can't be a
valid argument against a suggestion/api/... which should fit for most (but
not all) projects out there.

regards,
gerhard



2016-07-31 22:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:

>
> > Am 31.07.2016 um 21:51 schrieb Werner Keil <we...@gmail.com>:
> >
> > Just don't communicate about DS here, this is not a  DS mailing list;-)
> >
> > Cheers
>
>
> I guess Gerhards point is that you permanently spread wrong information
> about DeltaSpike.
> Not only here, but also in JCP groups, over at microprofile.io etc.
> Gerhard just wanted to get things straight.
>
> Maybe because you didn’t know any better. Despite we tried to explain it
> to you for quite some time already.
> But anyway, now you know that it works, so please stop spreading wrong
> information.
>
> LieGrue,
> strub
>
>

Re: [VOTE] fundamental goals of Tamaya

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

And especially if you look at overlapping concepts and items you mentioned
like ConfigQuery vs. ConfigOperator,
Look at Period ("2 years, 3 months and 4 days") vs. Duration ('34.5
seconds') IMHO highly redundant. Other parts of the JDK like JavaFX make no
difference, so that could have been simplified (if the Spec Lead was as
open to compromises as say Anatole or myself;-)

And

   - Temporal
   <https://docs.oracle.com/javase/8/docs/api/java/time/temporal/Temporal.html>
   - TemporalAccessor
   <https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalAccessor.html>
   - TemporalAdjuster
   <https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalAdjuster.html>
   - TemporalAmount
   <https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalAmount.html>
   - TemporalField
   <https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalField.html>
   - TemporalQuery
   <https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalQuery.html>
   - TemporalUnit
   <https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalUnit.html>

Does that sound familiar?;-)

The Jodaisms in Joda-Money were transferred into JSR 354 in a "milder"
form. Stephen was member of the EG (after a JSR goes final it technically
no longer exists, only the Spec/Maintenance Lead) so not every single
element, but some were also modeled after and inspired by JSR 310 (or where
better applicable Joda-Money)

I'm not saying everything may be perfect and there are probably a few
redundancies like MonetaryQuery vs. MonetaryOperator, but it was developed
by an EG with members everywhere from "Crazy Bob" (as he worked at Square
then) to Stephen (also works in a finance-related firm I think) and
several, in the end just one CS employee. Plus individuals like myself or
Simon Martinelli. And JUG members. Otavio was clearly the most active
"adopter", but we had others like Raj and it helped solve some of Java's
oldest BUGS like lack of Indian numbering format (which even Java 9 btw.
remains unsolved AFAIK;-O)

Not only because Anatole was involved in both, some of the initial API
design was then inspired by JSR 354.

What happened between the start of JSR 354 and its Final stage can and
should happen here, too. If the ConfigQuery or ConfigOperator is found to
duplicate themselves, then let's try to combine them. If it was found to be
more of a supplement, then  maybe it's not even needed in the core API
(e.g. JSR 363 moved Measurement from the API into the SPI of its RI because
we did not want to force one way of modeling that onto users, even though
it's simply a pattern by Martin Fowler and e.g. OSGi has it, too)

In the spirit of CDI, trying to add more comments to JIRA tickets like
https://issues.apache.org/jira/browse/TAMAYA-169 are probably best even if
this mailing list may not go away like java.net ;-)

Cheers,

Werner


On Mon, Aug 1, 2016 at 12:33 PM, Werner Keil <we...@gmail.com> wrote:

> This thread has been much too long and I don't have time to search for his
> exact message either, but he at least once urged, that Tamaya should not
> try to offer something DS already did (most likely about the CDI extension)
>
> If you don't have time for a proper, useful and extensible API, then
> trying to define a JSR or something similar may be a waste of time for all
> of us;-O
>
> The 2 examples of java.time vs. java.util.Collection et all were just to
> highlight how APIs (in these cases both some JSR, Collections API had no
> separate JSR, but you can see it with JSRs like 915 and above;-) should be
> extensible if you really plan to participate in something like a true
> standard, not "just an Open Source project".
>
> Cheers,
> Werner
>
>
>
> On Mon, Aug 1, 2016 at 12:09 PM, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
>> Ad 1) No, it was not Romain.
>>
>> Ad 2.) Again: please don’t go off-topic. I have no clue what the time API
>> has to do with this…
>> I don’t have time for this. So I’ll simply stop responding from now on.
>>
>>
>>
>> > Am 01.08.2016 um 11:46 schrieb Werner Keil <we...@gmail.com>:
>> >
>> > Ad 1) I recall it was Romain, if the extremely long thread should say
>> > otherwise or he thinks he was misunderstood, I'm sure he could speak up
>> ;-)
>> >
>> > Ad 2) Commons Config on a developer-facing side you don't see
>> annotations
>> > by default. With Spring and DeltaSpike you do. That does not mean,
>> people
>> > can't use the "low level elements" directly, but they rarely do. E.g. a
>> JSR
>> > like 310 (java.time) discourages people from using the API in
>> > "java.time.temporal" or at least has notes like
>> >> This interface must be implemented with care to ensure other classes
>> > operate correctly.
>> > The API was mostly introduced by Oracle as Co Spec Lead as "alibi" for
>> the
>> > JSR but all talks and documents by the main Spec Lead encourage people
>> to
>> > use Duration, LocalDate, etc. directly instead of the API elements.
>> > There also seems no SPI in that case that would make it easy to say add
>> a
>> > new chronology for Hebrew, Islamic or other calendars unless they
>> already
>> > come with the JDK. It's possible but very cumbersome, compared to say
>> ICU4J.
>> >
>> > Other parts of the JDK especially the Collections API are very open and
>> > everyone is encouraged to use List, Map or even the Collection
>> interface in
>> > some cases, not "TransformingSequantialList" (as in Guava ;-) directly,
>> at
>> > least when you pass arguments or return it between APIs.
>> >
>> > That's an example Tamaya also should handle with care. E.g. the low
>> level
>> > API. There's nothing wrong with a "Collection" equivalent offering the
>> > minimal set of useful methods and something like a "List" on top of that
>> > with further functionality. Unlike java.time most other JSRs or open
>> APIs
>> > encourage extensibility and look at all the possible "connectors" or
>> > sources tapping into Console, Etcd you name it, we should encourage
>> that,
>> > too.
>> >
>> > A vast number of developers may however use the annotation approach in
>> > their code like they do with DeltaSpike or Spring.
>> > They should not have to care, if there are 2, 3 or more levels of
>> > interfaces underneath the hood.
>> >
>> > There are many parts of Spring that are more like JSR 310/java.time
>> with a
>> > rudimentary or no real API and only one or very few implementations.
>> Like
>> > Microsoft or other proprietary vendors Pivotal/Spring cares in most
>> cases
>> > only for its own products to implement them, they don't define
>> standards.
>> > At most "inspire" them and where beneficial and reasonable later
>> implement
>> > them;-)
>> >
>> > Cheers,
>> > Werner
>> >
>> >
>> > On Mon, Aug 1, 2016 at 11:23 AM, Mark Struberg
>> <st...@yahoo.de.invalid>
>> > wrote:
>> >
>> >> I’ll repeat again (despite clarifying this 4 times already):
>> >>
>> >> 1.) I agree that competition is healthy. But it wasn’t Gerhard or me
>> who
>> >> cried out loud that we shall not compete with Tamaya.
>> >>
>> >> 2.) Apache Commons Config and Spring Config cannot be compared to the
>> >> DeltaSpike approach. Simply because DS-config is from the API more a
>> >> configuration-aggregator.
>> >> Whereas commons-config and Spring config is a great way to read
>> different
>> >> configuration formats. You can even use those in any self written
>> >> ConfigSource.
>> >> But that’s it, it doesn’t really aggregate information in such a
>> flexible
>> >> way like the DS-config approach does.
>> >>
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >>> Am 01.08.2016 um 10:26 schrieb Werner Keil <we...@gmail.com>:
>> >>>
>> >>> There have been arguments (e.g. Romain who has not said a lot lately,
>> >> also
>> >>> not on technical aspects btw. unlike Mark and others;-) saying "please
>> >>> don't compete with DS" that are not really valid.
>> >>> Apache is full of sometimes extremely competing things (Struts,
>> Tapestry,
>> >>> Wicket, OpenFaces,... just one on the Web UI side, multiple BigData or
>> >>> NoSQL projects being another) and projects.
>> >>>
>> >>> Similar to DS (regarding the CDI integration mostly) I'd say Apache
>> >> Commons
>> >>> Config or Spring Config (especially the whole PropertySource notion)
>> were
>> >>> quite influential so far.
>> >>>
>> >>> That's not a problem, and should some of it ever be a pattern or
>> >>> inspiration (not more) to a possible future standard somewhere, then
>> it
>> >>> would allow some of these to use such standard more easily than if
>> >>> everything is named and designed totally different;-)
>> >>>
>> >>> Nobody knows, what Oracle has in mind for a Java EE "revival". Should
>> it
>> >>> decide to take the lead and find ways that others can help, so be it.
>> JSR
>> >>> 375 is a possible way how this may look like (once a Spec Lead is
>> found
>> >> or
>> >>> several who are allowed to do their work;-) but it also shows, that
>> even
>> >>> the RI does not have to be Tamaya (it could, take e.g. Portlet 1-3)
>> >>> If the Glassfish ecosystem continues to exist and gets a new home, it
>> may
>> >>> well be there or in a different place (see JCache)
>> >>>
>> >>> We should do our best to demonstrate a "working example" with Tamaya.
>> 3,
>> >> 6
>> >>> or 23 classes, that isn't even the real issue yet, as long as it can
>> be
>> >>> used that way and Anatole or others are able to demonstrate that in
>> San
>> >>> Francisco or other places (maybe even Seville this fall?)
>> >>> If Spring, Deltaspike, Commons Config or other projects inspire a
>> future
>> >>> standard, that's also largely up to which people, companies and
>> >> communities
>> >>> are involved. Should Oracle let him, I would say Mike Keith was a
>> great
>> >>> asset for that, but we have to wait and see, who is allowed to
>> contribute
>> >>> in the future also by other companies.
>> >>>
>> >>> I guess like it was started with at least 2 JIRA tickets, it makes
>> sense
>> >> to
>> >>> get the discussion threads on Tamaya a bit less complex and bloated,
>> too
>> >>> btw. ;-D
>> >>>
>> >>> Regards,
>> >>> Werner
>> >>>
>> >>>
>> >>> On Mon, Aug 1, 2016 at 10:06 AM, Gerhard Petracek <
>> gpetracek@apache.org>
>> >>> wrote:
>> >>>
>> >>>> in addition:
>> >>>> compared to other topics in this thread it isn't even OT to talk
>> about
>> >>>> ds-config, because the suggested API is heavily influenced by it and
>> we
>> >>>> already have a reality-check for ds-config. if there is no concrete
>> and
>> >>>> common use-case (which isn't possible), there is no valid point
>> against
>> >>>> ds-config (and therefore against the suggested api) imo.
>> >>>> general statements like "project xyz couldn't use it, but it isn't
>> >> possible
>> >>>> to provide details" don't provide any useful feedback.
>> >>>> it should be always possible to show aspects/limitations/... in
>> >> general. if
>> >>>> it isn't possible then the project (which couldn't use it) is that
>> >> special
>> >>>> that it isn't representative for the majority and therefore it can't
>> be
>> >> a
>> >>>> valid argument against a suggestion/api/... which should fit for most
>> >> (but
>> >>>> not all) projects out there.
>> >>>>
>> >>>> regards,
>> >>>> gerhard
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2016-07-31 22:08 GMT+02:00 Mark Struberg <struberg@yahoo.de.invalid
>> >:
>> >>>>
>> >>>>>
>> >>>>>> Am 31.07.2016 um 21:51 schrieb Werner Keil <werner.keil@gmail.com
>> >:
>> >>>>>>
>> >>>>>> Just don't communicate about DS here, this is not a  DS mailing
>> >> list;-)
>> >>>>>>
>> >>>>>> Cheers
>> >>>>>
>> >>>>>
>> >>>>> I guess Gerhards point is that you permanently spread wrong
>> information
>> >>>>> about DeltaSpike.
>> >>>>> Not only here, but also in JCP groups, over at microprofile.io etc.
>> >>>>> Gerhard just wanted to get things straight.
>> >>>>>
>> >>>>> Maybe because you didn’t know any better. Despite we tried to
>> explain
>> >> it
>> >>>>> to you for quite some time already.
>> >>>>> But anyway, now you know that it works, so please stop spreading
>> wrong
>> >>>>> information.
>> >>>>>
>> >>>>> LieGrue,
>> >>>>> strub
>> >>>>>
>> >>>>>
>> >>>>
>> >>
>> >>
>>
>>
>

Re: [VOTE] fundamental goals of Tamaya

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

This thread has been much too long and I don't have time to search for his
exact message either, but he at least once urged, that Tamaya should not
try to offer something DS already did (most likely about the CDI extension)

If you don't have time for a proper, useful and extensible API, then trying
to define a JSR or something similar may be a waste of time for all of us;-O

The 2 examples of java.time vs. java.util.Collection et all were just to
highlight how APIs (in these cases both some JSR, Collections API had no
separate JSR, but you can see it with JSRs like 915 and above;-) should be
extensible if you really plan to participate in something like a true
standard, not "just an Open Source project".

Cheers,
Werner


On Mon, Aug 1, 2016 at 12:09 PM, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> Ad 1) No, it was not Romain.
>
> Ad 2.) Again: please don’t go off-topic. I have no clue what the time API
> has to do with this…
> I don’t have time for this. So I’ll simply stop responding from now on.
>
>
>
> > Am 01.08.2016 um 11:46 schrieb Werner Keil <we...@gmail.com>:
> >
> > Ad 1) I recall it was Romain, if the extremely long thread should say
> > otherwise or he thinks he was misunderstood, I'm sure he could speak up
> ;-)
> >
> > Ad 2) Commons Config on a developer-facing side you don't see annotations
> > by default. With Spring and DeltaSpike you do. That does not mean, people
> > can't use the "low level elements" directly, but they rarely do. E.g. a
> JSR
> > like 310 (java.time) discourages people from using the API in
> > "java.time.temporal" or at least has notes like
> >> This interface must be implemented with care to ensure other classes
> > operate correctly.
> > The API was mostly introduced by Oracle as Co Spec Lead as "alibi" for
> the
> > JSR but all talks and documents by the main Spec Lead encourage people to
> > use Duration, LocalDate, etc. directly instead of the API elements.
> > There also seems no SPI in that case that would make it easy to say add a
> > new chronology for Hebrew, Islamic or other calendars unless they already
> > come with the JDK. It's possible but very cumbersome, compared to say
> ICU4J.
> >
> > Other parts of the JDK especially the Collections API are very open and
> > everyone is encouraged to use List, Map or even the Collection interface
> in
> > some cases, not "TransformingSequantialList" (as in Guava ;-) directly,
> at
> > least when you pass arguments or return it between APIs.
> >
> > That's an example Tamaya also should handle with care. E.g. the low level
> > API. There's nothing wrong with a "Collection" equivalent offering the
> > minimal set of useful methods and something like a "List" on top of that
> > with further functionality. Unlike java.time most other JSRs or open APIs
> > encourage extensibility and look at all the possible "connectors" or
> > sources tapping into Console, Etcd you name it, we should encourage that,
> > too.
> >
> > A vast number of developers may however use the annotation approach in
> > their code like they do with DeltaSpike or Spring.
> > They should not have to care, if there are 2, 3 or more levels of
> > interfaces underneath the hood.
> >
> > There are many parts of Spring that are more like JSR 310/java.time with
> a
> > rudimentary or no real API and only one or very few implementations. Like
> > Microsoft or other proprietary vendors Pivotal/Spring cares in most cases
> > only for its own products to implement them, they don't define standards.
> > At most "inspire" them and where beneficial and reasonable later
> implement
> > them;-)
> >
> > Cheers,
> > Werner
> >
> >
> > On Mon, Aug 1, 2016 at 11:23 AM, Mark Struberg <struberg@yahoo.de.invalid
> >
> > wrote:
> >
> >> I’ll repeat again (despite clarifying this 4 times already):
> >>
> >> 1.) I agree that competition is healthy. But it wasn’t Gerhard or me who
> >> cried out loud that we shall not compete with Tamaya.
> >>
> >> 2.) Apache Commons Config and Spring Config cannot be compared to the
> >> DeltaSpike approach. Simply because DS-config is from the API more a
> >> configuration-aggregator.
> >> Whereas commons-config and Spring config is a great way to read
> different
> >> configuration formats. You can even use those in any self written
> >> ConfigSource.
> >> But that’s it, it doesn’t really aggregate information in such a
> flexible
> >> way like the DS-config approach does.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 01.08.2016 um 10:26 schrieb Werner Keil <we...@gmail.com>:
> >>>
> >>> There have been arguments (e.g. Romain who has not said a lot lately,
> >> also
> >>> not on technical aspects btw. unlike Mark and others;-) saying "please
> >>> don't compete with DS" that are not really valid.
> >>> Apache is full of sometimes extremely competing things (Struts,
> Tapestry,
> >>> Wicket, OpenFaces,... just one on the Web UI side, multiple BigData or
> >>> NoSQL projects being another) and projects.
> >>>
> >>> Similar to DS (regarding the CDI integration mostly) I'd say Apache
> >> Commons
> >>> Config or Spring Config (especially the whole PropertySource notion)
> were
> >>> quite influential so far.
> >>>
> >>> That's not a problem, and should some of it ever be a pattern or
> >>> inspiration (not more) to a possible future standard somewhere, then it
> >>> would allow some of these to use such standard more easily than if
> >>> everything is named and designed totally different;-)
> >>>
> >>> Nobody knows, what Oracle has in mind for a Java EE "revival". Should
> it
> >>> decide to take the lead and find ways that others can help, so be it.
> JSR
> >>> 375 is a possible way how this may look like (once a Spec Lead is found
> >> or
> >>> several who are allowed to do their work;-) but it also shows, that
> even
> >>> the RI does not have to be Tamaya (it could, take e.g. Portlet 1-3)
> >>> If the Glassfish ecosystem continues to exist and gets a new home, it
> may
> >>> well be there or in a different place (see JCache)
> >>>
> >>> We should do our best to demonstrate a "working example" with Tamaya.
> 3,
> >> 6
> >>> or 23 classes, that isn't even the real issue yet, as long as it can be
> >>> used that way and Anatole or others are able to demonstrate that in San
> >>> Francisco or other places (maybe even Seville this fall?)
> >>> If Spring, Deltaspike, Commons Config or other projects inspire a
> future
> >>> standard, that's also largely up to which people, companies and
> >> communities
> >>> are involved. Should Oracle let him, I would say Mike Keith was a great
> >>> asset for that, but we have to wait and see, who is allowed to
> contribute
> >>> in the future also by other companies.
> >>>
> >>> I guess like it was started with at least 2 JIRA tickets, it makes
> sense
> >> to
> >>> get the discussion threads on Tamaya a bit less complex and bloated,
> too
> >>> btw. ;-D
> >>>
> >>> Regards,
> >>> Werner
> >>>
> >>>
> >>> On Mon, Aug 1, 2016 at 10:06 AM, Gerhard Petracek <
> gpetracek@apache.org>
> >>> wrote:
> >>>
> >>>> in addition:
> >>>> compared to other topics in this thread it isn't even OT to talk about
> >>>> ds-config, because the suggested API is heavily influenced by it and
> we
> >>>> already have a reality-check for ds-config. if there is no concrete
> and
> >>>> common use-case (which isn't possible), there is no valid point
> against
> >>>> ds-config (and therefore against the suggested api) imo.
> >>>> general statements like "project xyz couldn't use it, but it isn't
> >> possible
> >>>> to provide details" don't provide any useful feedback.
> >>>> it should be always possible to show aspects/limitations/... in
> >> general. if
> >>>> it isn't possible then the project (which couldn't use it) is that
> >> special
> >>>> that it isn't representative for the majority and therefore it can't
> be
> >> a
> >>>> valid argument against a suggestion/api/... which should fit for most
> >> (but
> >>>> not all) projects out there.
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>>
> >>>>
> >>>> 2016-07-31 22:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> >>>>
> >>>>>
> >>>>>> Am 31.07.2016 um 21:51 schrieb Werner Keil <we...@gmail.com>:
> >>>>>>
> >>>>>> Just don't communicate about DS here, this is not a  DS mailing
> >> list;-)
> >>>>>>
> >>>>>> Cheers
> >>>>>
> >>>>>
> >>>>> I guess Gerhards point is that you permanently spread wrong
> information
> >>>>> about DeltaSpike.
> >>>>> Not only here, but also in JCP groups, over at microprofile.io etc.
> >>>>> Gerhard just wanted to get things straight.
> >>>>>
> >>>>> Maybe because you didn’t know any better. Despite we tried to explain
> >> it
> >>>>> to you for quite some time already.
> >>>>> But anyway, now you know that it works, so please stop spreading
> wrong
> >>>>> information.
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>
> >>
> >>
>
>

Re: [VOTE] fundamental goals of Tamaya

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

Ad 1) No, it was not Romain. 

Ad 2.) Again: please don’t go off-topic. I have no clue what the time API has to do with this…
I don’t have time for this. So I’ll simply stop responding from now on.



> Am 01.08.2016 um 11:46 schrieb Werner Keil <we...@gmail.com>:
> 
> Ad 1) I recall it was Romain, if the extremely long thread should say
> otherwise or he thinks he was misunderstood, I'm sure he could speak up ;-)
> 
> Ad 2) Commons Config on a developer-facing side you don't see annotations
> by default. With Spring and DeltaSpike you do. That does not mean, people
> can't use the "low level elements" directly, but they rarely do. E.g. a JSR
> like 310 (java.time) discourages people from using the API in
> "java.time.temporal" or at least has notes like
>> This interface must be implemented with care to ensure other classes
> operate correctly.
> The API was mostly introduced by Oracle as Co Spec Lead as "alibi" for the
> JSR but all talks and documents by the main Spec Lead encourage people to
> use Duration, LocalDate, etc. directly instead of the API elements.
> There also seems no SPI in that case that would make it easy to say add a
> new chronology for Hebrew, Islamic or other calendars unless they already
> come with the JDK. It's possible but very cumbersome, compared to say ICU4J.
> 
> Other parts of the JDK especially the Collections API are very open and
> everyone is encouraged to use List, Map or even the Collection interface in
> some cases, not "TransformingSequantialList" (as in Guava ;-) directly, at
> least when you pass arguments or return it between APIs.
> 
> That's an example Tamaya also should handle with care. E.g. the low level
> API. There's nothing wrong with a "Collection" equivalent offering the
> minimal set of useful methods and something like a "List" on top of that
> with further functionality. Unlike java.time most other JSRs or open APIs
> encourage extensibility and look at all the possible "connectors" or
> sources tapping into Console, Etcd you name it, we should encourage that,
> too.
> 
> A vast number of developers may however use the annotation approach in
> their code like they do with DeltaSpike or Spring.
> They should not have to care, if there are 2, 3 or more levels of
> interfaces underneath the hood.
> 
> There are many parts of Spring that are more like JSR 310/java.time with a
> rudimentary or no real API and only one or very few implementations. Like
> Microsoft or other proprietary vendors Pivotal/Spring cares in most cases
> only for its own products to implement them, they don't define standards.
> At most "inspire" them and where beneficial and reasonable later implement
> them;-)
> 
> Cheers,
> Werner
> 
> 
> On Mon, Aug 1, 2016 at 11:23 AM, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
> 
>> I’ll repeat again (despite clarifying this 4 times already):
>> 
>> 1.) I agree that competition is healthy. But it wasn’t Gerhard or me who
>> cried out loud that we shall not compete with Tamaya.
>> 
>> 2.) Apache Commons Config and Spring Config cannot be compared to the
>> DeltaSpike approach. Simply because DS-config is from the API more a
>> configuration-aggregator.
>> Whereas commons-config and Spring config is a great way to read different
>> configuration formats. You can even use those in any self written
>> ConfigSource.
>> But that’s it, it doesn’t really aggregate information in such a flexible
>> way like the DS-config approach does.
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 01.08.2016 um 10:26 schrieb Werner Keil <we...@gmail.com>:
>>> 
>>> There have been arguments (e.g. Romain who has not said a lot lately,
>> also
>>> not on technical aspects btw. unlike Mark and others;-) saying "please
>>> don't compete with DS" that are not really valid.
>>> Apache is full of sometimes extremely competing things (Struts, Tapestry,
>>> Wicket, OpenFaces,... just one on the Web UI side, multiple BigData or
>>> NoSQL projects being another) and projects.
>>> 
>>> Similar to DS (regarding the CDI integration mostly) I'd say Apache
>> Commons
>>> Config or Spring Config (especially the whole PropertySource notion) were
>>> quite influential so far.
>>> 
>>> That's not a problem, and should some of it ever be a pattern or
>>> inspiration (not more) to a possible future standard somewhere, then it
>>> would allow some of these to use such standard more easily than if
>>> everything is named and designed totally different;-)
>>> 
>>> Nobody knows, what Oracle has in mind for a Java EE "revival". Should it
>>> decide to take the lead and find ways that others can help, so be it. JSR
>>> 375 is a possible way how this may look like (once a Spec Lead is found
>> or
>>> several who are allowed to do their work;-) but it also shows, that even
>>> the RI does not have to be Tamaya (it could, take e.g. Portlet 1-3)
>>> If the Glassfish ecosystem continues to exist and gets a new home, it may
>>> well be there or in a different place (see JCache)
>>> 
>>> We should do our best to demonstrate a "working example" with Tamaya. 3,
>> 6
>>> or 23 classes, that isn't even the real issue yet, as long as it can be
>>> used that way and Anatole or others are able to demonstrate that in San
>>> Francisco or other places (maybe even Seville this fall?)
>>> If Spring, Deltaspike, Commons Config or other projects inspire a future
>>> standard, that's also largely up to which people, companies and
>> communities
>>> are involved. Should Oracle let him, I would say Mike Keith was a great
>>> asset for that, but we have to wait and see, who is allowed to contribute
>>> in the future also by other companies.
>>> 
>>> I guess like it was started with at least 2 JIRA tickets, it makes sense
>> to
>>> get the discussion threads on Tamaya a bit less complex and bloated, too
>>> btw. ;-D
>>> 
>>> Regards,
>>> Werner
>>> 
>>> 
>>> On Mon, Aug 1, 2016 at 10:06 AM, Gerhard Petracek <gp...@apache.org>
>>> wrote:
>>> 
>>>> in addition:
>>>> compared to other topics in this thread it isn't even OT to talk about
>>>> ds-config, because the suggested API is heavily influenced by it and we
>>>> already have a reality-check for ds-config. if there is no concrete and
>>>> common use-case (which isn't possible), there is no valid point against
>>>> ds-config (and therefore against the suggested api) imo.
>>>> general statements like "project xyz couldn't use it, but it isn't
>> possible
>>>> to provide details" don't provide any useful feedback.
>>>> it should be always possible to show aspects/limitations/... in
>> general. if
>>>> it isn't possible then the project (which couldn't use it) is that
>> special
>>>> that it isn't representative for the majority and therefore it can't be
>> a
>>>> valid argument against a suggestion/api/... which should fit for most
>> (but
>>>> not all) projects out there.
>>>> 
>>>> regards,
>>>> gerhard
>>>> 
>>>> 
>>>> 
>>>> 2016-07-31 22:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>>>> 
>>>>> 
>>>>>> Am 31.07.2016 um 21:51 schrieb Werner Keil <we...@gmail.com>:
>>>>>> 
>>>>>> Just don't communicate about DS here, this is not a  DS mailing
>> list;-)
>>>>>> 
>>>>>> Cheers
>>>>> 
>>>>> 
>>>>> I guess Gerhards point is that you permanently spread wrong information
>>>>> about DeltaSpike.
>>>>> Not only here, but also in JCP groups, over at microprofile.io etc.
>>>>> Gerhard just wanted to get things straight.
>>>>> 
>>>>> Maybe because you didn’t know any better. Despite we tried to explain
>> it
>>>>> to you for quite some time already.
>>>>> But anyway, now you know that it works, so please stop spreading wrong
>>>>> information.
>>>>> 
>>>>> LieGrue,
>>>>> strub
>>>>> 
>>>>> 
>>>> 
>> 
>> 

Re: [VOTE] fundamental goals of Tamaya

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

Ad 1) I recall it was Romain, if the extremely long thread should say
otherwise or he thinks he was misunderstood, I'm sure he could speak up ;-)

Ad 2) Commons Config on a developer-facing side you don't see annotations
by default. With Spring and DeltaSpike you do. That does not mean, people
can't use the "low level elements" directly, but they rarely do. E.g. a JSR
like 310 (java.time) discourages people from using the API in
"java.time.temporal" or at least has notes like
>This interface must be implemented with care to ensure other classes
operate correctly.
The API was mostly introduced by Oracle as Co Spec Lead as "alibi" for the
JSR but all talks and documents by the main Spec Lead encourage people to
use Duration, LocalDate, etc. directly instead of the API elements.
There also seems no SPI in that case that would make it easy to say add a
new chronology for Hebrew, Islamic or other calendars unless they already
come with the JDK. It's possible but very cumbersome, compared to say ICU4J.

Other parts of the JDK especially the Collections API are very open and
everyone is encouraged to use List, Map or even the Collection interface in
some cases, not "TransformingSequantialList" (as in Guava ;-) directly, at
least when you pass arguments or return it between APIs.

That's an example Tamaya also should handle with care. E.g. the low level
API. There's nothing wrong with a "Collection" equivalent offering the
minimal set of useful methods and something like a "List" on top of that
with further functionality. Unlike java.time most other JSRs or open APIs
encourage extensibility and look at all the possible "connectors" or
sources tapping into Console, Etcd you name it, we should encourage that,
too.

A vast number of developers may however use the annotation approach in
their code like they do with DeltaSpike or Spring.
They should not have to care, if there are 2, 3 or more levels of
interfaces underneath the hood.

There are many parts of Spring that are more like JSR 310/java.time with a
rudimentary or no real API and only one or very few implementations. Like
Microsoft or other proprietary vendors Pivotal/Spring cares in most cases
only for its own products to implement them, they don't define standards.
At most "inspire" them and where beneficial and reasonable later implement
them;-)

Cheers,
Werner


On Mon, Aug 1, 2016 at 11:23 AM, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> I’ll repeat again (despite clarifying this 4 times already):
>
> 1.) I agree that competition is healthy. But it wasn’t Gerhard or me who
> cried out loud that we shall not compete with Tamaya.
>
> 2.) Apache Commons Config and Spring Config cannot be compared to the
> DeltaSpike approach. Simply because DS-config is from the API more a
> configuration-aggregator.
> Whereas commons-config and Spring config is a great way to read different
> configuration formats. You can even use those in any self written
> ConfigSource.
> But that’s it, it doesn’t really aggregate information in such a flexible
> way like the DS-config approach does.
>
>
> LieGrue,
> strub
>
>
> > Am 01.08.2016 um 10:26 schrieb Werner Keil <we...@gmail.com>:
> >
> > There have been arguments (e.g. Romain who has not said a lot lately,
> also
> > not on technical aspects btw. unlike Mark and others;-) saying "please
> > don't compete with DS" that are not really valid.
> > Apache is full of sometimes extremely competing things (Struts, Tapestry,
> > Wicket, OpenFaces,... just one on the Web UI side, multiple BigData or
> > NoSQL projects being another) and projects.
> >
> > Similar to DS (regarding the CDI integration mostly) I'd say Apache
> Commons
> > Config or Spring Config (especially the whole PropertySource notion) were
> > quite influential so far.
> >
> > That's not a problem, and should some of it ever be a pattern or
> > inspiration (not more) to a possible future standard somewhere, then it
> > would allow some of these to use such standard more easily than if
> > everything is named and designed totally different;-)
> >
> > Nobody knows, what Oracle has in mind for a Java EE "revival". Should it
> > decide to take the lead and find ways that others can help, so be it. JSR
> > 375 is a possible way how this may look like (once a Spec Lead is found
> or
> > several who are allowed to do their work;-) but it also shows, that even
> > the RI does not have to be Tamaya (it could, take e.g. Portlet 1-3)
> > If the Glassfish ecosystem continues to exist and gets a new home, it may
> > well be there or in a different place (see JCache)
> >
> > We should do our best to demonstrate a "working example" with Tamaya. 3,
> 6
> > or 23 classes, that isn't even the real issue yet, as long as it can be
> > used that way and Anatole or others are able to demonstrate that in San
> > Francisco or other places (maybe even Seville this fall?)
> > If Spring, Deltaspike, Commons Config or other projects inspire a future
> > standard, that's also largely up to which people, companies and
> communities
> > are involved. Should Oracle let him, I would say Mike Keith was a great
> > asset for that, but we have to wait and see, who is allowed to contribute
> > in the future also by other companies.
> >
> > I guess like it was started with at least 2 JIRA tickets, it makes sense
> to
> > get the discussion threads on Tamaya a bit less complex and bloated, too
> > btw. ;-D
> >
> > Regards,
> > Werner
> >
> >
> > On Mon, Aug 1, 2016 at 10:06 AM, Gerhard Petracek <gp...@apache.org>
> > wrote:
> >
> >> in addition:
> >> compared to other topics in this thread it isn't even OT to talk about
> >> ds-config, because the suggested API is heavily influenced by it and we
> >> already have a reality-check for ds-config. if there is no concrete and
> >> common use-case (which isn't possible), there is no valid point against
> >> ds-config (and therefore against the suggested api) imo.
> >> general statements like "project xyz couldn't use it, but it isn't
> possible
> >> to provide details" don't provide any useful feedback.
> >> it should be always possible to show aspects/limitations/... in
> general. if
> >> it isn't possible then the project (which couldn't use it) is that
> special
> >> that it isn't representative for the majority and therefore it can't be
> a
> >> valid argument against a suggestion/api/... which should fit for most
> (but
> >> not all) projects out there.
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2016-07-31 22:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
> >>
> >>>
> >>>> Am 31.07.2016 um 21:51 schrieb Werner Keil <we...@gmail.com>:
> >>>>
> >>>> Just don't communicate about DS here, this is not a  DS mailing
> list;-)
> >>>>
> >>>> Cheers
> >>>
> >>>
> >>> I guess Gerhards point is that you permanently spread wrong information
> >>> about DeltaSpike.
> >>> Not only here, but also in JCP groups, over at microprofile.io etc.
> >>> Gerhard just wanted to get things straight.
> >>>
> >>> Maybe because you didn’t know any better. Despite we tried to explain
> it
> >>> to you for quite some time already.
> >>> But anyway, now you know that it works, so please stop spreading wrong
> >>> information.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>
>
>

Re: [VOTE] fundamental goals of Tamaya

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

I’ll repeat again (despite clarifying this 4 times already):

1.) I agree that competition is healthy. But it wasn’t Gerhard or me who cried out loud that we shall not compete with Tamaya. 

2.) Apache Commons Config and Spring Config cannot be compared to the DeltaSpike approach. Simply because DS-config is from the API more a configuration-aggregator.
Whereas commons-config and Spring config is a great way to read different configuration formats. You can even use those in any self written ConfigSource.
But that’s it, it doesn’t really aggregate information in such a flexible way like the DS-config approach does.


LieGrue,
strub


> Am 01.08.2016 um 10:26 schrieb Werner Keil <we...@gmail.com>:
> 
> There have been arguments (e.g. Romain who has not said a lot lately, also
> not on technical aspects btw. unlike Mark and others;-) saying "please
> don't compete with DS" that are not really valid.
> Apache is full of sometimes extremely competing things (Struts, Tapestry,
> Wicket, OpenFaces,... just one on the Web UI side, multiple BigData or
> NoSQL projects being another) and projects.
> 
> Similar to DS (regarding the CDI integration mostly) I'd say Apache Commons
> Config or Spring Config (especially the whole PropertySource notion) were
> quite influential so far.
> 
> That's not a problem, and should some of it ever be a pattern or
> inspiration (not more) to a possible future standard somewhere, then it
> would allow some of these to use such standard more easily than if
> everything is named and designed totally different;-)
> 
> Nobody knows, what Oracle has in mind for a Java EE "revival". Should it
> decide to take the lead and find ways that others can help, so be it. JSR
> 375 is a possible way how this may look like (once a Spec Lead is found or
> several who are allowed to do their work;-) but it also shows, that even
> the RI does not have to be Tamaya (it could, take e.g. Portlet 1-3)
> If the Glassfish ecosystem continues to exist and gets a new home, it may
> well be there or in a different place (see JCache)
> 
> We should do our best to demonstrate a "working example" with Tamaya. 3, 6
> or 23 classes, that isn't even the real issue yet, as long as it can be
> used that way and Anatole or others are able to demonstrate that in San
> Francisco or other places (maybe even Seville this fall?)
> If Spring, Deltaspike, Commons Config or other projects inspire a future
> standard, that's also largely up to which people, companies and communities
> are involved. Should Oracle let him, I would say Mike Keith was a great
> asset for that, but we have to wait and see, who is allowed to contribute
> in the future also by other companies.
> 
> I guess like it was started with at least 2 JIRA tickets, it makes sense to
> get the discussion threads on Tamaya a bit less complex and bloated, too
> btw. ;-D
> 
> Regards,
> Werner
> 
> 
> On Mon, Aug 1, 2016 at 10:06 AM, Gerhard Petracek <gp...@apache.org>
> wrote:
> 
>> in addition:
>> compared to other topics in this thread it isn't even OT to talk about
>> ds-config, because the suggested API is heavily influenced by it and we
>> already have a reality-check for ds-config. if there is no concrete and
>> common use-case (which isn't possible), there is no valid point against
>> ds-config (and therefore against the suggested api) imo.
>> general statements like "project xyz couldn't use it, but it isn't possible
>> to provide details" don't provide any useful feedback.
>> it should be always possible to show aspects/limitations/... in general. if
>> it isn't possible then the project (which couldn't use it) is that special
>> that it isn't representative for the majority and therefore it can't be a
>> valid argument against a suggestion/api/... which should fit for most (but
>> not all) projects out there.
>> 
>> regards,
>> gerhard
>> 
>> 
>> 
>> 2016-07-31 22:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>> 
>>> 
>>>> Am 31.07.2016 um 21:51 schrieb Werner Keil <we...@gmail.com>:
>>>> 
>>>> Just don't communicate about DS here, this is not a  DS mailing list;-)
>>>> 
>>>> Cheers
>>> 
>>> 
>>> I guess Gerhards point is that you permanently spread wrong information
>>> about DeltaSpike.
>>> Not only here, but also in JCP groups, over at microprofile.io etc.
>>> Gerhard just wanted to get things straight.
>>> 
>>> Maybe because you didn’t know any better. Despite we tried to explain it
>>> to you for quite some time already.
>>> But anyway, now you know that it works, so please stop spreading wrong
>>> information.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>> 

Re: [VOTE] fundamental goals of Tamaya

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

There have been arguments (e.g. Romain who has not said a lot lately, also
not on technical aspects btw. unlike Mark and others;-) saying "please
don't compete with DS" that are not really valid.
Apache is full of sometimes extremely competing things (Struts, Tapestry,
Wicket, OpenFaces,... just one on the Web UI side, multiple BigData or
NoSQL projects being another) and projects.

Similar to DS (regarding the CDI integration mostly) I'd say Apache Commons
Config or Spring Config (especially the whole PropertySource notion) were
quite influential so far.

That's not a problem, and should some of it ever be a pattern or
inspiration (not more) to a possible future standard somewhere, then it
would allow some of these to use such standard more easily than if
everything is named and designed totally different;-)

Nobody knows, what Oracle has in mind for a Java EE "revival". Should it
decide to take the lead and find ways that others can help, so be it. JSR
375 is a possible way how this may look like (once a Spec Lead is found or
several who are allowed to do their work;-) but it also shows, that even
the RI does not have to be Tamaya (it could, take e.g. Portlet 1-3)
If the Glassfish ecosystem continues to exist and gets a new home, it may
well be there or in a different place (see JCache)

We should do our best to demonstrate a "working example" with Tamaya. 3, 6
or 23 classes, that isn't even the real issue yet, as long as it can be
used that way and Anatole or others are able to demonstrate that in San
Francisco or other places (maybe even Seville this fall?)
If Spring, Deltaspike, Commons Config or other projects inspire a future
standard, that's also largely up to which people, companies and communities
are involved. Should Oracle let him, I would say Mike Keith was a great
asset for that, but we have to wait and see, who is allowed to contribute
in the future also by other companies.

I guess like it was started with at least 2 JIRA tickets, it makes sense to
get the discussion threads on Tamaya a bit less complex and bloated, too
btw. ;-D

Regards,
Werner


On Mon, Aug 1, 2016 at 10:06 AM, Gerhard Petracek <gp...@apache.org>
wrote:

> in addition:
> compared to other topics in this thread it isn't even OT to talk about
> ds-config, because the suggested API is heavily influenced by it and we
> already have a reality-check for ds-config. if there is no concrete and
> common use-case (which isn't possible), there is no valid point against
> ds-config (and therefore against the suggested api) imo.
> general statements like "project xyz couldn't use it, but it isn't possible
> to provide details" don't provide any useful feedback.
> it should be always possible to show aspects/limitations/... in general. if
> it isn't possible then the project (which couldn't use it) is that special
> that it isn't representative for the majority and therefore it can't be a
> valid argument against a suggestion/api/... which should fit for most (but
> not all) projects out there.
>
> regards,
> gerhard
>
>
>
> 2016-07-31 22:08 GMT+02:00 Mark Struberg <st...@yahoo.de.invalid>:
>
> >
> > > Am 31.07.2016 um 21:51 schrieb Werner Keil <we...@gmail.com>:
> > >
> > > Just don't communicate about DS here, this is not a  DS mailing list;-)
> > >
> > > Cheers
> >
> >
> > I guess Gerhards point is that you permanently spread wrong information
> > about DeltaSpike.
> > Not only here, but also in JCP groups, over at microprofile.io etc.
> > Gerhard just wanted to get things straight.
> >
> > Maybe because you didn’t know any better. Despite we tried to explain it
> > to you for quite some time already.
> > But anyway, now you know that it works, so please stop spreading wrong
> > information.
> >
> > LieGrue,
> > strub
> >
> >
>