[PROPOSAL] New plan for Apache ServiceMix 5.0

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] New plan for Apache ServiceMix 5.0

Gert Vanthienen
Administrator
L.S.,


About a year and a half ago, we had some discussions on the mailing list
about a plan for Apache ServiceMix 5.0 and had some initial commits to
build the additional services and functionality.  Since then however, none
of us have actually had the time to work on that code or move things
forward.

In the meanwhile, we are also struggling constantly to get our releases
done in timely fashion.  The latest 4.5.0 release took almost 9 months
since the first mention of it on the dev@ list.  Doing a ServiceMix release
now is quite a task: it usually involves doing releases in 5 or 6
subprojects.

I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
doing a lot of new development, how about we start with the current 4.x
features codebase and remove everything that's related to JBI and the NMR.
 That will give us a nice and simple integration container build (based on
Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
project that's quick and easy to release.

If we start doing this now, we could get a build out with Karaf 2.3.0,
ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
the possibility to include the Akka OSGi examples I built a few months ago)
pretty soon after those versions are available.   With only one project to
maintain the versions of all those dependencies, we should be able to
follow up more regularly as our sibling projects do (new) fix releases as
well.

We don't have to throw away the existing ServiceMix 5.0 code by the way, we
can always move that into a separate branch and then cherry-pick the useful
bits afterwards, but I think our first goal now should be to get ourselves
in a position that we can actually build and release stuff more easily
again.


Wdyt?

Gert Vanthienen
Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Willem.Jiang
It sounds good. Keep it simple and deliverable is a best practice we always do :)

发自我的 iPhone

在 2013-2-4,上午4:54,Gert Vanthienen <[hidden email]> 写道:

> L.S.,
>
>
> About a year and a half ago, we had some discussions on the mailing list
> about a plan for Apache ServiceMix 5.0 and had some initial commits to
> build the additional services and functionality.  Since then however, none
> of us have actually had the time to work on that code or move things
> forward.
>
> In the meanwhile, we are also struggling constantly to get our releases
> done in timely fashion.  The latest 4.5.0 release took almost 9 months
> since the first mention of it on the dev@ list.  Doing a ServiceMix release
> now is quite a task: it usually involves doing releases in 5 or 6
> subprojects.
>
> I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
> doing a lot of new development, how about we start with the current 4.x
> features codebase and remove everything that's related to JBI and the NMR.
> That will give us a nice and simple integration container build (based on
> Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> project that's quick and easy to release.
>
> If we start doing this now, we could get a build out with Karaf 2.3.0,
> ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
> the possibility to include the Akka OSGi examples I built a few months ago)
> pretty soon after those versions are available.   With only one project to
> maintain the versions of all those dependencies, we should be able to
> follow up more regularly as our sibling projects do (new) fix releases as
> well.
>
> We don't have to throw away the existing ServiceMix 5.0 code by the way, we
> can always move that into a separate branch and then cherry-pick the useful
> bits afterwards, but I think our first goal now should be to get ourselves
> in a position that we can actually build and release stuff more easily
> again.
>
>
> Wdyt?
>
> Gert Vanthienen
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Jean-Baptiste Onofré
In reply to this post by Gert Vanthienen
+1

It sounds like a good plan, and provide a good message to the community.

Regards
JB

On 02/03/2013 09:54 PM, Gert Vanthienen wrote:

> L.S.,
>
>
> About a year and a half ago, we had some discussions on the mailing list
> about a plan for Apache ServiceMix 5.0 and had some initial commits to
> build the additional services and functionality.  Since then however, none
> of us have actually had the time to work on that code or move things
> forward.
>
> In the meanwhile, we are also struggling constantly to get our releases
> done in timely fashion.  The latest 4.5.0 release took almost 9 months
> since the first mention of it on the dev@ list.  Doing a ServiceMix release
> now is quite a task: it usually involves doing releases in 5 or 6
> subprojects.
>
> I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
> doing a lot of new development, how about we start with the current 4.x
> features codebase and remove everything that's related to JBI and the NMR.
>   That will give us a nice and simple integration container build (based on
> Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> project that's quick and easy to release.
>
> If we start doing this now, we could get a build out with Karaf 2.3.0,
> ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
> the possibility to include the Akka OSGi examples I built a few months ago)
> pretty soon after those versions are available.   With only one project to
> maintain the versions of all those dependencies, we should be able to
> follow up more regularly as our sibling projects do (new) fix releases as
> well.
>
> We don't have to throw away the existing ServiceMix 5.0 code by the way, we
> can always move that into a separate branch and then cherry-pick the useful
> bits afterwards, but I think our first goal now should be to get ourselves
> in a position that we can actually build and release stuff more easily
> again.
>
>
> Wdyt?
>
> Gert Vanthienen
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Filippo Balicchia
+1

streamline and increase the frequency of releases sound good for me

Regards

--Filippo

2013/2/4 Jean-Baptiste Onofré <[hidden email]>:

> +1
>
> It sounds like a good plan, and provide a good message to the community.
>
> Regards
> JB
>
>
> On 02/03/2013 09:54 PM, Gert Vanthienen wrote:
>>
>> L.S.,
>>
>>
>> About a year and a half ago, we had some discussions on the mailing list
>> about a plan for Apache ServiceMix 5.0 and had some initial commits to
>> build the additional services and functionality.  Since then however, none
>> of us have actually had the time to work on that code or move things
>> forward.
>>
>> In the meanwhile, we are also struggling constantly to get our releases
>> done in timely fashion.  The latest 4.5.0 release took almost 9 months
>> since the first mention of it on the dev@ list.  Doing a ServiceMix
>> release
>> now is quite a task: it usually involves doing releases in 5 or 6
>> subprojects.
>>
>> I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
>> doing a lot of new development, how about we start with the current 4.x
>> features codebase and remove everything that's related to JBI and the NMR.
>>   That will give us a nice and simple integration container build (based
>> on
>> Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
>> project that's quick and easy to release.
>>
>> If we start doing this now, we could get a build out with Karaf 2.3.0,
>> ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
>> the possibility to include the Akka OSGi examples I built a few months
>> ago)
>> pretty soon after those versions are available.   With only one project to
>> maintain the versions of all those dependencies, we should be able to
>> follow up more regularly as our sibling projects do (new) fix releases as
>> well.
>>
>> We don't have to throw away the existing ServiceMix 5.0 code by the way,
>> we
>> can always move that into a separate branch and then cherry-pick the
>> useful
>> bits afterwards, but I think our first goal now should be to get ourselves
>> in a position that we can actually build and release stuff more easily
>> again.
>>
>>
>> Wdyt?
>>
>> Gert Vanthienen
>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Guillaume Nodet
Administrator
In reply to this post by Gert Vanthienen
Are you also talking about moving back everything in a single subproject ?
So that the release would only consist in a single maven release ?
If so, I'm not sure we can easily do that for bundles (which are used by
downstream projects), and also the specs (which are used by Karaf).


On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen
<[hidden email]>wrote:

> L.S.,
>
>
> About a year and a half ago, we had some discussions on the mailing list
> about a plan for Apache ServiceMix 5.0 and had some initial commits to
> build the additional services and functionality.  Since then however, none
> of us have actually had the time to work on that code or move things
> forward.
>
> In the meanwhile, we are also struggling constantly to get our releases
> done in timely fashion.  The latest 4.5.0 release took almost 9 months
> since the first mention of it on the dev@ list.  Doing a ServiceMix
> release
> now is quite a task: it usually involves doing releases in 5 or 6
> subprojects.
>
> I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
> doing a lot of new development, how about we start with the current 4.x
> features codebase and remove everything that's related to JBI and the NMR.
>  That will give us a nice and simple integration container build (based on
> Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> project that's quick and easy to release.
>
> If we start doing this now, we could get a build out with Karaf 2.3.0,
> ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
> the possibility to include the Akka OSGi examples I built a few months ago)
> pretty soon after those versions are available.   With only one project to
> maintain the versions of all those dependencies, we should be able to
> follow up more regularly as our sibling projects do (new) fix releases as
> well.
>
> We don't have to throw away the existing ServiceMix 5.0 code by the way, we
> can always move that into a separate branch and then cherry-pick the useful
> bits afterwards, but I think our first goal now should be to get ourselves
> in a position that we can actually build and release stuff more easily
> again.
>
>
> Wdyt?
>
> Gert Vanthienen
>



--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Gert Vanthienen
Administrator
Guillaume,


Bundles and specs are usually released separately these days and they have
a completely different release cycle than the container, so I would keep
those as they are today.

I was mainly thinking about Features itself and the things we usually
release together with that (Utils, Components, NMR, Archetypes).  If we
could strip that down to a single maven build for the container itself and
drop the JBI/NMR bits, we should be able to do those container builds more
quickly and easily, making it easier to stay up-to-date with all other
dependency versions (Karaf, Camel, CXF, ...)


Regards,

Gert Vanthienen


On Mon, Feb 4, 2013 at 9:16 AM, Guillaume Nodet <[hidden email]> wrote:

> Are you also talking about moving back everything in a single subproject ?
> So that the release would only consist in a single maven release ?
> If so, I'm not sure we can easily do that for bundles (which are used by
> downstream projects), and also the specs (which are used by Karaf).
>
>
> On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen
> <[hidden email]>wrote:
>
> > L.S.,
> >
> >
> > About a year and a half ago, we had some discussions on the mailing list
> > about a plan for Apache ServiceMix 5.0 and had some initial commits to
> > build the additional services and functionality.  Since then however,
> none
> > of us have actually had the time to work on that code or move things
> > forward.
> >
> > In the meanwhile, we are also struggling constantly to get our releases
> > done in timely fashion.  The latest 4.5.0 release took almost 9 months
> > since the first mention of it on the dev@ list.  Doing a ServiceMix
> > release
> > now is quite a task: it usually involves doing releases in 5 or 6
> > subprojects.
> >
> > I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
> > doing a lot of new development, how about we start with the current 4.x
> > features codebase and remove everything that's related to JBI and the
> NMR.
> >  That will give us a nice and simple integration container build (based
> on
> > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> > project that's quick and easy to release.
> >
> > If we start doing this now, we could get a build out with Karaf 2.3.0,
> > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
> > the possibility to include the Akka OSGi examples I built a few months
> ago)
> > pretty soon after those versions are available.   With only one project
> to
> > maintain the versions of all those dependencies, we should be able to
> > follow up more regularly as our sibling projects do (new) fix releases as
> > well.
> >
> > We don't have to throw away the existing ServiceMix 5.0 code by the way,
> we
> > can always move that into a separate branch and then cherry-pick the
> useful
> > bits afterwards, but I think our first goal now should be to get
> ourselves
> > in a position that we can actually build and release stuff more easily
> > again.
> >
> >
> > Wdyt?
> >
> > Gert Vanthienen
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: [hidden email]
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Guillaume Nodet
Administrator
Yeah, that sounds like a good plan to me, +1


