Do we need a.TCK at all? We are not a JSR. If we can run one we will have to rediscuss things again and it still enough time to provide a TCK imo. Btw the tck tests all aspects that can be tested based on the api AND the specification.
Cheers Anstole Oliver B. Fischer <[email protected]> schrieb am Fr., 23. Jan. 2015 um 07:15: > 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 < > [email protected]>: > >> 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 > >
