HiveMind for Applications

[Raffael Herzog-2]

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

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... · Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com

[Jean-Francois Poilpret-2]

Hello Raffael,

I saw you mentioned HiveMind extensibility issues in order to have HiveMind
for Swing; for your information, I have developed several HiveMind
extensions (but no patch to HiveMind itself), one including HiveGUI, which
aims to use HiveMind in a Swing client.

Everything is available at http://hivetranse.sourceforge.net

However, I have to mention that I don't see much activity around HiveMind
(just look at the number of recent messages in this mailing list) and I tend
to believe that originators and maintainers don't find much interest into it
any longer, that's quite a pity, but that's seems reality!
Personally, I believe I will soon abandon any evolutions to my HiveMind
Utilities (what's the point?) and will just support it (and fix bugs) if I
receive any request.

Cheers

Jean-Francois

-----Original Message-----
From: Raffael Herzog [mailto:herzog@...]
Sent: Tuesday, May 13, 2008 6:17 PM
To: dev@...
Subject: HiveMind for Applications

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

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... . Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 . http://keyserver.pgp.com

[Jochen.Zimmermann]

Hi to everyone!

I'm using Hivemind for quite a while now (even for a little project on my job), but I think that I must abandon this, too.
I really understand if the original contributors don't have the time anymore (I must admit that I tried for two times now to help the Hivemind-Project with some documentation and could not manage to spend time on it myself) but at least you should try to keep the project alive ... Last board report there were some answers to the report, too, and the people were told to have a look at the jira issues, but I really feel that this is not enough to create a bigger interest in contributing to the project.
As I said before - I have no experience in managing an open source project or something, so I could not tell what should be done, but Hivemind is cool and should not die that silently .....

James - do you think that there is any chance that there will be any work on Hivemind in the future? Or is it really at its end?

Regards,
Jochen Zimmermann



-----Ursprüngliche Nachricht-----
Von: Jean-Francois Poilpret [mailto:jfpoilpret@...]
Gesendet: Dienstag, 13. Mai 2008 13:38
An: dev@...
Betreff: RE: HiveMind for Applications

Hello Raffael,

I saw you mentioned HiveMind extensibility issues in order to have HiveMind
for Swing; for your information, I have developed several HiveMind
extensions (but no patch to HiveMind itself), one including HiveGUI, which
aims to use HiveMind in a Swing client.

Everything is available at http://hivetranse.sourceforge.net

However, I have to mention that I don't see much activity around HiveMind
(just look at the number of recent messages in this mailing list) and I tend
to believe that originators and maintainers don't find much interest into it
any longer, that's quite a pity, but that's seems reality!
Personally, I believe I will soon abandon any evolutions to my HiveMind
Utilities (what's the point?) and will just support it (and fix bugs) if I
receive any request.

Cheers

Jean-Francois

-----Original Message-----
From: Raffael Herzog [mailto:herzog@...]
Sent: Tuesday, May 13, 2008 6:17 PM
To: dev@...
Subject: HiveMind for Applications

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

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... . Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 . http://keyserver.pgp.com

[Stefan Liebig-2]

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
>
>  

[jwcarman]

On Tue, May 13, 2008 at 7:57 AM,  <Jochen.Zimmermann@...> wrote:
>  James - do you think that there is any chance that there will be any work on Hivemind in the future? Or is it really at its end?

I really don't know at this point.  Spring is very pervasive and even
Howard stopped using HiveMind on Tapestry (our biggest source of
customers by far) in version 5.  I actually use Spring myself now.

[Jochen.Zimmermann]

You see, in fact I want to continue to use Hivemind and I have some good reasons to do so, but beside that reasons the overall status of the project strongly tells me to change ...

A last couple of questions to give me at least a little hope:
 
The Boad report says there is no active developer left in the project. Who is left for a rescue effort (for example someone who has an interest in recruiting new developers)? Or is there really no one left in the project at all (of course you (James) are left, but I'm not sure about your position and interests)

It looks like the new version 2 was/is not far from completion.
What must get done to do so?
Is anyone left in the project who knows what was planned beyond Hivemind 2?

Another point of view:
To be honest I do not know much about Spring. Hivemind was my first experience with IOC (because I almost always look first at Apache.org when I need some open source solution) and Hivemind gave me all I needed, so I stayed with it. But - is there any point in sticking to Hivemind?
Where is the difference to Spring in terms of conceptual differences? Or is there no difference and someone could just take Spring for gaining the exact same result?

-----Ursprüngliche Nachricht-----
Von: jcarman@... [mailto:jcarman@...] Im Auftrag von James Carman
Gesendet: Dienstag, 13. Mai 2008 15:05
An: dev@...
Betreff: Re: HiveMind for Applications

On Tue, May 13, 2008 at 7:57 AM,  <Jochen.Zimmermann@...> wrote:
>  James - do you think that there is any chance that there will be any work on Hivemind in the future? Or is it really at its end?

I really don't know at this point.  Spring is very pervasive and even
Howard stopped using HiveMind on Tapestry (our biggest source of
customers by far) in version 5.  I actually use Spring myself now.

[Johan Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Not to forget is that there has actually been some contributions in
terms of patches in the last couple of months (albeit from only 2
contributors), but I suspect it is not enough to create that extra bit
of interest ...   and I guess that with spring being what it is,
hivemind has less and less to compete with ...

but, hivemind is still in use, and it would be nice to see another
update or two ... i would be more than happy to apply the current
patches that are sitting in JIRA - and if nothing else, with the aim to
try to get a 1.2 release out the door.

Cheers,

Johan

James Carman wrote:
| On Tue, May 13, 2008 at 7:57 AM,  <Jochen.Zimmermann@...> wrote:
|>  James - do you think that there is any chance that there will be any
work on Hivemind in the future? Or is it really at its end?
|
| I really don't know at this point.  Spring is very pervasive and even
| Howard stopped using HiveMind on Tapestry (our biggest source of
| customers by far) in version 5.  I actually use Spring myself now.
|
|

- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKakIpHYnED7evioRAgnnAJ9lrHBLOoG675XPBHX39XpAxQe7OgCfZ3MI
K2BLvlqZc4adrfKEmh+X42c=
=ROeL
-----END PGP SIGNATURE-----

[Johan Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jochen,

I am not entirely sure about the current status of 2.0, but I believe it
was left with a few things still - some documentation and on-the-fly
classpath lookup of modules are outstanding last time I heard.

And as for going beyond 2.0 - I don't think the planning got that far
ahead ;)  But one place that could do with work is the website - it is
somewhat difficult to find the info you need (having 2.0 in alpha off
the main page and 1.0 as almost a side note confuses people sometimes I
believe) and as always, like with many other things, there are not so
many examples as you might want.  There was also a lot of talk about a
hivemind maven plugin, both for verification and hivedoc etc ... Not
sure where that got to ...  And not to forget the 80 or so open tickets
in JIRA... :)

As a side note, Achim began to move the 2.0 stuff onto the Apache Wiki,
which is a good  option.  Using the wiki would definitely allow more
document contributions to be applied.

Cheers,

Johan

Jochen.Zimmermann@... wrote:
| You see, in fact I want to continue to use Hivemind and I have some
good reasons to do so, but beside that reasons the overall status of the
project strongly tells me to change ...
|
| A last couple of questions to give me at least a little hope:
|
| The Boad report says there is no active developer left in the project.
Who is left for a rescue effort (for example someone who has an interest
in recruiting new developers)? Or is there really no one left in the
project at all (of course you (James) are left, but I'm not sure about
your position and interests)
|
| It looks like the new version 2 was/is not far from completion.
| What must get done to do so?
| Is anyone left in the project who knows what was planned beyond
Hivemind 2?
|
| Another point of view:
| To be honest I do not know much about Spring. Hivemind was my first
experience with IOC (because I almost always look first at Apache.org
when I need some open source solution) and Hivemind gave me all I
needed, so I stayed with it. But - is there any point in sticking to
Hivemind?
| Where is the difference to Spring in terms of conceptual differences?
Or is there no difference and someone could just take Spring for gaining
the exact same result?
|
| -----Ursprüngliche Nachricht-----
| Von: jcarman@...
[mailto:jcarman@...] Im Auftrag von James Carman
| Gesendet: Dienstag, 13. Mai 2008 15:05
| An: dev@...
| Betreff: Re: HiveMind for Applications
|
| On Tue, May 13, 2008 at 7:57 AM,  <Jochen.Zimmermann@...> wrote:
|>  James - do you think that there is any chance that there will be any
work on Hivemind in the future? Or is it really at its end?
|
| I really don't know at this point.  Spring is very pervasive and even
| Howard stopped using HiveMind on Tapestry (our biggest source of
| customers by far) in version 5.  I actually use Spring myself now.
|
|
|

- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKau8pHYnED7evioRAk3zAKCo3DjtaKMFe16FHzMPxKKkvxIpRACdGm5o
oc5IX2p8iVg10BjkZgZakX0=
=I4TR
-----END PGP SIGNATURE-----

[Raffael Herzog-2]

Am Dienstag, 13. Mai 2008 15.04:43 schrieb James Carman:
> On Tue, May 13, 2008 at 7:57 AM,  <Jochen.Zimmermann@...> wrote:
> >  James - do you think that there is any chance that there will be any
> > work on Hivemind in the future? Or is it really at its end?
>
> I really don't know at this point.  Spring is very pervasive and even
> Howard stopped using HiveMind on Tapestry (our biggest source of
> customers by far) in version 5.  I actually use Spring myself now.

I think, this is exactly HiveMind's problem: In that moment, when Tapestry
stopped using HiveMind, HiveMind basically lost it's reason of existence.
There are now two options:

a) we let it die
b) we give it a new reason of existence

This might also include throwing away some existing efforts for 1.2 or 2.0,
no replacement planned. *might*, not *must*!

I think, if we want to get HiveMind back to life, we should be open to take
some drastic measures.

Cheers,
   Raffi

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... · Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com

[Raffael Herzog-2]

Am Dienstag, 13. Mai 2008 16.54:52 schrieb Johan Lindquist:
> I am not entirely sure about the current status of 2.0, but I believe it
> was left with a few things still - some documentation and on-the-fly
                                                            ^^^^^^^^^^
> classpath lookup of modules are outstanding last time I heard.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ah, that sounds like a duplication of features with HiveApp to me. I was
never aware of that ...

> And as for going beyond 2.0 - I don't think the planning got that far
> ahead ;)  But one place that could do with work is the website - it is
> somewhat difficult to find the info you need (having 2.0 in alpha off
> the main page and 1.0 as almost a side note confuses people sometimes I
> believe) and as always, like with many other things, there are not so
> many examples as you might want.

