That's a really good start, thanks for bringing it up. Comments inline.
> On Sunday, 4 January 2015, 12:57, Anatole Tresch <[email protected]> wrote: > > Hi all > Looking at the discussions from this morning I think we need more discussions > what core should contain. The term minimalistic obviosly is not precise > enough. > So we must agree in more detail what the features and objectives of core are. > So > I make a first try: > > 1. it should implement the api/spi for simple se usage. +1 > 2. it should provider enough logic to provide the minimal building blocks so > a > user could build a minimal config system. +1 > 3. said this I would expect that properties configs are supported ootb as a > format. +1 The question is how this should be done. I would just define a default classpath resource name (e.g. "META-INF/javaconfiguration.properties") and pick all those property files up as a PropertySource each. We later could easily add features similar to DeltaSpikes PropertyFileConfig http://deltaspike.apache.org/documentation/configuration.html#_propertyfileconfig or also pick them up via a ServiceLoader approach. > 4. I would expect that adding a propertysource is basically a one liner if > the > file is in the cp or a file. +0.5 If we do like to add this then we also need to reflect this in our API module. Probably a few helper classes in our spi package are enough. > 5. I would expect that core helps me defining my location declaratively. > users > dont care about resource loading details, they expect the lib to handle that > ootb. +0.5 If the java.util.ServiceLoader mechanism falls under the category 'declarative' then that's ok. I'm -1 for requiring an own class scanning mechanism in our core for SE. For EE environments we might simply leverage CDI. We might even specify this for EE later. To sum it up: +0.5 for picking it up via ServiceLoader -1 for class scanning in SE +1 for fully implementing it in EE > 6. I would expect that the mechanisms provided are extendible, so with adding > additional modules the api basically still feels the same. Given that > abstractions must be defined in the api or in core. I'd make a difference between the 'user' which just likes to get it's configured values (our Configuration interface) vs the programmers who provide own PropertySources. For both all necessary parts must be available in the api module. core is imo just a runtime impl in both cases. Remember that this will probably come from the container in the future. > 7. I dont think extension modules must rely on the api only (if that would be > a > decision we might have to discuss if the api may define more things). My idea > is > that tamaya is a combinable set of modules that as a whole can be tailored to > the many different facets required. Constraining modules on api deps will > probably lead to much duplications, but lets see... That depends whether we think that our Extensions are 'portable' or bound to a specific implementation. > 6 and 7 are things to be argued about I think. > > If we see core as a supermonimalistic set that is not enough per se for all > supertrivial usage scenarios I agree I would remove latest additions to a > separate module. Perhaps this is even the best solution to keep our personal > hygiene in place ;) > > Cheers> Anatole > > - > Anatole Tresch > Glärnischweg 10 > 8620 Wetzikon > Tel +41 (43) 317 05 30 > - > Send from Mobile >
