:) Coincidence. Today, I was reading older news and those that got my attention were those about Spring dm Server and latest modulefusion 1.1.0 that uses pax runner. And yep, that was my idea. we should have an open server (open as in our open participation). So, I'm 100% into this.
Related to where modulefusion lives, is not a problem, but what is the motivation behind having it at google code? We do have a good infrastructure here, we are in control, and so on. So, ops4j seems as a good place for such a project. And this because I have trust in the idea behind it. Now related to profiles: I was looking lately how I can improve the idea behind. So, for now I'm studying Equinox P2 (or maybe OBR) as this I think it could be a good base for what I wanna archive over there. The way profiles are handled right now it does not fill right. I will be back on the subject. Also for this kind of OSGI app server to be easy adopted an "a la Spring dm server" auto bundle discovery and installation should be in place. Also I guess in relation with good metadata, Equinox P2 or OBR. The only problem I see with OBR is that is not too much traction behind the idea this days. In conclusion, count me into this. On Mon, Feb 2, 2009 at 11:10 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > Gang, > I have been talking Face2Face with Roman Roelofsen at ProSyst, also > the driving force behind the ModuleFusion application server platform. > > What prompted me to do so (other than 'being nearby') is that > ModuleFusion touches on the 'future plans' of Pax in general. Once > upon a time, when Pax was created a few years back, I had this vision > that it would eventually evolve into a "OSGi Server Toolkit" or > something to that effect. I admit that the vision wasn't clear and > many things along the way have changed that too. Now, since > ModuleFusion is taking a large chunk of Pax stuff and doing what I now > think is the right thing for Pax, I think we should co-operate as much > as possible to make this a success. > > So, Roman would like to see a http://www.modulefusion.org where > everything happens, but Pax as a project stays here. Pax developers > are most welcome to work on ModuleFusion, now at Google Code, and I > don't think it is *that* important of where things live. > > Please take a look a ModuleFusion, and come with suggestions both here > and on the MF forums, of what things Pax should concentrate on to make > ModuleFusion the best, most versatile, easy-to-use and unpolluted[1] > OSGi based application server out there. (Well, it may not be limited > to servers either). > > > Cheers > Niclas > > [1] Unpolluted in this context is that we are not biased against any > particular technology or non-standard features. All our stuff should > work on all conformant OSGi platforms, and we shouldn't force people > into choice. MF already supports Peaberry (Stuart's Guice-Osgi > integration) and since MF uses Pax Runner, a simple profile will bring > in Spring DM. And this is Ok. But since a lot of the Eclipse stuff > requires Equinox specific features (Buddy Classloader), and less > desirable features (Required-Bundle), a lot of those subsystems > shouldl not be considered. If there are, or will be, similar issues > with Spring DM, then the same applies. > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
