2009/2/3 Alin Dreghiciu <adreghi...@gmail.com> > :) 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. >
just a quick FYI, I hosted peaberry on googlecode mainly because I wanted to see what their hosting was like - also guice is hosted there, so it's a little bit easier for people to pick up peaberry - halo effect, and all that... but it's just code in subversion + a wiki, so moving it around isn't a big deal as for modulefusion I don't mind where it's hosted, as long as we don't end up duplicating work because of the two systems (like having to post to two mailing lists / needing bug reports in two issue tracking systems) 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. > part of the problem is that the OBR RFC has stagnated, and so it's hard to find a complete implementation of even the current spec - especially wrt. fragments and how they map to the schema... btw, I think Jeff mentioned P2 should be able to consume OBR metadata and that P2 should be able to run on other OSGi frameworks (he said if it didn't raise a bug to get it fixed!) so even if we went with P2 we should be able to take advantage of existing OBRs, perhaps Maven repos too so +1 for investigating P2 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 > -- Cheers, Stuart
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
