Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
Thanks Taher,

I create a clean new thread to have it more prominent.

This is really what needs to be discussed indeed.

Are we sure that's what we want for plugins?

Will they not be disregarded by committers?

Will plugins follow the framework trend?

This is a very important community decision.
I hope everybody will (try to) understand the consequences and participate to this discussion, before it will be too late...

Jacques


Le 12/02/2017 à 13:32, Taher Alkhateeb a écrit :

> Let's take a look at the big picture for a moment before we decide. We have
> broken OFBiz into essentially two products: framework and plugins.
>
> Why did we break it up? Why did we go through the trouble of creating two
> different repositories? I hope the answer is something like "because it is
> too big" or "because it carried a lot of non-essential functionality around"
>
> So breaking up the project brings the advantage of not having to _worry
> about everything_ on each and every commit. These are two projects with two
> release cycles and they don't need to be developed together simultaneously.
> People can specialize and focus on different areas.
>
> The whole idea of breaking the system up and then using gradle's plugin API
> for OFBiz is to remove the coupling between the two projects. If we
> introduce svn externals then all  we achieve is create two repositories
> only to merge them again. Why! that's pointless!
>
> Two products means two buildbot scripts, two releases, two development
> cycles, two different things!
>
> So to achieve true separation and decoupling, I suggest to avoid any hacks
> like svn externals.
>
> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Hi All,
>>
>> This discussion already happened at OFBIZ-9182, but only between Taher,
>> Nicolas and I.
>>
>> The question is simple, below reflects it, and the subject summarises it.
>>
>> So what are your thoughts and opinions?
>>
>> Also when answering I guess we can remove  '(was Re: Proposal to create a
>> separate svn repository for the OFBiz official plugins)' from the subject
>> (I was just "lazy" here)
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 12/02/2017 à 11:22, Jacques Le Roux a écrit :
>>
>>> Sincerely I hardly see the benefit, but I see the disadvantages when I
>>> remember what happened with R13.07. I mean how and by who will be
>>> maintained the OOTB plugins?
>>>
>>> I think this should be more discussed, and maybe voted, here
>>>
>>> Jacques
>>>
>>>
>>> Le 12/02/2017 à 11:18, Deepak Dixit a écrit :
>>>
>>>> Hi Jacques,
>>>>
>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>> de-coupling plugins from core so I think its good idea to keep them
>>>> separate. If any committer or developer want he can use gradle task for
>>>> the
>>>> same.
>>>>
>>>> Thanks & Regards
>>>> --
>>>> Deepak Dixit
>>>> www.hotwaxsystems.com
>>>>
>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> Yes this is the idea, why should we not? How else committers will easily
>>>>> maintain the plugins?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/02/2017 à 10:25, Deepak Dixit a écrit :
>>>>>
>>>>> Hi Jacques,
>>>>>> I think if wesvn:external  on trunk, then it will always checkout the
>>>>>> plugins with trunk
>>>>>>
>>>>>>
>>>>>> Thanks & Regards
>>>>>> --
>>>>>> Deepak Dixit
>>>>>> www.hotwaxsystems.com
>>>>>>
>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>> [hidden email]> wrote:
>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

taher
Why did you start a new thread? What's wrong with the other thread?

On Sun, Feb 12, 2017 at 3:55 PM, Jacques Le Roux <
[hidden email]> wrote:

> Thanks Taher,
>
> I create a clean new thread to have it more prominent.
>
> This is really what needs to be discussed indeed.
>
> Are we sure that's what we want for plugins?
>
> Will they not be disregarded by committers?
>
> Will plugins follow the framework trend?
>
> This is a very important community decision.
> I hope everybody will (try to) understand the consequences and participate
> to this discussion, before it will be too late...
>
> Jacques
>
>
> Le 12/02/2017 à 13:32, Taher Alkhateeb a écrit :
>
>> Let's take a look at the big picture for a moment before we decide. We
>> have
>> broken OFBiz into essentially two products: framework and plugins.
>>
>> Why did we break it up? Why did we go through the trouble of creating two
>> different repositories? I hope the answer is something like "because it is
>> too big" or "because it carried a lot of non-essential functionality
>> around"
>>
>> So breaking up the project brings the advantage of not having to _worry
>> about everything_ on each and every commit. These are two projects with
>> two
>> release cycles and they don't need to be developed together
>> simultaneously.
>> People can specialize and focus on different areas.
>>
>> The whole idea of breaking the system up and then using gradle's plugin
>> API
>> for OFBiz is to remove the coupling between the two projects. If we
>> introduce svn externals then all  we achieve is create two repositories
>> only to merge them again. Why! that's pointless!
>>
>> Two products means two buildbot scripts, two releases, two development
>> cycles, two different things!
>>
>> So to achieve true separation and decoupling, I suggest to avoid any hacks
>> like svn externals.
>>
>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> Hi All,
>>>
>>> This discussion already happened at OFBIZ-9182, but only between Taher,
>>> Nicolas and I.
>>>
>>> The question is simple, below reflects it, and the subject summarises it.
>>>
>>> So what are your thoughts and opinions?
>>>
>>> Also when answering I guess we can remove  '(was Re: Proposal to create a
>>> separate svn repository for the OFBiz official plugins)' from the subject
>>> (I was just "lazy" here)
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>> Le 12/02/2017 à 11:22, Jacques Le Roux a écrit :
>>>
>>> Sincerely I hardly see the benefit, but I see the disadvantages when I
>>>> remember what happened with R13.07. I mean how and by who will be
>>>> maintained the OOTB plugins?
>>>>
>>>> I think this should be more discussed, and maybe voted, here
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/02/2017 à 11:18, Deepak Dixit a écrit :
>>>>
>>>> Hi Jacques,
>>>>>
>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>> separate. If any committer or developer want he can use gradle task for
>>>>> the
>>>>> same.
>>>>>
>>>>> Thanks & Regards
>>>>> --
>>>>> Deepak Dixit
>>>>> www.hotwaxsystems.com
>>>>>
>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Yes this is the idea, why should we not? How else committers will
>>>>> easily
>>>>>
>>>>>> maintain the plugins?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 12/02/2017 à 10:25, Deepak Dixit a écrit :
>>>>>>
>>>>>> Hi Jacques,
>>>>>>
>>>>>>> I think if wesvn:external  on trunk, then it will always checkout the
>>>>>>> plugins with trunk
>>>>>>>
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> --
>>>>>>> Deepak Dixit
>>>>>>> www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
In (my) Thunderbird it was buried in the previous thread so I "created a clean new thread to have it more prominent."

We should rather focus on the questions...

Jacques


Le 12/02/2017 à 18:42, Taher Alkhateeb a écrit :

> Why did you start a new thread? What's wrong with the other thread?
>
> On Sun, Feb 12, 2017 at 3:55 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Thanks Taher,
>>
>> I create a clean new thread to have it more prominent.
>>
>> This is really what needs to be discussed indeed.
>>
>> Are we sure that's what we want for plugins?
>>
>> Will they not be disregarded by committers?
>>
>> Will plugins follow the framework trend?
>>
>> This is a very important community decision.
>> I hope everybody will (try to) understand the consequences and participate
>> to this discussion, before it will be too late...
>>
>> Jacques
>>
>>
>> Le 12/02/2017 à 13:32, Taher Alkhateeb a écrit :
>>
>>> Let's take a look at the big picture for a moment before we decide. We
>>> have
>>> broken OFBiz into essentially two products: framework and plugins.
>>>
>>> Why did we break it up? Why did we go through the trouble of creating two
>>> different repositories? I hope the answer is something like "because it is
>>> too big" or "because it carried a lot of non-essential functionality
>>> around"
>>>
>>> So breaking up the project brings the advantage of not having to _worry
>>> about everything_ on each and every commit. These are two projects with
>>> two
>>> release cycles and they don't need to be developed together
>>> simultaneously.
>>> People can specialize and focus on different areas.
>>>
>>> The whole idea of breaking the system up and then using gradle's plugin
>>> API
>>> for OFBiz is to remove the coupling between the two projects. If we
>>> introduce svn externals then all  we achieve is create two repositories
>>> only to merge them again. Why! that's pointless!
>>>
>>> Two products means two buildbot scripts, two releases, two development
>>> cycles, two different things!
>>>
>>> So to achieve true separation and decoupling, I suggest to avoid any hacks
>>> like svn externals.
>>>
>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>> Hi All,
>>>> This discussion already happened at OFBIZ-9182, but only between Taher,
>>>> Nicolas and I.
>>>>
>>>> The question is simple, below reflects it, and the subject summarises it.
>>>>
>>>> So what are your thoughts and opinions?
>>>>
>>>> Also when answering I guess we can remove  '(was Re: Proposal to create a
>>>> separate svn repository for the OFBiz official plugins)' from the subject
>>>> (I was just "lazy" here)
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/02/2017 à 11:22, Jacques Le Roux a écrit :
>>>>
>>>> Sincerely I hardly see the benefit, but I see the disadvantages when I
>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>> maintained the OOTB plugins?
>>>>>
>>>>> I think this should be more discussed, and maybe voted, here
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/02/2017 à 11:18, Deepak Dixit a écrit :
>>>>>
>>>>> Hi Jacques,
>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>> separate. If any committer or developer want he can use gradle task for
>>>>>> the
>>>>>> same.
>>>>>>
>>>>>> Thanks & Regards
>>>>>> --
>>>>>> Deepak Dixit
>>>>>> www.hotwaxsystems.com
>>>>>>
>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>> easily
>>>>>>
>>>>>>> maintain the plugins?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 12/02/2017 à 10:25, Deepak Dixit a écrit :
>>>>>>>
>>>>>>> Hi Jacques,
>>>>>>>
>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout the
>>>>>>>> plugins with trunk
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks & Regards
>>>>>>>> --
>>>>>>>> Deepak Dixit
>>>>>>>> www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

taher
It's confusing to have multiple threads just because your email client is
mixing things. We already participated in the other thread.

On Feb 12, 2017 8:50 PM, "Jacques Le Roux" <[hidden email]>
wrote:

