Adding bundles

[Daniel Fagerstrom <da...@nada.kth.se>]

Was: Re: kxml.jar

Didier Donsez wrote:
> Daniel Fagerstrom a écrit :
>> Didier Donsez wrote:
<snip/>
>>> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparser/readme.html
>>> and for the demo
>>> http://www-adele.imag.fr/~donsez/dev/osgi/metadataparsertest/readme.html
>>>
>>> This bundle could join the Felix code base.
>> How is it related to the metatype service?
>>
> No relationship.
> But I used the MetadataParser to quickly implement a simple Metatype 
> service.
> The MetadataParser parses the XML document associated to the service.
> http://www-adele.imag.fr/~donsez/dev/osgi/metatype/readme.html

If your Metatype service is part of the offering ;) I think it would 
make a good addition to Felix.

                  --- o0o ---

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.

* Committers can add whatever bundle they want to their sandbox.

* 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.

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.

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

Re: Adding bundles

[Niclas Hedhman <ni...@hedhman.org>]

On Friday 26 August 2005 05:59, Daniel Fagerstrom wrote:
> 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.

Yes. We should learn from experiences elsewhere in Apache, such as Cocoon and 
the commons projects.
But sometimes I am 'confused' that small useful code pieces "that just works" 
are often discarded as "not maintained" and "should not be used", which IMHO 
instead leads to "re-inventing the wheels" more often than necessary.

The more modular and scaled down a codebase is, the less important it is that 
there is a healthy community doing active development on it on a daily basis. 
Small codebases have less bugs, and if any users can find a bug quickly, and 
if there is a good feedback channel in place, it would not be a problem, 
IMVHO.

Now, that said, I would also like to take this opportunity to suggest that we 
could instead have "tools" and "infrastructure" to "publish" bundles that are 
available from a development point of view from elsewhere. I don't know the 
principles behind the Oscar Bundle Repository, but we could work on that 
principle and perhaps look into;
  *  Central discovery of N x OBRs, and/or
  *  RDF to publish and search for bundles across distributed sets of OBRs
  *  Meta information to classify bundles along various axis.

and so on...

Bottom line of that;  Allow one-man shows "elsewhere", and Felix community 
helps such efforts to reach a larger audience. For the users, it means go to 
Felix and from there they can search for any bundles, in any market segment, 
and over time I think such system of repositories would be an enormous help 
compared to the current Google searches.


Cheers
Niclas

Re: Adding bundles

[Enrique Rodriguez <en...@gmail.com>]

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
>