Hello Raffael,
Have you ever considered to do something similar that has been made with
Spring and OSGi (e.g. Equinox), i.e Spring Dynamic Modules? While
OSGi/Equinox solves the problems of dynamic modules (aka bundles),
versioning, class loading, ..; Spring contributes a simple injection
model similar to HiveMind.
Stefan
Raffael Herzog wrote:
Hi there,
I just wanted to inform everyone, that there's at least *some* activity
related to HiveMind. :)
I'm working on and with a extension to HiveMind, which is targeted at
building module based applications. There's a Wiki online at
http://hiveapp.raffael.ch/
Sorry, it's very incomplete, but at least it's *something* ... ;) Generally,
the project is open source and licensed under the Apache license, however,
it currently is a one-man-show, I'm the only contributor.
To help you understand better what the idea behind HiveApp is, let me tell
you a bit about its history/origins:
I was prototyping a build system based on a the idea of using the drools
rule engine to take the build decisions. This build system should, of
course be plugin-based, my idea was basically: Without plugins, it doesn't
do anything at all. I decided to use HiveMind as my container.
There were, however, some things about HiveMind, I had to change/extend.
First of all, I wanted drop-in plugability: A plugin should add its
functionality just by its presence. Also, it needed to be able to contain
its own classpath. Further, there were resources (DRL rule files in this
case), that, ideally, could be detected and added to the rule base auto-
matically. Finally, it should be runnable from within the IDE without
having to run any Ant or Maven tasks, to ease development.
That's the point, where the VFS was born: Each module is a little VFS:
/hivemodule.xml: We all know, what this is :)
/lib/*: All the classpath, a bunch of JAR files (called top-level-
container, they are not always actual JAR files)
/whatever: Put more other stuff here
When running in production, this will be the actual directory structure.
When running from within the IDE, those resources are located ... well ...
wherever they are. They're mounted by an entry in a mount file, eg:
EXTEND: target/classpath-mount.properties
/hivemodule.xml: descriptor/hivemodule.xml
/rules: resources/rules
The left side is the target path in the VFS, the right side is the physical
path relaitve to the mount file or an absolute URI. The 'EXTEND' entry is
sort of an include: The file target/classpath-mount.porperties is created
by a Maven plugin and contains the runtime dependencies from the M2 POMs.
Using this is optional, of course. The method to build the module's VFS is
is a pluggable module layout.
A second important point was classloader management. Because, if this build
system would ever be usable, I wanted to avoid version conflicts of
different versions of different plugins (which may also be 3rd party
plugins, of course), I wanted to add a intelligent classloader management.
See http://hiveapp.raffael.ch/wiki/doku.php/classloader for details.
Other things you can find in HiveApp are mainly some additional services
(e.g. the pattern for sharing service implementations as introduced at
http://imsardine.blogspot.com/2008/03/hivemind-how-to-share-same.html is
part of the HiveApp core since almost the beginning).
Unfortunately, I had to do some workarounds and hacks, to achieve my goals.
In one instance, the AppBuilderFactory, I even had to copy and modify
HiveMind's code. I'd be happy to start contributing to HiveMind to make it
more open, so it's easier to add functionality to HiveMind, i.e. make
HiveMind itself more pluggable. This may be useful for other things, too,
like e.g. some HiveMind for Swing or HiveMind for EJBs project. I'd
definitely would want to keep such extensions out of HiveMind's core.
Of course, we'd have to discuss *what* we're actually going to do. But
allowing to extend HiveMind a bit more might revive the project a bit by
making it more open to other applications than just Webapps (I know,
HiveMind basically already is open to other applications, but you can
always "feel" that the developers mainly had Webapps in mind).
Comments and suggestions are of course welcome ... (I probably wouldn't have
written this mail if they weren't ;)
Cheers,
Raffi