On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
<[hidden email]>wrote:

> Guillaume,
>
>
> Bundles and specs are usually released separately these days and they have
> a completely different release cycle than the container, so I would keep
> those as they are today.
>
> I was mainly thinking about Features itself and the things we usually
> release together with that (Utils, Components, NMR, Archetypes).  If we
> could strip that down to a single maven build for the container itself and
> drop the JBI/NMR bits, we should be able to do those container builds more
> quickly and easily, making it easier to stay up-to-date with all other
> dependency versions (Karaf, Camel, CXF, ...)
>
>
> Regards,
>
> Gert Vanthienen
>
>
> On Mon, Feb 4, 2013 at 9:16 AM, Guillaume Nodet <[hidden email]> wrote:
>
> > Are you also talking about moving back everything in a single subproject
> ?
> > So that the release would only consist in a single maven release ?
> > If so, I'm not sure we can easily do that for bundles (which are used by
> > downstream projects), and also the specs (which are used by Karaf).
> >
> >
> > On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen
> > <[hidden email]>wrote:
> >
> > > L.S.,
> > >
> > >
> > > About a year and a half ago, we had some discussions on the mailing
> list
> > > about a plan for Apache ServiceMix 5.0 and had some initial commits to
> > > build the additional services and functionality.  Since then however,
> > none
> > > of us have actually had the time to work on that code or move things
> > > forward.
> > >
> > > In the meanwhile, we are also struggling constantly to get our releases
> > > done in timely fashion.  The latest 4.5.0 release took almost 9 months
> > > since the first mention of it on the dev@ list.  Doing a ServiceMix
> > > release
> > > now is quite a task: it usually involves doing releases in 5 or 6
> > > subprojects.
> > >
> > > I would like to propose a new plan for Apache ServiceMix 5.0.  Instead
> of
> > > doing a lot of new development, how about we start with the current 4.x
> > > features codebase and remove everything that's related to JBI and the
> > NMR.
> > >  That will give us a nice and simple integration container build (based
> > on
> > > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> > > project that's quick and easy to release.
> > >
> > > If we start doing this now, we could get a build out with Karaf 2.3.0,
> > > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens
> up
> > > the possibility to include the Akka OSGi examples I built a few months
> > ago)
> > > pretty soon after those versions are available.   With only one project
> > to
> > > maintain the versions of all those dependencies, we should be able to
> > > follow up more regularly as our sibling projects do (new) fix releases
> as
> > > well.
> > >
> > > We don't have to throw away the existing ServiceMix 5.0 code by the
> way,
> > we
> > > can always move that into a separate branch and then cherry-pick the
> > useful
> > > bits afterwards, but I think our first goal now should be to get
> > ourselves
> > > in a position that we can actually build and release stuff more easily
> > > again.
> > >
> > >
> > > Wdyt?
> > >
> > > Gert Vanthienen
> > >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: [hidden email]
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>



--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Robert Davies-2
sounds good to me too

On 4 February 2013 10:21, Guillaume Nodet <[hidden email]> wrote:

> Yeah, that sounds like a good plan to me, +1
>
>
> On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
> <[hidden email]>wrote:
>
> > Guillaume,
> >
> >
> > Bundles and specs are usually released separately these days and they
> have
> > a completely different release cycle than the container, so I would keep
> > those as they are today.
> >
> > I was mainly thinking about Features itself and the things we usually
> > release together with that (Utils, Components, NMR, Archetypes).  If we
> > could strip that down to a single maven build for the container itself
> and
> > drop the JBI/NMR bits, we should be able to do those container builds
> more
> > quickly and easily, making it easier to stay up-to-date with all other
> > dependency versions (Karaf, Camel, CXF, ...)
> >
> >
> > Regards,
> >
> > Gert Vanthienen
> >
> >
> > On Mon, Feb 4, 2013 at 9:16 AM, Guillaume Nodet <[hidden email]>
> wrote:
> >
> > > Are you also talking about moving back everything in a single
> subproject
> > ?
> > > So that the release would only consist in a single maven release ?
> > > If so, I'm not sure we can easily do that for bundles (which are used
> by
> > > downstream projects), and also the specs (which are used by Karaf).
> > >
> > >
> > > On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen
> > > <[hidden email]>wrote:
> > >
> > > > L.S.,
> > > >
> > > >
> > > > About a year and a half ago, we had some discussions on the mailing
> > list
> > > > about a plan for Apache ServiceMix 5.0 and had some initial commits
> to
> > > > build the additional services and functionality.  Since then however,
> > > none
> > > > of us have actually had the time to work on that code or move things
> > > > forward.
> > > >
> > > > In the meanwhile, we are also struggling constantly to get our
> releases
> > > > done in timely fashion.  The latest 4.5.0 release took almost 9
> months
> > > > since the first mention of it on the dev@ list.  Doing a ServiceMix
> > > > release
> > > > now is quite a task: it usually involves doing releases in 5 or 6
> > > > subprojects.
> > > >
> > > > I would like to propose a new plan for Apache ServiceMix 5.0.
>  Instead
> > of
> > > > doing a lot of new development, how about we start with the current
> 4.x
> > > > features codebase and remove everything that's related to JBI and the
> > > NMR.
> > > >  That will give us a nice and simple integration container build
> (based
> > > on
> > > > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a
> single
> > > > project that's quick and easy to release.
> > > >
> > > > If we start doing this now, we could get a build out with Karaf
> 2.3.0,
> > > > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and
> opens
> > up
> > > > the possibility to include the Akka OSGi examples I built a few
> months
> > > ago)
> > > > pretty soon after those versions are available.   With only one
> project
> > > to
> > > > maintain the versions of all those dependencies, we should be able to
> > > > follow up more regularly as our sibling projects do (new) fix
> releases
> > as
> > > > well.
> > > >
> > > > We don't have to throw away the existing ServiceMix 5.0 code by the
> > way,
> > > we
> > > > can always move that into a separate branch and then cherry-pick the
> > > useful
> > > > bits afterwards, but I think our first goal now should be to get
> > > ourselves
> > > > in a position that we can actually build and release stuff more
> easily
> > > > again.
> > > >
> > > >
> > > > Wdyt?
> > > >
> > > > Gert Vanthienen
> > > >
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > > ------------------------
> > > Red Hat, Open Source Integration
> > >
> > > Email: [hidden email]
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: [hidden email]
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Andreas Pieber
+1 from my side too!

Kind regards,
Andreas


On Mon, Feb 4, 2013 at 11:49 AM, Robert Davies <[hidden email]> wrote:

> sounds good to me too
>
> On 4 February 2013 10:21, Guillaume Nodet <[hidden email]> wrote:
>
> > Yeah, that sounds like a good plan to me, +1
> >
> >
> > On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
> > <[hidden email]>wrote:
> >
> > > Guillaume,
> > >
> > >
> > > Bundles and specs are usually released separately these days and they
> > have
> > > a completely different release cycle than the container, so I would
> keep
> > > those as they are today.
> > >
> > > I was mainly thinking about Features itself and the things we usually
> > > release together with that (Utils, Components, NMR, Archetypes).  If we
> > > could strip that down to a single maven build for the container itself
> > and
> > > drop the JBI/NMR bits, we should be able to do those container builds
> > more
> > > quickly and easily, making it easier to stay up-to-date with all other
> > > dependency versions (Karaf, Camel, CXF, ...)
> > >
> > >
> > > Regards,
> > >
> > > Gert Vanthienen
> > >
> > >
> > > On Mon, Feb 4, 2013 at 9:16 AM, Guillaume Nodet <[hidden email]>
> > wrote:
> > >
> > > > Are you also talking about moving back everything in a single
> > subproject
> > > ?
> > > > So that the release would only consist in a single maven release ?
> > > > If so, I'm not sure we can easily do that for bundles (which are used
> > by
> > > > downstream projects), and also the specs (which are used by Karaf).
> > > >
> > > >
> > > > On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen
> > > > <[hidden email]>wrote:
> > > >
> > > > > L.S.,
> > > > >
> > > > >
> > > > > About a year and a half ago, we had some discussions on the mailing
> > > list
> > > > > about a plan for Apache ServiceMix 5.0 and had some initial commits
> > to
> > > > > build the additional services and functionality.  Since then
> however,
> > > > none
> > > > > of us have actually had the time to work on that code or move
> things
> > > > > forward.
> > > > >
> > > > > In the meanwhile, we are also struggling constantly to get our
> > releases
> > > > > done in timely fashion.  The latest 4.5.0 release took almost 9
> > months
> > > > > since the first mention of it on the dev@ list.  Doing a
> ServiceMix
> > > > > release
> > > > > now is quite a task: it usually involves doing releases in 5 or 6
> > > > > subprojects.
> > > > >
> > > > > I would like to propose a new plan for Apache ServiceMix 5.0.
> >  Instead
> > > of
> > > > > doing a lot of new development, how about we start with the current
> > 4.x
> > > > > features codebase and remove everything that's related to JBI and
> the
> > > > NMR.
> > > > >  That will give us a nice and simple integration container build
> > (based
> > > > on
> > > > > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a
> > single
> > > > > project that's quick and easy to release.
> > > > >
> > > > > If we start doing this now, we could get a build out with Karaf
> > 2.3.0,
> > > > > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and
> > opens
> > > up
> > > > > the possibility to include the Akka OSGi examples I built a few
> > months
> > > > ago)
> > > > > pretty soon after those versions are available.   With only one
> > project
> > > > to
> > > > > maintain the versions of all those dependencies, we should be able
> to
> > > > > follow up more regularly as our sibling projects do (new) fix
> > releases
> > > as
> > > > > well.
> > > > >
> > > > > We don't have to throw away the existing ServiceMix 5.0 code by the
> > > way,
> > > > we
> > > > > can always move that into a separate branch and then cherry-pick
> the
> > > > useful
> > > > > bits afterwards, but I think our first goal now should be to get
> > > > ourselves
> > > > > in a position that we can actually build and release stuff more
> > easily
> > > > > again.
> > > > >
> > > > >
> > > > > Wdyt?
> > > > >
> > > > > Gert Vanthienen
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > > ------------------------
> > > > Red Hat, Open Source Integration
> > > >
> > > > Email: [hidden email]
> > > > Web: http://fusesource.com
> > > > Blog: http://gnodet.blogspot.com/
> > > >
> > >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: [hidden email]
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Freeman-2
+1
-------------
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋

On 2013-2-4, at 下午6:50, Andreas Pieber wrote:

> +1 from my side too!
>
> Kind regards,
> Andreas
>
>
> On Mon, Feb 4, 2013 at 11:49 AM, Robert Davies <[hidden email]> wrote:
>
>> sounds good to me too
>>
>> On 4 February 2013 10:21, Guillaume Nodet <[hidden email]> wrote:
>>
>>> Yeah, that sounds like a good plan to me, +1
>>>
>>>
>>> On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
>>> <[hidden email]>wrote:
>>>
>>>> Guillaume,
>>>>
>>>>
>>>> Bundles and specs are usually released separately these days and they
>>> have
>>>> a completely different release cycle than the container, so I would
>> keep
>>>> those as they are today.
>>>>
>>>> I was mainly thinking about Features itself and the things we usually
>>>> release together with that (Utils, Components, NMR, Archetypes).  If we
>>>> could strip that down to a single maven build for the container itself
>>> and
>>>> drop the JBI/NMR bits, we should be able to do those container builds
>>> more
>>>> quickly and easily, making it easier to stay up-to-date with all other
>>>> dependency versions (Karaf, Camel, CXF, ...)
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert Vanthienen
>>>>
>>>>
>>>> On Mon, Feb 4, 2013 at 9:16 AM, Guillaume Nodet <[hidden email]>
>>> wrote:
>>>>
>>>>> Are you also talking about moving back everything in a single
>>> subproject
>>>> ?
>>>>> So that the release would only consist in a single maven release ?
>>>>> If so, I'm not sure we can easily do that for bundles (which are used
>>> by
>>>>> downstream projects), and also the specs (which are used by Karaf).
>>>>>
>>>>>
>>>>> On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen
>>>>> <[hidden email]>wrote:
>>>>>
>>>>>> L.S.,
>>>>>>
>>>>>>
>>>>>> About a year and a half ago, we had some discussions on the mailing
>>>> list
>>>>>> about a plan for Apache ServiceMix 5.0 and had some initial commits
>>> to
>>>>>> build the additional services and functionality.  Since then
>> however,
>>>>> none
>>>>>> of us have actually had the time to work on that code or move
>> things
>>>>>> forward.
>>>>>>
>>>>>> In the meanwhile, we are also struggling constantly to get our
>>> releases
>>>>>> done in timely fashion.  The latest 4.5.0 release took almost 9
>>> months
>>>>>> since the first mention of it on the dev@ list.  Doing a
>> ServiceMix
>>>>>> release
>>>>>> now is quite a task: it usually involves doing releases in 5 or 6
>>>>>> subprojects.
>>>>>>
>>>>>> I would like to propose a new plan for Apache ServiceMix 5.0.
>>> Instead
>>>> of
>>>>>> doing a lot of new development, how about we start with the current
>>> 4.x
>>>>>> features codebase and remove everything that's related to JBI and
>> the
>>>>> NMR.
>>>>>> That will give us a nice and simple integration container build
>>> (based
>>>>> on
>>>>>> Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a
>>> single
>>>>>> project that's quick and easy to release.
>>>>>>
>>>>>> If we start doing this now, we could get a build out with Karaf
>>> 2.3.0,
>>>>>> ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and
>>> opens
>>>> up
>>>>>> the possibility to include the Akka OSGi examples I built a few
>>> months
>>>>> ago)
>>>>>> pretty soon after those versions are available.   With only one
>>> project
>>>>> to
>>>>>> maintain the versions of all those dependencies, we should be able
>> to
>>>>>> follow up more regularly as our sibling projects do (new) fix
>>> releases
>>>> as
>>>>>> well.
>>>>>>
>>>>>> We don't have to throw away the existing ServiceMix 5.0 code by the
>>>> way,
>>>>> we
>>>>>> can always move that into a separate branch and then cherry-pick
>> the
>>>>> useful
>>>>>> bits afterwards, but I think our first goal now should be to get
>>>>> ourselves
>>>>>> in a position that we can actually build and release stuff more
>>> easily
>>>>>> again.
>>>>>>
>>>>>>
>>>>>> Wdyt?
>>>>>>
>>>>>> Gert Vanthienen
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Red Hat, Open Source Integration
>>>>>
>>>>> Email: [hidden email]
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gnodet.blogspot.com/
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: [hidden email]
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Corrado Campisano
In reply to this post by Willem.Jiang
hi

