Agree for isScannable, was a bug in my IDE, sorry again for this noise. About TCK I agree but think it could force us to get another impl showing if our design is clean.
About java8 can you detail features you like please? Excepted optional I dont see much and I cant imagine it being strong enough to justified your answer so please give me some examples. Le 23 janv. 2015 07:15, "Oliver B. Fischer" <[email protected]> a écrit : > Hi Romain, > > PropertySource#isScannable() should stay IMHO. It is very usefull if you > want to support property sources as a DB. Surely no one of us want to see > somethink like "SELECT * from properties". So isScannable should stay IMHO. > > Oliver > > Am 22.01.15 um 16:18 schrieb Romain Manni-Bucau: > >> shouldnt prevent us to go futher but also means we make a lot of noise >> and no progress... >> >> That said here the feedbacks I try to make precise: >> >> - java 7 module: >> -- ConfigurationProvider should be called ConfigurationFactory IMO (see >> next) >> >> - org.apache.tamaya.spi.ServiceContext#getServices should disappear -> >> no usage at least >> -- Configuration.current() miss the "config" stage where you can >> select your impl: Configuration.byDefaultProvider() or >> Configuration.byProvider(MySuperProvider.class) and then we just call >> build() (or we can add in between addPropertySource/Converter). Doing >> it we don't need to cache >> org.apache.tamaya.spi.ServiceContextManager# >> serviceContextProviderDelegate >> which makes it more reliable >> >> - org.apache.tamaya.spi.ConfigurationContext#context has no real >> meaning IMO and shouldn't be public if it is needed (it is not IMO) >> >> - org.apache.tamaya.spi.PropertySource#isScannable is not used ATM >> AFAIK so we should remove it IMO >> >> - I'd remove org.apache.tamaya.ConfigOperator and just allow to export >> a Config as a Map -> then use Map API to actually "map" >> - ConfigQuery -> same as previous comment >> -> adapt Configuration with 2 previous comments >> >> - finally check it does worth to keep this j8 module (think only >> drawback removing it would be to loose Configuration.current() - or >> new equivalent - which is not a big deal IMO. >> >> That's what I had in mind more or less >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-22 16:01 GMT+01:00 Tresch, Anatole <anatole.tresch@credit-suisse. >> com>: >> >>> Hi Romain >>> >>> Do we? I am only focused on config related use cases and know about what >>> I am talking: >>> - Exposing a part of the internals as API does not make a storage >>> solution. >>> - Using TypeLiteral for property conversion does not have anything in >>> common with a storage solution. >>> >>> -> So please stay on the topic and keep off things that are not >>> relevant, please. >>> >>> -> Which is providing a configuration solution. I have well defined and >>> well important use cases. If you don’t have them, well... >>> -> I do not care (too much) what other projects do. Often others provide >>> good features, but also some less good ones. To argue not to repeat, what >>> others did >>> IMO is useless. We should take the good things and combine it here, >>> so we get a good solution. And again: if you have something that disturbs >>> you, be >>> explicit. Just claiming or writing down your feelings does not help >>> anybody here. Either you write down your concerns clearly, at the end by >>> code, or your input >>> is not much of use. It is that simple IMO. I am exposing me by >>> writing down and trying to do things as Java API, simply because that is >>> the only way it works to get >>> a common understanding. Sorry for the hard words here. >>> >>> -> So we have a scope discussion for the new release now. IMO the >>> current artifacts within the API are clearly in focus for release 1 (from >>> an API perspective). If you want to remove anything, you should >>> exactly write down, WHAT should be removed and also WHY. >>> -> About Collection support, we may have a vote on it. Or other people >>> here on the mailing list should add their cents ;) >>> -> Gathering feedback is OK. Nevertheless we can mark the release as >>> alpha, so everybody is clear that things may still change. >>> -> And again discussing what should be part of release 1 IMO must not >>> constrain us to discuss on further concepts as long as the threads are >>> clearly separated and not too many. So help us constructively with the >>> discussion instead of throwing woods into our legs all the times. >>> That would be great! >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-22 13:47 GMT+01:00 Tresch, Anatole < >>> [email protected]>: >>> >> > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > J [email protected] > X http://xing.to/obf > >
