okidoki! A "Felix Caraf" makes sense and will help sharing knowledge NOW. (+1) "we should think hard about how to communicate that bundles are just bundles": Indeed. Probably it would help to communicate that the felix framework (that what we see in main + framework currently) is a high quality _but exchangeable_ framework implementation.
To me, the "What is Felix" on the main page should reorder the initial statement: "[..] community effort to implement the OSGi R4 Service Platform<http://www2.osgi.org/Specifications/HomePage>, which includes the OSGi framework and standard services, as well as providing and supporting other interesting OSGi-related technologies." to something highlight the ".. is a ecosystem for OSGi-related products and technologies including high class standard service/framework implementations" Then it makes thing clear that other vendors can pick and choose "best of bread". If this direction is correct i would also look into a more complete statement/description proposal. On Sat, Apr 4, 2009 at 11:07 AM, Marcel Offermans < [email protected]> wrote: > +1 on moving ahead on making Karaf a subproject at Felix > > On Apr 4, 2009, at 8:18 , Richard S. Hall wrote: > > I am happy to have the ServiceMix Kernel become a Felix subproject, but >> if the people involved wanted to pursue a TLP instead, I would happy >> with that decision too. But I wouldn't be happy if a TLP was pursued >> only because there is this perception that Felix subprojects are for >> Felix only. That just perpetuates people's ignorance. >> > > Agreed, we should think hard about how to communicate that bundles are just > bundles. That's not an easy battle though, because in quite a few other > implementations, most bundles are strongly tied to extensions that are > specific to that framework. > > <rant> > > Some examples: > > In Knopflerfish, most bundles have a dependency on their extended > LogService, which arguably is "just another bundle" but it still is > inconvenient that you have to drag in other bundles of the same > implementation (in this case, for very little reason). > > In Equinox, or rather in Eclipse, there are a lot of components that are > wired up through require bundle dependencies (which is a mechanism that > should have been deprecated from the start anyway). This makes it very hard > to get any type of substitutability. > > In Spring, arguably not an OSGi implementation, but they mention the word > OSGi so often that I'm mentioning them here anyway, it's also quite hard to > just use small components of their code because there too are so many > dependencies amongst core bundles that it's hard to "pick and choose". > > </rant> > > +10000 for the web site changes. Anyone willing to take a stab at it? >> > > Yes. There are two things that currently holding me back a bit: > > a) we do not have a staging environment, which would be nice for such a big > reorganization because it will take some time and that would leave our > website in an "undefined state" for some time > > b) I need to figure out a way to directly see changes in the auto export, > because having to wait for hours before I can see updates is inconvenient > when making big changes > > I probably could make this work by trying to install a private copy of > Confluence to make all changes and export/import everything but that would > require "locking" the space in the mean time (does not really sound like a > good solution). > > Greetings, Marcel > > -- Toni Menzel Software Developer Professional Profile: http://www.osgify.com [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
