Hi Taher,
Inline...
Le 13/03/2017 à 12:47, Taher Alkhateeb a écrit :
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.
It should only happens when running the ofbiz-framework + ofbiz-plugins
build. I see no reasons we would get library version bugs with
ofbiz-framework build alone.
I don't clearly see what the ofbiz-framework build brings in. Because the
plugins dependencies are specified in plugins.
So, if a plugin changes its dependencies, nothing should change in the
main build, so no implications for ofbiz-framework build, right?
It also means that, each time we would make a change on the framework,
both builds will run which is not negligible, and more work to maintain.
- Next, to ensure real separation between the two projects,
So far, it's not 2 projects but 2 products ;)
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
We must previously fix the already known issues and get a stable
situation. Among known issues, at least
https://issues.apache.org/jira/browse/OFBIZ-9243
https://issues.apache.org/jira/browse/OFBIZ-6976
https://issues.apache.org/jira/browse/OFBIZ-9241
I see no points uselessly running a failing build for months (I don't
expect above to be fixed in few weeks)
Later if we find good reasons the ofbiz-framework build might be
activated. I'm not yet convinced so far, but I'm sure you have good reasons
I still don't get.
- 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 differ here, I see a separation of concerns I don't like. It seems to me
that if a committer, committing something on the framework, breaks a
plugins s/he is also responsible of fixing the plugins issue.
This is something I already addressed some times ago in another message
http://markmail.org/message/lbz6o4i5vshlglkp
<<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.>>
Nobody said anything about this important point of our policies!
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.
This is to be seen. Actually it's not only a technical issue but also a
political one, on how we see the separation of the products.
Anyway, let's keep infra resources unaffected as long as at least the
above issues are not fixed.
Jacques
Regards,
Taher Alkhateeb
On Mon, Mar 13, 2017 at 2:31 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> 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
