Re: [proposal] actions to take with plugins

[Taher Alkhateeb]

Hi Michael,

Good points, thank you for sharing your thoughts. So the dependencies in
the past were just jars that we put in the code base which we cannot do for
release purposes. But even if we can, although you have the advantage of
stable versions, you will have the disadvantage of manually fixing
dependency hell. If you issue the command "./gradlew dependencies" and
observe the size and complexity of the dependency tree, you will see one
massive beast. Doing this by hand is something that I really am grateful to
avoid by using a modern tool like Gradle.

For example, a component in framework depends on lib-1.2.3 and a component
in plugins depends on lib-1.3.1, gradle would bump the dependency to the
higher number. But if you bump the dependency to lib-1.3.1 this might in
return depend on different / new libraries which would change the
dependency graph. How do we resolve this by hand? I would say .. very
painfully :)

So whether manually or automatically, in either case you will have a
changed dependency tree if you have conflicting libraries between plugins
and the rest of the system. That's why I suggested a full split between the
two projects .. to test both in isolation from each other.

Cheers,

Taher Alkhateeeb

On Mon, Mar 13, 2017 at 11:39 PM, Michael Brohl 
wrote:

> Hi Taher,
>
> first of all, thank you very much for your ongoing hard work on this, I
> really appreciate it.
>
> Maybe I'm a little late joining this discussion but I'd like to express
> one view point which I think is really important to ensure stable
> production settings. It came to my mind as I read about the transitional
> dependendies you mentioned in this thread.
>
> I think we should preserve a stable way to add functionality to OFBiz in
> parallel to the more dynamic plugins mechanism. The plugin system is a
> great way to enhance OFBiz through external resources. In productive
> business systems, you'll need a stable mechanism to add your internal
> functionality the "old" way, maybe with fixed library dependencies relying
> on specified release versions, without loading it from external
> repositories etc..
>
> I'm not really sure if this is guaranteed when we remove the hot-deploy
> mechanism and solely rely on the plugins mechanism?
>
> Best regards,
>
> Michael
>
>
> Am 12.03.17 um 09:38 schrieb Taher Alkhateeb:
>
> Hello everyone,
>>
>> Now that nearly all plugin-API is completed in [5] and [6] and after
>> having
>> various discussions about the plugins system in [1][2][3] and [4], I
>> propose the following action points:
>>
>> - Remove the hot-deploy directory with all references to it.
>> - 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?
>>
>> [1] https://s.apache.org/5Dv8 - separate plugins in new repo
>> [2] https://s.apache.org/7Y2w - hot-deploy removal
>> [3] https://s.apache.org/CvW3 - svn:external vs gradle
>> [4] https://s.apache.org/LF1o - plugin system design
>> [5] https://issues.apache.org/jira/browse/OFBIZ-9182 - new svn for
>> plugins
>> JIRA
>> [6] https://issues.apache.org/jira/browse/OFBIZ-7972 - original work on
>> plugin system
>>
>> Cheers,
>>
>> Taher Alkhateeb
>>
>>
>
>

Re: port mapping 8080 to 8443 is broken

[Taher Alkhateeb]

Hi Paul,

While the proposition to move to SSL is open for discussion elsewhere, I
share Michael's concern that the issue we are discussing here might have
not been done properly. The discussion in JIRAs and the way the commits
were done gives me the impression that this was a quick hack more than a
proper solution, and it did leave the system broken because I can go to any
URL in OFBiz like say http://localhost:8080/partymgr and it will transfer
me to https://localhost/partymgr/control and gives me a resource not found
error. This is a broken system!

As for switching to SSL, I don't know actually, but I would think a proper
solution is perhaps to make this into a configuration instead of a flat-out
block of port 8080.

Regards,

Taher Alkhateeb

On Tue, Mar 14, 2017 at 3:47 AM, Paul Foxworthy  wrote:

