Niclas Hedhman schrieb: > You can of course move anywhere you like. Personally, I want HiveApp > to stay and prosper as much as want Hansa to do the same.
Good to read that. ;) > Setting up and running infrastructure is quite a bit of work, and if > you are looking for more visibility through a domain name, I think we > can accommodate that. No, the domain name really isn't an issue. However, to create a full documentation in a Wiki probably would require a whole Sub-Wiki -- putting everything in a single page would produce one *huge* page ... :) But while we're at the infrastructure: Did you ever have a look at Trac? It might be a good idea to setup Trac for active non-laboratory projects like e.g. pax-wicket. > So, I think your first step is documentation. Sure. > I mean, you have taken > some time to write the stuff below. Copy that up to the Wiki, or > convert it to Maven's APT Moving things to M2 (also Loom) is something which I'm seriously considering. And using a M2 site would also solve the problem of overcrowding the Wiki with HiveApp documentation. > and ask for a publish and I'll help out > making it happen (just like Pax Wicket now resides in > http://www.ops4j.org/projects/pax/wicket), and a hiveapp.org domain > name proxy for that is easy to set up. That's future, things like that can be considered when/if people jump in. For now, it's just a one-man project which actually is a side-ef- fect of my Silk efforts that eventually turned into a project of its own. ;) (Very much like HiveMind is basically a side-effect of Tapestry) My plan is to get docs and a build up, announce HiveApp to the HiveMind mailing list and see what happens ... :) Maybe they say "what crap is this, what did this freak do to our beloved HiveMind", maybe they say "do what you want, not our business", maybe they say "wow, cool stuff, let's incorporate this into HiveMind 2.0 immediately". :) Come to think of it, full JavaDoc with elaborate package.html files, full HiveDoc, a build, and a single Wiki page summarising things should be enough for this step. > At the OSGi Enterprise Expert Group kick-off last week, it was > identified that OSGi is not an application model, whereas Spring is, > so the synergies are very good. Adrian Colyer and Andy Piper (and > others) are working hard to merge OSGi and Spring, with the best from > both worlds. BTW, HiveMind also provides some support for Spring: <service-point id="MyService" interface="MyInterface"> <invoke-factory service-id="hivemind.lib.SpringLookupFactory> <lookup-bean name="MySpringBean" bean-factory="service:MyBeanFactory"/> </invoke-factory> </service-point> => voilà, we've got a Spring bean in our hive. :) It would probably be possible to do something similar with OSGi, I don't know whether this would make sense, however. > Their work looks really promising and there are talks > about making EEG amendments to the Declarative Services specification > in OSGi along the findings of the Spring/OSGi integration. The DS++ > would make old-school IoC friends (Spring, Pico, HiveMind) very happy > and still allow for the dynamic nature of OSGi. > > Now, HiveMind (AFAIK) is more in the space of Spring than it is in > the space of OSGi, and perhaps HiveMind will need to provide the same > level of OSGi support under its covers not to be totally marginalized > by Spring. The point is that Spring provides a huge number of ready-to-use beans, the IoC part is just one aspect of it. HiveMind doesn't have all those tools, but in the IoC department, it's IMO much better, if not the best. And I know that I'm not the only one who thinks so, but in practice, most people will choose Spring over HiveMind because everything's there already, while with HiveMind, you'll still have to do things yourself. Will HiveMind survive? I don't know, really. But the fact that it's just recently been converted from a Jakarta subproject into a top-level project of its own is encouraging. :) cu, Raffi -- The difference between theory and practice is that in theory, there is no difference, but in practice, there is. [EMAIL PROTECTED] · Jabber: [EMAIL PROTECTED] PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
