As a reference, here are the related code that implement custom NamespaceHandlers: http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/bus/blueprint/ http://svn.apache.org/repos/asf/karaf/trunk/jaas/jasypt/src/main/java/org/apache/karaf/jaas/jasypt/handler/ http://svn.apache.org/repos/asf/karaf/trunk/shell/console/src/main/java/org/apache/karaf/shell/console/commands/ http://svn.apache.org/repos/asf/karaf/trunk/jaas/config/src/main/java/org/apache/karaf/jaas/config/impl/ http://svn.apache.org/repos/asf/camel/trunk/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/handler/ http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-blueprint/src/main/java/org/apache/xbean/blueprint/cm/ http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-blueprint/src/main/java/org/apache/xbean/blueprint/context/impl/
On Fri, Nov 25, 2011 at 13:17, Alasdair Nottingham <[email protected]> wrote: > Hi, > > I would like to propose we come up with a road map for getting the bundles > in aries up to the 1.0.0 release. Some things I think we need to do are: > > 1. Ensure we comply with relevant OSGi CTs > 2. Ensure we do semantic versioning > 3. Ensure we have a well defined API for extending and reusing blueprint > such that our internals are not exposed and we can ensure we don't break > CXF, XBeans-Blueprint, Karaf et al > > Based on the discussions over the last few weeks I would like to suggest we > have a discussion about what is needed by extenders of blueprint. While > those working on CXF, XBeans-blueprint Karaf etc all know how they are > using blueprint that information is not known to the whole aries community > causing may issues. We can then move to having an API we can keep stable, > and internals we can break. > > Thoughts? > Alasdair > > -- > Alasdair Nottingham > [email protected] > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