will the choice to "remove everything that's related to JBI and the NMR"
will make the installation footprint better?

Karaf is 10MB (as much as smix4 minimal assembly), other smix4 assemblies
are default=50MB, JBI=80MB, full=200MB (as much as Fuse ESB is), what about
smix5 assemblies?


Regards,
corrado


2013/2/4 Willem Jiang <[hidden email]>

> It sounds good. Keep it simple and deliverable is a best practice we
> always do :)
>
> 发自我的 iPhone
>
> 在 2013-2-4,上午4:54,Gert Vanthienen <[hidden email]> 写道:
>
> > L.S.,
> >
> >
> > About a year and a half ago, we had some discussions on the mailing list
> > about a plan for Apache ServiceMix 5.0 and had some initial commits to
> > build the additional services and functionality.  Since then however,
> none
> > of us have actually had the time to work on that code or move things
> > forward.
> >
> > In the meanwhile, we are also struggling constantly to get our releases
> > done in timely fashion.  The latest 4.5.0 release took almost 9 months
> > since the first mention of it on the dev@ list.  Doing a ServiceMix
> release
> > now is quite a task: it usually involves doing releases in 5 or 6
> > subprojects.
> >
> > I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
> > doing a lot of new development, how about we start with the current 4.x
> > features codebase and remove everything that's related to JBI and the
> NMR.
> > That will give us a nice and simple integration container build (based on
> > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> > project that's quick and easy to release.
> >
> > If we start doing this now, we could get a build out with Karaf 2.3.0,
> > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
> > the possibility to include the Akka OSGi examples I built a few months
> ago)
> > pretty soon after those versions are available.   With only one project
> to
> > maintain the versions of all those dependencies, we should be able to
> > follow up more regularly as our sibling projects do (new) fix releases as
> > well.
> >
> > We don't have to throw away the existing ServiceMix 5.0 code by the way,
> we
> > can always move that into a separate branch and then cherry-pick the
> useful
> > bits afterwards, but I think our first goal now should be to get
> ourselves
> > in a position that we can actually build and release stuff more easily
> > again.
> >
> >
> > Wdyt?
> >
> > Gert Vanthienen
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Claus Ibsen-2
In reply to this post by Gert Vanthienen
On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
<[hidden email]> wrote:

> Guillaume,
>
>
> Bundles and specs are usually released separately these days and they have
> a completely different release cycle than the container, so I would keep
> those as they are today.
>
> I was mainly thinking about Features itself and the things we usually
> release together with that (Utils, Components, NMR, Archetypes).  If we
> could strip that down to a single maven build for the container itself and
> drop the JBI/NMR bits, we should be able to do those container builds more
> quickly and easily, making it easier to stay up-to-date with all other
> dependency versions (Karaf, Camel, CXF, ...)
>
>
> Regards,
>
> Gert Vanthienen
>

+1

Sounds good if it becomes easier to cut new SMX releases (as well
patch releases).



>
> On Mon, Feb 4, 2013 at 9:16 AM, Guillaume Nodet <[hidden email]> wrote:
>
>> Are you also talking about moving back everything in a single subproject ?
>> So that the release would only consist in a single maven release ?
>> If so, I'm not sure we can easily do that for bundles (which are used by
>> downstream projects), and also the specs (which are used by Karaf).
>>
>>
>> On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen
>> <[hidden email]>wrote:
>>
>> > L.S.,
>> >
>> >
>> > About a year and a half ago, we had some discussions on the mailing list
>> > about a plan for Apache ServiceMix 5.0 and had some initial commits to
>> > build the additional services and functionality.  Since then however,
>> none
>> > of us have actually had the time to work on that code or move things
>> > forward.
>> >
>> > In the meanwhile, we are also struggling constantly to get our releases
>> > done in timely fashion.  The latest 4.5.0 release took almost 9 months
>> > since the first mention of it on the dev@ list.  Doing a ServiceMix
>> > release
>> > now is quite a task: it usually involves doing releases in 5 or 6
>> > subprojects.
>> >
>> > I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
>> > doing a lot of new development, how about we start with the current 4.x
>> > features codebase and remove everything that's related to JBI and the
>> NMR.
>> >  That will give us a nice and simple integration container build (based
>> on
>> > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
>> > project that's quick and easy to release.
>> >
>> > If we start doing this now, we could get a build out with Karaf 2.3.0,
>> > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
>> > the possibility to include the Akka OSGi examples I built a few months
>> ago)
>> > pretty soon after those versions are available.   With only one project
>> to
>> > maintain the versions of all those dependencies, we should be able to
>> > follow up more regularly as our sibling projects do (new) fix releases as
>> > well.
>> >
>> > We don't have to throw away the existing ServiceMix 5.0 code by the way,
>> we
>> > can always move that into a separate branch and then cherry-pick the
>> useful
>> > bits afterwards, but I think our first goal now should be to get
>> ourselves
>> > in a position that we can actually build and release stuff more easily
>> > again.
>> >
>> >
>> > Wdyt?
>> >
>> > Gert Vanthienen
>> >
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>



