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