> Hi all,
>
> I agree with Taher, we should simply remove non-SSL access. The world is
> rapidly moving to SSL only.
>
> It is now close to essential that passwords should be encrypted in transit
> for a serious system like OFBiz.
>
> Cheers
>
> Paul Foxworthy
>
>
> On 14 March 2017 at 07:18, Michael Brohl  wrote:
>
> > Unfortunately I have not the time to dig deeper into this but I've got a
> > bad feeling about this and similar threads we had lately.
> >
> > Ports 8080 and 8443 are used for a long time without problems and it's a
> > common production setting if you run OFBiz behind a webserver connected
> > through AJP. I don't see any reason why we should not use port 8080 in
> > OFBiz, even it is getting more common to have everything on https.
> >
> > Even if this work is done in trunk, which is regarded as unstable, we
> > should take more care to commit consistent and working code instead of
> > using trunk as a playground and dumping place for unfinished work.
> >
> > I'm in favor to better not commit and wait until everything works as
> > expected instead of beginning work, committing and then leave it as is
> > because there is "no time to look at it right now". We can always use
> > branches for this kind of work.
> >
> > My apologies if I got this wrong but I feel uneasy with this approach.
> >
> > Best regards,
> >
> > Michael
> >
> >
> > Am 13.03.17 um 16:55 schrieb Taher Alkhateeb:
> >
> > I faced this issue again while trying some tests today, and I read your
> >> comments which refer to this as "not a bug".
> >>
> >> So my question is: if we should not use 8080 as the port, why is it
> >> enabled
> >> in the first place in OFBiz? why not disable it completely instead of
> >> confusing people.
> >>
> >> On Fri, Mar 3, 2017 at 10:49 PM, Taher Alkhateeb <
> >> slidingfilame...@gmail.com
> >>
> >>> wrote:
> >>> Okay so it seems this issue was introduced by your work based on what I
> >>> read in jira. I don't think you should apply code changes that cause
> >>> regressions like this one.
> >>>
> >>> On Mar 3, 2017 4:40 PM, "Jacques Le Roux" <
> jacques.le.r...@les7arts.com>
> >>> wrote:
> >>>
> >>> Le 02/03/2017 à 17:12, Jacques Le Roux a écrit :
> 
>  Le 02/03/2017 à 15:52, Taher Alkhateeb a écrit :
> >
> > I'm not sure who committed what, but now the automatic redirection
> from
> >> 8080 to 8443 ssl is broken. Jacques is this related to your work on
> >> port
> >> offset stuff?
> >>
> >> This is only with localhost, right?
> >>
> > If it's the case, I guess it's related to OFBIZ-9206 but I have no
> time
> > to look at it right now
> >
> > Jacques
> >
> >
> > See my comments at OFBIZ-9242
> >
>  Jacques
> 
> 
> 
> >
> >
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: +61 3 9585 6788
> Web: http://www.coherentsoftware.com.au/
> Email: i...@coherentsoftware.com.au
>

Re: port mapping 8080 to 8443 is broken

[Paul Foxworthy]

Hi all,

I agree with Taher, we should simply remove non-SSL access. The world is
rapidly moving to SSL only.

It is now close to essential that passwords should be encrypted in transit
for a serious system like OFBiz.

Cheers

Paul Foxworthy


On 14 March 2017 at 07:18, Michael Brohl  wrote:

> Unfortunately I have not the time to dig deeper into this but I've got a
> bad feeling about this and similar threads we had lately.
>
> Ports 8080 and 8443 are used for a long time without problems and it's a
> common production setting if you run OFBiz behind a webserver connected
> through AJP. I don't see any reason why we should not use port 8080 in
> OFBiz, even it is getting more common to have everything on https.
>
> Even if this work is done in trunk, which is regarded as unstable, we
> should take more care to commit consistent and working code instead of
> using trunk as a playground and dumping place for unfinished work.
>
> I'm in favor to better not commit and wait until everything works as
> expected instead of beginning work, committing and then leave it as is
> because there is "no time to look at it right now". We can always use
> branches for this kind of work.
>
> My apologies if I got this wrong but I feel uneasy with this approach.
>
> Best regards,
>
> Michael
>
>
> Am 13.03.17 um 16:55 schrieb Taher Alkhateeb:
>
> I faced this issue again while trying some tests today, and I read your
>> comments which refer to this as "not a bug".
>>
>> So my question is: if we should not use 8080 as the port, why is it
>> enabled
>> in the first place in OFBiz? why not disable it completely instead of
>> confusing people.
>>
>> On Fri, Mar 3, 2017 at 10:49 PM, Taher Alkhateeb <
>> slidingfilame...@gmail.com
>>
>>> wrote:
>>> Okay so it seems this issue was introduced by your work based on what I
>>> read in jira. I don't think you should apply code changes that cause
>>> regressions like this one.
>>>
>>> On Mar 3, 2017 4:40 PM, "Jacques Le Roux" 
>>> wrote:
>>>
>>> Le 02/03/2017 à 17:12, Jacques Le Roux a écrit :

 Le 02/03/2017 à 15:52, Taher Alkhateeb a écrit :