[hmmm ...]

> There was also a lot of talk about a  
> hivemind maven plugin, both for verification and hivedoc etc ... Not
> sure where that got to ...

Oh, I just recently did one for HiveApp, I can do that again. ;)

Generally, my idea is not merging HiveApp into HiveMind, but there are
ideas, code and know-how ...

> As a side note, Achim began to move the 2.0 stuff onto the Apache Wiki,
> which is a good  option.  Using the wiki would definitely allow more
> document contributions to be applied.

A Wiki is a very good start, IMHO. Also in my case, when I started that
Wiki, at least *some* docs started to show up. Three month's ago, docs were
exactly at level zero ...

Cheers,
   Raffi

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... · Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com

[Raffael Herzog-2]

Am Dienstag, 13. Mai 2008 14.02:18 schrieb Stefan Liebig:
> 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.

No, I didn't. I'm not a friend of OSGi, even though I took some ideas from
it. You're right, that, especially in the area of classloading, I
re-implemented things, that are already present in OSGi, and that those
implementations (and their specifications) are more complete.

Sorry, but answering that question further as above takes a little more time
than I'm willing to spend at 1:00 ... ;)

Cheers,
   Raffi

--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.

herzog@... · Jabber: herzog@...
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com

[Ryan Slack]

On May 13, 2008 04:31:38 pm Raffael Herzog wrote:
> I think, if we want to get HiveMind back to life, we should be open to take
> some drastic measures.

