> Am 15.07.2016 um 02:56 schrieb Anatole Tresch <[email protected]>: > > Hi all > > Folks, calm down a bit.
+1, let’s try to turn this into a productive discussion > Neverthess what I really dislike, is > > 1) that after so much work done, and neither Mark nor Romain being actively > participating on the project the last months you raise your own initiative > without involving the other people here. You probably remember that Gerhard, Romain and I tried hard to push for a very lightweight solution back then. After we got asked that as a mentor should cut our technical commitment and mostly observe the project. Btw by the same people who boil this up now. Lets now focus on what >> I << thought was/is the goal of Tamaya and what the current Tamaya community thinks it is. My initial understanding was that we really push hard to become a JSR in a relatively short time period. Means we should be as powerful as needed BUT as lightweight as possible. The less classes the better. The more straight forward, the better. Provide * an API * a TCK * a Spec paper * a RI And optional some additional modules on top of it. Was my understanding wrong? If not, is this still the goal? If so, look at the current codebase and honestly tell me how close we are to that almost 2 years later? I checked out the latest sources yesterday and it took me half an hour to at least find the API and RI part. Btw it also was initially intended to move the config from DeltaSpike to Tamaya. Which neither happened because Tamaya didn’t yet focus on it’s core business. Btw 2, the stuff I published on github was actually not based on Tamaya but on the stuff I wrote in DeltaSpike. > 2) That the whole Tamaya project is too bis for a JSR is clear, nevertheless > the API part may be still small enough (it is smaller than the money > JSR...). This was clearly stated from the start, just remember this. Yes, I remember this well and I wonder where we derailed (at least from my pov). Don’t get me wrong I STILL think it is possible to review the API and cut it down to the bare minimun to get the project back on track for a JSR. Again this is only MY personal view. Maybe all others think the project is doing perfectly fine anyway and the API is already the best you can think of. After all, it boils down to whether we are talking about the same goals… Remember where we started. We had about 10 different configuration projects to look at. We added 300 classes and then reviewed the core ideas and concepts behind it. It seems that the algorithm Gerhard and I created for OWB, CODI and finally DeltaSpike made the race and we got rid of most stuff which were previously added. I guess you nowadays see the power of this approach and we share a common idea, right? There are imo 3 different sizes which are possible Option 1.) the really bare core * ConfigProvider + Config * ConfigSource chain (including ConfigSourceProvider) + ConfigFilter chain Essentially we don’t even need ConfigFileProvider. It could easily be done as addon. That makes exactly 5 interface classes for that whole thing! Intentionally left out: * It only handles String/String, no other Types! Why? Because it can easily added on top of it anyway… * No List, Set, etc handling! This adds huge complexity for a very limited benefit. * No lookup chain like variable evaluation, ’staged’ lookup like DeltaSpike ProjectStage. Why? Because it can easily added on top of it anyway… * No fancy other ConfigSources out of the box. Why? See above… * No DI support, again can easily get added on top. Option 2.) like 1.) but with a Coverter logic for other types than Strings, caching, variable expression, lookup chain. Makes another 2 classes: Converter and TypedResolver (written by Gerhard a long time ago) See https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/api/config/ConfigResolver.java#L636 http://deltaspike.apache.org/documentation/configuration.html#_typedresolver_api Option 3.) The fully blown Tamaya logic. Not sure what the other 20 interfaces aim for. But it’s somehow clear that there are parts we might potentially get rid of. E.g. ConfigQuery, ConfigOperator? Tried to understand that a long time ago and always failed. Maybe it’s a tad too flexible? > There is much more politics involved that you can ever imagine, ignoring that > point is simply naive IMO. You know, I’m a bloody technician and not that much interested in politics. But you are most probably right with this point ;) LieGrue, strub