>
> I'm not sure who committed what, but now the automatic redirection from
>> 8080 to 8443 ssl is broken. Jacques is this related to your work on
>> port
>> offset stuff?
>>
>> This is only with localhost, right?
>>
> If it's the case, I guess it's related to OFBIZ-9206 but I have no time
> to look at it right now
>
> Jacques
>
>
> See my comments at OFBIZ-9242
>
 Jacques



>
>


-- 
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au

Re: [proposal] actions to take with plugins

[Michael Brohl]

I agree that themes are different from plugins, providing 
cross-sectional functionality and I think that we should treat them 
differently.


Regards,

Michael


Am 12.03.17 um 11:58 schrieb Jacques Le Roux:

Hi Pierre,

The question we need to answer here is "Can we consider themes as 
plugins"
At the moment I don't think so, because at least one is necessary and 
we can't really agree on which one it should be (though Flat Grey 
seems the most complete)
So I'd wait for Julien and Nicolas effort to create a basic theme on 
which all others would rely.


Then indeed it would be a good idea IMO but would need more work than 
just putting them in plugins because themes don't use the same 
mechanism than plugins to be "plugged".


Jacques

Le 12/03/2017 à 10:22, Pierre Smits a écrit :

I suggest to move theme components from ofbiz-framework to ofbiz-plugins
(or another repo).

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Mar 12, 2017 at 9:38 AM, Taher Alkhateeb 

Re: [proposal] actions to take with plugins

[Michael Brohl]

Hi Taher,

first of all, thank you very much for your ongoing hard work on this, I 
really appreciate it.


Maybe I'm a little late joining this discussion but I'd like to express 
one view point which I think is really important to ensure stable 
production settings. It came to my mind as I read about the transitional 
dependendies you mentioned in this thread.


I think we should preserve a stable way to add functionality to OFBiz in 
parallel to the more dynamic plugins mechanism. The plugin system is a 
great way to enhance OFBiz through external resources. In productive 
business systems, you'll need a stable mechanism to add your internal 
functionality the "old" way, maybe with fixed library dependencies 
relying on specified release versions, without loading it from external 
repositories etc..


I'm not really sure if this is guaranteed when we remove the hot-deploy 
mechanism and solely rely on the plugins mechanism?


Best regards,

Michael


Am 12.03.17 um 09:38 schrieb Taher Alkhateeb:

Hello everyone,

Now that nearly all plugin-API is completed in [5] and [6] and after having
various discussions about the plugins system in [1][2][3] and [4], I
propose the following action points:

- Remove the hot-deploy directory with all references to it.
- 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?

[1] https://s.apache.org/5Dv8 - separate plugins in new repo
[2] https://s.apache.org/7Y2w - hot-deploy removal
[3] https://s.apache.org/CvW3 - svn:external vs gradle
[4] https://s.apache.org/LF1o - plugin system design
[5] https://issues.apache.org/jira/browse/OFBIZ-9182 - new svn for plugins
JIRA
[6] https://issues.apache.org/jira/browse/OFBIZ-7972 - original work on
plugin system

Cheers,

Taher Alkhateeb






smime.p7s
Description: S/MIME Cryptographic Signature

Re: port mapping 8080 to 8443 is broken

[Michael Brohl]

Unfortunately I have not the time to dig deeper into this but I've got a 
bad feeling about this and similar threads we had lately.


Ports 8080 and 8443 are used for a long time without problems and it's a 
common production setting if you run OFBiz behind a webserver connected 
through AJP. I don't see any reason why we should not use port 8080 in 
OFBiz, even it is getting more common to have everything on https.


Even if this work is done in trunk, which is regarded as unstable, we 
should take more care to commit consistent and working code instead of 
using trunk as a playground and dumping place for unfinished work.


I'm in favor to better not commit and wait until everything works as 
expected instead of beginning work, committing and then leave it as is 
because there is "no time to look at it right now". We can always use 
branches for this kind of work.


My apologies if I got this wrong but I feel uneasy with this approach.

Best regards,

Michael


Am 13.03.17 um 16:55 schrieb Taher Alkhateeb:

I faced this issue again while trying some tests today, and I read your
comments which refer to this as "not a bug".

So my question is: if we should not use 8080 as the port, why is it enabled
in the first place in OFBiz? why not disable it completely instead of
confusing people.

On Fri, Mar 3, 2017 at 10:49 PM, Taher Alkhateeb 
wrote:


Le 02/03/2017 à 17:12, Jacques Le Roux a écrit :


Le 02/03/2017 à 15:52, Taher Alkhateeb a écrit :


I'm not sure who committed what, but now the automatic redirection from
8080 to 8443 ssl is broken. Jacques is this related to your work on port
offset stuff?

This is only with localhost, right?

If it's the case, I guess it's related to OFBIZ-9206 but I have no time
to look at it right now

Jacques


See my comments at OFBIZ-9242

Jacques







smime.p7s
Description: S/MIME Cryptographic Signature

Re: [proposal] actions to take with plugins

[james yong]

+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.

Re: port mapping 8080 to 8443 is broken

[Taher Alkhateeb]

I faced this issue again while trying some tests today, and I read your
comments which refer to this as "not a bug".

So my question is: if we should not use 8080 as the port, why is it enabled
in the first place in OFBiz? why not disable it completely instead of
confusing people.

On Fri, Mar 3, 2017 at 10:49 PM, Taher Alkhateeb  wrote:

> Okay so it seems this issue was introduced by your work based on what I
> read in jira. I don't think you should apply code changes that cause
> regressions like this one.
>
> On Mar 3, 2017 4:40 PM, "Jacques Le Roux" 
> wrote:
>
>> Le 02/03/2017 à 17:12, Jacques Le Roux a écrit :
>>
>>> Le 02/03/2017 à 15:52, Taher Alkhateeb a écrit :
>>>
 I'm not sure who committed what, but now the automatic redirection from
 8080 to 8443 ssl is broken. Jacques is this related to your work on port
 offset stuff?

 This is only with localhost, right?
>>> If it's the case, I guess it's related to OFBIZ-9206 but I have no time
>>> to look at it right now
>>>
>>> Jacques
>>>
>>>
>>> See my comments at OFBIZ-9242
>>
>> Jacques
>>
>>

Re: buildbot failure in on ofbiz-trunk-framework

[Jacques Le Roux]

Hi,

On every branches (lately R14 and trunk) , we randomly get false tests failures 
and errors always and only related to SOAP and XML-RPC

We can neglect them but this is annoying because we have to check the status uselessly. I have not yet for sure identified the reason even if I still 
suspect a 8080 port random pre-emption


Before bothering Infra, I'll try to have another look when I'll get a chance, 
help appreciated...

Jacques


Le 12/03/2017 à 13:45, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbiz-trunk-framework while 
building . Full details are available at:
 https://ci.apache.org/builders/ofbiz-trunk-framework/builds/15

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1786568
Blamelist: jleroux

BUILD FAILED: failed shell_2

Sincerely,
  -The Buildbot

Re: [proposal] actions to take with plugins

[Taher Alkhateeb]

Well here is exactly what you said:

"So, if a plugin changes its dependencies, nothing should change in the
main build, so no implications for ofbiz-framework build, right?"

And the answer is, no, there _are_ implications which I explained in my
previous post.

Anyway, I leave it for the community to pitch in their opinion before going
in any direction with this. There is no point in all of this work if people
are not interested in the plugin system anyway. So please everyone, feel
free to share your thoughts, we need your guidance in this!

On Mon, Mar 13, 2017 at 6:43 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I did not say it the same dependencies graph. Anyway I'll also not
> continue on this, please do as you like and we will see then.
>
> If you look at the links (and subtasks) I provided, it's a "bit" more than
> moving few XML files, notably OFBIZ-9241.  And with these links we have no
> completeness guarantee.
>
> The graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+
> and+Component+Set+Dependencies could help on where to move seed and demo
> data from ecommerce.
>
> Looking forward :)
>
> Jacques
>
>
>
> Le 13/03/2017 à 15:18, Taher Alkhateeb a écrit :
>
>> So I'm not going to reply to everything because we both made our points.
>> My
>> reply is mostly for dependencies. Ofbiz + plugins is not just a difference
>> of the plugins dependencies. No you actually get different versions of
>> libraries (up or down) and sometimes even different libraries altogether
>> from transitive dependencies. So the answer to your question is definitely
>> no, they are not the same and the dependency graph changes if you remove
>> plugins.
>>
>> Secondly, I don't think it would take weeks, not even hours to move the
>> data from ecommerce to the framework. Just move a few XML files and that's
>> it. In fact I don't mind moving the data myself while building two build
>> scripts for the two products.
>>
>> On Mar 13, 2017 4:20 PM, "Jacques Le Roux" 
>> wrote:
>>
>> 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
>>> 

