You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Gert Vanthienen <ge...@gmail.com> on 2013/02/03 21:54:38 UTC
[PROPOSAL] New plan for Apache ServiceMix 5.0
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
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Gert Vanthienen <ge...@gmail.com>.
Oliver,
In ServiceMix 5, we won't be including the JBI and NMR layers nor the
JBI components any more. You can still install the older versions of
those bundles into ServiceMix 5, but that will only be a convenient
solution as long the version ranges of those bundles still match up
with what we have available (e.g. for things like Spring, Blueprint,
...).
At this moment, we are using our ServiceMix 4 features/trunk to work
towards newer 4.5.x releases but we haven't been doing any upgrades to
newer versions of Camel, Karaf, ActiveMQ, ... there. We can easily
change that and set up the necessary branch to maintain a newer
version of ServiceMix 4.x if you or anyone else in the community
fancies working on that.
In the long run, you'll probably want to move away from JBI for your
own development. If you run into any issues or features that are
missing or have any tips and tricks to share with other users, we'd
obviously be very interested in learning about those experiences too.
Regards,
Gert Vanthienen
On Mon, Apr 29, 2013 at 1:49 PM, Oliver Kuntze
<ol...@union-investment.de> wrote:
> Hi Gert,
>
> what does "remove everything that's related to JBI and the NMR" mean?
>
> Does it mean that you'll drop further development of the corresponding
> bundles but one could use the "old" bundles in Servicemix 5?
> Or does it mean that one cannot use existing JBI components in Servicemix 5?
>
> We have quite some JBI components swimming in our current Servicemix
> installation and I'll have to make up my mind regarding migration scenarios.
>
> Thanks in advance for your insight!
>
> Best regards
> Oliver
>
>
>
>
>
> --
> View this message in context: http://servicemix.396122.n5.nabble.com/PROPOSAL-New-plan-for-Apache-ServiceMix-5-0-tp5715705p5716603.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Oliver Kuntze <ol...@union-investment.de>.
Hi Gert,
what does "remove everything that's related to JBI and the NMR" mean?
Does it mean that you'll drop further development of the corresponding
bundles but one could use the "old" bundles in Servicemix 5?
Or does it mean that one cannot use existing JBI components in Servicemix 5?
We have quite some JBI components swimming in our current Servicemix
installation and I'll have to make up my mind regarding migration scenarios.
Thanks in advance for your insight!
Best regards
Oliver
--
View this message in context: http://servicemix.396122.n5.nabble.com/PROPOSAL-New-plan-for-Apache-ServiceMix-5-0-tp5715705p5716603.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Freeman Fang <fr...@gmail.com>.
+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 <ra...@gmail.com> wrote:
>
>> sounds good to me too
>>
>> On 4 February 2013 10:21, Guillaume Nodet <gn...@gmail.com> wrote:
>>
>>> Yeah, that sounds like a good plan to me, +1
>>>
>>>
>>> On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
>>> <ge...@gmail.com>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 <gn...@gmail.com>
>>> 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
>>>>> <ge...@gmail.com>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: gnodet@redhat.com
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gnodet.blogspot.com/
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Andreas Pieber <an...@gmail.com>.
+1 from my side too!
Kind regards,
Andreas
On Mon, Feb 4, 2013 at 11:49 AM, Robert Davies <ra...@gmail.com> wrote:
> sounds good to me too
>
> On 4 February 2013 10:21, Guillaume Nodet <gn...@gmail.com> wrote:
>
> > Yeah, that sounds like a good plan to me, +1
> >
> >
> > On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
> > <ge...@gmail.com>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 <gn...@gmail.com>
> > 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
> > > > <ge...@gmail.com>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: gnodet@redhat.com
> > > > Web: http://fusesource.com
> > > > Blog: http://gnodet.blogspot.com/
> > > >
> > >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Robert Davies <ra...@gmail.com>.
sounds good to me too
On 4 February 2013 10:21, Guillaume Nodet <gn...@gmail.com> wrote:
> Yeah, that sounds like a good plan to me, +1
>
>
> On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
> <ge...@gmail.com>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 <gn...@gmail.com>
> 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
> > > <ge...@gmail.com>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: gnodet@redhat.com
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, that sounds like a good plan to me, +1
On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
<ge...@gmail.com>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 <gn...@gmail.com> 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
> > <ge...@gmail.com>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: gnodet@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen
<ge...@gmail.com> 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 <gn...@gmail.com> 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
>> <ge...@gmail.com>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: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Gert Vanthienen <ge...@gmail.com>.
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 <gn...@gmail.com> 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
> <ge...@gmail.com>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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<ge...@gmail.com>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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Corrado Campisano <co...@gmail.com>.
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 <he...@gmail.com>
> > 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
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Henryk Konsek <he...@gmail.com>.
> 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
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Andreas Pieber <an...@gmail.com>.
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 <
corrado.campisano@gmail.com> 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 <he...@gmail.com>
>
> > > 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
> >
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Corrado Campisano <co...@gmail.com>.
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 <he...@gmail.com>
> > 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
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Henryk Konsek <he...@gmail.com>.
> 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
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Filippo Balicchia <fb...@gmail.com>.
+1
streamline and increase the frequency of releases sound good for me
Regards
--Filippo
2013/2/4 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> +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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Gert Vanthienen <ge...@gmail.com>.
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 <
corrado.campisano@gmail.com> 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 <wi...@gmail.com>
>
> > It sounds good. Keep it simple and deliverable is a best practice we
> > always do :)
> >
> > 发自我的 iPhone
> >
> > 在 2013-2-4，上午4:54，Gert Vanthienen <ge...@gmail.com> 写道：
> >
> > > 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
> >
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Corrado Campisano <co...@gmail.com>.
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 <wi...@gmail.com>
> It sounds good. Keep it simple and deliverable is a best practice we
> always do :)
>
> 发自我的 iPhone
>
> 在 2013-2-4，上午4:54，Gert Vanthienen <ge...@gmail.com> 写道：
>
> > 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
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Willem Jiang <wi...@gmail.com>.
It sounds good. Keep it simple and deliverable is a best practice we always do :)
发自我的 iPhone
在 2013-2-4，上午4:54，Gert Vanthienen <ge...@gmail.com> 写道：
> 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
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Jon Anstey <ja...@gmail.com>.
Excellent idea Gert +1
On Sun, Feb 3, 2013 at 5:24 PM, Gert Vanthienen
<ge...@gmail.com>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: janstey@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Matt Pavlovich <ma...@gmail.com>.
+1
I think that goes a long way to removing the end-user confusion/new
developer ramp up period if JBI+NMR is fully removed.
Thanks
On 2/3/13 2: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
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Ioannis Canellos <io...@gmail.com>.
Awesome idea! Let's keep SM.
--
*Ioannis Canellos*
*
**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Filippo Balicchia <fb...@gmail.com>.
+1 re-using the SM project for 5.0.x
Regards
--Filippo
2013/2/6 Gert Vanthienen <ge...@gmail.com>:
> L.S.,
>
>
> The new development trunk for 5.0 is available at
> http://svn.apache.org/repos/asf/servicemix/smx5/trunk/ - I also set up a CI
> build at https://builds.apache.org/job/ServiceMix5/ and a first set of
> SNAPSHOTs has been deployed to repository.apache.org.
>
> The container itself is starting, but several bundles are not starting
> correctly (probably due to version mismatches or config changes that are
> required by the newer versions of specs, changes in ActiveMQ, ...). Apart
> from ironing out these issues, we probably want to convert the integration
> tests to pax-exam-karaf as well (cfr.
> https://issues.apache.org/jira/browse/SMX4-1282). Let's start raising JIRA
> issues for these remaining issues and tasks, but that brings us to the next
> question...
>
> What would be the best way to track issues for this new release? We could
> get a new JIRA for SMX5 as we have for SMX4, but we already have quite a
> few JIRA projects to work with. We could also just add a version to
> project SMX4 (though this project name might confuse users) or start
> re-using the SM project for 5.0.x (since we are no longer actively
> maintaining 3.x). Any preferences?
>
>
> Regards,
>
> Gert
>
>
> On Tue, Feb 5, 2013 at 10:40 AM, Gert Vanthienen
> <ge...@gmail.com>wrote:
>
>> L.S.,
>>
>>
>> I was planning to move the old code to a branch and set up the build today
>> or tomorrow, so we can start working on this once the 4.5.0 release is out.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>>
>>
>> On Tue, Feb 5, 2013 at 8:13 AM, Henryk Konsek <he...@gmail.com> wrote:
>>
>>> > +1 sounds good
>>>
>>> Facing this swarm of +1s, when do you plan to start working on the SMX
>>> 5.0 release? I'll be more than happy to help as much as my limited
>>> time resources allow me to :) .
>>>
>>> --
>>> Henryk Konsek
>>> http://henryk-konsek.blogspot.com
>>>
>>
>>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Freeman Fang <fr...@gmail.com>.
+1 to reuse SM
－－－－－－－－－－－－－
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-7, at 上午4:58, Christian Müller wrote:
> +1 for reusing SM or creating a new one SMX (without the 5 at the end)
>
> Sent from a mobile device
> Am 06.02.2013 21:46 schrieb "Gert Vanthienen" <ge...@gmail.com>:
>
>> L.S.,
>>
>>
>> The new development trunk for 5.0 is available at
>> http://svn.apache.org/repos/asf/servicemix/smx5/trunk/ - I also set up a
>> CI
>> build at https://builds.apache.org/job/ServiceMix5/ and a first set of
>> SNAPSHOTs has been deployed to repository.apache.org.
>>
>> The container itself is starting, but several bundles are not starting
>> correctly (probably due to version mismatches or config changes that are
>> required by the newer versions of specs, changes in ActiveMQ, ...). Apart
>> from ironing out these issues, we probably want to convert the integration
>> tests to pax-exam-karaf as well (cfr.
>> https://issues.apache.org/jira/browse/SMX4-1282). Let's start raising
>> JIRA
>> issues for these remaining issues and tasks, but that brings us to the next
>> question...
>>
>> What would be the best way to track issues for this new release? We could
>> get a new JIRA for SMX5 as we have for SMX4, but we already have quite a
>> few JIRA projects to work with. We could also just add a version to
>> project SMX4 (though this project name might confuse users) or start
>> re-using the SM project for 5.0.x (since we are no longer actively
>> maintaining 3.x). Any preferences?
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>> On Tue, Feb 5, 2013 at 10:40 AM, Gert Vanthienen
>> <ge...@gmail.com>wrote:
>>
>>> L.S.,
>>>
>>>
>>> I was planning to move the old code to a branch and set up the build
>> today
>>> or tomorrow, so we can start working on this once the 4.5.0 release is
>> out.
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>>
>>>
>>> On Tue, Feb 5, 2013 at 8:13 AM, Henryk Konsek <he...@gmail.com>
>> wrote:
>>>
>>>>> +1 sounds good
>>>>
>>>> Facing this swarm of +1s, when do you plan to start working on the SMX
>>>> 5.0 release? I'll be more than happy to help as much as my limited
>>>> time resources allow me to :) .
>>>>
>>>> --
>>>> Henryk Konsek
>>>> http://henryk-konsek.blogspot.com
>>>>
>>>
>>>
>>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Christian Müller <ch...@gmail.com>.
+1 for reusing SM or creating a new one SMX (without the 5 at the end)
Sent from a mobile device
Am 06.02.2013 21:46 schrieb "Gert Vanthienen" <ge...@gmail.com>:
> L.S.,
>
>
> The new development trunk for 5.0 is available at
> http://svn.apache.org/repos/asf/servicemix/smx5/trunk/ - I also set up a
> CI
> build at https://builds.apache.org/job/ServiceMix5/ and a first set of
> SNAPSHOTs has been deployed to repository.apache.org.
>
> The container itself is starting, but several bundles are not starting
> correctly (probably due to version mismatches or config changes that are
> required by the newer versions of specs, changes in ActiveMQ, ...). Apart
> from ironing out these issues, we probably want to convert the integration
> tests to pax-exam-karaf as well (cfr.
> https://issues.apache.org/jira/browse/SMX4-1282). Let's start raising
> JIRA
> issues for these remaining issues and tasks, but that brings us to the next
> question...
>
> What would be the best way to track issues for this new release? We could
> get a new JIRA for SMX5 as we have for SMX4, but we already have quite a
> few JIRA projects to work with. We could also just add a version to
> project SMX4 (though this project name might confuse users) or start
> re-using the SM project for 5.0.x (since we are no longer actively
> maintaining 3.x). Any preferences?
>
>
> Regards,
>
> Gert
>
>
> On Tue, Feb 5, 2013 at 10:40 AM, Gert Vanthienen
> <ge...@gmail.com>wrote:
>
> > L.S.,
> >
> >
> > I was planning to move the old code to a branch and set up the build
> today
> > or tomorrow, so we can start working on this once the 4.5.0 release is
> out.
> >
> >
> > Regards,
> >
> > Gert Vanthienen
> >
> >
> > On Tue, Feb 5, 2013 at 8:13 AM, Henryk Konsek <he...@gmail.com>
> wrote:
> >
> >> > +1 sounds good
> >>
> >> Facing this swarm of +1s, when do you plan to start working on the SMX
> >> 5.0 release? I'll be more than happy to help as much as my limited
> >> time resources allow me to :) .
> >>
> >> --
> >> Henryk Konsek
> >> http://henryk-konsek.blogspot.com
> >>
> >
> >
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
The new development trunk for 5.0 is available at
http://svn.apache.org/repos/asf/servicemix/smx5/trunk/ - I also set up a CI
build at https://builds.apache.org/job/ServiceMix5/ and a first set of
SNAPSHOTs has been deployed to repository.apache.org.
The container itself is starting, but several bundles are not starting
correctly (probably due to version mismatches or config changes that are
required by the newer versions of specs, changes in ActiveMQ, ...). Apart
from ironing out these issues, we probably want to convert the integration
tests to pax-exam-karaf as well (cfr.
https://issues.apache.org/jira/browse/SMX4-1282). Let's start raising JIRA
issues for these remaining issues and tasks, but that brings us to the next
question...
What would be the best way to track issues for this new release? We could
get a new JIRA for SMX5 as we have for SMX4, but we already have quite a
few JIRA projects to work with. We could also just add a version to
project SMX4 (though this project name might confuse users) or start
re-using the SM project for 5.0.x (since we are no longer actively
maintaining 3.x). Any preferences?
Regards,
Gert
On Tue, Feb 5, 2013 at 10:40 AM, Gert Vanthienen
<ge...@gmail.com>wrote:
> L.S.,
>
>
> I was planning to move the old code to a branch and set up the build today
> or tomorrow, so we can start working on this once the 4.5.0 release is out.
>
>
> Regards,
>
> Gert Vanthienen
>
>
> On Tue, Feb 5, 2013 at 8:13 AM, Henryk Konsek <he...@gmail.com> wrote:
>
>> > +1 sounds good
>>
>> Facing this swarm of +1s, when do you plan to start working on the SMX
>> 5.0 release? I'll be more than happy to help as much as my limited
>> time resources allow me to :) .
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>>
>
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It makes sense.
Let me know if I can help Gert ;)
Regards
JB
On 02/05/2013 10:40 AM, Gert Vanthienen wrote:
> L.S.,
>
>
> I was planning to move the old code to a branch and set up the build today
> or tomorrow, so we can start working on this once the 4.5.0 release is out.
>
>
> Regards,
>
> Gert Vanthienen
>
>
> On Tue, Feb 5, 2013 at 8:13 AM, Henryk Konsek <he...@gmail.com> wrote:
>
>>> +1 sounds good
>>
>> Facing this swarm of +1s, when do you plan to start working on the SMX
>> 5.0 release? I'll be more than happy to help as much as my limited
>> time resources allow me to :) .
>>
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
I was planning to move the old code to a branch and set up the build today
or tomorrow, so we can start working on this once the 4.5.0 release is out.
Regards,
Gert Vanthienen
On Tue, Feb 5, 2013 at 8:13 AM, Henryk Konsek <he...@gmail.com> wrote:
> > +1 sounds good
>
> Facing this swarm of +1s, when do you plan to start working on the SMX
> 5.0 release? I'll be more than happy to help as much as my limited
> time resources allow me to :) .
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Henryk Konsek <he...@gmail.com>.
> +1 sounds good
Facing this swarm of +1s, when do you plan to start working on the SMX
5.0 release? I'll be more than happy to help as much as my limited
time resources allow me to :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: [PROPOSAL] New plan for Apache ServiceMix 5.0
Posted by Christian Müller <ch...@gmail.com>.
+1 sounds good
Sent from a mobile device
Am 03.02.2013 21:55 schrieb "Gert Vanthienen" <ge...@gmail.com>:
> 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
>