I think the aim should be for blueprint to be the first major 1.0 module. I don't think we need the dependencies to be at 1.0, but I think it would be safer.
Alasdair Nottingham On 25 Nov 2011, at 16:47, Graham Charters <[email protected]> wrote: > 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]