Re: [proposal] actions to take with plugins

[Jacques Le Roux]

I did not say it the same dependencies graph. Anyway I'll also not continue on 
this, please do as you like and we will see then.

If you look at the links (and subtasks) I provided, it's a "bit" more than moving few XML files, notably OFBIZ-9241.  And with these links we have no 
completeness guarantee.


The graph at https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies could help on where to move seed and demo data 
from ecommerce.


Looking forward :)

Jacques


Le 13/03/2017 à 15:18, Taher Alkhateeb a écrit :

So I'm not going to reply to everything because we both made our points. My
reply is mostly for dependencies. Ofbiz + plugins is not just a difference
of the plugins dependencies. No you actually get different versions of
libraries (up or down) and sometimes even different libraries altogether
from transitive dependencies. So the answer to your question is definitely
no, they are not the same and the dependency graph changes if you remove
plugins.

Secondly, I don't think it would take weeks, not even hours to move the
data from ecommerce to the framework. Just move a few XML files and that's
it. In fact I don't mind moving the data myself while building two build
scripts for the two products.

On Mar 13, 2017 4:20 PM, "Jacques Le Roux" 
wrote:


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

Re: [SKYPE CALL] Mentoring Support for New and Existing Committers

[Jacques Le Roux]

Le 13/03/2017 à 15:01, Sharan Foga a écrit :

Hi Everyone

I'm bringing up a topic that has been raised in the past regarding committer 
mentoring. [1][2][3].
  
As  project we don't have any on-boarding process to help new committers or support existing ones. Sometimes people assume that by the time you become a committer then you should know how everything works! (and that isn't always the case. )


In the past year with the re-factoring, the framework, plugins, gradle etc we 
have a lot of changes happening and people may be a little overwhelmed about 
how they can continue to contribute. Getting feedback and sharing knowledge 
helps make people more confident in their way of working and contributions, and 
the end result is better code which is a great thing for the project.

So I would  like invite all of our committers (and also any interested 
contributors) to a Skype call to about mentoring and the support that you can 
get from our more experienced project committers. The call will be 
approximately 1 hour and will include an opportunity to ask questions.

If you'd like to attend then please add your details, location and timezone to 
the table at the bottom of the following wiki page so that I can find a 
suitable time for everyone.

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Mentors

I really think that mentoring will help empower committers more, standardise 
work and coding practices and generally improve our working relationships.

As always, feedback welcome and please don't forget to add your name if you'd 
like to attend.

Thanks
Sharan

[1]  https://s.apache.org/FzI0
[2]  https://s.apache.org/60t1
[3]  https://s.apache.org/GWtv


Thanks Sharan,

I have seen ASF members using the convenient 
https://www.timeanddate.com/worldclock/fixedform.html I think it can be reused 
here

I did not use it for a while, is it technically realistic to have a Skype 
conf-call with a large number of people?

Jacques

Re: [SKYPE CALL] Mentoring Support for New and Existing Committers

[Taher Alkhateeb]

Thank you for the initiative and detailed explanation Sharan. I've added
myself and encourage all our committers to do the same.

On Mon, Mar 13, 2017 at 5:01 PM, Sharan Foga  wrote:

