« Return to Thread: HiveMind for Applications
Re: HiveMind for Applications
by Stefan Liebig-2
::
Rate this Message:
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
>
>
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
>
>
« Return to Thread: HiveMind for Applications
| Free embeddable forum powered by Nabble | Forum Help |
