Service provider module resolution <was> Re: Services/configuration/context webrevs

[Alan Bateman]

On 06/08/2012 11:41, Paul Sandoz wrote:
> :
> And i am gonna do the same for optional dependencies too, so this code is gonna change again. Thus the mandatory dependencies have to resolve and are not affected by any optional dependencies (service-based or otherwise).
This make sense.

> :
> I was tempted to write a Deque implementation that was based on linked hash set :-) It's gonna change soon with support for optional dependencies, so there is no point adding such a comment.
>
> Basically there is no need to cache optional stuff (services or otherwise) while traversing the dependency graph. Instead linear traversal of the partial configuration can be performed i.e. iteration of Resolver.modules, which needs to change to preserve order (and in general we need to preserve the topological order of the modules through out the resolving and linking process).
Okay, just something I notice when going through the changes.

> :
> No, it needs to be separated out as a project, there is exploded source, and i want to open it in a IDE (plus it will be updated when moving to TestNG, notice that there is a test dimension for testing the various class loaders, a TestNG data provider can be used to abstract this). We also may have other projects in the future.
>
> When this patch goes in i will be updating the runtime tests to include more test code related to service instance iteration failure.
>
My comment was actually about the additional level rather the source 
tree. When open in an IDE or with TestNG then I assume that the shell 
test isn't interesting and could remain at the same level as the other 
shell scripts. If this is all going to be reorganized then it's no big 
deal but it is critical that all the infrastructure we use support 
TestNG before we can really move over.

-Alan.