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