> In (my) Thunderbird it was buried in the previous thread so I "created a
> clean new thread to have it more prominent."
>
> We should rather focus on the questions...
>
> Jacques
>
>
> Le 12/02/2017 à 18:42, Taher Alkhateeb a écrit :
>
>> Why did you start a new thread? What's wrong with the other thread?
>>
>> On Sun, Feb 12, 2017 at 3:55 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> Thanks Taher,
>>>
>>> I create a clean new thread to have it more prominent.
>>>
>>> This is really what needs to be discussed indeed.
>>>
>>> Are we sure that's what we want for plugins?
>>>
>>> Will they not be disregarded by committers?
>>>
>>> Will plugins follow the framework trend?
>>>
>>> This is a very important community decision.
>>> I hope everybody will (try to) understand the consequences and
>>> participate
>>> to this discussion, before it will be too late...
>>>
>>> Jacques
>>>
>>>
>>> Le 12/02/2017 à 13:32, Taher Alkhateeb a écrit :
>>>
>>> Let's take a look at the big picture for a moment before we decide. We
>>>> have
>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>
>>>> Why did we break it up? Why did we go through the trouble of creating
>>>> two
>>>> different repositories? I hope the answer is something like "because it
>>>> is
>>>> too big" or "because it carried a lot of non-essential functionality
>>>> around"
>>>>
>>>> So breaking up the project brings the advantage of not having to _worry
>>>> about everything_ on each and every commit. These are two projects with
>>>> two
>>>> release cycles and they don't need to be developed together
>>>> simultaneously.
>>>> People can specialize and focus on different areas.
>>>>
>>>> The whole idea of breaking the system up and then using gradle's plugin
>>>> API
>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>> introduce svn externals then all  we achieve is create two repositories
>>>> only to merge them again. Why! that's pointless!
>>>>
>>>> Two products means two buildbot scripts, two releases, two development
>>>> cycles, two different things!
>>>>
>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>> hacks
>>>> like svn externals.
>>>>
>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> Hi All,
>>>>
>>>>> This discussion already happened at OFBIZ-9182, but only between Taher,
>>>>> Nicolas and I.
>>>>>
>>>>> The question is simple, below reflects it, and the subject summarises
>>>>> it.
>>>>>
>>>>> So what are your thoughts and opinions?
>>>>>
>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>> create a
>>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>> subject
>>>>> (I was just "lazy" here)
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/02/2017 à 11:22, Jacques Le Roux a écrit :
>>>>>
>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when I
>>>>>
>>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>> maintained the OOTB plugins?
>>>>>>
>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 12/02/2017 à 11:18, Deepak Dixit a écrit :
>>>>>>
>>>>>> Hi Jacques,
>>>>>>
>>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>> separate. If any committer or developer want he can use gradle task
>>>>>>> for
>>>>>>> the
>>>>>>> same.
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> --
>>>>>>> Deepak Dixit
>>>>>>> www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>> easily
>>>>>>>
>>>>>>> maintain the plugins?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 12/02/2017 à 10:25, Deepak Dixit a écrit :
>>>>>>>>
>>>>>>>> Hi Jacques,
>>>>>>>>
>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>> the
>>>>>>>>> plugins with trunk
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks & Regards
>>>>>>>>> --
>>>>>>>>> Deepak Dixit
>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
Can we focus on the questions please?

Jacques


Le 12/02/2017 à 18:52, Taher Alkhateeb a écrit :

> It's confusing to have multiple threads just because your email client is
> mixing things. We already participated in the other thread.
>
> On Feb 12, 2017 8:50 PM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
>> In (my) Thunderbird it was buried in the previous thread so I "created a
>> clean new thread to have it more prominent."
>>
>> We should rather focus on the questions...
>>
>> Jacques
>>
>>
>> Le 12/02/2017 à 18:42, Taher Alkhateeb a écrit :
>>
>>> Why did you start a new thread? What's wrong with the other thread?
>>>
>>> On Sun, Feb 12, 2017 at 3:55 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>> Thanks Taher,
>>>> I create a clean new thread to have it more prominent.
>>>>
>>>> This is really what needs to be discussed indeed.
>>>>
>>>> Are we sure that's what we want for plugins?
>>>>
>>>> Will they not be disregarded by committers?
>>>>
>>>> Will plugins follow the framework trend?
>>>>
>>>> This is a very important community decision.
>>>> I hope everybody will (try to) understand the consequences and
>>>> participate
>>>> to this discussion, before it will be too late...
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/02/2017 à 13:32, Taher Alkhateeb a écrit :
>>>>
>>>> Let's take a look at the big picture for a moment before we decide. We
>>>>> have
>>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>>
>>>>> Why did we break it up? Why did we go through the trouble of creating
>>>>> two
>>>>> different repositories? I hope the answer is something like "because it
>>>>> is
>>>>> too big" or "because it carried a lot of non-essential functionality
>>>>> around"
>>>>>
>>>>> So breaking up the project brings the advantage of not having to _worry
>>>>> about everything_ on each and every commit. These are two projects with
>>>>> two
>>>>> release cycles and they don't need to be developed together
>>>>> simultaneously.
>>>>> People can specialize and focus on different areas.
>>>>>
>>>>> The whole idea of breaking the system up and then using gradle's plugin
>>>>> API
>>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>>> introduce svn externals then all  we achieve is create two repositories
>>>>> only to merge them again. Why! that's pointless!
>>>>>
>>>>> Two products means two buildbot scripts, two releases, two development
>>>>> cycles, two different things!
>>>>>
>>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>>> hacks
>>>>> like svn externals.
>>>>>
>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>>> This discussion already happened at OFBIZ-9182, but only between Taher,
>>>>>> Nicolas and I.
>>>>>>
>>>>>> The question is simple, below reflects it, and the subject summarises
>>>>>> it.
>>>>>>
>>>>>> So what are your thoughts and opinions?
>>>>>>
>>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>>> create a
>>>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>>> subject
>>>>>> (I was just "lazy" here)
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 12/02/2017 à 11:22, Jacques Le Roux a écrit :
>>>>>>
>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when I
>>>>>>
>>>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>>> maintained the OOTB plugins?
>>>>>>>
>>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 12/02/2017 à 11:18, Deepak Dixit a écrit :
>>>>>>>
>>>>>>> Hi Jacques,
>>>>>>>
>>>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>>> separate. If any committer or developer want he can use gradle task
>>>>>>>> for
>>>>>>>> the
>>>>>>>> same.
>>>>>>>>
>>>>>>>> Thanks & Regards
>>>>>>>> --
>>>>>>>> Deepak Dixit
>>>>>>>> www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>>> easily
>>>>>>>>
>>>>>>>> maintain the plugins?
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 12/02/2017 à 10:25, Deepak Dixit a écrit :
>>>>>>>>>
>>>>>>>>> Hi Jacques,
>>>>>>>>>
>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>>> the
>>>>>>>>>> plugins with trunk
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards
>>>>>>>>>> --
>>>>>>>>>> Deepak Dixit
>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
An issue we have with Buildbot when not using externals is how to load the default data

This:  Task 'loadDefault' not found in root project 'build'.

The root is, of course, http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk

There are maybe possibilities in BuildBot or with Gradle but enough for me for today...

Jacques

Le 12/02/2017 à 20:05, Jacques Le Roux a écrit :

> Can we focus on the questions please?
>
> Jacques
>
>
> Le 12/02/2017 à 18:52, Taher Alkhateeb a écrit :
>> It's confusing to have multiple threads just because your email client is
>> mixing things. We already participated in the other thread.
>>
>> On Feb 12, 2017 8:50 PM, "Jacques Le Roux" <[hidden email]>
>> wrote:
>>
>>> In (my) Thunderbird it was buried in the previous thread so I "created a
>>> clean new thread to have it more prominent."
>>>
>>> We should rather focus on the questions...
>>>
>>> Jacques
>>>
>>>
>>> Le 12/02/2017 à 18:42, Taher Alkhateeb a écrit :
>>>
>>>> Why did you start a new thread? What's wrong with the other thread?
>>>>
>>>> On Sun, Feb 12, 2017 at 3:55 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> Thanks Taher,
>>>>> I create a clean new thread to have it more prominent.
>>>>>
>>>>> This is really what needs to be discussed indeed.
>>>>>
>>>>> Are we sure that's what we want for plugins?
>>>>>
>>>>> Will they not be disregarded by committers?
>>>>>
>>>>> Will plugins follow the framework trend?
>>>>>
>>>>> This is a very important community decision.
>>>>> I hope everybody will (try to) understand the consequences and
>>>>> participate
>>>>> to this discussion, before it will be too late...
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/02/2017 à 13:32, Taher Alkhateeb a écrit :
>>>>>
>>>>> Let's take a look at the big picture for a moment before we decide. We
>>>>>> have
>>>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>>>
>>>>>> Why did we break it up? Why did we go through the trouble of creating
>>>>>> two
>>>>>> different repositories? I hope the answer is something like "because it
>>>>>> is
>>>>>> too big" or "because it carried a lot of non-essential functionality
>>>>>> around"
>>>>>>
>>>>>> So breaking up the project brings the advantage of not having to _worry
>>>>>> about everything_ on each and every commit. These are two projects with
>>>>>> two
>>>>>> release cycles and they don't need to be developed together
>>>>>> simultaneously.
>>>>>> People can specialize and focus on different areas.
>>>>>>
>>>>>> The whole idea of breaking the system up and then using gradle's plugin
>>>>>> API
>>>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>>>> introduce svn externals then all  we achieve is create two repositories
>>>>>> only to merge them again. Why! that's pointless!
>>>>>>
>>>>>> Two products means two buildbot scripts, two releases, two development
>>>>>> cycles, two different things!
>>>>>>
>>>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>>>> hacks
>>>>>> like svn externals.
>>>>>>
>>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>>> This discussion already happened at OFBIZ-9182, but only between Taher,
>>>>>>> Nicolas and I.
>>>>>>>
>>>>>>> The question is simple, below reflects it, and the subject summarises
>>>>>>> it.
>>>>>>>
>>>>>>> So what are your thoughts and opinions?
>>>>>>>
>>>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>>>> create a
>>>>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>>>> subject
>>>>>>> (I was just "lazy" here)
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 12/02/2017 à 11:22, Jacques Le Roux a écrit :
>>>>>>>
>>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when I
>>>>>>>
>>>>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>>>> maintained the OOTB plugins?
>>>>>>>>
>>>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 12/02/2017 à 11:18, Deepak Dixit a écrit :
>>>>>>>>
>>>>>>>> Hi Jacques,
>>>>>>>>
>>>>>>>>> We can add gradle task to pull all plugins from remote. As we are
>>>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>>>> separate. If any committer or developer want he can use gradle task
>>>>>>>>> for
>>>>>>>>> the
>>>>>>>>> same.
>>>>>>>>>
>>>>>>>>> Thanks & Regards
>>>>>>>>> --
>>>>>>>>> Deepak Dixit
>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>>>> easily
>>>>>>>>>
>>>>>>>>> maintain the plugins?
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 12/02/2017 à 10:25, Deepak Dixit a écrit :
>>>>>>>>>>
>>>>>>>>>> Hi Jacques,
>>>>>>>>>>
>>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>>>> the
>>>>>>>>>>> plugins with trunk
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards
>>>>>>>>>>> --
>>>>>>>>>>> Deepak Dixit
>>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Sharan Foga
In reply to this post by Jacques Le Roux
Hi All

