You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Alasdair Nottingham <no...@apache.org> on 2011/11/25 13:17:08 UTC
Roadmap for Apache Aries 1.0
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
not@apache.org
RE: Roadmap for Apache Aries 1.0
Posted by Timothy Ward <ti...@apache.org>.
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> Date: Fri, 25 Nov 2011 16:47:42 +0000
> Subject: Re: Roadmap for Apache Aries 1.0
> From: gcharters@gmail.com
> To: dev@aries.apache.org
>
> 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?
I think that there should be, otherwise you have a confusing difference between the pre 1.0 and post 1.0 semantic versioning we do. Some dependencies would need minor ranges and others major. Not easy to understand from the outside!
>
> On 25 November 2011 16:31, Alasdair Nottingham <no...@apache.org> 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 <gc...@gmail.com> wrote:
> >
> >> +1 to the criteria and +1 to picking on Blueprint first.
> >>
> >> On 25 November 2011 12:31, Guillaume Nodet <gn...@gmail.com> 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 <no...@apache.org>
> >> 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
> >> >> not@apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > ------------------------
> >> > Guillaume Nodet
> >> > ------------------------
> >> > Blog: http://gnodet.blogspot.com/
> >> > ------------------------
> >> > Open Source SOA
> >> > http://fusesource.com
> >>
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
Re: Roadmap for Apache Aries 1.0
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gc...@gmail.com> 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 <no...@apache.org> 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 <gc...@gmail.com> wrote:
>>
>>> +1 to the criteria and +1 to picking on Blueprint first.
>>>
>>> On 25 November 2011 12:31, Guillaume Nodet <gn...@gmail.com> 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 <no...@apache.org>
>>> 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
>>>>> not@apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
Re: Roadmap for Apache Aries 1.0
Posted by Graham Charters <gc...@gmail.com>.
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 <no...@apache.org> 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 <gc...@gmail.com> wrote:
>
>> +1 to the criteria and +1 to picking on Blueprint first.
>>
>> On 25 November 2011 12:31, Guillaume Nodet <gn...@gmail.com> 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 <no...@apache.org>
>> 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
>> >> not@apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
Re: Roadmap for Apache Aries 1.0
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gc...@gmail.com> wrote:
> +1 to the criteria and +1 to picking on Blueprint first.
>
> On 25 November 2011 12:31, Guillaume Nodet <gn...@gmail.com> 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 <no...@apache.org>
> 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
> >> not@apache.org
> >>
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: Roadmap for Apache Aries 1.0
Posted by Graham Charters <gc...@gmail.com>.
+1 to the criteria and +1 to picking on Blueprint first.
On 25 November 2011 12:31, Guillaume Nodet <gn...@gmail.com> 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 <no...@apache.org> 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
>> not@apache.org
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Roadmap for Apache Aries 1.0
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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
> not@apache.org
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com