Daniel Fagerstrom wrote:
...
But before we start to add bundles to Felix I think we need to discuss
what policy we should have for adding bundles. Here are my opinions:
* As it is part of our charter to "implement, document, maintain, and
support standard OSGi R4 services", we should in most cases accept code
contributions for standard services as initial code base (as long as the
legal issues are solved of course). For some services there might be
several different approaches for the services, in such cases we need of
course more discussion.
Sounds great. There are a number of smaller OBR repos with a lot to
offer and I hope we hear from more people like Didier who are willing to
raise the visibility of their work.
* Committers can add whatever bundle they want to their sandbox.
This is very cool. Without accountability, the sandbox rapidly becomes
a litterbox.
* Now we come to the complicated part: non standard bundles. One of the
cool things with our project is that we have the goal to "provide a
focal point for the open-source OSGi community to develop next
generation enhancements to the core framework and act as a conduit for
the open-source community to the OSGi Alliance". Fullfilling that
requires IMO some focus, we should not let our project become a dumping
ground for various half baked ideas and one man shows.
I'd like to provide some commentary, namely what we were thinking when
writing the proposal regarding #3 ("common needs not fully specified")
vs. #4 ("next generation enhancements"). Of course, I look forward to
Felix taking on a life of its own so this may largely be personal opinion.
As you note, #4 results in non-standard bundles. Really, with #4, "next
generation enhancements," we were thinking about how the Service Binder
went on to become Declarative Services. In other words, "next
generation" meant modularity and classloading ... deeper stuff.
But, I'd like to draw some attention to #3 as I believe that is where
some of the most useful bundles will come from. By "interfaces, APIs,
and other common needs not fully specified" we had in mind:
1) "store interfaces" - services such as UserAdmin, ConfigAdmin, and
PrefsAdmin did not define store interfaces. With store interfaces
defined, we could provide bundles for directory (JNDI), JDBC, or object
store (db4o, Prevayler) backends. Existing implementations either
provide no persistence or a simple file store. I believe the lack of
store options is holding back their wider usage.
2) "aspects of the runtime container's packaging" - really this means
daemons and installers (GUI, RPM) for Windows and Linux. We should be
able to provide these as features for Felix users at Apache and
elsewhere to re-use for their projects.
3) "bundle repositories" - OBR and related ideas, such as standardizing
repo formats with Maven and maybe even Eclipse update sites.
OK, I hope that helped. Looking back at the proposal I wouldn't be
surprised if it wasn't clear. Opps.
IMO a non standard bundle should only be accepted if it is a community
effort, i.e. if a couple of community members takes part in discussions,
design and implementation. We should also have vote about accepting the
bundle.
Makes sense.
The above might sound somewhat harsh but we have some rather bad
experience from the Cocoon project on letting people add modules
(blocks) whenever they feel like. After a number of years we have the
following situation: http://svn.apache.org/repos/asf/cocoon/blocks/.
Around 50 blocks of which only a handfull are actively maintained by the
community. It is not that easy for a new user to evaluate which of all
these blocks that they can rely on. And categorizing and removing blocks
leads to community friction.
So IMO we should only add a bundle after that we have made sure it has
real long term community support.
What do you think?
/Daniel