I'm not exactly completely sure what this discussion is all about. The title talks about svn and Gradle but questions in the thread seem to about something different. If it is as important as you say then we need to make sure that everyone understands exactly what this means.

Are you saying that because of the framework / plugin split then committers will work only on the framework? If so, then remember that it was our contributors and committers that put the 'plugins' into OFBiz in the first place which means that people who are interested in developing a particular functionality further can do it without worrying about or breaking the framework.

From my side I know that we also have some OFBiz application documentation that is sitting in docbook inside OFBiz I think would be better implemented as a plugin. It would be good to be able to work on and test this separately.

I apologise if I've misunderstood this thread but as I say - it's not very clear what it is all about.

Thanks
Sharan

On 2017-02-12 13:55 (+0100), Jacques Le Roux <[hidden email]> wrote:

> Thanks Taher,
>
> I create a clean new thread to have it more prominent.
>
> This is really what needs to be discussed indeed.
>
> Are we sure that's what we want for plugins?
>
> Will they not be disregarded by committers?
>
> Will plugins follow the framework trend?
>
> This is a very important community decision.
> I hope everybody will (try to) understand the consequences and participate to this discussion, before it will be too late...
>
> Jacques
>
>
> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
> > Let's take a look at the big picture for a moment before we decide. We have
> > broken OFBiz into essentially two products: framework and plugins.
> >
> > Why did we break it up? Why did we go through the trouble of creating two
> > different repositories? I hope the answer is something like "because it is
> > too big" or "because it carried a lot of non-essential functionality around"
> >
> > So breaking up the project brings the advantage of not having to _worry
> > about everything_ on each and every commit. These are two projects with two
> > release cycles and they don't need to be developed together simultaneously.
> > People can specialize and focus on different areas.
> >
> > The whole idea of breaking the system up and then using gradle's plugin API
> > for OFBiz is to remove the coupling between the two projects. If we
> > introduce svn externals then all  we achieve is create two repositories
> > only to merge them again. Why! that's pointless!
> >
> > Two products means two buildbot scripts, two releases, two development
> > cycles, two different things!
> >
> > So to achieve true separation and decoupling, I suggest to avoid any hacks
> > like svn externals.
> >
> > On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> Hi All,
> >>
> >> This discussion already happened at OFBIZ-9182, but only between Taher,
> >> Nicolas and I.
> >>
> >> The question is simple, below reflects it, and the subject summarises it.
> >>
> >> So what are your thoughts and opinions?
> >>
> >> Also when answering I guess we can remove  '(was Re: Proposal to create a
> >> separate svn repository for the OFBiz official plugins)' from the subject
> >> (I was just "lazy" here)
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >>
> >> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
> >>
> >>> Sincerely I hardly see the benefit, but I see the disadvantages when I
> >>> remember what happened with R13.07. I mean how and by who will be
> >>> maintained the OOTB plugins?
> >>>
> >>> I think this should be more discussed, and maybe voted, here
> >>>
> >>> Jacques
> >>>
> >>>
> >>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
> >>>
> >>>> Hi Jacques,
> >>>>
> >>>> We can add gradle task to  pull all plugins from remote. As we are
> >>>> de-coupling plugins from core so I think its good idea to keep them
> >>>> separate. If any committer or developer want he can use gradle task for
> >>>> the
> >>>> same.
> >>>>
> >>>> Thanks & Regards
> >>>> --
> >>>> Deepak Dixit
> >>>> www.hotwaxsystems.com
> >>>>
> >>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
> >>>> [hidden email]> wrote:
> >>>>
> >>>> Yes this is the idea, why should we not? How else committers will easily
> >>>>> maintain the plugins?
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>>
> >>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
> >>>>>
> >>>>> Hi Jacques,
> >>>>>> I think if wesvn:external  on trunk, then it will always checkout the
> >>>>>> plugins with trunk
> >>>>>>
> >>>>>>
> >>>>>> Thanks & Regards
> >>>>>> --
> >>>>>> Deepak Dixit
> >>>>>> www.hotwaxsystems.com
> >>>>>>
> >>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
> >>>>>> [hidden email]> wrote:
> >>>>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

taher
Hi Sharan,

I think this is not the topic under discussion, and since it seems vague to
you I will try to clarify:

The question now that we split framework and plugins is how to combine
them. The discussion so far between myself and Jacques is as follows:
- Jacques wants to use svn:externals so that subversion pulls all the
plugins into the framework and keep everything as is (testing, builds, etc)
the way they were.
- My position is that we should use gradle to pull the plugins we need
without reliance on Subversion or any other tool and to treat the two
projects as two separate projects.

Both reasons / concerns from me and Jacques are expressed by reading the
history of this thread (that partly exists in another thread for which
Deepak contributed his opinion).

On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <[hidden email]> wrote:

> Hi All
>
> I'm not exactly completely sure what this discussion is all about. The
> title talks about svn and Gradle but questions in the thread seem to about
> something different. If it is as important as you say then we need to make
> sure that everyone understands exactly what this means.
>
> Are you saying that because of the framework / plugin split then
> committers will work only on the framework? If so, then remember that it
> was our contributors and committers that put the 'plugins' into OFBiz in
> the first place which means that people who are interested in developing a
> particular functionality further can do it without worrying about or
> breaking the framework.
>
> From my side I know that we also have some OFBiz application documentation
> that is sitting in docbook inside OFBiz I think would be better implemented
> as a plugin. It would be good to be able to work on and test this
> separately.
>
> I apologise if I've misunderstood this thread but as I say - it's not very
> clear what it is all about.
>
> Thanks
> Sharan
>
> On 2017-02-12 13:55 (+0100), Jacques Le Roux <[hidden email]>
> wrote:
> > Thanks Taher,
> >
> > I create a clean new thread to have it more prominent.
> >
> > This is really what needs to be discussed indeed.
> >
> > Are we sure that's what we want for plugins?
> >
> > Will they not be disregarded by committers?
> >
> > Will plugins follow the framework trend?
> >
> > This is a very important community decision.
> > I hope everybody will (try to) understand the consequences and
> participate to this discussion, before it will be too late...
> >
> > Jacques
> >
> >
> > Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
> > > Let's take a look at the big picture for a moment before we decide. We
> have
> > > broken OFBiz into essentially two products: framework and plugins.
> > >
> > > Why did we break it up? Why did we go through the trouble of creating
> two
> > > different repositories? I hope the answer is something like "because
> it is
> > > too big" or "because it carried a lot of non-essential functionality
> around"
> > >
> > > So breaking up the project brings the advantage of not having to _worry
> > > about everything_ on each and every commit. These are two projects
> with two
> > > release cycles and they don't need to be developed together
> simultaneously.
> > > People can specialize and focus on different areas.
> > >
> > > The whole idea of breaking the system up and then using gradle's
> plugin API
> > > for OFBiz is to remove the coupling between the two projects. If we
> > > introduce svn externals then all  we achieve is create two repositories
> > > only to merge them again. Why! that's pointless!
> > >
> > > Two products means two buildbot scripts, two releases, two development
> > > cycles, two different things!
> > >
> > > So to achieve true separation and decoupling, I suggest to avoid any
> hacks
> > > like svn externals.
> > >
> > > On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
> > > [hidden email]> wrote:
> > >
> > >> Hi All,
> > >>
> > >> This discussion already happened at OFBIZ-9182, but only between
> Taher,
> > >> Nicolas and I.
> > >>
> > >> The question is simple, below reflects it, and the subject summarises
> it.
> > >>
> > >> So what are your thoughts and opinions?
> > >>
> > >> Also when answering I guess we can remove  '(was Re: Proposal to
> create a
> > >> separate svn repository for the OFBiz official plugins)' from the
> subject
> > >> (I was just "lazy" here)
> > >>
> > >> Thanks
> > >>
> > >> Jacques
> > >>
> > >>
> > >> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
> > >>
> > >>> Sincerely I hardly see the benefit, but I see the disadvantages when
> I
> > >>> remember what happened with R13.07. I mean how and by who will be
> > >>> maintained the OOTB plugins?
> > >>>
> > >>> I think this should be more discussed, and maybe voted, here
> > >>>
> > >>> Jacques
> > >>>
> > >>>
> > >>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
> > >>>
> > >>>> Hi Jacques,
> > >>>>
> > >>>> We can add gradle task to  pull all plugins from remote. As we are
> > >>>> de-coupling plugins from core so I think its good idea to keep them
> > >>>> separate. If any committer or developer want he can use gradle task
> for
> > >>>> the
> > >>>> same.
> > >>>>
> > >>>> Thanks & Regards
> > >>>> --
> > >>>> Deepak Dixit
> > >>>> www.hotwaxsystems.com
> > >>>>
> > >>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
> > >>>> [hidden email]> wrote:
> > >>>>
> > >>>> Yes this is the idea, why should we not? How else committers will
> easily
> > >>>>> maintain the plugins?
> > >>>>>
> > >>>>> Jacques
> > >>>>>
> > >>>>>
> > >>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
> > >>>>>
> > >>>>> Hi Jacques,
> > >>>>>> I think if wesvn:external  on trunk, then it will always checkout
> the
> > >>>>>> plugins with trunk
> > >>>>>>
> > >>>>>>
> > >>>>>> Thanks & Regards
> > >>>>>> --
> > >>>>>> Deepak Dixit
> > >>>>>> www.hotwaxsystems.com
> > >>>>>>
> > >>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
> > >>>>>> [hidden email]> wrote:
> > >>>>>>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Michael Brohl-3
Hi,

first of all: great work and many thanks to Taher, Jacques and Deepak
for their efforts on the repository separation this weekend.

I think we should provide processes and support for the following cases:

1. separated development of the framework and core applications without
forced embedding of the plugins

2. separated development of the plugins with the support to embed the
framework part in the development environment

