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 <werner.k...@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 <strub...@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 <werner.k...@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 <gpetra...@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 <strub...@yahoo.de.invalid>: >>>> >>>>> >>>>>> Am 31.07.2016 um 21:51 schrieb Werner Keil <werner.k...@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 >>>>> >>>>> >>>> >> >>
