I took your last para to be a suggestion for blueprint- my mistake. It seems to be the one giving us the most indigestion. By suggesting util first, as its at the bottom of the stack, is there a criterion that says a 1.0 release can't/shouldn't depend on pre-1.0 modules?
On 25 November 2011 16:31, Alasdair Nottingham <[email protected]> wrote: > Hmm, well I might pick on util first myself, but only because it is at the > bottom of the stack. Blueprint is the bit that has the most work required I > think. > > On 25 November 2011 16:19, Graham Charters <[email protected]> wrote: > >> +1 to the criteria and +1 to picking on Blueprint first. >> >> On 25 November 2011 12:31, Guillaume Nodet <[email protected]> wrote: >> > 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 >> > > > > -- > Alasdair Nottingham > [email protected]