3. combined development of both framework and plugins.

I think we'll need convenience tools/processes/support for these
combinations because we should make contributions for and use of
framework + plugins as easy as possible without forcing the entanglement
of the different projects.

As far as I understand forced use of svn:externals is contra productive
because it prevents the separation. We should instead describe the
mechanism and provide a set of svn:externals files for all users who
want to use it. Maybe also a gradle task which generates the needed
file(s) for convenience.

I think we cannot only rely on the pull plugin mechanism because
combined development needs to have framework and plugins in the IDE
under version control.

Users and developers should have a choice (and low hurdles to
contribute), on the other hand we should keep it lean and simple per
default.

Not sure if I could make my viewpoint clear enough, I'm currently too
tired to concentrate on better words :-)

Best regards,

Michael


Am 12.02.17 um 20:59 schrieb Taher Alkhateeb:

> Hi Sharan,
>
> I think this is not the topic under discussion, and since it seems vague to
> you I will try to clarify:
>
> The question now that we split framework and plugins is how to combine
> them. The discussion so far between myself and Jacques is as follows:
> - Jacques wants to use svn:externals so that subversion pulls all the
> plugins into the framework and keep everything as is (testing, builds, etc)
> the way they were.
> - My position is that we should use gradle to pull the plugins we need
> without reliance on Subversion or any other tool and to treat the two
> projects as two separate projects.
>
> Both reasons / concerns from me and Jacques are expressed by reading the
> history of this thread (that partly exists in another thread for which
> Deepak contributed his opinion).
>
> On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <[hidden email]> wrote:
>
>> Hi All
>>
>> I'm not exactly completely sure what this discussion is all about. The
>> title talks about svn and Gradle but questions in the thread seem to about
>> something different. If it is as important as you say then we need to make
>> sure that everyone understands exactly what this means.
>>
>> Are you saying that because of the framework / plugin split then
>> committers will work only on the framework? If so, then remember that it
>> was our contributors and committers that put the 'plugins' into OFBiz in
>> the first place which means that people who are interested in developing a
>> particular functionality further can do it without worrying about or
>> breaking the framework.
>>
>>  From my side I know that we also have some OFBiz application documentation
>> that is sitting in docbook inside OFBiz I think would be better implemented
>> as a plugin. It would be good to be able to work on and test this
>> separately.
>>
>> I apologise if I've misunderstood this thread but as I say - it's not very
>> clear what it is all about.
>>
>> Thanks
>> Sharan
>>
>> On 2017-02-12 13:55 (+0100), Jacques Le Roux <[hidden email]>
>> wrote:
>>> Thanks Taher,
>>>
>>> I create a clean new thread to have it more prominent.
>>>
>>> This is really what needs to be discussed indeed.
>>>
>>> Are we sure that's what we want for plugins?
>>>
>>> Will they not be disregarded by committers?
>>>
>>> Will plugins follow the framework trend?
>>>
>>> This is a very important community decision.
>>> I hope everybody will (try to) understand the consequences and
>> participate to this discussion, before it will be too late...
>>> Jacques
>>>
>>>
>>> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
>>>> Let's take a look at the big picture for a moment before we decide. We
>> have
>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>
>>>> Why did we break it up? Why did we go through the trouble of creating
>> two
>>>> different repositories? I hope the answer is something like "because
>> it is
>>>> too big" or "because it carried a lot of non-essential functionality
>> around"
>>>> So breaking up the project brings the advantage of not having to _worry
>>>> about everything_ on each and every commit. These are two projects
>> with two
>>>> release cycles and they don't need to be developed together
>> simultaneously.
>>>> People can specialize and focus on different areas.
>>>>
>>>> The whole idea of breaking the system up and then using gradle's
>> plugin API
>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>> introduce svn externals then all  we achieve is create two repositories
>>>> only to merge them again. Why! that's pointless!
>>>>
>>>> Two products means two buildbot scripts, two releases, two development
>>>> cycles, two different things!
>>>>
>>>> So to achieve true separation and decoupling, I suggest to avoid any
>> hacks
>>>> like svn externals.
>>>>
>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> This discussion already happened at OFBIZ-9182, but only between
>> Taher,
>>>>> Nicolas and I.
>>>>>
>>>>> The question is simple, below reflects it, and the subject summarises
>> it.
>>>>> So what are your thoughts and opinions?
>>>>>
>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>> create a
>>>>> separate svn repository for the OFBiz official plugins)' from the
>> subject
>>>>> (I was just "lazy" here)
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
>>>>>
>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when
>> I
>>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>> maintained the OOTB plugins?
>>>>>>
>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
>>>>>>
>>>>>>> Hi Jacques,
>>>>>>>
>>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>> separate. If any committer or developer want he can use gradle task
>> for
>>>>>>> the
>>>>>>> same.
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> --
>>>>>>> Deepak Dixit
>>>>>>> www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> Yes this is the idea, why should we not? How else committers will
>> easily
>>>>>>>> maintain the plugins?
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
>>>>>>>>
>>>>>>>> Hi Jacques,
>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>> the
>>>>>>>>> plugins with trunk
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks & Regards
>>>>>>>>> --
>>>>>>>>> Deepak Dixit
>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>
>>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

taher
Hi Michael, All

All good points, thank you for your thoughts. So a solution that I proposed
in jira to easily manage and maintain our official plugins is to have a
gradle task named for example pullPluginSourceAll which pulls all the
plugins in one shot for testing and development purposes. Maybe we can also
add logic in this task so that it updates already downloaded plugins.

I'm sure there are other good ideas as well. My point of emphasis is to
Simply keep the two projects clearly separated, and to avoid relying
directly on tools not embedded within the framework like subversion.

On Feb 13, 2017 12:08 AM, "Michael Brohl" <[hidden email]> wrote:

> Hi,
>
> first of all: great work and many thanks to Taher, Jacques and Deepak for
> their efforts on the repository separation this weekend.
>
> I think we should provide processes and support for the following cases:
>
> 1. separated development of the framework and core applications without
> forced embedding of the plugins
>
> 2. separated development of the plugins with the support to embed the
> framework part in the development environment
>
> 3. combined development of both framework and plugins.
>
> I think we'll need convenience tools/processes/support for these
> combinations because we should make contributions for and use of framework
> + plugins as easy as possible without forcing the entanglement of the
> different projects.
>
> As far as I understand forced use of svn:externals is contra productive
> because it prevents the separation. We should instead describe the
> mechanism and provide a set of svn:externals files for all users who want
> to use it. Maybe also a gradle task which generates the needed file(s) for
> convenience.
>
> I think we cannot only rely on the pull plugin mechanism because combined
> development needs to have framework and plugins in the IDE under version
> control.
>
> Users and developers should have a choice (and low hurdles to contribute),
> on the other hand we should keep it lean and simple per default.
>
> Not sure if I could make my viewpoint clear enough, I'm currently too
> tired to concentrate on better words :-)
>
> Best regards,
>
> Michael
>
>
> Am 12.02.17 um 20:59 schrieb Taher Alkhateeb:
>
>> Hi Sharan,
>>
>> I think this is not the topic under discussion, and since it seems vague
>> to
>> you I will try to clarify:
>>
>> The question now that we split framework and plugins is how to combine
>> them. The discussion so far between myself and Jacques is as follows:
>> - Jacques wants to use svn:externals so that subversion pulls all the
>> plugins into the framework and keep everything as is (testing, builds,
>> etc)
>> the way they were.
>> - My position is that we should use gradle to pull the plugins we need
>> without reliance on Subversion or any other tool and to treat the two
>> projects as two separate projects.
>>
>> Both reasons / concerns from me and Jacques are expressed by reading the
>> history of this thread (that partly exists in another thread for which
>> Deepak contributed his opinion).
>>
>> On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <[hidden email]> wrote:
>>
>> Hi All
>>>
>>> I'm not exactly completely sure what this discussion is all about. The
>>> title talks about svn and Gradle but questions in the thread seem to
>>> about
>>> something different. If it is as important as you say then we need to
>>> make
>>> sure that everyone understands exactly what this means.
>>>
>>> Are you saying that because of the framework / plugin split then
>>> committers will work only on the framework? If so, then remember that it
>>> was our contributors and committers that put the 'plugins' into OFBiz in
>>> the first place which means that people who are interested in developing
>>> a
>>> particular functionality further can do it without worrying about or
>>> breaking the framework.
>>>
>>>  From my side I know that we also have some OFBiz application
>>> documentation
>>> that is sitting in docbook inside OFBiz I think would be better
>>> implemented
>>> as a plugin. It would be good to be able to work on and test this
>>> separately.
>>>
>>> I apologise if I've misunderstood this thread but as I say - it's not
>>> very
>>> clear what it is all about.
>>>
>>> Thanks
>>> Sharan
>>>
>>> On 2017-02-12 13:55 (+0100), Jacques Le Roux <
>>> [hidden email]>
>>> wrote:
>>>
>>>> Thanks Taher,
>>>>
>>>> I create a clean new thread to have it more prominent.
>>>>
>>>> This is really what needs to be discussed indeed.
>>>>
>>>> Are we sure that's what we want for plugins?
>>>>
>>>> Will they not be disregarded by committers?
>>>>
>>>> Will plugins follow the framework trend?
>>>>
>>>> This is a very important community decision.
>>>> I hope everybody will (try to) understand the consequences and
>>>>
>>> participate to this discussion, before it will be too late...
>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
>>>>
>>>>> Let's take a look at the big picture for a moment before we decide. We
>>>>>
>>>> have
>>>
>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>>
>>>>> Why did we break it up? Why did we go through the trouble of creating
>>>>>
>>>> two
>>>
>>>> different repositories? I hope the answer is something like "because
>>>>>
>>>> it is
>>>
>>>> too big" or "because it carried a lot of non-essential functionality
>>>>>
>>>> around"
>>>
>>>> So breaking up the project brings the advantage of not having to _worry
>>>>> about everything_ on each and every commit. These are two projects
>>>>>
>>>> with two
>>>
>>>> release cycles and they don't need to be developed together
>>>>>
>>>> simultaneously.
>>>
>>>> People can specialize and focus on different areas.
>>>>>
>>>>> The whole idea of breaking the system up and then using gradle's
>>>>>
>>>> plugin API
>>>
>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>>> introduce svn externals then all  we achieve is create two repositories
>>>>> only to merge them again. Why! that's pointless!
>>>>>
>>>>> Two products means two buildbot scripts, two releases, two development
>>>>> cycles, two different things!
>>>>>
>>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>>>
>>>> hacks
>>>
>>>> like svn externals.
>>>>>
>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Hi All,
>>>>>>
>>>>>> This discussion already happened at OFBIZ-9182, but only between
>>>>>>
>>>>> Taher,
>>>
>>>> Nicolas and I.
>>>>>>
>>>>>> The question is simple, below reflects it, and the subject summarises
>>>>>>
>>>>> it.
>>>
>>>> So what are your thoughts and opinions?
>>>>>>
>>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>>>
>>>>> create a
>>>
>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>>>
>>>>> subject
>>>
>>>> (I was just "lazy" here)
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
>>>>>>
>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when
>>>>>>>
>>>>>> I
>>>
>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>>> maintained the OOTB plugins?
>>>>>>>
>>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
>>>>>>>
>>>>>>> Hi Jacques,
>>>>>>>>
>>>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>>> separate. If any committer or developer want he can use gradle task
>>>>>>>>
>>>>>>> for
>>>
>>>> the
>>>>>>>> same.
>>>>>>>>
>>>>>>>> Thanks & Regards
>>>>>>>> --
>>>>>>>> Deepak Dixit
>>>>>>>> www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>>>
>>>>>>> easily
>>>
>>>> maintain the plugins?
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
>>>>>>>>>
>>>>>>>>> Hi Jacques,
>>>>>>>>>
>>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>>>
>>>>>>>>> the
>>>
>>>> plugins with trunk
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards
>>>>>>>>>> --
>>>>>>>>>> Deepak Dixit
>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacopo Cappellato-5
On Mon, Feb 13, 2017 at 6:33 AM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Michael, All
>
> All good points, thank you for your thoughts. So a solution that I proposed
> in jira to easily manage and maintain our official plugins is to have a
> gradle task named for example pullPluginSourceAll which pulls all the
> plugins in one shot for testing and development purposes. Maybe we can also
> add logic in this task so that it updates already downloaded plugins.
>
> I'm sure there are other good ideas as well. My point of emphasis is to
> Simply keep the two projects clearly separated, and to avoid relying
> directly on tools not embedded within the framework like subversion.