--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Jon Anstey
In reply to this post by Gert Vanthienen
Excellent idea Gert +1


On Sun, Feb 3, 2013 at 5:24 PM, Gert Vanthienen
<[hidden email]>wrote:

> L.S.,
>
>
> About a year and a half ago, we had some discussions on the mailing list
> about a plan for Apache ServiceMix 5.0 and had some initial commits to
> build the additional services and functionality.  Since then however, none
> of us have actually had the time to work on that code or move things
> forward.
>
> In the meanwhile, we are also struggling constantly to get our releases
> done in timely fashion.  The latest 4.5.0 release took almost 9 months
> since the first mention of it on the dev@ list.  Doing a ServiceMix
> release
> now is quite a task: it usually involves doing releases in 5 or 6
> subprojects.
>
> I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
> doing a lot of new development, how about we start with the current 4.x
> features codebase and remove everything that's related to JBI and the NMR.
>  That will give us a nice and simple integration container build (based on
> Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> project that's quick and easy to release.
>
> If we start doing this now, we could get a build out with Karaf 2.3.0,
> ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
> the possibility to include the Akka OSGi examples I built a few months ago)
> pretty soon after those versions are available.   With only one project to
> maintain the versions of all those dependencies, we should be able to
> follow up more regularly as our sibling projects do (new) fix releases as
> well.
>
> We don't have to throw away the existing ServiceMix 5.0 code by the way, we
> can always move that into a separate branch and then cherry-pick the useful
> bits afterwards, but I think our first goal now should be to get ourselves
> in a position that we can actually build and release stuff more easily
> again.
>
>
> Wdyt?
>
> Gert Vanthienen
>



--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: [hidden email]
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Gert Vanthienen
Administrator
In reply to this post by Corrado Campisano
L.S.,


I don't think that the installation (disk space) footprint would change a
lot, to be honest.

For the default assembly, that already doesn't include any of the JBI/NMR
stuff, so it is just Karaf + Camel/CXF/ActiveMQ JARs.  The JBI assembly
would disappear and the full assembly would probably become only slightly
smaller (because we drop the NMR/JBI + JBI components, but a lot of their
dependencies are part of Camel & co as well).  The whole point of the full
assembly is to have something that contains all the runtime dependencies
for offline use, so that's bound to be a rather large distribution.

We added the minimal assembly for people that don't like our default
dependency set (Camel, CXF and ActiveMQ) and just need one or two of those,
so they can start with an empty container and only add the things they
want.  What particular combination of components/dependencies did you have
in mind when you were thinking about a smaller footprint assembly?


Regards,

Gert Vanthienen

On Mon, Feb 4, 2013 at 12:17 PM, Corrado Campisano <
[hidden email]> wrote:

> hi
>
> will the choice to "remove everything that's related to JBI and the NMR"
> will make the installation footprint better?
>
> Karaf is 10MB (as much as smix4 minimal assembly), other smix4 assemblies
> are default=50MB, JBI=80MB, full=200MB (as much as Fuse ESB is), what about
> smix5 assemblies?
>
>
> Regards,
> corrado
>
>
> 2013/2/4 Willem Jiang <[hidden email]>
>
> > It sounds good. Keep it simple and deliverable is a best practice we
> > always do :)
> >
> > 发自我的 iPhone
> >
> > 在 2013-2-4,上午4:54,Gert Vanthienen <[hidden email]> 写道:
> >
> > > L.S.,
> > >
> > >
> > > About a year and a half ago, we had some discussions on the mailing
> list
> > > about a plan for Apache ServiceMix 5.0 and had some initial commits to
> > > build the additional services and functionality.  Since then however,
> > none
> > > of us have actually had the time to work on that code or move things
> > > forward.
> > >
> > > In the meanwhile, we are also struggling constantly to get our releases
> > > done in timely fashion.  The latest 4.5.0 release took almost 9 months
> > > since the first mention of it on the dev@ list.  Doing a ServiceMix
> > release
> > > now is quite a task: it usually involves doing releases in 5 or 6
> > > subprojects.
> > >
> > > I would like to propose a new plan for Apache ServiceMix 5.0.  Instead
> of
> > > doing a lot of new development, how about we start with the current 4.x
> > > features codebase and remove everything that's related to JBI and the
> > NMR.
> > > That will give us a nice and simple integration container build (based
> on
> > > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> > > project that's quick and easy to release.
> > >
> > > If we start doing this now, we could get a build out with Karaf 2.3.0,
> > > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens
> up
> > > the possibility to include the Akka OSGi examples I built a few months
> > ago)
> > > pretty soon after those versions are available.   With only one project
> > to
> > > maintain the versions of all those dependencies, we should be able to
> > > follow up more regularly as our sibling projects do (new) fix releases
> as
> > > well.
> > >
> > > We don't have to throw away the existing ServiceMix 5.0 code by the
> way,
> > we
> > > can always move that into a separate branch and then cherry-pick the
> > useful
> > > bits afterwards, but I think our first goal now should be to get
> > ourselves
> > > in a position that we can actually build and release stuff more easily
> > > again.
> > >
> > >
> > > Wdyt?
> > >
> > > Gert Vanthienen
> >
>
Regards,

Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Henryk Konsek
In reply to this post by Gert Vanthienen
> Wdyt?

