Hi,
IMHO it is to early to get started with an TCK as we are not so stable
as we need to be for an TCK. A TCK pays only off if the API will stay
stable for more than one or better two releases.
Futhermore the TCK can only test the API part of Tamaya. It can not help
us to test our core and our extension modules. Therefore we will always
need unit tests.
Did I oversee something?
Bye,
Oliver
Am 22.01.15 um 15:38 schrieb Mark Struberg:
we can certainly do a clean review without [] support now. But there are quite
a few important things missing atm imo.
1.) TCK or better unit tests in general.
2.) the Java7 impl needs to get implemented
3.) a REAL in depth license and IP clearing. We really need to do that _before_
our first release.
LieGrue,
strub
On Thursday, 22 January 2015, 15:29, Romain Manni-Bucau <[email protected]>
wrote:
field and we are implementing a storage solution. There are already
numerous projects doing it at apache - even if they can sometimes
mandate some infra - so we should stick to the first goal of tamaya.
I also not fully agree with the basis - in particular the SPI to be
clear - we have ATM.
To sumamrize a first release with:
1) SPI ("provider" + property source)
2) basic merge/conflict policy
3) String read API
4) basic convertion support
Is far enough IMO.
Once all of it is clear I'd like we do a release to gather feedback
then continue building on top of it - we are ATM in the tunnel ;).
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]>:
far and I do not want to
simple request to use the algorithm pattern
evaluated). The usage of TypeLiteral was even your
already so flexible that I can implement 60-70% of use cases
"benchmark", which from my discussions I had during the last years
covers a
yesterday about Collection support. My proposal
support collections based only on Map<String,String>
getListProperty(String) methods.
we need TypeLiterals, which similarly is useful perhaps for other non collection
sources, a final list may want to contain all the properties found, instead of
overriding,
already agreed on that UC. Hardcoding yet another strategy IMO makes
is what we already have in place) and add support for adapting the default
(TypeLiterals and the collector) are the same for evaluating single property
values as well,
extend/flexibilize the way how we can access properties in general.
Perhaps also the name PropertyQuery is confusing. Alternates would be
open here ;)
not solve anything. Also we already invested a lot of discussing collection
support, why stop here.
affect the Configuration interface as a whole. Adding them later may be a bad
idea, so we
continue to see, if we end up in a common view. If so, others on the mailing
list also have a
Works perfectly.
3 methods to Configuration. We get as well all the flexibility we would need for
collection support as well ;)
overridding? Its already there, but hardcoded the same, which is obviously not
flexible enough!
<[email protected]>:
lambda
and actually
<[email protected]>:
overriding may not
configured value
set/list).
(already
the result
convenience)
will end up
ValueCollector);
which
aspects
enough to
may be ommitted as well ?
additional
ValueCollector
PropertySource
the existing
currentValue}
currentValue}.
{@code
the current
containing the
meta-data, how
(k, nv, ps,
--
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
