> > I think a hierarchy is fine. If you can't use the other > modules without the main module, perhaps making them separate > sandbox projects is not terribly useful. On the other hand, > perhaps the main module could be just another "mix-in" that > you check out from the repository to add to separate projects > to support them. Or maybe I'm missing the point entirely. > > This is one area I have struggled with many times before. > Maven has some promise, as you have noted, to allow support > for clean separation of modules. I tried doing this entirely > in CVS, but was not altogether successful.
I think its about managing dependencies. HiveMind has limited dependencies on some other commons projects and on Javassist. If you build some HiveMind glue to another project, you may inadventantly require the other project as a dependency, so you add a few KB of HiveMinde glue and, possibly, many megs of external dependency. Also, just like you want to keep your APIs lean and mean, keeping the services and extension-points in a module lean and mean helps with comprehension. So, I'd rather have a new module, say "hivemind.standard.hibernate" that contains wrappers around Hibernate than have those wrappers part of the main library whether you use Hibernate or not. > > >What kind of services can we create for the additional libraries? > > Would a data access service be too ambitious? Even something > that helps with ordinary JDBC setup and testing would be > nice/useful for many projects. Sounds like a decent idea for me; we're doing something similar at WebCT shortly and I'm pushing to leverage HiveMind. Now if only I could MANDATE it ... -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
