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 <[email protected]>: > > 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 <[email protected]> > 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 <[email protected]>: >> >>> >>>> Am 31.07.2016 um 21:51 schrieb Werner Keil <[email protected]>: >>>> >>>> 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 >>> >>> >>
