+1

Regards,
James Yong


taher wrote
> Hi Jacques,
> 
> It seems you might be missing the implications of a full split between the
> framework and plugins including with buildbot. So I will try to explain
> why
> I think it is extremely important to completely separate the build process
> into two unrelated, non-synchronized setups:
> 
> - First, the dependencies of ofbiz-framework without ofbiz-plugins is
> different from the dependencies of ofbiz-framework + ofbiz-plugins. So
> testing needs to happen in both scenarios because you might face library
> version bugs.
> - Next, to ensure real separation between the two projects, you must test
> each in isolation. For example, right now, ofbiz-framework alone does not
> pass tests. Why? because it depends on data found in the ecommerce
> component. Separating the builds would force us to fix this issue
> - Let's say a design change was made in the framework that had regressions
> or implications on the plugins, the committer should not worry about
> getting both builds right. First, the commiter should commit and make sure
> the framework works correctly and as expected. Then in a later stage same
> committer or someone could help fix the plugins.
> 
> I believe that without a full and strong separation between the two
> products, we gain absolutely no value and actually get more work and
> headache instead.
> 
> Regards,
> 
> Taher Alkhateeb
> 
> On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux <

> jacques.le.roux@

>> wrote:
> 
>> Hi Taher,
>>
>> Inline following the "Plugins packages?" thread.
>>
>>
>> Le 12/03/2017 à 11:51, Jacques Le Roux a écrit :
>>
>>>
>>> Le 12/03/2017 à 09:38, Taher Alkhateeb a écrit :
>>>
>>> - Create two different buildbot scripts for OFBiz, one for standalone
>>>> ofbiz-framework and the other for ofbiz-framework + ofbiz-plugins. The
>>>> second buildbot script would use the pullAllPluginsSource instead of
>>>> svn:external for combining the two repositories.
>>>>
>>>> WDYT?
>>>>
>>> I agree. After some tests (all seem OK so far, tests currently running
>>> here), I will remove the ofbiz-framework-buildbot branch and replace the
>>> ofbiz-framework-buildbot Buildbot build by ofbiz-framework +
>>> ofbiz-plugins
>>> and will change the same for the trunk demo.
>>> I'll also remove the Buildbot build I created for the ofbiz-plugins
>>> branch (no tests, was only a build) and add one for ofbiz-framework
>>> alone
>>> as you suggest.
>>>
>>
>> From our last discussion in Hipchat, you want to put a hand in the
>> Buildbot scripts. Great, I felt alone so far :)
>>
>> Now I was wondering, why would we need an ofbiz-framework Buildbot
>> script?
>> We can achieve all with the ofbiz-framework + ofbiz-plugins script. What
>> I
>> would do after the 1st svn step:
>> 1) using gradlew in one step (using --stacktrace): pullAllPluginsSource
>> loadDefault testIntegration .  No need for "build", it's included in
>> loadDefault. You have to put all the arguments as strings separated with
>> commas.
>> 2) Continue to create a ofbiz-trunk-framework-.zip archive
>> 3) Create a ofbiz-trunk-plugins-.zip archive reusing the
>> ofbiz-trunk-plugins builder source
>> The rest should not change
>> So it would slightly be less pull on resources, and especially we can
>> remove the ofbiz-trunk-plugins builder and all related, even the
>> ofbiz-trunk-plugins-rat builder. because all would be included in
>> ofbiz-trunk-framework-rat (renamed ofbiz-trunk-rat IMO)
>> So it would be finally simpler.
>>
>> WDYT?
>>
>> Jacques
>>





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/proposal-actions-to-take-with-plugins-tp4703181p4703235.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Reply via email to