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 2011/09/28 11:05:13 UTC
[HEADS UP] Refactoring the features build
L.S.,
Earlier this year, we cleaned out some of our POM files to remove duplicate
versions. Unfortunately, we also linked our builds even closer together.
This means that we're always looking at big bulky releases and we are also
waiting for all the planets (aka dependency releases) to get aligned before
we can start moving.
I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we did and
most of the time, especially those that are about a fix releases (e.g. Camel
2.8.0 -> 2.8.x), don't require any code change on our side in the components
and NMR project - we just update the POMs with the new version. Technically
though, we don't really need a new release for the NMR and components in
that scenario: the OSGi import version ranges should already allow us to
update to the newer fix version.
If nobody objects, I would like to investigate refactoring the features
build so it can be released independently of anything else, which will allow
us to just do a new ServiceMix 4 (aka features) release whenever we have new
versions of Camel/Karaf/ActiveMQ/CXF available.
P.S. This improvement will not help us with the upcoming 4.4.0-fuse release,
that one does require everything to be released in one go.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
Re: [HEADS UP] Refactoring the features build
Posted by Jon Anstey <ja...@gmail.com>.
+1
Sounds like a great improvement.
On Wed, Sep 28, 2011 at 6:35 AM, Gert Vanthienen
<ge...@gmail.com>wrote:
> L.S.,
>
>
> Earlier this year, we cleaned out some of our POM files to remove duplicate
> versions. Unfortunately, we also linked our builds even closer together.
> This means that we're always looking at big bulky releases and we are also
> waiting for all the planets (aka dependency releases) to get aligned before
> we can start moving.
>
> I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we did and
> most of the time, especially those that are about a fix releases (e.g.
> Camel
> 2.8.0 -> 2.8.x), don't require any code change on our side in the
> components
> and NMR project - we just update the POMs with the new version.
> Technically
> though, we don't really need a new release for the NMR and components in
> that scenario: the OSGi import version ranges should already allow us to
> update to the newer fix version.
>
> If nobody objects, I would like to investigate refactoring the features
> build so it can be released independently of anything else, which will
> allow
> us to just do a new ServiceMix 4 (aka features) release whenever we have
> new
> versions of Camel/Karaf/ActiveMQ/CXF available.
>
> P.S. This improvement will not help us with the upcoming 4.4.0-fuse
> release,
> that one does require everything to be released in one go.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
--
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: [HEADS UP] Refactoring the features build
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
By now, the bulk of the refactoring has been done - we still have the
pending discussion about how to deal with the different features files
provided by the dependency project and what to do to make it easier to work
with them.
For the refactoring itself, the second batch of changes mainly improves the
way the assemblies are getting built - we now have a project per assembly
type under assemblies and I tried optimizing both the POMs and the assembly
descriptors to reduce any unnecessary elements from them. If you look at
assemblies/apache-servicemix-jbi and assemblies/apache-servicemix-full,
you'll notice it becomes very easy to just build a new container with
different features preinstalled. If you leave out the examples component in
the assembly descriptor, users should also be able to use the same technique
for building their own ServiceMix-based assemblies.
Just one more proposal: I would like to add an apache-servicemix-minimal to
the assemblies, which would basically be Karaf with all the features
descriptors preinstalled and OBR enabled, which provide a very convenient
way for people to 'build their own container' without having to manually add
features descriptors or startup bundles themselves.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Wed, Oct 12, 2011 at 2:50 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Thanks Gert,
>
> Regards
> JB
>
>
> On 10/12/2011 02:49 PM, Gert Vanthienen wrote:
>
>> L.S.,
>>
>>
>> I just committed the initial step in this refactoring. At the POM level,
>> the Features build is now decoupled from the NMR build. My next step will
>> be to alter the way the assemblies are being built to ensure that we can
>> just create an assembly out of compatible versions of Karaf/Camel/CXF/...
>> without being too restricted by e.g. what's defined in the NMR build.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.**blogspot.com/<http://gertvanthienen.blogspot.com/>
>>
>>
>> On Wed, Sep 28, 2011 at 11:05 AM, Gert Vanthienen<gert.vanthienen@**
>> gmail.com <ge...@gmail.com>
>>
>>> wrote:
>>>
>>
>> L.S.,
>>>
>>>
>>> Earlier this year, we cleaned out some of our POM files to remove
>>> duplicate
>>> versions. Unfortunately, we also linked our builds even closer together.
>>> This means that we're always looking at big bulky releases and we are
>>> also
>>> waiting for all the planets (aka dependency releases) to get aligned
>>> before
>>> we can start moving.
>>>
>>> I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we did
>>> and
>>> most of the time, especially those that are about a fix releases (e.g.
>>> Camel
>>> 2.8.0 -> 2.8.x), don't require any code change on our side in the
>>> components
>>> and NMR project - we just update the POMs with the new version.
>>> Technically
>>> though, we don't really need a new release for the NMR and components in
>>> that scenario: the OSGi import version ranges should already allow us to
>>> update to the newer fix version.
>>>
>>> If nobody objects, I would like to investigate refactoring the features
>>> build so it can be released independently of anything else, which will
>>> allow
>>> us to just do a new ServiceMix 4 (aka features) release whenever we have
>>> new
>>> versions of Camel/Karaf/ActiveMQ/CXF available.
>>>
>>> P.S. This improvement will not help us with the upcoming 4.4.0-fuse
>>> release, that one does require everything to be released in one go.
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>> ------------------------
>>> FuseSource
>>> Web: http://fusesource.com
>>> Blog: http://gertvanthienen.**blogspot.com/<http://gertvanthienen.blogspot.com/>
>>>
>>>
>>>
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [HEADS UP] Refactoring the features build
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Thanks Gert,
Regards
JB
On 10/12/2011 02:49 PM, Gert Vanthienen wrote:
> L.S.,
>
>
> I just committed the initial step in this refactoring. At the POM level,
> the Features build is now decoupled from the NMR build. My next step will
> be to alter the way the assemblies are being built to ensure that we can
> just create an assembly out of compatible versions of Karaf/Camel/CXF/...
> without being too restricted by e.g. what's defined in the NMR build.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
> On Wed, Sep 28, 2011 at 11:05 AM, Gert Vanthienen<gert.vanthienen@gmail.com
>> wrote:
>
>> L.S.,
>>
>>
>> Earlier this year, we cleaned out some of our POM files to remove duplicate
>> versions. Unfortunately, we also linked our builds even closer together.
>> This means that we're always looking at big bulky releases and we are also
>> waiting for all the planets (aka dependency releases) to get aligned before
>> we can start moving.
>>
>> I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we did and
>> most of the time, especially those that are about a fix releases (e.g. Camel
>> 2.8.0 -> 2.8.x), don't require any code change on our side in the components
>> and NMR project - we just update the POMs with the new version. Technically
>> though, we don't really need a new release for the NMR and components in
>> that scenario: the OSGi import version ranges should already allow us to
>> update to the newer fix version.
>>
>> If nobody objects, I would like to investigate refactoring the features
>> build so it can be released independently of anything else, which will allow
>> us to just do a new ServiceMix 4 (aka features) release whenever we have new
>> versions of Camel/Karaf/ActiveMQ/CXF available.
>>
>> P.S. This improvement will not help us with the upcoming 4.4.0-fuse
>> release, that one does require everything to be released in one go.
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [HEADS UP] Refactoring the features build
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
I just committed the initial step in this refactoring. At the POM level,
the Features build is now decoupled from the NMR build. My next step will
be to alter the way the assemblies are being built to ensure that we can
just create an assembly out of compatible versions of Karaf/Camel/CXF/...
without being too restricted by e.g. what's defined in the NMR build.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Wed, Sep 28, 2011 at 11:05 AM, Gert Vanthienen <gert.vanthienen@gmail.com
> wrote:
> L.S.,
>
>
> Earlier this year, we cleaned out some of our POM files to remove duplicate
> versions. Unfortunately, we also linked our builds even closer together.
> This means that we're always looking at big bulky releases and we are also
> waiting for all the planets (aka dependency releases) to get aligned before
> we can start moving.
>
> I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we did and
> most of the time, especially those that are about a fix releases (e.g. Camel
> 2.8.0 -> 2.8.x), don't require any code change on our side in the components
> and NMR project - we just update the POMs with the new version. Technically
> though, we don't really need a new release for the NMR and components in
> that scenario: the OSGi import version ranges should already allow us to
> update to the newer fix version.
>
> If nobody objects, I would like to investigate refactoring the features
> build so it can be released independently of anything else, which will allow
> us to just do a new ServiceMix 4 (aka features) release whenever we have new
> versions of Camel/Karaf/ActiveMQ/CXF available.
>
> P.S. This improvement will not help us with the upcoming 4.4.0-fuse
> release, that one does require everything to be released in one go.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
>
Re: [HEADS UP] Refactoring the features build
Posted by Freeman Fang <fr...@gmail.com>.
+1
Freeman
On 2011-9-28, at 下午5:05, Gert Vanthienen wrote:
> L.S.,
>
>
> Earlier this year, we cleaned out some of our POM files to remove
> duplicate
> versions. Unfortunately, we also linked our builds even closer
> together.
> This means that we're always looking at big bulky releases and we
> are also
> waiting for all the planets (aka dependency releases) to get aligned
> before
> we can start moving.
>
> I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we
> did and
> most of the time, especially those that are about a fix releases
> (e.g. Camel
> 2.8.0 -> 2.8.x), don't require any code change on our side in the
> components
> and NMR project - we just update the POMs with the new version.
> Technically
> though, we don't really need a new release for the NMR and
> components in
> that scenario: the OSGi import version ranges should already allow
> us to
> update to the newer fix version.
>
> If nobody objects, I would like to investigate refactoring the
> features
> build so it can be released independently of anything else, which
> will allow
> us to just do a new ServiceMix 4 (aka features) release whenever we
> have new
> versions of Camel/Karaf/ActiveMQ/CXF available.
>
> P.S. This improvement will not help us with the upcoming 4.4.0-fuse
> release,
> that one does require everything to be released in one go.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: [HEADS UP] Refactoring the features build
Posted by Corrado Campisano <co...@gmail.com>.
+1
2011/9/28 Gert Vanthienen <ge...@gmail.com>
> L.S.,
>
>
> Earlier this year, we cleaned out some of our POM files to remove duplicate
> versions. Unfortunately, we also linked our builds even closer together.
> This means that we're always looking at big bulky releases and we are also
> waiting for all the planets (aka dependency releases) to get aligned before
> we can start moving.
>
> I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we did and
> most of the time, especially those that are about a fix releases (e.g.
> Camel
> 2.8.0 -> 2.8.x), don't require any code change on our side in the
> components
> and NMR project - we just update the POMs with the new version.
> Technically
> though, we don't really need a new release for the NMR and components in
> that scenario: the OSGi import version ranges should already allow us to
> update to the newer fix version.
>
> If nobody objects, I would like to investigate refactoring the features
> build so it can be released independently of anything else, which will
> allow
> us to just do a new ServiceMix 4 (aka features) release whenever we have
> new
> versions of Camel/Karaf/ActiveMQ/CXF available.
>
> P.S. This improvement will not help us with the upcoming 4.4.0-fuse
> release,
> that one does require everything to be released in one go.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
Re: [HEADS UP] Refactoring the features build
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
Very good idea, I would please to help you on that topic.
Regards
JB
On 09/28/2011 11:05 AM, Gert Vanthienen wrote:
> L.S.,
>
>
> Earlier this year, we cleaned out some of our POM files to remove duplicate
> versions. Unfortunately, we also linked our builds even closer together.
> This means that we're always looking at big bulky releases and we are also
> waiting for all the planets (aka dependency releases) to get aligned before
> we can start moving.
>
> I took a look at some of the latest CXF/ActiveMQ/Camel upgrades we did and
> most of the time, especially those that are about a fix releases (e.g. Camel
> 2.8.0 -> 2.8.x), don't require any code change on our side in the components
> and NMR project - we just update the POMs with the new version. Technically
> though, we don't really need a new release for the NMR and components in
> that scenario: the OSGi import version ranges should already allow us to
> update to the newer fix version.
>
> If nobody objects, I would like to investigate refactoring the features
> build so it can be released independently of anything else, which will allow
> us to just do a new ServiceMix 4 (aka features) release whenever we have new
> versions of Camel/Karaf/ActiveMQ/CXF available.
>
> P.S. This improvement will not help us with the upcoming 4.4.0-fuse release,
> that one does require everything to be released in one go.
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com