You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Krzysztof Sobkowiak <kr...@gmail.com> on 2017/02/08 20:58:11 UTC
ServiceMix Features
Hi
The features repository is ready - https://git-wip-us.apache.org/repos/asf/servicemix-features.git. The structure looks similar to the bundles repository but managing the versions and separate feature modules is still open. One solution would be the bundles way, e.g. submodule for each minor version like this
spring-3.1.x
spring-3.2.x
....
spring-4.1.x
spring-4.2.x
spring-security-3.1.x
activiti-5.19.x
activiti-6.0.x
.....
We could release next only the modules where we have fixed something (like in bundles). What do you think?
Kindly regards
Krzysztof
--
Krzysztof Sobkowiak (@ksobkowiak)
JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
Re: ServiceMix Features
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Krzysztof
Let me take a look today.
I keep you posted.
Regards
JB
On 02/20/2017 01:09 AM, Krzysztof Sobkowiak wrote:
> Hi
>
> Any other ideas? I'd propose the layout used in servicemix-bundles like described some emails ago - a separate maven module/project for each minor version of the feature.
>
> Kindly regards
> Krzysztof
>
> On 09.02.2017 01:08, Krzysztof Sobkowiak wrote:
>> I think it's easier to maintain the content when we have all in one branch. Tag is only a tag on a specific state, it's not a copy of the content.
>> With many branches we quickly lose the ability to easily maintain and oversee the content.
>>
>> There is also no problem to maintain the feature specific bundles as we can use following structure in this case
>>
>> feature-2.3.x/bundle1
>> feature-2.3.x/bundle2
>> feature-2.3.x/bundle3
>> ...
>> feature-2.3.x/bundlen
>> feature-2.3.x/feature
>>
>> Kindly regards
>> Krzysztof
>>
>>
>> On 08.02.2017 23:58, Jean-Baptiste Onofr� wrote:
>>> I'm not a big fan of branches that way because it's not easily visible.
>>> Git modules is not really an alternative as it would force us to use a special structure.
>>>
>>> I don't think it's a problem to tag unused files.
>>>
>>> Regards
>>> JB
>>>
>>> On Feb 8, 2017, 18:48, at 18:48, Christian Schneider <ch...@die-schneider.net> wrote:
>>>> The naming scheme you propose would match nicely with the current
>>>> scheme
>>>> we have in bundles.
>>>> What I see as a problem in both cases is that a git tag always covers
>>>> all content. So it would hold a lot of arbitrary files that are not
>>>> part
>>>> of the release.
>>>>
>>>> I have an unusual idea how we might do better.
>>>>
>>>> How about using one branch per "product" like spring and version
>>>> "group".
>>>>
>>>> Branches would be
>>>> spring-3.x
>>>> spring-3.1.x
>>>> spring-3.2.x
>>>> ..
>>>> Eventually also spring-3.1.3.x if we need to release the same spring
>>>> version a second time because of issues.
>>>>
>>>> Like you proposed as sub modules.
>>>>
>>>> Each spring branch would simply contain one directory
>>>> spring
>>>> with the structure for creating the spring feature. We could then
>>>> create
>>>> one tag per actual release.
>>>>
>>>> This would have the advantage that each branch only contains exactly
>>>> what we intend to release.
>>>>
>>>> Honestly I personally would even consider putting the bundles there too
>>>>
>>>> so the bundles and the feature of each spring release reside together
>>>> and can be released in one step.
>>>> As this was discussed this is only a personal remark.
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 08.02.2017 21:58, Krzysztof Sobkowiak wrote:
>>>>> Hi
>>>>>
>>>>> The features repository is ready -
>>>> https://git-wip-us.apache.org/repos/asf/servicemix-features.git. The
>>>> structure looks similar to the bundles repository but managing the
>>>> versions and separate feature modules is still open. One solution would
>>>> be the bundles way, e.g. submodule for each minor version like this
>>>>> spring-3.1.x
>>>>> spring-3.2.x
>>>>> ....
>>>>> spring-4.1.x
>>>>> spring-4.2.x
>>>>> spring-security-3.1.x
>>>>> activiti-5.19.x
>>>>> activiti-6.0.x
>>>>> .....
>>>>>
>>>>>
>>>>> We could release next only the modules where we have fixed something
>>>> (like in bundles). What do you think?
>>>>> Kindly regards
>>>>> Krzysztof
>>>>>
>>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>
>> --
>> Krzysztof Sobkowiak (@ksobkowiak)
>>
>> JEE & OSS Architect, Integration Architect
>> Apache Software Foundation Member (http://apache.org/)
>> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
>> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: ServiceMix Features
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi
Any other ideas? I'd propose the layout used in servicemix-bundles like described some emails ago - a separate maven module/project for each minor version of the feature.
Kindly regards
Krzysztof
On 09.02.2017 01:08, Krzysztof Sobkowiak wrote:
> I think it's easier to maintain the content when we have all in one branch. Tag is only a tag on a specific state, it's not a copy of the content.
> With many branches we quickly lose the ability to easily maintain and oversee the content.
>
> There is also no problem to maintain the feature specific bundles as we can use following structure in this case
>
> feature-2.3.x/bundle1
> feature-2.3.x/bundle2
> feature-2.3.x/bundle3
> ...
> feature-2.3.x/bundlen
> feature-2.3.x/feature
>
> Kindly regards
> Krzysztof
>
>
> On 08.02.2017 23:58, Jean-Baptiste Onofr� wrote:
>> I'm not a big fan of branches that way because it's not easily visible.
>> Git modules is not really an alternative as it would force us to use a special structure.
>>
>> I don't think it's a problem to tag unused files.
>>
>> Regards
>> JB
>>
>> On Feb 8, 2017, 18:48, at 18:48, Christian Schneider <ch...@die-schneider.net> wrote:
>>> The naming scheme you propose would match nicely with the current
>>> scheme
>>> we have in bundles.
>>> What I see as a problem in both cases is that a git tag always covers
>>> all content. So it would hold a lot of arbitrary files that are not
>>> part
>>> of the release.
>>>
>>> I have an unusual idea how we might do better.
>>>
>>> How about using one branch per "product" like spring and version
>>> "group".
>>>
>>> Branches would be
>>> spring-3.x
>>> spring-3.1.x
>>> spring-3.2.x
>>> ..
>>> Eventually also spring-3.1.3.x if we need to release the same spring
>>> version a second time because of issues.
>>>
>>> Like you proposed as sub modules.
>>>
>>> Each spring branch would simply contain one directory
>>> spring
>>> with the structure for creating the spring feature. We could then
>>> create
>>> one tag per actual release.
>>>
>>> This would have the advantage that each branch only contains exactly
>>> what we intend to release.
>>>
>>> Honestly I personally would even consider putting the bundles there too
>>>
>>> so the bundles and the feature of each spring release reside together
>>> and can be released in one step.
>>> As this was discussed this is only a personal remark.
>>>
>>> Christian
>>>
>>>
>>> On 08.02.2017 21:58, Krzysztof Sobkowiak wrote:
>>>> Hi
>>>>
>>>> The features repository is ready -
>>> https://git-wip-us.apache.org/repos/asf/servicemix-features.git. The
>>> structure looks similar to the bundles repository but managing the
>>> versions and separate feature modules is still open. One solution would
>>> be the bundles way, e.g. submodule for each minor version like this
>>>> spring-3.1.x
>>>> spring-3.2.x
>>>> ....
>>>> spring-4.1.x
>>>> spring-4.2.x
>>>> spring-security-3.1.x
>>>> activiti-5.19.x
>>>> activiti-6.0.x
>>>> .....
>>>>
>>>>
>>>> We could release next only the modules where we have fixed something
>>> (like in bundles). What do you think?
>>>> Kindly regards
>>>> Krzysztof
>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>
> --
> Krzysztof Sobkowiak (@ksobkowiak)
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
--
Krzysztof Sobkowiak (@ksobkowiak)
JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
Re: ServiceMix Features
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
I think it's easier to maintain the content when we have all in one branch. Tag is only a tag on a specific state, it's not a copy of the content.
With many branches we quickly lose the ability to easily maintain and oversee the content.
There is also no problem to maintain the feature specific bundles as we can use following structure in this case
feature-2.3.x/bundle1
feature-2.3.x/bundle2
feature-2.3.x/bundle3
...
feature-2.3.x/bundlen
feature-2.3.x/feature
Kindly regards
Krzysztof
On 08.02.2017 23:58, Jean-Baptiste Onofr� wrote:
> I'm not a big fan of branches that way because it's not easily visible.
> Git modules is not really an alternative as it would force us to use a special structure.
>
> I don't think it's a problem to tag unused files.
>
> Regards
> JB
>
> On Feb 8, 2017, 18:48, at 18:48, Christian Schneider <ch...@die-schneider.net> wrote:
>> The naming scheme you propose would match nicely with the current
>> scheme
>> we have in bundles.
>> What I see as a problem in both cases is that a git tag always covers
>> all content. So it would hold a lot of arbitrary files that are not
>> part
>> of the release.
>>
>> I have an unusual idea how we might do better.
>>
>> How about using one branch per "product" like spring and version
>> "group".
>>
>> Branches would be
>> spring-3.x
>> spring-3.1.x
>> spring-3.2.x
>> ..
>> Eventually also spring-3.1.3.x if we need to release the same spring
>> version a second time because of issues.
>>
>> Like you proposed as sub modules.
>>
>> Each spring branch would simply contain one directory
>> spring
>> with the structure for creating the spring feature. We could then
>> create
>> one tag per actual release.
>>
>> This would have the advantage that each branch only contains exactly
>> what we intend to release.
>>
>> Honestly I personally would even consider putting the bundles there too
>>
>> so the bundles and the feature of each spring release reside together
>> and can be released in one step.
>> As this was discussed this is only a personal remark.
>>
>> Christian
>>
>>
>> On 08.02.2017 21:58, Krzysztof Sobkowiak wrote:
>>> Hi
>>>
>>> The features repository is ready -
>> https://git-wip-us.apache.org/repos/asf/servicemix-features.git. The
>> structure looks similar to the bundles repository but managing the
>> versions and separate feature modules is still open. One solution would
>> be the bundles way, e.g. submodule for each minor version like this
>>> spring-3.1.x
>>> spring-3.2.x
>>> ....
>>> spring-4.1.x
>>> spring-4.2.x
>>> spring-security-3.1.x
>>> activiti-5.19.x
>>> activiti-6.0.x
>>> .....
>>>
>>>
>>> We could release next only the modules where we have fixed something
>> (like in bundles). What do you think?
>>> Kindly regards
>>> Krzysztof
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
--
Krzysztof Sobkowiak (@ksobkowiak)
JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
Re: ServiceMix Features
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I'm not a big fan of branches that way because it's not easily visible.
Git modules is not really an alternative as it would force us to use a special structure.
I don't think it's a problem to tag unused files.
Regards
JB
On Feb 8, 2017, 18:48, at 18:48, Christian Schneider <ch...@die-schneider.net> wrote:
>The naming scheme you propose would match nicely with the current
>scheme
>we have in bundles.
>What I see as a problem in both cases is that a git tag always covers
>all content. So it would hold a lot of arbitrary files that are not
>part
>of the release.
>
>I have an unusual idea how we might do better.
>
>How about using one branch per "product" like spring and version
>"group".
>
>Branches would be
>spring-3.x
>spring-3.1.x
>spring-3.2.x
>..
>Eventually also spring-3.1.3.x if we need to release the same spring
>version a second time because of issues.
>
>Like you proposed as sub modules.
>
>Each spring branch would simply contain one directory
>spring
>with the structure for creating the spring feature. We could then
>create
>one tag per actual release.
>
>This would have the advantage that each branch only contains exactly
>what we intend to release.
>
>Honestly I personally would even consider putting the bundles there too
>
>so the bundles and the feature of each spring release reside together
>and can be released in one step.
>As this was discussed this is only a personal remark.
>
>Christian
>
>
>On 08.02.2017 21:58, Krzysztof Sobkowiak wrote:
>> Hi
>>
>> The features repository is ready -
>https://git-wip-us.apache.org/repos/asf/servicemix-features.git. The
>structure looks similar to the bundles repository but managing the
>versions and separate feature modules is still open. One solution would
>be the bundles way, e.g. submodule for each minor version like this
>>
>> spring-3.1.x
>> spring-3.2.x
>> ....
>> spring-4.1.x
>> spring-4.2.x
>> spring-security-3.1.x
>> activiti-5.19.x
>> activiti-6.0.x
>> .....
>>
>>
>> We could release next only the modules where we have fixed something
>(like in bundles). What do you think?
>>
>> Kindly regards
>> Krzysztof
>>
>>
>
>
>--
>Christian Schneider
>http://www.liquid-reality.de
>
>Open Source Architect
>http://www.talend.com
Re: ServiceMix Features
Posted by Christian Schneider <ch...@die-schneider.net>.
The naming scheme you propose would match nicely with the current scheme
we have in bundles.
What I see as a problem in both cases is that a git tag always covers
all content. So it would hold a lot of arbitrary files that are not part
of the release.
I have an unusual idea how we might do better.
How about using one branch per "product" like spring and version "group".
Branches would be
spring-3.x
spring-3.1.x
spring-3.2.x
..
Eventually also spring-3.1.3.x if we need to release the same spring
version a second time because of issues.
Like you proposed as sub modules.
Each spring branch would simply contain one directory
spring
with the structure for creating the spring feature. We could then create
one tag per actual release.
This would have the advantage that each branch only contains exactly
what we intend to release.
Honestly I personally would even consider putting the bundles there too
so the bundles and the feature of each spring release reside together
and can be released in one step.
As this was discussed this is only a personal remark.
Christian
On 08.02.2017 21:58, Krzysztof Sobkowiak wrote:
> Hi
>
> The features repository is ready - https://git-wip-us.apache.org/repos/asf/servicemix-features.git. The structure looks similar to the bundles repository but managing the versions and separate feature modules is still open. One solution would be the bundles way, e.g. submodule for each minor version like this
>
> spring-3.1.x
> spring-3.2.x
> ....
> spring-4.1.x
> spring-4.2.x
> spring-security-3.1.x
> activiti-5.19.x
> activiti-6.0.x
> .....
>
>
> We could release next only the modules where we have fixed something (like in bundles). What do you think?
>
> Kindly regards
> Krzysztof
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com