Quantcast

ServiceMix Features

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ServiceMix Features

ksobkowiak
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/)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ServiceMix Features

Christian Schneider
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ServiceMix Features

Jean-Baptiste Onofré
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ServiceMix Features

ksobkowiak
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 <[hidden email]> 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/)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ServiceMix Features

ksobkowiak
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 <[hidden email]> 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/)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ServiceMix Features

Jean-Baptiste Onofré
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 <[hidden email]> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Loading...