+1

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Michael Brohl-3
In reply to this post by taher
Hi Taher,

inline...

Am 13.02.17 um 06:33 schrieb Taher Alkhateeb:
> Hi Michael, All
>
> All good points, thank you for your thoughts. So a solution that I proposed
> in jira to easily manage and maintain our official plugins is to have a
> gradle task named for example pullPluginSourceAll which pulls all the
> plugins in one shot for testing and development purposes. Maybe we can also
> add logic in this task so that it updates already downloaded plugins.
That's a good approach if you want to test plugins/integration within
the framework without the need to work on plugin sources under source
control, if I understand it right. This should be the default case.

Additionally, I suggest to provide a task which creates the
svn:externals file for the case where you want the plugin sources in
your project and have them under source control.
Or, if we don't want to have such a task in the codebase, provide some
documentation on how to achieve this manually.
Maybe there are other good solutions as well.

Else I cannot think of an easy process for a plugin developer to create
patches or make commits against the repository without hassle.
>
> I'm sure there are other good ideas as well. My point of emphasis is to
> Simply keep the two projects clearly separated, and to avoid relying
> directly on tools not embedded within the framework like subversion.
I completely agree on this point and this should be the default. I just
think that we should provide some (non default) alternatives or at least
how-to's to make it easy for everyone to contribute.
We should think about different types of users and contributors.

Regards,

Michael

>
> On Feb 13, 2017 12:08 AM, "Michael Brohl" <[hidden email]> wrote:
>
>> Hi,
>>
>> first of all: great work and many thanks to Taher, Jacques and Deepak for
>> their efforts on the repository separation this weekend.
>>
>> I think we should provide processes and support for the following cases:
>>
>> 1. separated development of the framework and core applications without
>> forced embedding of the plugins
>>
>> 2. separated development of the plugins with the support to embed the
>> framework part in the development environment
>>
>> 3. combined development of both framework and plugins.
>>
>> I think we'll need convenience tools/processes/support for these
>> combinations because we should make contributions for and use of framework
>> + plugins as easy as possible without forcing the entanglement of the
>> different projects.
>>
>> As far as I understand forced use of svn:externals is contra productive
>> because it prevents the separation. We should instead describe the
>> mechanism and provide a set of svn:externals files for all users who want
>> to use it. Maybe also a gradle task which generates the needed file(s) for
>> convenience.
>>
>> I think we cannot only rely on the pull plugin mechanism because combined
>> development needs to have framework and plugins in the IDE under version
>> control.
>>
>> Users and developers should have a choice (and low hurdles to contribute),
>> on the other hand we should keep it lean and simple per default.
>>
>> Not sure if I could make my viewpoint clear enough, I'm currently too
>> tired to concentrate on better words :-)
>>
>> Best regards,
>>
>> Michael
>>
>>
>> Am 12.02.17 um 20:59 schrieb Taher Alkhateeb:
>>
>>> Hi Sharan,
>>>
>>> I think this is not the topic under discussion, and since it seems vague
>>> to
>>> you I will try to clarify:
>>>
>>> The question now that we split framework and plugins is how to combine
>>> them. The discussion so far between myself and Jacques is as follows:
>>> - Jacques wants to use svn:externals so that subversion pulls all the
>>> plugins into the framework and keep everything as is (testing, builds,
>>> etc)
>>> the way they were.
>>> - My position is that we should use gradle to pull the plugins we need
>>> without reliance on Subversion or any other tool and to treat the two
>>> projects as two separate projects.
>>>
>>> Both reasons / concerns from me and Jacques are expressed by reading the
>>> history of this thread (that partly exists in another thread for which
>>> Deepak contributed his opinion).
>>>
>>> On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <[hidden email]> wrote:
>>>
>>> Hi All
>>>> I'm not exactly completely sure what this discussion is all about. The
>>>> title talks about svn and Gradle but questions in the thread seem to
>>>> about
>>>> something different. If it is as important as you say then we need to
>>>> make
>>>> sure that everyone understands exactly what this means.
>>>>
>>>> Are you saying that because of the framework / plugin split then
>>>> committers will work only on the framework? If so, then remember that it
>>>> was our contributors and committers that put the 'plugins' into OFBiz in
>>>> the first place which means that people who are interested in developing
>>>> a
>>>> particular functionality further can do it without worrying about or
>>>> breaking the framework.
>>>>
>>>>   From my side I know that we also have some OFBiz application
>>>> documentation
>>>> that is sitting in docbook inside OFBiz I think would be better
>>>> implemented
>>>> as a plugin. It would be good to be able to work on and test this
>>>> separately.
>>>>
>>>> I apologise if I've misunderstood this thread but as I say - it's not
>>>> very
>>>> clear what it is all about.
>>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>> On 2017-02-12 13:55 (+0100), Jacques Le Roux <
>>>> [hidden email]>
>>>> wrote:
>>>>
>>>>> Thanks Taher,
>>>>>
>>>>> I create a clean new thread to have it more prominent.
>>>>>
>>>>> This is really what needs to be discussed indeed.
>>>>>
>>>>> Are we sure that's what we want for plugins?
>>>>>
>>>>> Will they not be disregarded by committers?
>>>>>
>>>>> Will plugins follow the framework trend?
>>>>>
>>>>> This is a very important community decision.
>>>>> I hope everybody will (try to) understand the consequences and
>>>>>
>>>> participate to this discussion, before it will be too late...
>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
>>>>>
>>>>>> Let's take a look at the big picture for a moment before we decide. We
>>>>>>
>>>>> have
>>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>>> Why did we break it up? Why did we go through the trouble of creating
>>>>>>
>>>>> two
>>>>> different repositories? I hope the answer is something like "because
>>>>> it is
>>>>> too big" or "because it carried a lot of non-essential functionality
>>>>> around"
>>>>> So breaking up the project brings the advantage of not having to _worry
>>>>>> about everything_ on each and every commit. These are two projects
>>>>>>
>>>>> with two
>>>>> release cycles and they don't need to be developed together
>>>>> simultaneously.
>>>>> People can specialize and focus on different areas.
>>>>>> The whole idea of breaking the system up and then using gradle's
>>>>>>
>>>>> plugin API
>>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>>>> introduce svn externals then all  we achieve is create two repositories
>>>>>> only to merge them again. Why! that's pointless!
>>>>>>
>>>>>> Two products means two buildbot scripts, two releases, two development
>>>>>> cycles, two different things!
>>>>>>
>>>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>>>>
>>>>> hacks
>>>>> like svn externals.
>>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>> This discussion already happened at OFBIZ-9182, but only between
>>>>>>>
>>>>>> Taher,
>>>>> Nicolas and I.
>>>>>>> The question is simple, below reflects it, and the subject summarises
>>>>>>>
>>>>>> it.
>>>>> So what are your thoughts and opinions?
>>>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>>>>
>>>>>> create a
>>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>>> subject
>>>>> (I was just "lazy" here)
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
>>>>>>>
>>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when
>>>>>>> I
>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>>>> maintained the OOTB plugins?
>>>>>>>>
>>>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
>>>>>>>>
>>>>>>>> Hi Jacques,
>>>>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>>>> separate. If any committer or developer want he can use gradle task
>>>>>>>>>
>>>>>>>> for
>>>>> the
>>>>>>>>> same.
>>>>>>>>>
>>>>>>>>> Thanks & Regards
>>>>>>>>> --
>>>>>>>>> Deepak Dixit
>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>>>>
>>>>>>>> easily
>>>>> maintain the plugins?
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
>>>>>>>>>>
>>>>>>>>>> Hi Jacques,
>>>>>>>>>>
>>>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>>>>
>>>>>>>>>> the
>>>>> plugins with trunk
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards
>>>>>>>>>>> --
>>>>>>>>>>> Deepak Dixit
>>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
In reply to this post by taher
Hi,

Thanks Michael, your points are clearly explained.

I agree that using svn:externals for plugins breaks the initial purpose of decoupling plugins from the rest.

Also providing a set of svn:externals files would not help because svn:externals need to be committed in the repo to be effective.

Now, the pullPluginSource task is doing a checkout and developers have svn installed (to check out the framework)

So updting  a plugin by hand with svn, or even several plugins at a time with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
So we don't need Gradle tasks for that, all is still possible.

