Here's where I am. I have rewritten the DefaultLoader to actually implement a modified version of the Loader interface that takes a KernelConfig rather than a Map. The Map mechanism will no longer exist. I was going to make them co-exist but I failed to see the point in that after beginning to consider spi use cases.
Now these changes require changes strewn through the spi and impl subprojects. I have started to retrofit the unit subproject with the new configuration mechanism using the KernelConfig. I'm thinking of doing away with the DefaultEmbeddedKernel all together and just creating a MerlinTestCase that uses the DefaultKernel but uses the appropriate KernelConfig. This way we do not have multiple Kernel implementations. As a result of roaming around the code base I have been gathering some ideas. Now is a good time to run some of them by you guys. Property Changes I changed the name of the application repository from merlin.repository.user.path to merlin.repository.application.path and changed the KernelConfig property to reflect the name change. I did this because it makes sense to call it the application repository. Different applications may have their own non-system repositories segregated from others. Or in the maven plugin embedded configuration the system and applications repos are the same for everything. The bottom line is this is not a user based repo but an application based repo. Kernel Package/Subproject Structure * The kernel configuration code within the loader belongs within the kernel-spi subproject project rather than being its own entity. First of all the Loader interface will be dependent on KernelConfig and so it makes no sense to keep them separate. Loader and KernelConfig are both logically part of the SPI. * A general utilities package should be created to consolidate some of the utility methods which seem to be replicated within several subprojects. I often find myself wanting to use a method in one subproject but refrain because I would be introducing another inter-project dependency. This utility package can reside at the peer level with composition, repository, kernel and activation directories. Slowly as functionality accumulates here it can be staged out into the commons or other areas that may be more relevant to the functionality of the utility code. * The CLI stuff should be re-factored out of the kernel implementation subproject and moved into the command line Merlin application which currently resides within the bootstrap subsubproject of the kernel subproject. * More on structure later - I need to get a bit more familiar first. Alex
