Alex Karasulu wrote:
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.
As long as the loader classes are in the system classloader - we don't need that map.
About the only rationale for the map variant is if you wanted to create a KernelConfig via relection (i.e. passing a map as a constructor). But the way things are heading - I don't see a need for it. Anyway by the time we complete the refactorining of the plugin, abstract unit test, cli, test cases, and demos - I'm sure the requirements will real clear.
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.
+1
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.
Except that you need the loader classes in the system classpath to be able to bootstrap. You don't want SPI classes in the system classpath. That's the reason why I made it a seperate package. The loader classes should provide what we need to locate the merlin installation and system repository - after which we establish a new clessloader to load APIs, SPI, impls, etc. This ensures that the very minimum of classes are exposed to clients (components).
* 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.
+1
* 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.
+1
* More on structure later - I need to get a bit more familiar first.
Effort highly appreciated.
Cheers, Steve.
Alex
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