> Hi Everyone
>
> I'm bringing up a topic that has been raised in the past regarding
> committer mentoring. [1][2][3].
>
> As  project we don't have any on-boarding process to help new committers
> or support existing ones. Sometimes people assume that by the time you
> become a committer then you should know how everything works! (and that
> isn't always the case. )
>
> In the past year with the re-factoring, the framework, plugins, gradle etc
> we have a lot of changes happening and people may be a little overwhelmed
> about how they can continue to contribute. Getting feedback and sharing
> knowledge helps make people more confident in their way of working and
> contributions, and the end result is better code which is a great thing for
> the project.
>
> So I would  like invite all of our committers (and also any interested
> contributors) to a Skype call to about mentoring and the support that you
> can get from our more experienced project committers. The call will be
> approximately 1 hour and will include an opportunity to ask questions.
>
> If you'd like to attend then please add your details, location and
> timezone to the table at the bottom of the following wiki page so that I
> can find a suitable time for everyone.
>
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Mentors
>
> I really think that mentoring will help empower committers more,
> standardise work and coding practices and generally improve our working
> relationships.
>
> As always, feedback welcome and please don't forget to add your name if
> you'd like to attend.
>
> Thanks
> Sharan
>
> [1]  https://s.apache.org/FzI0
> [2]  https://s.apache.org/60t1
> [3]  https://s.apache.org/GWtv
>

Re: [proposal] actions to take with plugins

[Taher Alkhateeb]

So I'm not going to reply to everything because we both made our points. My
reply is mostly for dependencies. Ofbiz + plugins is not just a difference
of the plugins dependencies. No you actually get different versions of
libraries (up or down) and sometimes even different libraries altogether
from transitive dependencies. So the answer to your question is definitely
no, they are not the same and the dependency graph changes if you remove
plugins.

Secondly, I don't think it would take weeks, not even hours to move the
data from ecommerce to the framework. Just move a few XML files and that's
it. In fact I don't mind moving the data myself while building two build
scripts for the two products.

On Mar 13, 2017 4:20 PM, "Jacques Le Roux" 
wrote:

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

[SKYPE CALL] Mentoring Support for New and Existing Committers

[Sharan Foga]

Hi Everyone

I'm bringing up a topic that has been raised in the past regarding committer 
mentoring. [1][2][3]. 
 
As  project we don't have any on-boarding process to help new committers or 
support existing ones. Sometimes people assume that by the time you become a 
committer then you should know how everything works! (and that isn't always the 
case. )

In the past year with the re-factoring, the framework, plugins, gradle etc we 
have a lot of changes happening and people may be a little overwhelmed about 
how they can continue to contribute. Getting feedback and sharing knowledge 
helps make people more confident in their way of working and contributions, and 
the end result is better code which is a great thing for the project.

So I would  like invite all of our committers (and also any interested 
contributors) to a Skype call to about mentoring and the support that you can 
get from our more experienced project committers. The call will be 
approximately 1 hour and will include an opportunity to ask questions. 

If you'd like to attend then please add your details, location and timezone to 
the table at the bottom of the following wiki page so that I can find a 
suitable time for everyone.

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Mentors

I really think that mentoring will help empower committers more, standardise 
work and coding practices and generally improve our working relationships. 

As always, feedback welcome and please don't forget to add your name if you'd 
like to attend.

Thanks
Sharan

[1]  https://s.apache.org/FzI0
[2]  https://s.apache.org/60t1
[3]  https://s.apache.org/GWtv

Re: Default theme (WAS: [proposal] actions to take with plugins)

[Jacques Le Roux]

Yes, thanks James

Jacques


Le 13/03/2017 à 02:15, james yong a écrit :

Hi all,

It would be nice to have the themes in the plugins folder. Can add prefix to
the themes for easier identification.

As themes work a little different from the components, we need to discuss in
details how plugins folder can support the themes and also the basic theme
concept.

Regards,
James Yong


Scott Gray-3 wrote

We seemingly couldn't agree on the best logo either, yet we have only one.
I think an instant run-off vote (
https://en.wikipedia.org/wiki/Instant-runoff_voting) would probably be the
most appropriate way to come to a conclusion, given the large number of
themes and relatively small number of votes we'd receive.

Regards
Scott

On 12 March 2017 at 23:58, Jacques Le Roux 
jacques.le.roux@

wrote:


Hi Pierre,

The question we need to answer here is "Can we consider themes as
plugins"
At the moment I don't think so, because at least one is necessary and we
can't really agree on which one it should be (though Flat Grey seems the
most complete)
So I'd wait for Julien and Nicolas effort to create a basic theme on
which
all others would rely.

Then indeed it would be a good idea IMO but would need more work than
just
putting them in plugins because themes don't use the same mechanism than
plugins to be "plugged".

Jacques


Le 12/03/2017 à 10:22, Pierre Smits a écrit :


I suggest to move theme components from ofbiz-framework to ofbiz-plugins
(or another repo).

Best regards,

Pierre Smits

ORRTIZ.COM http://www.orrtiz.com;
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Mar 12, 2017 at 9:38 AM, Taher Alkhateeb <


slidingfilaments@

wrote:
Hello everyone,

Now that nearly all plugin-API is completed in [5] and [6] and after
having
various discussions about the plugins system in [1][2][3] and [4], I
propose the following action points:

- Remove the hot-deploy directory with all references to it.
- 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?

[1] https://s.apache.org/5Dv8 - separate plugins in new repo
[2] https://s.apache.org/7Y2w - hot-deploy removal
[3] https://s.apache.org/CvW3 - svn:external vs gradle
[4] https://s.apache.org/LF1o - plugin system design
[5] https://issues.apache.org/jira/browse/OFBIZ-9182 - new svn for
plugins
JIRA
[6] https://issues.apache.org/jira/browse/OFBIZ-7972 - original work on
plugin system

Cheers,

Taher Alkhateeb







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

Re: [proposal] actions to take with plugins

[Jacques Le Roux]

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
<>
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. 

Re: [proposal] actions to take with plugins

[Taher Alkhateeb]

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.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
>

Re: Plugins packages?

[Jacques Le Roux]

Le 13/03/2017 à 11:01, Taher Alkhateeb a écrit :

Hi Jacques,

You're mixing multiple topics in here as you are discussing both building
and packaging.

Yes, I know I made it on purpose, I also wanted to speak about builds.


With respect to building, the discussion is already taking place in [1],
essentially I suggested to create two build scripts, one for framework and
the other for plugins. I am experimenting with buildbot scripts to see how
can this be done effectively. If you want to continue the discussion then I
suggest to continue on that thread because it has more details.

I'll continue there


As far as packaging is concerned, we don't necessarily need to stick to
semver 2, we can have ecommerce-16.11.01 for example. When we first wrote
the plugin system, I just used what already exists for all maven packages
(semver) but this is not necessarily binding.

OK, seems easier with your history

Finally, I think the discussion about packaging is still a bit early. We
still have problems that need to be solved including:
- Completing and fine-tuning the plugins API for publishing and pulling
- Setting up an ASF based maven repo for our packages

Once the above is done, we can shift our focus to agreeing on a release
strategy on how to handle all the details of release, support, life-cycle,
compatibility, dependency, etc ...

OK let's wait then

Jacques


[1] https://s.apache.org/kerD

Cheers,

Taher Alkhateeb

On Mon, Mar 13, 2017 at 12:25 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

We have now 2 lines of products: framework and plugins, do we need to
create plugins packages?

First I read in the documentation that "OFBiz plugin versions
followSemantic Versioning 2.0.0 "
How and when is it planned to release plugins packages, as a whole or
independently (on for each plugin)?
I wonder because AFAIK we continue to use the Ubuntu way for framework
version numbers.
So how will users know which plugin is usable with their framework version?

With the now available pullAllPluginsSource Gradle task we can drop the
ofbiz-framework-buildbot branch and use ofbiz-framework + ofbiz-plugins in
a sole  Builbot scripts which will build and test the whole.

I created a ofbiz-trunk-plugins Buildbot script which for now only
generates archives at https://ci.apache.org/projects/ofbiz/snapshots/
Do we need to amend it? And if so how?

Jacques

Re: [proposal] actions to take with plugins

[Jacques Le Roux]

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

Re: Plugins packages?

[Taher Alkhateeb]

Hi Jacques,

You're mixing multiple topics in here as you are discussing both building
and packaging.

With respect to building, the discussion is already taking place in [1],
essentially I suggested to create two build scripts, one for framework and
the other for plugins. I am experimenting with buildbot scripts to see how
can this be done effectively. If you want to continue the discussion then I
suggest to continue on that thread because it has more details.

As far as packaging is concerned, we don't necessarily need to stick to
semver 2, we can have ecommerce-16.11.01 for example. When we first wrote
the plugin system, I just used what already exists for all maven packages
(semver) but this is not necessarily binding.

Finally, I think the discussion about packaging is still a bit early. We
still have problems that need to be solved including:
- Completing and fine-tuning the plugins API for publishing and pulling
- Setting up an ASF based maven repo for our packages

Once the above is done, we can shift our focus to agreeing on a release
strategy on how to handle all the details of release, support, life-cycle,
compatibility, dependency, etc ...

[1] https://s.apache.org/kerD

Cheers,

Taher Alkhateeb

On Mon, Mar 13, 2017 at 12:25 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> We have now 2 lines of products: framework and plugins, do we need to
> create plugins packages?
>
> First I read in the documentation that "OFBiz plugin versions
> followSemantic Versioning 2.0.0 "
> How and when is it planned to release plugins packages, as a whole or
> independently (on for each plugin)?
> I wonder because AFAIK we continue to use the Ubuntu way for framework
> version numbers.
> So how will users know which plugin is usable with their framework version?
>
> With the now available pullAllPluginsSource Gradle task we can drop the
> ofbiz-framework-buildbot branch and use ofbiz-framework + ofbiz-plugins in
> a sole  Builbot scripts which will build and test the whole.
>
> I created a ofbiz-trunk-plugins Buildbot script which for now only
> generates archives at https://ci.apache.org/projects/ofbiz/snapshots/
> Do we need to amend it? And if so how?
>
> Jacques
>
>

Plugins packages?

[Jacques Le Roux]

Hi,

We have now 2 lines of products: framework and plugins, do we need to create 
plugins packages?

First I read in the documentation that "OFBiz plugin versions followSemantic Versioning 
2.0.0 "
How and when is it planned to release plugins packages, as a whole or 
independently (on for each plugin)?
I wonder because AFAIK we continue to use the Ubuntu way for framework version 
numbers.
So how will users know which plugin is usable with their framework version?

With the now available pullAllPluginsSource Gradle task we can drop the ofbiz-framework-buildbot branch and use ofbiz-framework + ofbiz-plugins in a 
sole  Builbot scripts which will build and test the whole.


I created a ofbiz-trunk-plugins Buildbot script which for now only generates 
archives at https://ci.apache.org/projects/ofbiz/snapshots/
Do we need to amend it? And if so how?

Jacques

Re: Default theme (WAS: [proposal] actions to take with plugins)

[Jacques Le Roux]

I agree, this is really a smart way to vote on this subject and still not too complicated like other (sometimes necessarily combined) methods which 
follow the https://en.wikipedia.org/wiki/Condorcet_method


Jacques


Le 12/03/2017 à 23:17, Scott Gray a écrit :

We seemingly couldn't agree on the best logo either, yet we have only one.
I think an instant run-off vote (
https://en.wikipedia.org/wiki/Instant-runoff_voting) would probably be the
most appropriate way to come to a conclusion, given the large number of
themes and relatively small number of votes we'd receive.

Regards
Scott

On 12 March 2017 at 23:58, Jacques Le Roux 
wrote:


Hi Pierre,

The question we need to answer here is "Can we consider themes as plugins"
At the moment I don't think so, because at least one is necessary and we
can't really agree on which one it should be (though Flat Grey seems the
most complete)
So I'd wait for Julien and Nicolas effort to create a basic theme on which
all others would rely.

Then indeed it would be a good idea IMO but would need more work than just
putting them in plugins because themes don't use the same mechanism than
plugins to be "plugged".

Jacques


Le 12/03/2017 à 10:22, Pierre Smits a écrit :


I suggest to move theme components from ofbiz-framework to ofbiz-plugins
(or another repo).

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Mar 12, 2017 at 9:38 AM, Taher Alkhateeb <
slidingfilame...@gmail.com


wrote:
Hello everyone,

Now that nearly all plugin-API is completed in [5] and [6] and after
having
various discussions about the plugins system in [1][2][3] and [4], I
propose the following action points:

- Remove the hot-deploy directory with all references to it.
- 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?

[1] https://s.apache.org/5Dv8 - separate plugins in new repo
[2] https://s.apache.org/7Y2w - hot-deploy removal
[3] https://s.apache.org/CvW3 - svn:external vs gradle
[4] https://s.apache.org/LF1o - plugin system design
[5] https://issues.apache.org/jira/browse/OFBIZ-9182 - new svn for
plugins
JIRA
[6] https://issues.apache.org/jira/browse/OFBIZ-7972 - original work on
plugin system

Cheers,

Taher Alkhateeb

Re: Render table rows from pulled data

[james yong]

Hi all,

I have created an issue for it. See
https://issues.apache.org/jira/browse/OFBIZ-9258.
Also uploaded a simple POC patch for anyone who has the time to look into
it.

Thanks,
James Yong



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Render-table-rows-from-pulled-data-tp4703142p4703215.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.