+1

Actually recently I advised customer to choose vanilla Karaf instead
of ServiceMix. I wanted the latest container (Karaf) with all its
bugfixes and the latest Camel, so using ServiceMix was pointless. Many
users will appreciate shorter release cycles of SMX.

--
Henryk Konsek
http://henryk-konsek.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Corrado Campisano
Hi Henryk,

that would be my case, how difficult it would be to create a custom build
for Karaf?


regards,

2013/2/4 Henryk Konsek <[hidden email]>

> > Wdyt?
>
> +1
>
> Actually recently I advised customer to choose vanilla Karaf instead
> of ServiceMix. I wanted the latest container (Karaf) with all its
> bugfixes and the latest Camel, so using ServiceMix was pointless. Many
> users will appreciate shorter release cycles of SMX.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Andreas Pieber
It's not that difficult, but you need to face all the problems SMX solves
for you like updating the jre.properties, system.properties (system class
loader), additional libs and so on... So, it's possible but definitely not
a no-brain action...

Kind regards,
Andreas



On Mon, Feb 4, 2013 at 5:55 PM, Corrado Campisano <
[hidden email]> wrote:

> Hi Henryk,
>
> that would be my case, how difficult it would be to create a custom build
> for Karaf?
>
>
> regards,
>
> 2013/2/4 Henryk Konsek <[hidden email]>
>
> > > Wdyt?
> >
> > +1
> >
> > Actually recently I advised customer to choose vanilla Karaf instead
> > of ServiceMix. I wanted the latest container (Karaf) with all its
> > bugfixes and the latest Camel, so using ServiceMix was pointless. Many
> > users will appreciate shorter release cycles of SMX.
> >
> > --
> > Henryk Konsek
> > http://henryk-konsek.blogspot.com
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Henryk Konsek
In reply to this post by Corrado Campisano
> that would be my case, how difficult it would be to create a custom build
> for Karaf?

It is not really difficult but not trivial in case of problems and corner-cases.

This is good option for existing development teams with strong
understanding of the SMX stack (and the way it is build on the top of
the Karaf) in situations when the access to the latest version of
Karaf and dependencies is important.

--
Henryk Konsek
http://henryk-konsek.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Corrado Campisano
thx,
I think I'll stay on smix and do not mess with Karaf...


anyway +1 for the new smix5 approach.

regards,
corrado

2013/2/4 Henryk Konsek <[hidden email]>

> > that would be my case, how difficult it would be to create a custom build
> > for Karaf?
>
> It is not really difficult but not trivial in case of problems and
> corner-cases.
>
> This is good option for existing development teams with strong
> understanding of the SMX stack (and the way it is build on the top of
> the Karaf) in situations when the access to the latest version of
> Karaf and dependencies is important.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] New plan for Apache ServiceMix 5.0

Christian Mueller
In reply to this post by Gert Vanthienen
+1 sounds good

Sent from a mobile device
Am 03.02.2013 21:55 schrieb "Gert Vanthienen" <[hidden email]>:

> L.S.,
>
>
> About a year and a half ago, we had some discussions on the mailing list
> about a plan for Apache ServiceMix 5.0 and had some initial commits to
> build the additional services and functionality.  Since then however, none
> of us have actually had the time to work on that code or move things
> forward.
>
> In the meanwhile, we are also struggling constantly to get our releases
> done in timely fashion.  The latest 4.5.0 release took almost 9 months
> since the first mention of it on the dev@ list.  Doing a ServiceMix
> release
> now is quite a task: it usually involves doing releases in 5 or 6
> subprojects.
>
> I would like to propose a new plan for Apache ServiceMix 5.0.  Instead of
> doing a lot of new development, how about we start with the current 4.x
> features codebase and remove everything that's related to JBI and the NMR.
>  That will give us a nice and simple integration container build (based on
> Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single
> project that's quick and easy to release.
>
> If we start doing this now, we could get a build out with Karaf 2.3.0,
> ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up
> the possibility to include the Akka OSGi examples I built a few months ago)
> pretty soon after those versions are available.   With only one project to
> maintain the versions of all those dependencies, we should be able to
> follow up more regularly as our sibling projects do (new) fix releases as
> well.
>
> We don't have to throw away the existing ServiceMix 5.0 code by the way, we
> can always move that into a separate branch and then cherry-pick the useful
> bits afterwards, but I think our first goal now should be to get ourselves
> in a position that we can actually build and release stuff more easily
> again.
>
>
> Wdyt?
>
> Gert Vanthienen
>
12