Sounds ok to me ... but parsing of sub-modules really is a queue. Putting a SubmoduleDesriptor into the ModuleDescriptor is fair, but I'm hesistant to let that drive the actual search-and-parse of the sub-modules. It's a queue, not simply two passes (since sub-modules may themselves have sub-modules).
On the other hand, some of this other post-processing, including dependencies, lends itself well to a descriptor approach. The whole point is that, once all parsing has occured, dependencies can be check is perfectly valid. On Sun, 5 Sep 2004 19:54:48 +0200, Knut Wannheden <[EMAIL PROTECTED]> wrote: > Another idea on how to process module dependencies... > > > Using the RegistryAssembly is exactly the idea I was thinking of. > > Someting doesn't smell right, however, between the RegistryBuilder, > > RgistyAssembly, the DescriptorParser (and its base class) ... I think > > the seperation of concerns is not quite right. I've been on a path of > > breaking things up into smaller and smaller pieces with greater and > > greater success ... lately, I've been getting to the point where > > functionality central to a single class may still be coded into a > > seperate (and seprately testable) object if it isn't the contain > > class' core concern. Sounds pedantic buts its actuall pragmatic. > > > > How about having the DescriptorParser create objects of a class > DependencyDescriptor and add these to the ModuleDescriptor? This way > the responsibility of checking the dependencies (by registering a post > processor) could be moved to the RegistryBuilder, where it IMO makes > more sense. > > This could also be applied to submodule processing by having the > DescriptorParser add the referenced resources to the ModuleDescriptor > (e.g. an addSubmoduleResource(Resource) method). Then the > RegistryBuilder#processModule(ClassResolver, Resource) would parse > these and the RegistryAssembly could be relieved of the responsibility > of tracking submodules. Does this make sense? > > > > --knut > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