To summarize, so far I seed no disadvantages with Taher solution, but in Builbot for plugins.


I have an idea for that: we create a copy of the trunk in a BuildBot special branch, say ofbiz-framework-buildbot

This branch must never be used to commit directly (we can always revert in case)

This branch has svn:externals for plugins installed has described previously

In Buildbot, we no longer build the trunk framework and plugins.

But, on a svn commit in ofbiz-framework, or in the ofbiz-plugins, we merge the commit in ofbiz-framework-buildbot and we run the tests and the rest

I have though still to figure out how to trigger a build on a commit external to this branch, and even if it's possible...


So, apart if I missed something, technically it's OK. I believe committers need now to agree about checking out all plugins and maintaining them as we
did before. This must be documented in our policies.

Jacques


Le 13/02/2017 à 06:33, Taher Alkhateeb a écrit :

> Hi Michael, All
>
> All good points, thank you for your thoughts. So a solution that I proposed
> in jira to easily manage and maintain our official plugins is to have a
> gradle task named for example pullPluginSourceAll which pulls all the
> plugins in one shot for testing and development purposes. Maybe we can also
> add logic in this task so that it updates already downloaded plugins.
>
> I'm sure there are other good ideas as well. My point of emphasis is to
> Simply keep the two projects clearly separated, and to avoid relying
> directly on tools not embedded within the framework like subversion.
>
> On Feb 13, 2017 12:08 AM, "Michael Brohl" <[hidden email]> wrote:
>
>> Hi,
>>
>> first of all: great work and many thanks to Taher, Jacques and Deepak for
>> their efforts on the repository separation this weekend.
>>
>> I think we should provide processes and support for the following cases:
>>
>> 1. separated development of the framework and core applications without
>> forced embedding of the plugins
>>
>> 2. separated development of the plugins with the support to embed the
>> framework part in the development environment
>>
>> 3. combined development of both framework and plugins.
>>
>> I think we'll need convenience tools/processes/support for these
>> combinations because we should make contributions for and use of framework
>> + plugins as easy as possible without forcing the entanglement of the
>> different projects.
>>
>> As far as I understand forced use of svn:externals is contra productive
>> because it prevents the separation. We should instead describe the
>> mechanism and provide a set of svn:externals files for all users who want
>> to use it. Maybe also a gradle task which generates the needed file(s) for
>> convenience.
>>
>> I think we cannot only rely on the pull plugin mechanism because combined
>> development needs to have framework and plugins in the IDE under version
>> control.
>>
>> Users and developers should have a choice (and low hurdles to contribute),
>> on the other hand we should keep it lean and simple per default.
>>
>> Not sure if I could make my viewpoint clear enough, I'm currently too
>> tired to concentrate on better words :-)
>>
>> Best regards,
>>
>> Michael
>>
>>
>> Am 12.02.17 um 20:59 schrieb Taher Alkhateeb:
>>
>>> Hi Sharan,
>>>
>>> I think this is not the topic under discussion, and since it seems vague
>>> to
>>> you I will try to clarify:
>>>
>>> The question now that we split framework and plugins is how to combine
>>> them. The discussion so far between myself and Jacques is as follows:
>>> - Jacques wants to use svn:externals so that subversion pulls all the
>>> plugins into the framework and keep everything as is (testing, builds,
>>> etc)
>>> the way they were.
>>> - My position is that we should use gradle to pull the plugins we need
>>> without reliance on Subversion or any other tool and to treat the two
>>> projects as two separate projects.
>>>
>>> Both reasons / concerns from me and Jacques are expressed by reading the
>>> history of this thread (that partly exists in another thread for which
>>> Deepak contributed his opinion).
>>>
>>> On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <[hidden email]> wrote:
>>>
>>> Hi All
>>>> I'm not exactly completely sure what this discussion is all about. The
>>>> title talks about svn and Gradle but questions in the thread seem to
>>>> about
>>>> something different. If it is as important as you say then we need to
>>>> make
>>>> sure that everyone understands exactly what this means.
>>>>
>>>> Are you saying that because of the framework / plugin split then
>>>> committers will work only on the framework? If so, then remember that it
>>>> was our contributors and committers that put the 'plugins' into OFBiz in
>>>> the first place which means that people who are interested in developing
>>>> a
>>>> particular functionality further can do it without worrying about or
>>>> breaking the framework.
>>>>
>>>>   From my side I know that we also have some OFBiz application
>>>> documentation
>>>> that is sitting in docbook inside OFBiz I think would be better
>>>> implemented
>>>> as a plugin. It would be good to be able to work on and test this
>>>> separately.
>>>>
>>>> I apologise if I've misunderstood this thread but as I say - it's not
>>>> very
>>>> clear what it is all about.
>>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>> On 2017-02-12 13:55 (+0100), Jacques Le Roux <
>>>> [hidden email]>
>>>> wrote:
>>>>
>>>>> Thanks Taher,
>>>>>
>>>>> I create a clean new thread to have it more prominent.
>>>>>
>>>>> This is really what needs to be discussed indeed.
>>>>>
>>>>> Are we sure that's what we want for plugins?
>>>>>
>>>>> Will they not be disregarded by committers?
>>>>>
>>>>> Will plugins follow the framework trend?
>>>>>
>>>>> This is a very important community decision.
>>>>> I hope everybody will (try to) understand the consequences and
>>>>>
>>>> participate to this discussion, before it will be too late...
>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
>>>>>
>>>>>> Let's take a look at the big picture for a moment before we decide. We
>>>>>>
>>>>> have
>>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>>> Why did we break it up? Why did we go through the trouble of creating
>>>>>>
>>>>> two
>>>>> different repositories? I hope the answer is something like "because
>>>>> it is
>>>>> too big" or "because it carried a lot of non-essential functionality
>>>>> around"
>>>>> So breaking up the project brings the advantage of not having to _worry
>>>>>> about everything_ on each and every commit. These are two projects
>>>>>>
>>>>> with two
>>>>> release cycles and they don't need to be developed together
>>>>> simultaneously.
>>>>> People can specialize and focus on different areas.
>>>>>> The whole idea of breaking the system up and then using gradle's
>>>>>>
>>>>> plugin API
>>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>>>> introduce svn externals then all  we achieve is create two repositories
>>>>>> only to merge them again. Why! that's pointless!
>>>>>>
>>>>>> Two products means two buildbot scripts, two releases, two development
>>>>>> cycles, two different things!
>>>>>>
>>>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>>>>
>>>>> hacks
>>>>> like svn externals.
>>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>> This discussion already happened at OFBIZ-9182, but only between
>>>>>>>
>>>>>> Taher,
>>>>> Nicolas and I.
>>>>>>> The question is simple, below reflects it, and the subject summarises
>>>>>>>
>>>>>> it.
>>>>> So what are your thoughts and opinions?
>>>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>>>>
>>>>>> create a
>>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>>> subject
>>>>> (I was just "lazy" here)
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
>>>>>>>
>>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when
>>>>>>> I
>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>>>> maintained the OOTB plugins?
>>>>>>>>
>>>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
>>>>>>>>
>>>>>>>> Hi Jacques,
>>>>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>>>> separate. If any committer or developer want he can use gradle task
>>>>>>>>>
>>>>>>>> for
>>>>> the
>>>>>>>>> same.
>>>>>>>>>
>>>>>>>>> Thanks & Regards
>>>>>>>>> --
>>>>>>>>> Deepak Dixit
>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>>>>
>>>>>>>> easily
>>>>> maintain the plugins?
>>>>>>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
>>>>>>>>>>
>>>>>>>>>> Hi Jacques,
>>>>>>>>>>
>>>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>>>>
>>>>>>>>>> the
>>>>> plugins with trunk
>>>>>>>>>>>
>>>>>>>>>>> Thanks & Regards
>>>>>>>>>>> --
>>>>>>>>>>> Deepak Dixit
>>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
Ah, and looking forward for a pullAllPluginsSource task

Jacques


Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :

> Hi,
>
> Thanks Michael, your points are clearly explained.
>
> I agree that using svn:externals for plugins breaks the initial purpose of decoupling plugins from the rest.
>
> Also providing a set of svn:externals files would not help because svn:externals need to be committed in the repo to be effective.
>
> Now, the pullPluginSource task is doing a checkout and developers have svn installed (to check out the framework)
>
> So updting  a plugin by hand with svn, or even several plugins at a time with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
> So we don't need Gradle tasks for that, all is still possible.
>
> To summarize, so far I seed no disadvantages with Taher solution, but in Builbot for plugins.
>
>
> I have an idea for that: we create a copy of the trunk in a BuildBot special branch, say ofbiz-framework-buildbot
>
> This branch must never be used to commit directly (we can always revert in case)
>
> This branch has svn:externals for plugins installed has described previously
>
> In Buildbot, we no longer build the trunk framework and plugins.
>
> But, on a svn commit in ofbiz-framework, or in the ofbiz-plugins, we merge the commit in ofbiz-framework-buildbot and we run the tests and the rest
>
> I have though still to figure out how to trigger a build on a commit external to this branch, and even if it's possible...
>
>
> So, apart if I missed something, technically it's OK. I believe committers need now to agree about checking out all plugins and maintaining them as
> we did before. This must be documented in our policies.
>
> Jacques
>
>
> Le 13/02/2017 à 06:33, Taher Alkhateeb a écrit :
>> Hi Michael, All
>>
>> All good points, thank you for your thoughts. So a solution that I proposed
>> in jira to easily manage and maintain our official plugins is to have a
>> gradle task named for example pullPluginSourceAll which pulls all the
>> plugins in one shot for testing and development purposes. Maybe we can also
>> add logic in this task so that it updates already downloaded plugins.
>>
>> I'm sure there are other good ideas as well. My point of emphasis is to
>> Simply keep the two projects clearly separated, and to avoid relying
>> directly on tools not embedded within the framework like subversion.
>>
>> On Feb 13, 2017 12:08 AM, "Michael Brohl" <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> first of all: great work and many thanks to Taher, Jacques and Deepak for
>>> their efforts on the repository separation this weekend.
>>>
>>> I think we should provide processes and support for the following cases:
>>>
>>> 1. separated development of the framework and core applications without
>>> forced embedding of the plugins
>>>
>>> 2. separated development of the plugins with the support to embed the
>>> framework part in the development environment
>>>
>>> 3. combined development of both framework and plugins.
>>>
>>> I think we'll need convenience tools/processes/support for these
>>> combinations because we should make contributions for and use of framework
>>> + plugins as easy as possible without forcing the entanglement of the
>>> different projects.
>>>
>>> As far as I understand forced use of svn:externals is contra productive
>>> because it prevents the separation. We should instead describe the
>>> mechanism and provide a set of svn:externals files for all users who want
>>> to use it. Maybe also a gradle task which generates the needed file(s) for
>>> convenience.
>>>
>>> I think we cannot only rely on the pull plugin mechanism because combined
>>> development needs to have framework and plugins in the IDE under version
>>> control.
>>>
>>> Users and developers should have a choice (and low hurdles to contribute),
>>> on the other hand we should keep it lean and simple per default.
>>>
>>> Not sure if I could make my viewpoint clear enough, I'm currently too
>>> tired to concentrate on better words :-)
>>>
>>> Best regards,
>>>
>>> Michael
>>>
>>>
>>> Am 12.02.17 um 20:59 schrieb Taher Alkhateeb:
>>>
>>>> Hi Sharan,
>>>>
>>>> I think this is not the topic under discussion, and since it seems vague
>>>> to
>>>> you I will try to clarify:
>>>>
>>>> The question now that we split framework and plugins is how to combine
>>>> them. The discussion so far between myself and Jacques is as follows:
>>>> - Jacques wants to use svn:externals so that subversion pulls all the
>>>> plugins into the framework and keep everything as is (testing, builds,
>>>> etc)
>>>> the way they were.
>>>> - My position is that we should use gradle to pull the plugins we need
>>>> without reliance on Subversion or any other tool and to treat the two
>>>> projects as two separate projects.
>>>>
>>>> Both reasons / concerns from me and Jacques are expressed by reading the
>>>> history of this thread (that partly exists in another thread for which
>>>> Deepak contributed his opinion).
>>>>
>>>> On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <[hidden email]> wrote:
>>>>
>>>> Hi All
>>>>> I'm not exactly completely sure what this discussion is all about. The
>>>>> title talks about svn and Gradle but questions in the thread seem to
>>>>> about
>>>>> something different. If it is as important as you say then we need to
>>>>> make
>>>>> sure that everyone understands exactly what this means.
>>>>>
>>>>> Are you saying that because of the framework / plugin split then
>>>>> committers will work only on the framework? If so, then remember that it
>>>>> was our contributors and committers that put the 'plugins' into OFBiz in
>>>>> the first place which means that people who are interested in developing
>>>>> a
>>>>> particular functionality further can do it without worrying about or
>>>>> breaking the framework.
>>>>>
>>>>>   From my side I know that we also have some OFBiz application
>>>>> documentation
>>>>> that is sitting in docbook inside OFBiz I think would be better
>>>>> implemented
>>>>> as a plugin. It would be good to be able to work on and test this
>>>>> separately.
>>>>>
>>>>> I apologise if I've misunderstood this thread but as I say - it's not
>>>>> very
>>>>> clear what it is all about.
>>>>>
>>>>> Thanks
>>>>> Sharan
>>>>>
>>>>> On 2017-02-12 13:55 (+0100), Jacques Le Roux <
>>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Thanks Taher,
>>>>>>
>>>>>> I create a clean new thread to have it more prominent.
>>>>>>
>>>>>> This is really what needs to be discussed indeed.
>>>>>>
>>>>>> Are we sure that's what we want for plugins?
>>>>>>
>>>>>> Will they not be disregarded by committers?
>>>>>>
>>>>>> Will plugins follow the framework trend?
>>>>>>
>>>>>> This is a very important community decision.
>>>>>> I hope everybody will (try to) understand the consequences and
>>>>>>
>>>>> participate to this discussion, before it will be too late...
>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
>>>>>>
>>>>>>> Let's take a look at the big picture for a moment before we decide. We
>>>>>>>
>>>>>> have
>>>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>>>> Why did we break it up? Why did we go through the trouble of creating
>>>>>>>
>>>>>> two
>>>>>> different repositories? I hope the answer is something like "because
>>>>>> it is
>>>>>> too big" or "because it carried a lot of non-essential functionality
>>>>>> around"
>>>>>> So breaking up the project brings the advantage of not having to _worry
>>>>>>> about everything_ on each and every commit. These are two projects
>>>>>>>
>>>>>> with two
>>>>>> release cycles and they don't need to be developed together
>>>>>> simultaneously.
>>>>>> People can specialize and focus on different areas.
>>>>>>> The whole idea of breaking the system up and then using gradle's
>>>>>>>
>>>>>> plugin API
>>>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>>>>> introduce svn externals then all  we achieve is create two repositories
>>>>>>> only to merge them again. Why! that's pointless!
>>>>>>>
>>>>>>> Two products means two buildbot scripts, two releases, two development
>>>>>>> cycles, two different things!
>>>>>>>
>>>>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>>>>>
>>>>>> hacks
>>>>>> like svn externals.
>>>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>> This discussion already happened at OFBIZ-9182, but only between
>>>>>>>>
>>>>>>> Taher,
>>>>>> Nicolas and I.
>>>>>>>> The question is simple, below reflects it, and the subject summarises
>>>>>>>>
>>>>>>> it.
>>>>>> So what are your thoughts and opinions?
>>>>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>>>>>
>>>>>>> create a
>>>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>>>> subject
>>>>>> (I was just "lazy" here)
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
>>>>>>>>
>>>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when
>>>>>>>> I
>>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>>>>> maintained the OOTB plugins?
>>>>>>>>>
>>>>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
>>>>>>>>>
>>>>>>>>> Hi Jacques,
>>>>>>>>>> We can add gradle task to pull all plugins from remote. As we are
>>>>>>>>>> de-coupling plugins from core so I think its good idea to keep them
>>>>>>>>>> separate. If any committer or developer want he can use gradle task
>>>>>>>>>>
>>>>>>>>> for
>>>>>> the
>>>>>>>>>> same.
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards
>>>>>>>>>> --
>>>>>>>>>> Deepak Dixit
>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>>>>>
>>>>>>>>> easily
>>>>>> maintain the plugins?
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
>>>>>>>>>>>
>>>>>>>>>>> Hi Jacques,
>>>>>>>>>>>
>>>>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>> plugins with trunk
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks & Regards
>>>>>>>>>>>> --
>>>>>>>>>>>> Deepak Dixit
>>>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

taher
In reply to this post by Michael Brohl-3
Hi Michael. If I understand your point correctly regarding ease of
contribution, would it be a problem to just go to the plugin directory and
issue a command like svn diff > plugin-fix.patch?

On Mon, Feb 13, 2017 at 12:54 PM, Michael Brohl <[hidden email]>
wrote:

> Hi Taher,
>
> inline...
>
> Am 13.02.17 um 06:33 schrieb Taher Alkhateeb:
>
>> Hi Michael, All
>>
>> All good points, thank you for your thoughts. So a solution that I
>> proposed
>> in jira to easily manage and maintain our official plugins is to have a
>> gradle task named for example pullPluginSourceAll which pulls all the
>> plugins in one shot for testing and development purposes. Maybe we can
>> also
>> add logic in this task so that it updates already downloaded plugins.
>>
> That's a good approach if you want to test plugins/integration within the
> framework without the need to work on plugin sources under source control,
> if I understand it right. This should be the default case.
>
> Additionally, I suggest to provide a task which creates the svn:externals
> file for the case where you want the plugin sources in your project and
> have them under source control.
> Or, if we don't want to have such a task in the codebase, provide some
> documentation on how to achieve this manually.
> Maybe there are other good solutions as well.
>
> Else I cannot think of an easy process for a plugin developer to create
> patches or make commits against the repository without hassle.
>
>>
>> I'm sure there are other good ideas as well. My point of emphasis is to
>> Simply keep the two projects clearly separated, and to avoid relying
>> directly on tools not embedded within the framework like subversion.
>>
> I completely agree on this point and this should be the default. I just
> think that we should provide some (non default) alternatives or at least
> how-to's to make it easy for everyone to contribute.
> We should think about different types of users and contributors.
>
> Regards,
>
> Michael
>
>
>> On Feb 13, 2017 12:08 AM, "Michael Brohl" <[hidden email]>
>> wrote:
>>
>> Hi,
>>>
>>> first of all: great work and many thanks to Taher, Jacques and Deepak for
>>> their efforts on the repository separation this weekend.
>>>
>>> I think we should provide processes and support for the following cases:
>>>
>>> 1. separated development of the framework and core applications without
>>> forced embedding of the plugins
>>>
>>> 2. separated development of the plugins with the support to embed the
>>> framework part in the development environment
>>>
>>> 3. combined development of both framework and plugins.
>>>
>>> I think we'll need convenience tools/processes/support for these
>>> combinations because we should make contributions for and use of
>>> framework
>>> + plugins as easy as possible without forcing the entanglement of the
>>> different projects.
>>>
>>> As far as I understand forced use of svn:externals is contra productive
>>> because it prevents the separation. We should instead describe the
>>> mechanism and provide a set of svn:externals files for all users who want
>>> to use it. Maybe also a gradle task which generates the needed file(s)
>>> for
>>> convenience.
>>>
>>> I think we cannot only rely on the pull plugin mechanism because combined
>>> development needs to have framework and plugins in the IDE under version
>>> control.
>>>
>>> Users and developers should have a choice (and low hurdles to
>>> contribute),
>>> on the other hand we should keep it lean and simple per default.
>>>
>>> Not sure if I could make my viewpoint clear enough, I'm currently too
>>> tired to concentrate on better words :-)
>>>
>>> Best regards,
>>>
>>> Michael
>>>
>>>
>>> Am 12.02.17 um 20:59 schrieb Taher Alkhateeb:
>>>
>>> Hi Sharan,
>>>>
>>>> I think this is not the topic under discussion, and since it seems vague
>>>> to
>>>> you I will try to clarify:
>>>>
>>>> The question now that we split framework and plugins is how to combine
>>>> them. The discussion so far between myself and Jacques is as follows:
>>>> - Jacques wants to use svn:externals so that subversion pulls all the
>>>> plugins into the framework and keep everything as is (testing, builds,
>>>> etc)
>>>> the way they were.
>>>> - My position is that we should use gradle to pull the plugins we need
>>>> without reliance on Subversion or any other tool and to treat the two
>>>> projects as two separate projects.
>>>>
>>>> Both reasons / concerns from me and Jacques are expressed by reading the
>>>> history of this thread (that partly exists in another thread for which
>>>> Deepak contributed his opinion).
>>>>
>>>> On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <[hidden email]>
>>>> wrote:
>>>>
>>>> Hi All
>>>>
>>>>> I'm not exactly completely sure what this discussion is all about. The
>>>>> title talks about svn and Gradle but questions in the thread seem to
>>>>> about
>>>>> something different. If it is as important as you say then we need to
>>>>> make
>>>>> sure that everyone understands exactly what this means.
>>>>>
>>>>> Are you saying that because of the framework / plugin split then
>>>>> committers will work only on the framework? If so, then remember that
>>>>> it
>>>>> was our contributors and committers that put the 'plugins' into OFBiz
>>>>> in
>>>>> the first place which means that people who are interested in
>>>>> developing
>>>>> a
>>>>> particular functionality further can do it without worrying about or
>>>>> breaking the framework.
>>>>>
>>>>>   From my side I know that we also have some OFBiz application
>>>>> documentation
>>>>> that is sitting in docbook inside OFBiz I think would be better
>>>>> implemented
>>>>> as a plugin. It would be good to be able to work on and test this
>>>>> separately.
>>>>>
>>>>> I apologise if I've misunderstood this thread but as I say - it's not
>>>>> very
>>>>> clear what it is all about.
>>>>>
>>>>> Thanks
>>>>> Sharan
>>>>>
>>>>> On 2017-02-12 13:55 (+0100), Jacques Le Roux <
>>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>> Thanks Taher,
>>>>>>
>>>>>> I create a clean new thread to have it more prominent.
>>>>>>
>>>>>> This is really what needs to be discussed indeed.
>>>>>>
>>>>>> Are we sure that's what we want for plugins?
>>>>>>
>>>>>> Will they not be disregarded by committers?
>>>>>>
>>>>>> Will plugins follow the framework trend?
>>>>>>
>>>>>> This is a very important community decision.
>>>>>> I hope everybody will (try to) understand the consequences and
>>>>>>
>>>>>> participate to this discussion, before it will be too late...
>>>>>
>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit :
>>>>>>
>>>>>> Let's take a look at the big picture for a moment before we decide. We
>>>>>>>
>>>>>>> have
>>>>>> broken OFBiz into essentially two products: framework and plugins.
>>>>>>
>>>>>>> Why did we break it up? Why did we go through the trouble of creating
>>>>>>>
>>>>>>> two
>>>>>> different repositories? I hope the answer is something like "because
>>>>>> it is
>>>>>> too big" or "because it carried a lot of non-essential functionality
>>>>>> around"
>>>>>> So breaking up the project brings the advantage of not having to
>>>>>> _worry
>>>>>>
>>>>>>> about everything_ on each and every commit. These are two projects
>>>>>>>
>>>>>>> with two
>>>>>> release cycles and they don't need to be developed together
>>>>>> simultaneously.
>>>>>> People can specialize and focus on different areas.
>>>>>>
>>>>>>> The whole idea of breaking the system up and then using gradle's
>>>>>>>
>>>>>>> plugin API
>>>>>> for OFBiz is to remove the coupling between the two projects. If we
>>>>>>
>>>>>>> introduce svn externals then all  we achieve is create two
>>>>>>> repositories
>>>>>>> only to merge them again. Why! that's pointless!
>>>>>>>
>>>>>>> Two products means two buildbot scripts, two releases, two
>>>>>>> development
>>>>>>> cycles, two different things!
>>>>>>>
>>>>>>> So to achieve true separation and decoupling, I suggest to avoid any
>>>>>>>
>>>>>>> hacks
>>>>>> like svn externals.
>>>>>>
>>>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>>> This discussion already happened at OFBIZ-9182, but only between
>>>>>>>>
>>>>>>>> Taher,
>>>>>>>
>>>>>> Nicolas and I.
>>>>>>
>>>>>>> The question is simple, below reflects it, and the subject summarises
>>>>>>>>
>>>>>>>> it.
>>>>>>>
>>>>>> So what are your thoughts and opinions?
>>>>>>
>>>>>>> Also when answering I guess we can remove  '(was Re: Proposal to
>>>>>>>>
>>>>>>>> create a
>>>>>>>
>>>>>> separate svn repository for the OFBiz official plugins)' from the
>>>>>>
>>>>>>> subject
>>>>>>>
>>>>>> (I was just "lazy" here)
>>>>>>
>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit :
>>>>>>>>
>>>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when
>>>>>>>> I
>>>>>>>>
>>>>>>> remember what happened with R13.07. I mean how and by who will be
>>>>>>
>>>>>>> maintained the OOTB plugins?
>>>>>>>>>
>>>>>>>>> I think this should be more discussed, and maybe voted, here
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit :
>>>>>>>>>
>>>>>>>>> Hi Jacques,
>>>>>>>>>
>>>>>>>>>> We can add gradle task to  pull all plugins from remote. As we are
>>>>>>>>>> de-coupling plugins from core so I think its good idea to keep
>>>>>>>>>> them
>>>>>>>>>> separate. If any committer or developer want he can use gradle
>>>>>>>>>> task
>>>>>>>>>>
>>>>>>>>>> for
>>>>>>>>>
>>>>>>>> the
>>>>>>
>>>>>>> same.
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards
>>>>>>>>>> --
>>>>>>>>>> Deepak Dixit
>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes this is the idea, why should we not? How else committers will
>>>>>>>>>>
>>>>>>>>>> easily
>>>>>>>>>
>>>>>>>> maintain the plugins?
>>>>>>
>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit :
>>>>>>>>>>>
>>>>>>>>>>> Hi Jacques,
>>>>>>>>>>>
>>>>>>>>>>> I think if wesvn:external  on trunk, then it will always checkout
>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>> plugins with trunk
>>>>>>
>>>>>>>
>>>>>>>>>>>> Thanks & Regards
>>>>>>>>>>>> --
>>>>>>>>>>>> Deepak Dixit
>>>>>>>>>>>> www.hotwaxsystems.com
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
In reply to this post by Jacques Le Roux
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
> So updting  a plugin by hand with svn, or even several plugins at a time with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
> So we don't need Gradle tasks for that, all is still possible.
>
> To summarize, so far I seed no disadvantages with Taher solution, but in Builbot for plugins.

To make that more clear we should document how to commit in several branches at once (in committers wiki page). I know Eclipse and ToirtoiseSvn can do
that. I guess all Svn GUI clients. I never tried with different repos, but anyway here it's only branches, only 1 ASF repo.

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

taher
I don't think we should commit in several branches at once. This again
brings us back to the same problem, we are trying to treat separate
projects as one project.

On Mon, Feb 13, 2017 at 1:06 PM, Jacques Le Roux <
[hidden email]> wrote:

> Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
>
>> So updting  a plugin by hand with svn, or even several plugins at a time
>> with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
>> So we don't need Gradle tasks for that, all is still possible.
>>
>> To summarize, so far I seed no disadvantages with Taher solution, but in
>> Builbot for plugins.
>>
>
> To make that more clear we should document how to commit in several
> branches at once (in committers wiki page). I know Eclipse and ToirtoiseSvn
> can do that. I guess all Svn GUI clients. I never tried with different
> repos, but anyway here it's only branches, only 1 ASF repo.
>
> Jacques
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacopo Cappellato-5
In reply to this post by Jacques Le Roux
On Mon, Feb 13, 2017 at 11:06 AM, Jacques Le Roux <
[hidden email]> wrote:

> Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
>
>> So updting  a plugin by hand with svn, or even several plugins at a time
>> with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
>> So we don't need Gradle tasks for that, all is still possible.
>>
>> To summarize, so far I seed no disadvantages with Taher solution, but in
>> Builbot for plugins.
>>
>
> To make that more clear we should document how to commit in several
> branches at once (in committers wiki page). I know Eclipse and ToirtoiseSvn
> can do that. I guess all Svn GUI clients. I never tried with different
> repos, but anyway here it's only branches, only 1 ASF repo.


Technically they are not different repos: if you could checkout the whole
repo (http://svn.apache.org/repos/asf/ofbiz) and then issue one commit.
However we should start thinking to them as being different products; it
will take some time to adjust but when it will happen it will be a more
natural way of handling them.

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
Le 13/02/2017 à 11:15, Jacopo Cappellato a écrit :

> On Mon, Feb 13, 2017 at 11:06 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
>>
>>> So updting  a plugin by hand with svn, or even several plugins at a time
>>> with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
>>> So we don't need Gradle tasks for that, all is still possible.
>>>
>>> To summarize, so far I seed no disadvantages with Taher solution, but in
>>> Builbot for plugins.
>>>
>> To make that more clear we should document how to commit in several
>> branches at once (in committers wiki page). I know Eclipse and ToirtoiseSvn
>> can do that. I guess all Svn GUI clients. I never tried with different
>> repos, but anyway here it's only branches, only 1 ASF repo.
>
> Technically they are not different repos: if you could checkout the whole
> repo (http://svn.apache.org/repos/asf/ofbiz) and then issue one commit.
> However we should start thinking to them as being different products; it
> will take some time to adjust but when it will happen it will be a more
> natural way of handling them.
>
> Jacopo
>
Checking out the whole ASF repo, I guess it must be something ! :)

I guess committing at the same time in several plugins can happen but should be rare. It could even be a smell for refactoring (same kind of changes
in different places).

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

Jacques Le Roux
Administrator
In reply to this post by taher
I do that regularly when backporting same in several releases branches at once.

This could also happen when 2 plugins are related, example and exampleext for instance, ebay plugins also IIRW. And I'm sure in more cases...

I agree on the idea of having separated projects, but I'm not sure how it will evolve...

Jacques


Le 13/02/2017 à 11:09, Taher Alkhateeb a écrit :

> I don't think we should commit in several branches at once. This again
> brings us back to the same problem, we are trying to treat separate
> projects as one project.
>
> On Mon, Feb 13, 2017 at 1:06 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
>>
>>> So updting  a plugin by hand with svn, or even several plugins at a time
>>> with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
>>> So we don't need Gradle tasks for that, all is still possible.
>>>
>>> To summarize, so far I seed no disadvantages with Taher solution, but in
>>> Builbot for plugins.
>>>
>> To make that more clear we should document how to commit in several
>> branches at once (in committers wiki page). I know Eclipse and ToirtoiseSvn
>> can do that. I guess all Svn GUI clients. I never tried with different
>> repos, but anyway here it's only branches, only 1 ASF repo.
>>
>> Jacques
>>
>>

12