While I personally don't like it, Spring is the defacto standard wrt IoC
containers. Perhaps the best way to move forward is to redefine HiveMind to
be an extention/plugin for Spring. Nobody likes to see a great product like
this go to waste, so at this point perhaps it would be best to just EOL the
HiveMind project as we know it, and put the code to good use in some other
form.

--Ryan

[Johan Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Agree, but we should not forget the few faithfuls out there ;)  And
there has been interest out there for a 1.2 from quite a few ...

Would an option be to trickle out a 1.2 release while putting more
effort into re-defining Hivemind's reasons for not dying?

Cheers,

Johan

Raffael Herzog wrote:
| Am Dienstag, 13. Mai 2008 15.04:43 schrieb James Carman:
|> On Tue, May 13, 2008 at 7:57 AM,  <Jochen.Zimmermann@...> wrote:
|>>  James - do you think that there is any chance that there will be any
|>> work on Hivemind in the future? Or is it really at its end?
|> I really don't know at this point.  Spring is very pervasive and even
|> Howard stopped using HiveMind on Tapestry (our biggest source of
|> customers by far) in version 5.  I actually use Spring myself now.
|
| I think, this is exactly HiveMind's problem: In that moment, when
Tapestry
| stopped using HiveMind, HiveMind basically lost it's reason of existence.
| There are now two options:
| a) we let it die
| b) we give it a new reason of existence
|
| This might also include throwing away some existing efforts for 1.2 or
2.0,
| no replacement planned. *might*, not *must*!
|
| I think, if we want to get HiveMind back to life, we should be open to
take
| some drastic measures.
| Cheers,
|    Raffi
|

- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKoo7pHYnED7evioRAvBZAJ9pjVi9QlY4aCMxJ/EJhJTN0TlcogCfa5GA
KjC6ikFkEZTOFQOvdDU2dJQ=
=FjoQ
-----END PGP SIGNATURE-----

[Jochen.Zimmermann]

Yesterday evening I scanned all the JIRA Issues.
I found quite a few bugs where patches already exists. As I see it there are 78 issues, but only 13 bugs without a patch. All other issues do have patches or are improvements, wishes or new feature requests (and there are also some with patches already included).
From that 13 open bugs are some with comments that suggests that these "bugs" could be solved with a different approach or aren't bugs at all, some are for Hivemind 2.0 only, so I believe there are less than 10 real bugs left for Hivemind 1.1.1 ...

Perhaps someone (Johan? :-) should scan the issues (and patches) and mark the ones (including feature requests) we need solved (or refactored) for a 1.2 release. I made an Excel sheet where I marked the issues that have patches supplied and the ones that are open, but I can only send this in the evening, because I'm at work now :-)

To start a discussion for "give Hivemind a new reason of existence":
Could someone emphasise differences to Spring that exists at the moment?
There must be some differences, I think Howard did something like this in the past already, but I was not able to find the web page again where I read this ... this could be a good start for a discussion ... what do you think??

Cheers,
Jochen

-----Ursprüngliche Nachricht-----
Von: Johan Lindquist [mailto:johan@...]
Gesendet: Mittwoch, 14. Mai 2008 08:44
An: dev@...
Betreff: Re: HiveMind for Applications

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Agree, but we should not forget the few faithfuls out there ;)  And
there has been interest out there for a 1.2 from quite a few ...

Would an option be to trickle out a 1.2 release while putting more
effort into re-defining Hivemind's reasons for not dying?

Cheers,

Johan

Raffael Herzog wrote:
| Am Dienstag, 13. Mai 2008 15.04:43 schrieb James Carman:
|> On Tue, May 13, 2008 at 7:57 AM,  <Jochen.Zimmermann@...> wrote:
|>>  James - do you think that there is any chance that there will be any
|>> work on Hivemind in the future? Or is it really at its end?
|> I really don't know at this point.  Spring is very pervasive and even
|> Howard stopped using HiveMind on Tapestry (our biggest source of
|> customers by far) in version 5.  I actually use Spring myself now.
|
| I think, this is exactly HiveMind's problem: In that moment, when
Tapestry
| stopped using HiveMind, HiveMind basically lost it's reason of existence.
| There are now two options:
| a) we let it die
| b) we give it a new reason of existence
|
| This might also include throwing away some existing efforts for 1.2 or
2.0,
| no replacement planned. *might*, not *must*!
|
| I think, if we want to get HiveMind back to life, we should be open to
take
| some drastic measures.
| Cheers,
|    Raffi
|

- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKoo7pHYnED7evioRAvBZAJ9pjVi9QlY4aCMxJ/EJhJTN0TlcogCfa5GA
KjC6ikFkEZTOFQOvdDU2dJQ=
=FjoQ
-----END PGP SIGNATURE-----

[Johan Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As a start, maybe we should call for all interested parties to have a
look at issues (focusing on bugs primarily) and use the JIRA voting
system.  This would give us a good hint as to what is immediately
wanted/needed.  I can in parallel take a look to try to summarize
outstanding issues as well ...

It would also be nice perhaps to add a couple of new versions to JIRA
(1.2, 1.2.1 or even 1.3) and re-assign pending maintenance and
enhancements for 1.X - giving us small roadmap to work against.
Emphasis on 'maintenance updates' at the moment, to see where the wind
takes it ...

Jochen, a couple of Howards posts relating to Spring/Hivemind
differences below - somewhat outdated, but a start ...

http://tapestryjava.blogspot.com/2004/02/comparing-hivemind-to-spring.html<