Re: [VOTE] Apache OFBiz 18.12.10

[Gil Portenseigne]

+1

Thanks,

Gil

On 27/11/2023 11:48, Jacopo Cappellato wrote:

This is the vote thread to publish "Apache OFBiz 18.12.10", tenth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.10.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.10.zip.asc: the detached signature file
* apache-ofbiz-18.12.10.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.10
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

IDEA plugin contribution

[Gil Portenseigne]

Hello,

I'm starting a new thread to get your opinion about contributing the 
OFBiz idea plugin.


This intention was already done in the past in 
https://lists.apache.org/thread/03fr40tvhkv97pqrgt4nl78w4m6ml33w , but 
no conclusion was made.


Gaëtan continued working on the plugin to provide more and more 
features, last one was about inspection of file references through 
`component://` notation.


Other features from the top of my head are :
* field completion in view and entity for declared GenericValue
* Completion in DynamicView system
* widget navigation in standard screens, and more recently in compound
* service name completion in runSync and navigation
* entity name completion in EntityQuery usage and navigation
* POC hover documentation

I totally agree with the last message from Michael in the existing 
thread, and we started to work on Apache standards in : 
https://github.com/Nereide-lab/idea-ofbiz-plugin/tree/apache-standardisation


If the idea pleases the community, i will be happy to set up the new 
repository and procedure for plugin release and so on. I will just need 
some guidance on the best way to do it.


Thanks and regards,

Gil

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Gil Portenseigne]

Hello,

Reading this i discussed with Gaëtan about somthing that could help control 
that every groovyScript reference in Screens/Forms/Services are effectively 
referencing an existing file.

As you might know, Gaëtan is contributing an IDEA plugin dedicated to OFBiz [1].
The plugin already manage component:// notation, that allow highlighting of 
missing referenced file in editor.

We discussed about inspection feature, that could detect bad references for 
groovyScript (and others) files. Whereas he is not familiar with IDEA 
inspection feature in the plugin, we could try to start building one for this 
particular effort, if that could bring more confidence in migration.

Regards,

Gil
 
[1] https://lists.apache.org/thread/03fr40tvhkv97pqrgt4nl78w4m6ml33w  

On 2023/05/02 07:16:35 Daniel Watford wrote:
> Hi Michael,
> 
> I would be concerned about our capacity to move all these groovy scripts
> and ensure correct location updates are made to the  path="..." /> elements in the controller.xml files and  engine="groovy" location="..." .../> elements in service definitions in
> both trunk and the release22.01 branch.
> 
> If we were to pursue these changes, could we add a test mode to code that
> parses service definitions and controller xml files to check that the
> groovy location (and invoked methods were relevant) are accessible? This
> means we would have some automation to help ensure changes have been
> applied correctly.
> 
> This will be a big undertaking, so I would suggest creating some
> mini-project-management similar to that done for the CodeNarc integration
> where we have a list of files that need moving and committers add their
> name to files they are actively working on. I would also request that we
> introduce rules for this mini-project such as, 'No functional changes to
> code', and 'keep Pull Requests small', etc.
> 
> To answer your original question, if we do not make the proposed changes to
> release 22.01, we will substantially degrade the ability for developers
> using Eclipse to work with OFBiz. But if we do proceed with this work, we
> will effectively need to do it twice - once for the release22.01 branch and
> once for trunk - a pretty heavy undertaking.
> 
> On balance I think it would be bad for the project to release OFBiz in a
> state which is difficult for developers/system integrators to work with, so
> we MUST ensure OFBiz is 'debuggable'.
> 
> I'll ask one more question (and then run for cover!): Rather than carry out
> this work twice.  What if we abandon the 22.01 release and instead make a
> new release branch (23.xx) soon after moving the Groovy sources?
> 
> Thanks,
> 
> Dan.
> 
> On Wed, 26 Apr 2023 at 12:23, Michael Brohl 
> wrote:
> 
> > Hi,
> >
> > I suggest to start with a new ticket to coordinate the refactoring work
> > (will you take this into your hands, Wiebke?).
> >
> > OFBIZ-10226 has another intention which will not solve the overall
> > problem Wiebke described.
> >
> > Does the community agree that we'll have to do this work?
> >
> > Even more, do we agree that it has to be done before we can ship a first
> > 22.01 release based on JDK 17?
> >
> > Best regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 25.04.23 um 18:30 schrieb Jacques Le Roux:
> > > Thanks Wiebke,
> > >
> > > I know that for a while (https://s.apache.org/kewrn) but was
> > > desperately trying to avoid what you propose. It's indeed the right
> > > solution.
> > >
> > > So I think we can go on with OFBIZ-10226. At the bottom there is a
> > > link to a related discussion with some opinions from then. Or do you
> > > prefer to start anew for the sake of clarity?
> > >
> > > Thanks again for your work, I was not aware of this Groovy page. It
> > > definitely confirms what Mathieu said then.
> > >
> > > Jacques
> > >
> > > Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit :
> > >> Hi everyone,
> > >>
> > >> I did a bit of research regarding the groovy debugging.
> > >> After some research I found this:
> > >>
> > >> “The Java Platform Module System requires that classes in distinct
> > >> modules have distinct package names. Groovy has its own "modules" but
> > >> these haven’t historically been structured according to the above
> > >> requirement. For this reason, Groovy 2.x and 3.0 should be added to
> > >> the classpath not module path when using JDK9+. This places Groovy’s
> > >> classes into the unnamed module where the split package naming
> > >> requirement is not enforced.“
> > >>
> > http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages
> > >>
> > >>
> > >> For testing I used the service "sendEmailDated" in
> > >> CommunicationEventServices.groovy. I can confirm the described
> > >> behavior of Jacques, without a package declaration the service does
> > >> not stop at my breakpoint. If I add the package declaration for the
> > >> class, the service stops at my breakpoint.
> > >>
> > >> From my point of view it 

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Gil Portenseigne]

+1

Thanks,

Gil

Le 03/05/2023 à 16:39, Michael Brohl a écrit :

+1 from my side.

Best regards,

Michael


Am 03.05.23 um 09:45 schrieb Jacopo Cappellato:

On Tue, May 2, 2023 at 9:17 AM Daniel Watford  wrote:
[...]
I'll ask one more question (and then run for cover!): Rather than 
carry out
this work twice.  What if we abandon the 22.01 release and instead 
make a

new release branch (23.xx) soon after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"

[Gil Portenseigne]

Hello I got a quick look about it, having two separate class means 
having two distinct groovy DSL and need lot of modification that IMO are 
not worth the complexity for this subject.


I now only wonder, is it that bad too keep that one exception (about 
untyped return) for GroovyBaseScript::success ?


Gil

Le 26/04/2023 à 09:49, Gil Portenseigne a écrit :

Hello,

I like the idea that the developer do not have to sync about which 
method to use.


If I understand well what Michael envision, i.e. to use for event a 
new GroovyBaseEvent class, and for services/scripts a GroovyBaseScript 
class, that both extends a common class for the common code, should be 
one way to allow this usage.


But I don't know about IDE integration behavior of such a solution...

Do you think that is worth a look ?

I will just add that there is a chance that project implementation are 
using groovy script as the event target (I know some ;) )


Thanks,

Gil

Le 20/04/2023 à 17:13, Michael Brohl a écrit :
To have it even more clear, I would separate logic for events and 
services.


The GroovyBaseScript in the service engine package should only be 
used for services and there should be another one for events, if 
really needed. Mixing both together is bad practice IMO. There seem 
to be only 7 controller entries using a groovy script as the event 
target.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 20.04.23 um 16:49 schrieb Jacques Le Roux:

Hi Daniel,

I dont think there is a knowledge about methods being both services 
and events. I think there are not (much?) such cases.
Being acquainted to OFBiz logs I did not check the trunk demo log 
content (now in Docker);
so I wonder if there are such other cases than 
CommunicationEventServices::sendEmail  (colon notation is available 
in Groovy 3)

that bots and demo uses could have generated.

I tend to agree about having GroovyBaseScript::success deprecated 
and replaced with methods GroovyBaseScript::scriptSuccess 
GroovyBaseScript::serviceSuccess and GroovyCaseScript::eventSuccess


I'm not yet acquainted with Codernarc rules, but the changes in 
GroovyBaseScript seem straightforward.
And (hopefully) this should not be a big deal to change accordingly 
in scripts methods with the help of Codenarc, right ?


My 2 cts

Jacques

Le 19/04/2023 à 18:37, Daniel Watford a écrit :

Hello,

In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the 
code was

called.

The untyped nature of Groovy had allowed a certain degree of 
flexibility in

code that GroovyBaseScript#success could be relied upon to prepare a
response appropriate to the calling conventions of an event handler or
service implementation. However over the last decade, possibly 
driven by
increased use of linters/static analysers, we have seen a push back 
towards

explicit typing, particularly on public methods.

If we continue to adopt the guidance from static analysers and apply
explicit typing to public methods in our groovy code, then we need 
to avoid

the black box approach of GroovyBaseScript#success figuring out what
calling conventions (i.e. event or service) are in play and, 
instead, a
groovy method should be intentionally written as either a service 
or event

handler.

If we have cases where a groovy method is used to provide 
implementations
for both a service and an event handler, then we can employ a thin 
adapter
layer to convert the result type between the two calling 
conventions. Do we

know if many such cases currently exist in OFBiz?

My preference would be to see GroovyBaseScript#success deprecated and
replaced with methods along the lines of 
GroovyBaseScript#scriptSuccess and
GroovyCaseScript#eventSuccess that return a Map and 
String

respectively.

Thanks,

Dan.

On Wed, 19 Apr 2023 at 16:44, Jacques Le 
Roux

wrote:


Hi All,

At OFBIZ-12801, we had a discussion with Daniel and Gil about the
described issue (last comments there)
We are unsure of the best solution, so this thread to discuss and 
decide.


As Gil reported, Jacopo's comment of the related commit* contains

 <>

What would be your opinion about a best solution?

TIA

Jacques

*http://svn.apache.org/viewvc?view=revision=1298908

Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup

[Gil Portenseigne]

+1

Gil

Le 26/04/2023 à 16:36, Jacques Le Roux a écrit :

+1

Jacques

Le 26/04/2023 à 16:01, Jacopo Cappellato a écrit :

+1

Jacopo

On Wed, Apr 26, 2023 at 3:11 PM Michael Brohl 
 wrote:

Hi everyone,

any objections against merging those pr's for framework/plugins in
trunk/release22.01?

I think it would be good to test the changes on the demo servers as 
well

to detect possible runtime problems caused by the changed dependencies.

If there are no objections, I would like to merge the changes tomorrow.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 21.04.23 um 14:54 schrieb Michael Brohl (Jira):
  [ 
https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714986#comment-17714986 
]


Michael Brohl commented on OFBIZ-12808:
---

Fixes for framework / plugins for trunk and release22.01 are now in 
the pull requests.


To test, the corresponding pr's for framework and plugins have to 
be checked out respectively.



Eclipse build problems and proper dependency setup
--

  Key: OFBIZ-12808
  URL: 
https://issues.apache.org/jira/browse/OFBIZ-12808

  Project: OFBiz
   Issue Type: Bug
   Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS
 Affects Versions: 22.01.01, Upcoming Branch
 Reporter: Michael Brohl
 Assignee: Michael Brohl
 Priority: Major
  Fix For: 22.01.01, Upcoming Branch


Due to improper dependency configurations and the JPMS (Java 
Plattform Module System) which was introduced to Java since 
version 9, the Eclipse build and running/debugging is not working 
with JDK 17 (trunk and release22.01).
The reason is that there are dependencies to libraries which are 
also shipped with the JDK which causes a conflict leading to 
ignore those packages/classes in the build.

We have a working solution for this.


--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"

[Gil Portenseigne]

Hello,

I like the idea that the developer do not have to sync about which 
method to use.


If I understand well what Michael envision, i.e. to use for event a new 
GroovyBaseEvent class, and for services/scripts a GroovyBaseScript 
class, that both extends a common class for the common code, should be 
one way to allow this usage.


But I don't know about IDE integration behavior of such a solution...

Do you think that is worth a look ?

I will just add that there is a chance that project implementation are 
using groovy script as the event target (I know some ;) )


Thanks,

Gil

Le 20/04/2023 à 17:13, Michael Brohl a écrit :
To have it even more clear, I would separate logic for events and 
services.


The GroovyBaseScript in the service engine package should only be used 
for services and there should be another one for events, if really 
needed. Mixing both together is bad practice IMO. There seem to be 
only 7 controller entries using a groovy script as the event target.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 20.04.23 um 16:49 schrieb Jacques Le Roux:

Hi Daniel,

I dont think there is a knowledge about methods being both services 
and events. I think there are not (much?) such cases.
Being acquainted to OFBiz logs I did not check the trunk demo log 
content (now in Docker);
so I wonder if there are such other cases than 
CommunicationEventServices::sendEmail  (colon notation is available 
in Groovy 3)

that bots and demo uses could have generated.

I tend to agree about having GroovyBaseScript::success deprecated and 
replaced with methods GroovyBaseScript::scriptSuccess 
GroovyBaseScript::serviceSuccess and GroovyCaseScript::eventSuccess


I'm not yet acquainted with Codernarc rules, but the changes in 
GroovyBaseScript seem straightforward.
And (hopefully) this should not be a big deal to change accordingly 
in scripts methods with the help of Codenarc, right ?


My 2 cts

Jacques

Le 19/04/2023 à 18:37, Daniel Watford a écrit :

Hello,

In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the 
code was

called.

The untyped nature of Groovy had allowed a certain degree of 
flexibility in

code that GroovyBaseScript#success could be relied upon to prepare a
response appropriate to the calling conventions of an event handler or
service implementation. However over the last decade, possibly 
driven by
increased use of linters/static analysers, we have seen a push back 
towards

explicit typing, particularly on public methods.

If we continue to adopt the guidance from static analysers and apply
explicit typing to public methods in our groovy code, then we need 
to avoid

the black box approach of GroovyBaseScript#success figuring out what
calling conventions (i.e. event or service) are in play and, instead, a
groovy method should be intentionally written as either a service or 
event

handler.

If we have cases where a groovy method is used to provide 
implementations
for both a service and an event handler, then we can employ a thin 
adapter
layer to convert the result type between the two calling 
conventions. Do we

know if many such cases currently exist in OFBiz?

My preference would be to see GroovyBaseScript#success deprecated and
replaced with methods along the lines of 
GroovyBaseScript#scriptSuccess and
GroovyCaseScript#eventSuccess that return a Map and 
String

respectively.

Thanks,

Dan.

On Wed, 19 Apr 2023 at 16:44, Jacques Le 
Roux

wrote:


Hi All,

At OFBIZ-12801, we had a discussion with Daniel and Gil about the
described issue (last comments there)
We are unsure of the best solution, so this thread to discuss and 
decide.


As Gil reported, Jacopo's comment of the related commit* contains

 <>

What would be your opinion about a best solution?

TIA

Jacques

*http://svn.apache.org/viewvc?view=revision=1298908

Re: Codenarc integration process

[Gil Portenseigne]

Hello !

I just squashed and committed the pull request, I would like to thank 
you again for the review work and animation !


I failed the commit message due to the pull request feature i was not 
familiar about...


I am not aware of "force push" policy in trunk that could allow me to 
fix that, i wanted to ask if it is allowed ?


Gil


Le 27/03/2023 à 16:46, Jacques Le Roux a écrit :

Hi Guys,

For those who have used a non "PASSED" lozenge in wiki and resolved a 
related conversation in GH please update the status in wiki


TIA

Jacques

Le 28/01/2023 à 11:51, Gil Portenseigne a écrit :

Oh sorry indeed i overview the review approach section.

The table is nice, thanks Dan !

28 janv. 2023 09:37:50 Daniel Watford :


Hi Gil,

I don't think a checklist is quite enough, assuming we want to track 
the

status of each file reviewed.

 From the review approach section:


    - If in the reviewers opinion a file change will not change OFBiz
    behaviour in any way they should mark the corresponding entry in 
the table

    below as PASSED.
    - If the reviewer identifies an issue with a changed file, then 
they
    should add a comment in the PR on GitHub AND mark the 
corresponding entry

    in the table below as WORK NEEDED.
    - If the reviewer is unsure how to classify a changed file they 
should

    mark the corresponding entry in the table below as UNSURE.
    - In each of the above cases, the reviewer should add their name 
against

    the entry in the table below.

The checklist doesn't give us the opportunity to see what files need 
some

additional help.

I'm sure there must be some way of getting Confluence to produce a 
table
from a list - I just don't seem to have found it yet! I'll play 
around with

Confluence a bit more.

But as mentioned before, perhaps I am making too much out of 
tracking this

review.

Thanks,

Dan.


On Fri, 27 Jan 2023 at 17:05, gil.portenseigne 


wrote:


I got to leave, but i generated in confluence a list of check, is that
good enough ?

Gil
On 27/01/23 05:41, gil.portenseigne wrote:
Hello, indeed, that will generate much spam, i did some before 
reading

your answer.

I'll have a look for conluence.

Gil


On 27/01/23 04:14, Daniel Watford wrote:

Hi Gill and Jacques,

I don't think we should add comments to the PR to track the files 
that

we

have reviewed as I think each comment will appear separately in the

PR's

conversation view.

However, with such a large PR where we hope to get several reviewers
involved I think we do need a mechanism to track reviewed files.

I created a page here - Codenarc integration review tracker - OFBiz

Project

Open Wiki - Apache Software Foundation
<
https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker 


-
suggesting an approach.

If the approach is acceptable then all reviewers should be able to

update

the page as we go.

I'm stuck with finding a nice way to generate a table listing all 
the
changed files and the review status of each file. I have included 
the

commands to produce the list of files and shown some examples of how

to add

a header, but my attempts to turn that into something useful on a
confluence page have not been fruitful.

So two questions.
- Is it worth coming up with a page/table to track this PR or am 
I just
creating unnecessary admin work when we could use comments in the 
PR?

- Can anyone create a table in Confluence that we could use to track

the

review effort?

Thanks,

Dan.


On Fri, 27 Jan 2023 at 15:27, gil.portenseigne <

gil.portensei...@nereide.fr>

wrote:


Oops, i did a fixup commit with push force that remove all comments

in

the pull request... Will not do that again.

I fixed the detected typo.

gil
On 27/01/23 02:56, Jacques Le Roux wrote:

…

the pull

…

checkbox if a

…

request,

…

to the

same conclusion.

…

Could

be easy if it's the same unique words in every file.

…

concern

one

…

but it

…

file, to

let

…

"Review
changes" button allows you to comment, approve or request 
changes on

this

file.

…

can

mark an

…

reviewers

can skip

…


--
Daniel Watford




--
Daniel Watford

Re: [VOTE] Apache OFBiz 18.12.07

[Gil Portenseigne]

+1

Everything is fine from my side !

Thanks

Gil

Le 03/04/2023 à 09:47, Jacopo Cappellato a écrit :

This is the vote thread to publish "Apache OFBiz 18.12.07", seventh
and probably final release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.07.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.07.zip.asc: the detached signature file
* apache-ofbiz-18.12.07.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.07
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: Codenarc integration process

[Gil Portenseigne]

Oh sorry indeed i overview the review approach section.

The table is nice, thanks Dan !

28 janv. 2023 09:37:50 Daniel Watford :

> Hi Gil,
> 
> I don't think a checklist is quite enough, assuming we want to track the
> status of each file reviewed.
> 
> From the review approach section:
> 
> 
>    - If in the reviewers opinion a file change will not change OFBiz
>    behaviour in any way they should mark the corresponding entry in the table
>    below as PASSED.
>    - If the reviewer identifies an issue with a changed file, then they
>    should add a comment in the PR on GitHub AND mark the corresponding entry
>    in the table below as WORK NEEDED.
>    - If the reviewer is unsure how to classify a changed file they should
>    mark the corresponding entry in the table below as UNSURE.
>    - In each of the above cases, the reviewer should add their name against
>    the entry in the table below.
> 
> The checklist doesn't give us the opportunity to see what files need some
> additional help.
> 
> I'm sure there must be some way of getting Confluence to produce a table
> from a list - I just don't seem to have found it yet! I'll play around with
> Confluence a bit more.
> 
> But as mentioned before, perhaps I am making too much out of tracking this
> review.
> 
> Thanks,
> 
> Dan.
> 
> 
> On Fri, 27 Jan 2023 at 17:05, gil.portenseigne 
> wrote:
> 
>> I got to leave, but i generated in confluence a list of check, is that
>> good enough ?
>> 
>> Gil
>> On 27/01/23 05:41, gil.portenseigne wrote:
>>> Hello, indeed, that will generate much spam, i did some before reading
>>> your answer.
>>> 
>>> I'll have a look for conluence.
>>> 
>>> Gil
>>> 
>>> 
>>> On 27/01/23 04:14, Daniel Watford wrote:
 Hi Gill and Jacques,
 
 I don't think we should add comments to the PR to track the files that
>> we
 have reviewed as I think each comment will appear separately in the
>> PR's
 conversation view.
 
 However, with such a large PR where we hope to get several reviewers
 involved I think we do need a mechanism to track reviewed files.
 
 I created a page here - Codenarc integration review tracker - OFBiz
>> Project
 Open Wiki - Apache Software Foundation
 <
>> https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker
>>> 
 -
 suggesting an approach.
 
 If the approach is acceptable then all reviewers should be able to
>> update
 the page as we go.
 
 I'm stuck with finding a nice way to generate a table listing all the
 changed files and the review status of each file. I have included the
 commands to produce the list of files and shown some examples of how
>> to add
 a header, but my attempts to turn that into something useful on a
 confluence page have not been fruitful.
 
 So two questions.
 - Is it worth coming up with a page/table to track this PR or am I just
 creating unnecessary admin work when we could use comments in the PR?
 - Can anyone create a table in Confluence that we could use to track
>> the
 review effort?
 
 Thanks,
 
 Dan.
 
 
 On Fri, 27 Jan 2023 at 15:27, gil.portenseigne <
>> gil.portensei...@nereide.fr>
 wrote:
 
> Oops, i did a fixup commit with push force that remove all comments
>> in
> the pull request... Will not do that again.
> 
> I fixed the detected typo.
> 
> gil
> On 27/01/23 02:56, Jacques Le Roux wrote:
>> …
>> the pull
>> …
>> checkbox if a
>> …
>> request,
>> …
>> to the
> same conclusion.
>> …
>> Could
> be easy if it's the same unique words in every file.
>> …
>> concern
> one
>> …
>> but it
>> …
>> file, to
> let
>> …
>> "Review
> changes" button allows you to comment, approve or request changes on
>> this
> file.
>> …
>> can
> mark an
>> …
>> reviewers
> can skip
>> …
> 
 
 
 --
 Daniel Watford
>> 
>> 
>> 
> 
> -- 
> Daniel Watford

Re: Codenarc integration process

[Gil Portenseigne]

Haha, i understand, I will continue reviewing and testing while others can 
review also,

Thanks Jacques

21 janv. 2023 10:43:08 Jacques Le Roux :

> Thanks Gil,
> 
> OK, seems good to me to avoid gstring indeed.
> 
> I had a glance, I was too optimistic. I'll not review the 455(!) files and 
> will rather call our CTR mode as I'm much confident in your (big) work :)
> 
> +1 from my side
> 
> Jacques
> 
> 
> Le 21/01/2023 à 09:57, Gil Portenseigne a écrit :
>> Yes, it is considered best practice to avoid gstring usage when not needed.
>> 
>> Like for others, we can decide to not apply this rule.
>> 
>> The detailed rule from codenarc documentation :
>> 
>> 
>> *UnnecessaryGString** Rule*
>> 
>> /Since //CodeNarc// 0.13/
>> 
>> String objects should be created with single quotes, and GString objects 
>> created with double quotes. Creating normal String objects with double 
>> quotes is confusing to readers.
>> 
>> Gil
>> 
>> 21 janv. 2023 09:41:39 Jacques Le Roux :
>> 
>>> Hi Gil,
>>> 
>>> So we need to use single quotes instead of double quotes now in Groovy?
>>> 
>>> Thanks
>>> 
>>> Jacques
>>> 
>>> Le 20/01/2023 à 17:01, Jacques Le Roux a écrit :
>>>> Thank you very much Gil,
>>>> 
>>>> +1 for a big squash... after some reviews...
>>>> 
>>>> Jacques
>>>> 
>>>> Le 20/01/2023 à 15:53, gil.portenseigne a écrit :
>>>>> Hello Devs,
>>>>> 
>>>>> That is with pleasure, that I managed to integrate into OFBiz framework
>>>>> (no plugins yet) Codenarc, and that the build is successful under java
>>>>> 17.
>>>>> 
>>>>> https://github.com/apache/ofbiz-framework/pull/517#issuecomment-1398487745
>>>>> 
>>>>> I tried to isolate rule fixes in separated commits, there are a lot (133
>>>>> commits), with some redundancy. But rebasing is not easy since files are
>>>>> modified by several rule fixing.
>>>>> 
>>>>> Integration and unit test are ok. I did some manual testing when I got
>>>>> some doubt, but it could be nice to have some more eyes on the subject.
>>>>> 
>>>>> After reviewing process, and if everything is fine, should we commit
>>>>> that as a big squash ?
>>>>> 
>>>>> WDYT
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Gil

Re: Codenarc integration process

[Gil Portenseigne]

Yes, it is considered best practice to avoid gstring usage when not needed.

Like for others, we can decide to not apply this rule.

The detailed rule from codenarc documentation :


*UnnecessaryGString** Rule*

/Since //CodeNarc// 0.13/

String objects should be created with single quotes, and GString objects 
created with double quotes. Creating normal String objects with double quotes 
is confusing to readers.

Gil

21 janv. 2023 09:41:39 Jacques Le Roux :

> Hi Gil,
> 
> So we need to use single quotes instead of double quotes now in Groovy?
> 
> Thanks
> 
> Jacques
> 
> Le 20/01/2023 à 17:01, Jacques Le Roux a écrit :
>> Thank you very much Gil,
>> 
>> +1 for a big squash... after some reviews...
>> 
>> Jacques
>> 
>> Le 20/01/2023 à 15:53, gil.portenseigne a écrit :
>>> Hello Devs,
>>> 
>>> That is with pleasure, that I managed to integrate into OFBiz framework
>>> (no plugins yet) Codenarc, and that the build is successful under java
>>> 17.
>>> 
>>> https://github.com/apache/ofbiz-framework/pull/517#issuecomment-1398487745
>>> 
>>> I tried to isolate rule fixes in separated commits, there are a lot (133
>>> commits), with some redundancy. But rebasing is not easy since files are
>>> modified by several rule fixing.
>>> 
>>> Integration and unit test are ok. I did some manual testing when I got
>>> some doubt, but it could be nice to have some more eyes on the subject.
>>> 
>>> After reviewing process, and if everything is fine, should we commit
>>> that as a big squash ?
>>> 
>>> WDYT
>>> 
>>> Regards,
>>> 
>>> Gil

Re: Welcome to Leila Mekika as new committer

[Gil Portenseigne]

Congratulations Leila ! Bravo !

Gil

On 04/10/2022 09:30, MLeila wrote:

Hello all,

Thanks for your welcome!
I am glad to join the team and be able to contribute more actively on 
the project


Regards,
Leila

Le 04/10/2022 à 07:38, Devanshu Vyas a écrit :

Many congratulations and welcome aboard Leila!!

Thanks & Regards,
Devanshu Vyas.


On Mon, Oct 3, 2022 at 6:27 PM Nicolas Malin 
wrote:


The OFBiz PMC has invited Leila Mekika as new
committer and we are glad to announce that she have accepted the
nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Hello Jacques, 

Thanks for your feedback, I'll go with that.

Gil
On Mon, Jul 25, 2022 at 10:08:20AM +0200, Jacques Le Roux wrote:
> Hi Gil,
> 
> Here are my preferences inline...
> 
> Le 20/07/2022 à 23:49, Gil Portenseigne a écrit :
> > Thanks All for the feedback.
> > 
> > I continue in my spare time and did analyse some rule that I propose to 
> > disable.
> > Here are my thought :
> > 
> > * DuplicateStringLiteral :  Not Adapted to OFBiz : String Literal are 
> > massively entityName. No need to make them constants.
> 
> +1
> 
> > * LineLength : Can be configured : default 120, with 140 configured there 
> > are 654 fix needed, 445 fixes to 150 length configuration (same as Java 
> > checkstyle). IMO I prefer default config, but we could go with the same as 
> > checkstyle config ?
> 150
> > * UnnecessaryGetter : Lot of java OFBiz code use getXXX. Applying this 
> > rule, will lead massive java changes. I prefer to ignore.
> +1
> >   * NoDef : We need to agree to not use def in variable declaration or 
> > method return type (implies lots of fix). I think that is better to have 
> > type defined.
> +1
> > * MethodReturnTypeRequired : same as above
> +1
> > * UnnecessaryReturnKeyword : Not sure that is is wanted, in our dev team it 
> > can be disturbing, *WDYT* ?
> Better to have return, clearer
> > * UnnecessaryObjectReferences : with method usage to reduce code. 
> > Context.with { toto = « toto »}, I was unaware of this, i'd like to keep it 
> > if possible.
> +1
> > * CompileStatic : I propose to ignore this rule, not needed IMO
> +1
> >   IfStatementBraces : Do we allow one lined if without braces ? I prefer 
> > not, but that seems convenient some times, This rule applies also on 
> > multiline, and for me we should keep it. Since it is not configurable for 
> > oneline, i am into keeping it.
> +1
> > * DuplicateNumberLiteral : Same as String Literal
> +1
> > * UnnecessarySetter : Same as UnnecessaryGetter
> 
> +1
> 
> Thanks
> 
> Jacques
> 
> > 
> > Thanks,
> > 
> > Gil
> > 
> > On 2022/07/04 15:24:43 Gil Portenseigne wrote:
> > > Hello Devs,
> > > 
> > > I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
> > > 
> > > For those who are not aware, Codenarc is an analysis tools for Groovy
> > > for defects, bad practices, inconsistencies, style issues and more.
> > > 
> > > For this purpose we need to agree about the ruleset to put in place.
> > > 
> > > I took as a basis the ruleset :
> > > https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
> > > 
> > > And started to fix some in 
> > > https://github.com/apache/ofbiz-framework/pull/517
> > > 
> > > Before doing the complete work, a first rule made me wonder if that is a
> > > choice that we will be doing as a community :
> > > 
> > > IfStatementBraces - Use braces for if statements, even for a single 
> > > statement.
> > > 
> > > There are 234 occurrences in the project, and I guess that some opinions
> > > might diverge on this subject.
> > > 
> > > Moreover, some rules needs lots of fixes in the project (those with more
> > > than 200 occurrences) :
> > > 
> > > ++-+
> > > | Number of  | Rule name and details  
> > >  |
> > > | occurrence |
> > >  |
> > > ++=+
> > > | 9883   | UnnecessaryGString  - String objects should be created 
> > > with single  |
> > > ||  quotes, and GString  objects created with double quotes. 
> > > Creating  |
> > > ||  normal String objects with  double quotes is confusing to 
> > > readers. |
> > > ++-+
> > > | 4569   | DuplicateStringLiteral  - Code containing duplicate String 
> > > literals |
> > > ||  can usually be improved by  declaring the String as a 
> > > constant |
> > > || field. The ignoreStrings property ()  can optionally 
> > > specify a  |
> > > || comma-separated list of Strings to ignore. 
> > >  |
> 

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Thanks All for the feedback.

I continue in my spare time and did analyse some rule that I propose to disable.
Here are my thought : 

* DuplicateStringLiteral :  Not Adapted to OFBiz : String Literal are 
massively entityName. No need to make them constants.
* LineLength : Can be configured : default 120, with 140 configured there are 
654 fix needed, 445 fixes to 150 length configuration (same as Java 
checkstyle). IMO I prefer default config, but we could go with the same as 
checkstyle config ?
* UnnecessaryGetter : Lot of java OFBiz code use getXXX. Applying this rule, 
will lead massive java changes. I prefer to ignore.
 * NoDef : We need to agree to not use def in variable declaration or method 
return type (implies lots of fix). I think that is better to have type defined.
* MethodReturnTypeRequired : same as above
* UnnecessaryReturnKeyword : Not sure that is is wanted, in our dev team it can 
be disturbing, *WDYT* ? 
* UnnecessaryObjectReferences : with method usage to reduce code. Context.with 
{ toto = « toto »}, I was unaware of this, i'd like to keep it if possible.
* CompileStatic : I propose to ignore this rule, not needed IMO
 IfStatementBraces : Do we allow one lined if without braces ? I prefer not, 
but that seems convenient some times, This rule applies also on multiline, and 
for me we should keep it. Since it is not configurable for oneline, i am into 
keeping it.
* DuplicateNumberLiteral : Same as String Literal
* UnnecessarySetter : Same as UnnecessaryGetter

Thanks,

Gil

On 2022/07/04 15:24:43 Gil Portenseigne wrote:
> Hello Devs,
> 
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
> 
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practices, inconsistencies, style issues and more.
> 
> For this purpose we need to agree about the ruleset to put in place.
> 
> I took as a basis the ruleset : 
> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
> 
> And started to fix some in https://github.com/apache/ofbiz-framework/pull/517
> 
> Before doing the complete work, a first rule made me wonder if that is a
> choice that we will be doing as a community : 
> 
> IfStatementBraces - Use braces for if statements, even for a single statement.
> 
> There are 234 occurrences in the project, and I guess that some opinions
> might diverge on this subject.
> 
> Moreover, some rules needs lots of fixes in the project (those with more
> than 200 occurrences) :
> 
> ++-+
> | Number of  | Rule name and details  
>  |
> | occurrence |
>  |
> ++=+
> | 9883   | UnnecessaryGString  - String objects should be created with 
> single  |
> ||  quotes, and GString  objects created with double quotes. 
> Creating  |
> ||  normal String objects with  double quotes is confusing to 
> readers. |
> ++-+
> | 4569   | DuplicateStringLiteral  - Code containing duplicate String 
> literals |
> ||  can usually be improved by  declaring the String as a 
> constant |
> || field. The ignoreStrings property ()  can optionally specify a 
>  |
> || comma-separated list of Strings to ignore. 
>  |
> ++-+
> | 4209   | SpaceAroundMapEntryColon  - Check for configured formatting of 
>  |
> || whitespace around colons for  literal Map entries. 
>  |
> || The characterBeforeColonRegex and  characterAfterColonRegex
>  |
> || properties specify a regular expression that  must match the   
>  |
> || character before/after the colon.  
>  |
> ++-+
> | 1448   | LineLength  - Checks the maximum length for each line of   
>  |
> || source code. It checks for  number of characters, so lines 
>  |
> ||  that include tabs may appear longer than  the allowed number  
>  |
> ||  when viewing the file. The maximum line length can  be
>  |
> || configured by setting the length property, which defaults to 
> 120.   |
> ++-+
> | 885| UnnecessaryGetter  - Checks f

Re: Codenarc integration, rules to use.

[gil . portenseigne]

Hello Michael,

Sure, you can see in the pull request I started to separate the commit, a 
commit for one rule fix.

The last one is a big one :)

https://github.com/apache/ofbiz-framework/pull/517/commits/384894dfafce5e7261e2564b40261650deda7a22

Regards,

Gil


Le Dimanche, Juillet 10, 2022 16:02 CEST, Michael Brohl 
 a écrit:
 Hi Gil,

I was on vacation so a bit late: I fully agree to apply these rules.

We should, however, encourage contributors to apply those changes in
separate commits which ONLY contain those changes and not mix it up with
other changes to make review work easier.

Thanks for the initiative,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 04.07.22 um 17:24 schrieb Gil Portenseigne:
> Hello Devs,
>
> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>
> For those who are not aware, Codenarc is an analysis tools for Groovy
> for defects, bad practices, inconsistencies, style issues and more.
>
> For this purpose we need to agree about the ruleset to put in place.
>
> I took as a basis the ruleset :
> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
>
> And started to fix some in https://github.com/apache/ofbiz-framework/pull/517
>
> Before doing the complete work, a first rule made me wonder if that is a
> choice that we will be doing as a community :
>
> IfStatementBraces - Use braces for if statements, even for a single statement.
>
> There are 234 occurrences in the project, and I guess that some opinions
> might diverge on this subject.
>
> Moreover, some rules needs lots of fixes in the project (those with more
> than 200 occurrences) :
>
> ++-+
> | Number of | Rule name and details |
> | occurrence | |
> ++=+
> | 9883 | UnnecessaryGString - String objects should be created with single |
> | | quotes, and GString objects created with double quotes. Creating |
> | | normal String objects with double quotes is confusing to readers. |
> ++-+
> | 4569 | DuplicateStringLiteral - Code containing duplicate String literals |
> | | can usually be improved by declaring the String as a constant |
> | | field. The ignoreStrings property () can optionally specify a |
> | | comma-separated list of Strings to ignore. |
> ++-+
> | 4209 | SpaceAroundMapEntryColon - Check for configured formatting of |
> | | whitespace around colons for literal Map entries. |
> | | The characterBeforeColonRegex and characterAfterColonRegex |
> | | properties specify a regular expression that must match the |
> | | character before/after the colon. |
> ++-+
> | 1448 | LineLength - Checks the maximum length for each line of |
> | | source code. It checks for number of characters, so lines |
> | | that include tabs may appear longer than the allowed number |
> | | when viewing the file. The maximum line length can be |
> | | configured by setting the length property, which defaults to 120. |
> ++-+
> | 885 | UnnecessaryGetter - Checks for explicit calls to getter/accessor |
> | | methods which can, for the most part, be replaced by property |
> | | access. A getter is defined as a method call that matches |
> | | get[A-Z] but not getClass() or get[A-Z][A-Z] such as getURL(). |
> | | Getters do not take method arguments. The ignoreMethodNames |
> | | property (null) can specify method names that should be ignored |
> | | , optionally containing wildcard characters ('*' or '?'). |
> ++-+
> | 601 | NoDef - def should not be used. You should replace it with |
> | | concrete type. |
> ++-+
> | 485 | MethodReturnTypeRequired - Checks that method return types |
> | | are not dynamic, that is they are explicitly stated and |
> | | different than def. |
> ++-+
> | 484 | Indentation - Check indentation for class and method |
> | | declarations, and initial statements. |
> ++-+
> | 482 | UnnecessaryReturnKeyword - In Groovy, the return keyword |
> | | is often optional. If a statement is the last line in a |
> | | method or closure then you do not need to have the return keyword. |
> +--

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Forgot the ref https://github.com/CodeNarc/CodeNarc/issues/331

Le 12 juillet 2022 21:11:13 GMT+02:00, Gil Portenseigne 
 a écrit :
>Hello, 
>
>I agree with you, i find out here [1] that it is customisable.
>
>So we can agree upon this variation of the rule !
>
>I have not tested yet, will see in the near future 
>
>Thanks
>
>Gil
>
>Le 11 juillet 2022 17:57:45 GMT+02:00, Scott Gray  a écrit :
>>+1 in general from me although some of those rules might be challenging to
>>resolve.  For example DuplicateStringLiteral could be referring to an
>>entity name being used in delegator queries more than once, I don't think
>>we'd prefer to see that extracted to a constant.
>>
>>SpaceAroundMapEntryColon I'm not so sure about, my preference for
>>legibility has always been [someKey: someValue].  I find
>>[someKey:someValue] a bit too condensed and harder to differentiate key
>>from value.
>>
>>Regards
>>Scott
>>
>>On Mon, 4 Jul 2022 at 16:25, Gil Portenseigne 
>>wrote:
>>
>>> Hello Devs,
>>>
>>> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>>>
>>> For those who are not aware, Codenarc is an analysis tools for Groovy
>>> for defects, bad practices, inconsistencies, style issues and more.
>>>
>>> For this purpose we need to agree about the ruleset to put in place.
>>>
>>> I took as a basis the ruleset :
>>> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
>>>
>>> And started to fix some in
>>> https://github.com/apache/ofbiz-framework/pull/517
>>>
>>> Before doing the complete work, a first rule made me wonder if that is a
>>> choice that we will be doing as a community :
>>>
>>> IfStatementBraces - Use braces for if statements, even for a single
>>> statement.
>>>
>>> There are 234 occurrences in the project, and I guess that some opinions
>>> might diverge on this subject.
>>>
>>> Moreover, some rules needs lots of fixes in the project (those with more
>>> than 200 occurrences) :
>>>
>>>
>>> ++-+
>>> | Number of  | Rule name and details
>>>  |
>>> | occurrence |
>>>  |
>>>
>>> ++=+
>>> | 9883   | UnnecessaryGString  - String objects should be created with
>>> single  |
>>> ||  quotes, and GString  objects created with double quotes.
>>> Creating  |
>>> ||  normal String objects with  double quotes is confusing to
>>> readers. |
>>>
>>> ++-+
>>> | 4569   | DuplicateStringLiteral  - Code containing duplicate String
>>> literals |
>>> ||  can usually be improved by  declaring the String as a
>>> constant |
>>> || field. The ignoreStrings property ()  can optionally
>>> specify a  |
>>> || comma-separated list of Strings to ignore.
>>> |
>>>
>>> ++-+
>>> | 4209   | SpaceAroundMapEntryColon  - Check for configured formatting
>>> of  |
>>> || whitespace around colons for  literal Map entries.
>>> |
>>> || The characterBeforeColonRegex and
>>> characterAfterColonRegex |
>>> || properties specify a regular expression that  must match
>>> the|
>>> || character before/after the colon.
>>>  |
>>>
>>> ++-+
>>> | 1448   | LineLength  - Checks the maximum length for each line of
>>> |
>>> || source code. It checks for  number of characters, so lines
>>> |
>>> ||  that include tabs may appear longer than  the allowed
>>> number   |
>>> ||  when viewing the file. The maximum line length can  be
>>>  |
>>> || configured by setting the length property, which defaults
>>> to 120.   |
>>>
>>> ++-+
>>> | 885| Unnecessar

Re: Codenarc integration, rules to use.

[Gil Portenseigne]

Hello, 

I agree with you, i find out here [1] that it is customisable.

So we can agree upon this variation of the rule !

I have not tested yet, will see in the near future 

Thanks

Gil

Le 11 juillet 2022 17:57:45 GMT+02:00, Scott Gray  a écrit :
>+1 in general from me although some of those rules might be challenging to
>resolve.  For example DuplicateStringLiteral could be referring to an
>entity name being used in delegator queries more than once, I don't think
>we'd prefer to see that extracted to a constant.
>
>SpaceAroundMapEntryColon I'm not so sure about, my preference for
>legibility has always been [someKey: someValue].  I find
>[someKey:someValue] a bit too condensed and harder to differentiate key
>from value.
>
>Regards
>Scott
>
>On Mon, 4 Jul 2022 at 16:25, Gil Portenseigne 
>wrote:
>
>> Hello Devs,
>>
>> I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).
>>
>> For those who are not aware, Codenarc is an analysis tools for Groovy
>> for defects, bad practices, inconsistencies, style issues and more.
>>
>> For this purpose we need to agree about the ruleset to put in place.
>>
>> I took as a basis the ruleset :
>> https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt
>>
>> And started to fix some in
>> https://github.com/apache/ofbiz-framework/pull/517
>>
>> Before doing the complete work, a first rule made me wonder if that is a
>> choice that we will be doing as a community :
>>
>> IfStatementBraces - Use braces for if statements, even for a single
>> statement.
>>
>> There are 234 occurrences in the project, and I guess that some opinions
>> might diverge on this subject.
>>
>> Moreover, some rules needs lots of fixes in the project (those with more
>> than 200 occurrences) :
>>
>>
>> ++-+
>> | Number of  | Rule name and details
>>  |
>> | occurrence |
>>  |
>>
>> ++=+
>> | 9883   | UnnecessaryGString  - String objects should be created with
>> single  |
>> ||  quotes, and GString  objects created with double quotes.
>> Creating  |
>> ||  normal String objects with  double quotes is confusing to
>> readers. |
>>
>> ++-+
>> | 4569   | DuplicateStringLiteral  - Code containing duplicate String
>> literals |
>> ||  can usually be improved by  declaring the String as a
>> constant |
>> || field. The ignoreStrings property ()  can optionally
>> specify a  |
>> || comma-separated list of Strings to ignore.
>> |
>>
>> ++-+
>> | 4209   | SpaceAroundMapEntryColon  - Check for configured formatting
>> of  |
>> || whitespace around colons for  literal Map entries.
>> |
>> || The characterBeforeColonRegex and
>> characterAfterColonRegex |
>> || properties specify a regular expression that  must match
>> the|
>> || character before/after the colon.
>>  |
>>
>> ++-+
>> | 1448   | LineLength  - Checks the maximum length for each line of
>> |
>> || source code. It checks for  number of characters, so lines
>> |
>> ||  that include tabs may appear longer than  the allowed
>> number   |
>> ||  when viewing the file. The maximum line length can  be
>>  |
>> || configured by setting the length property, which defaults
>> to 120.   |
>>
>> ++-+
>> | 885| UnnecessaryGetter  - Checks for explicit calls to
>> getter/accessor   |
>> ||  methods which can, for  the most part, be replaced by
>> property |
>> ||  access. A getter is defined as a  method call that
>> matches |
>> || get[A-Z] but not getClass() or get[A-Z][A-Z]  such as
>> getURL(). |
>> ||  Getters do not take method arguments. The
>> ignoreMethodNames   |
>> || property (null) can specify method names that should  be
>> i

Codenarc integration, rules to use.

[Gil Portenseigne]

Hello Devs,

I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).

For those who are not aware, Codenarc is an analysis tools for Groovy
for defects, bad practices, inconsistencies, style issues and more.

For this purpose we need to agree about the ruleset to put in place.

I took as a basis the ruleset : 
https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt

And started to fix some in https://github.com/apache/ofbiz-framework/pull/517

Before doing the complete work, a first rule made me wonder if that is a
choice that we will be doing as a community : 

IfStatementBraces - Use braces for if statements, even for a single statement.

There are 234 occurrences in the project, and I guess that some opinions
might diverge on this subject.

Moreover, some rules needs lots of fixes in the project (those with more
than 200 occurrences) :

++-+
| Number of  | Rule name and details
   |
| occurrence |  
   |
++=+
| 9883   | UnnecessaryGString  - String objects should be created with 
single  |
||  quotes, and GString  objects created with double quotes. 
Creating  |
||  normal String objects with  double quotes is confusing to 
readers. |
++-+
| 4569   | DuplicateStringLiteral  - Code containing duplicate String 
literals |
||  can usually be improved by  declaring the String as a constant  
   |
|| field. The ignoreStrings property ()  can optionally specify a   
   |
|| comma-separated list of Strings to ignore.   
   |
++-+
| 4209   | SpaceAroundMapEntryColon  - Check for configured formatting of   
   |
|| whitespace around colons for  literal Map entries.   
   |
|| The characterBeforeColonRegex and  characterAfterColonRegex  
   |
|| properties specify a regular expression that  must match the 
   |
|| character before/after the colon.
   |
++-+
| 1448   | LineLength  - Checks the maximum length for each line of 
   |
|| source code. It checks for  number of characters, so lines   
   |
||  that include tabs may appear longer than  the allowed number
   |
||  when viewing the file. The maximum line length can  be  
   |
|| configured by setting the length property, which defaults to 
120.   |
++-+
| 885| UnnecessaryGetter  - Checks for explicit calls to 
getter/accessor   |
||  methods which can, for  the most part, be replaced by property  
   |
||  access. A getter is defined as a  method call that matches  
   |
|| get[A-Z] but not getClass() or get[A-Z][A-Z]  such as getURL().  
   |
||  Getters do not take method arguments. The  ignoreMethodNames
   |
|| property (null) can specify method names that should  be ignored 
   |
|| , optionally containing wildcard characters ('*' or '?').
   |
++-+
| 601| NoDef - def should not be used. You should replace it with   
   |
|| concrete type.   
   |
++-+
| 485| MethodReturnTypeRequired  - Checks that method return types  
   |
||  are not dynamic, that is they are  explicitly stated and
   |
||  different than def. 
   |
++-+
| 484| Indentation - Check indentation for class and method 
   |
|| declarations, and initial statements.
   |
++-+
| 482| UnnecessaryReturnKeyword  - In Groovy, the return keyword
   |
||  is often optional. If a statement is  the last line in a
   |
|| method or closure then you do not need to have the return 
keyword.  |
++-+
| 407| UnnecessaryObjectReferences  - Violations are triggered when 
   |
| 

Re: "New commiter first steps" wiki page proposal

[Gil Portenseigne]

Hello Giulio,

I just went through the page, it's nice and clear ! 

Thanks

Gil


Le samedi 14 mai 2022 à 16:32 +0200, Giulio Speri - MpStyle Srl a
écrit :
> Hello Devs,
> 
> I hope you are all doing well!
> I finally had some time to write a little guide regarding the steps
> to
> perform as a new committer in order to start working with online
> OFBiz
> repositories.
> I published the page in the section Community ->  Apache OFBiz
> Contribution
> and Development : OFBiz New Committer's first steps
> 
> 
> All the feedbacks and suggestions about it are happily appreciated.
> :)
> 
> Thanks in advance and have a great WE ahead,
> Giulio
> 
> Il giorno sab 2 apr 2022 alle ore 15:03 Jacques Le Roux <
> jacques.le.r...@les7arts.com> ha scritto:


> [...]

Re: [INFRA-22722] Restart the ofbiz-vm3 demos server

[Gil Portenseigne]

I do not remember doing such :)

Gil

On Wed, Mar 23, 2022 at 07:13:02PM +0100, Jacques Le Roux wrote:
> Ah forgot, did you fix the warnings?
> 
> Le 23/03/2022 à 19:09, Jacques Le Roux a écrit :
> > Great, thanks Gil!
> > 
> > Le 23/03/2022 à 18:15, Gil Portenseigne a écrit :
> > > Hello Jacques,
> > > 
> > > We have some production server based on 18.12, with java 11.
> > > 
> > > It is working fine.
> > > 
> > > Gil
> > > On Wed, Mar 23, 2022 at 05:58:25PM +0100, Jacques Le Roux wrote:
> > > > BTW,
> > > > 
> > > > Is there someone who is already using Java 11 with 18.12?
> > > > 
> > > > TIA
> > > > 
> > > > Jacques
> > > > 
> > > > Le 23/03/2022 à 16:24, Jacques Le Roux a écrit :
> > > > > Hi Michael,
> > > > > 
> > > > > I don't remember clearly why I had that in mind. I have just
> > > > > tried to run current 18.12 with Java 11 and so far it seems
> > > > > OK. I'll check that better...
> > > > > 
> > > > > Nevertheless, I'll already ask to install both Java 8 and 11 on the 
> > > > > new VM (nothing started yet).
> > > > > 
> > > > > Thanks for the suggestion.
> > > > > 
> > > > > Jacques
> > > > > 
> > > > > Le 18/03/2022 à 12:55, Jacques Le Roux a écrit :
> > > > > > Hi Michael,
> > > > > > 
> > > > > > I suggest to tackle that, including the necessary on the VM, when 
> > > > > > we will effectively switch 22.01 to JDK 11
> > > > > > 
> > > > > > Jacques
> > > > > > 
> > > > > > Le 18/03/2022 à 12:03, Michael Brohl a écrit :
> > > > > > > Hi Jacques,
> > > > > > > 
> > > > > > > should we not also have a VM supporting Java 11 for the 22.01 
> > > > > > > release branch?
> > > > > > > 
> > > > > > > +1 for the rest of the specifications
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > 
> > > > > > > Michael Brohl
> > > > > > > 
> > > > > > > ecomify GmbH - www.ecomify.de
> > > > > > > 
> > > > > > > 
> > > > > > > Am 18.03.22 um 11:46 schrieb Jacques Le Roux:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Good news, demos will soon be back :).
> > > > > > > > 
> > > > > > > > Greg asked me to provide specs for a new OFBIZ-VM, I guess 
> > > > > > > > OFBIZ-VM4.
> > > > > > > > 
> > > > > > > > If nobody is against Monday I'll ask for the same than 
> > > > > > > > OFBIZ-VM3 (JDK 8, 8GB RAM, letsencrypt). I guess it will be 
> > > > > > > > Ubuntu again.
> > > > > > > > 
> > > > > > > > JDK8 because it will still need to support 18.12 branch, 8GM 
> > > > > > > > RAM has proven to be good enough for 3 demos so far.
> > > > > > > > 
> > > > > > > > What will change is the replacement of
> > > > > > > > https://demo-old.ofbiz.apache.org/
> > > > > > > > by
> > > > > > > > https://demo-next.ofbiz.apache.org/
> > > > > > > > 
> > > > > > > > https://demo-stable.ofbiz.apache.org/
> > > > > > > > and
> > > > > > > > https://demo-trunk.ofbiz.apache.org/
> > > > > > > > will stay of course.
> > > > > > > > 
> > > > > > > > I have things almost ready at 
> > > > > > > > https://github.com/apache/ofbiz-tools/tree/master/demo-backup
> > > > > > > > 
> > > > > > > > Jacques
> > > > > > > > 


signature.asc
Description: PGP signature

Re: [INFRA-22722] Restart the ofbiz-vm3 demos server

[Gil Portenseigne]

Hello Jacques, 

We have some production server based on 18.12, with java 11.

It is working fine.

Gil
On Wed, Mar 23, 2022 at 05:58:25PM +0100, Jacques Le Roux wrote:
> BTW,
> 
> Is there someone who is already using Java 11 with 18.12?
> 
> TIA
> 
> Jacques
> 
> Le 23/03/2022 à 16:24, Jacques Le Roux a écrit :
> > Hi Michael,
> > 
> > I don't remember clearly why I had that in mind. I have just tried to run 
> > current 18.12 with Java 11 and so far it seems OK. I'll check that better...
> > 
> > Nevertheless, I'll already ask to install both Java 8 and 11 on the new VM 
> > (nothing started yet).
> > 
> > Thanks for the suggestion.
> > 
> > Jacques
> > 
> > Le 18/03/2022 à 12:55, Jacques Le Roux a écrit :
> > > Hi Michael,
> > > 
> > > I suggest to tackle that, including the necessary on the VM, when we will 
> > > effectively switch 22.01 to JDK 11
> > > 
> > > Jacques
> > > 
> > > Le 18/03/2022 à 12:03, Michael Brohl a écrit :
> > > > Hi Jacques,
> > > > 
> > > > should we not also have a VM supporting Java 11 for the 22.01 release 
> > > > branch?
> > > > 
> > > > +1 for the rest of the specifications
> > > > 
> > > > Thanks,
> > > > 
> > > > Michael Brohl
> > > > 
> > > > ecomify GmbH - www.ecomify.de
> > > > 
> > > > 
> > > > Am 18.03.22 um 11:46 schrieb Jacques Le Roux:
> > > > > Hi,
> > > > > 
> > > > > Good news, demos will soon be back :).
> > > > > 
> > > > > Greg asked me to provide specs for a new OFBIZ-VM, I guess OFBIZ-VM4.
> > > > > 
> > > > > If nobody is against Monday I'll ask for the same than OFBIZ-VM3 (JDK 
> > > > > 8, 8GB RAM, letsencrypt). I guess it will be Ubuntu again.
> > > > > 
> > > > > JDK8 because it will still need to support 18.12 branch, 8GM RAM has 
> > > > > proven to be good enough for 3 demos so far.
> > > > > 
> > > > > What will change is the replacement of
> > > > > https://demo-old.ofbiz.apache.org/
> > > > > by
> > > > > https://demo-next.ofbiz.apache.org/
> > > > > 
> > > > > https://demo-stable.ofbiz.apache.org/
> > > > > and
> > > > > https://demo-trunk.ofbiz.apache.org/
> > > > > will stay of course.
> > > > > 
> > > > > I have things almost ready at 
> > > > > https://github.com/apache/ofbiz-tools/tree/master/demo-backup
> > > > > 
> > > > > Jacques
> > > > > 


signature.asc
Description: PGP signature

Re: Welcome to Nicola Mazzoni and Giulio Speri as new committers

[Gil Portenseigne]

Congratulations, Welcome !

Gil
On Mon, Mar 21, 2022 at 09:26:16PM +0100, Jacopo Cappellato wrote:
> The OFBiz PMC has invited Nicola Mazzoni and Giulio Speri as new
> committers and we are glad to announce that they have accepted the
> nomination.
> 
> On behalf of the OFBiz PMC, welcome on board!


signature.asc
Description: PGP signature

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.05 (second attempt)

[Gil Portenseigne]

+1,

Verifying files...
sha check of file: apache-ofbiz-18.12.05.zip
Using sha file: apache-ofbiz-18.12.05.zip.sha512
apache-ofbiz-18.12.05.zip: F7952ED5 C794357F E730C7DE 404B0B8B 7A123A89 
9DA7A1C1 4D0136ED 64D6FAA3 7645018E 9EDE93FB 88FC27A3 D718DA64 E8636541 
334583ED 606F5516 6D653B2C
apache-ofbiz-18.12.05.zip: F7952ED5 C794357F E730C7DE 404B0B8B 7A123A89 
9DA7A1C1 4D0136ED 64D6FAA3 7645018E 9EDE93FB 88FC27A3 D718DA64 E8636541 
334583ED 606F5516 6D653B2C
sha checksum OK

PGP sigs and integration test ok.

Thanks,

Gil

On Sun, Jan 02, 2022 at 12:29:37PM +0100, Jacopo Cappellato wrote:
> This is the second vote thread to release a new bug fix release for the
> release18.12 branch. This new release, "Apache OFBiz 18.12.05"
> supersedes all the previous releases from the same branch.
> 
> The release files can be downloaded from here:
> https://dist.apache.org/repos/dist/dev/ofbiz/
> 
> and are:
> * apache-ofbiz-18.12.05.zip
> * KEYS: text file with keys
> * apache-ofbiz-18.12.05.zip.asc: the detached signature file
> * apache-ofbiz-18.12.05.zip.sha512: checksum file
> 
> Please download and test the zip file and its signatures (for
> instructions on testing the signatures see [*]).
> 
> Vote:
> 
> [ +1] release as Apache OFBiz 18.12.05
> [ -1] do not release
> 
> For more details about this process please read [**].
> [*]
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz#ReleaseManagementGuideforOFBiz-Votingonarelease
> [**] http://www.apache.org/foundation/voting.html


signature.asc
Description: PGP signature

Re: [Conclusion] PartyRole usage in OFBiz

[Gil Portenseigne]

Hello Pierre,

Inline,

On Fri, Nov 19, 2021 at 06:48:40PM +0100, Pierre Smits wrote:
> Hi Gil, All,
> 
> My apologies, but I have to object to this and for the following reasoning:
> Objections to pursuing improvements to the entity definition (for
> PartyRole) and subsequent addressing front-end issues (screens/forms,
> requests, services etc) for that and other entities impacted were raised,
> before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole was
> brought forward now 4 days ago.

I'm aware about this page and discussion, if i'm not wrong, it is not
about adding lifespan into PartyRole entity. That is the point I wanted
to clarify. I'm not contesting this improvement, that can continue in a
dedicated thread.

If you think that subject is common please clarify to let us take
position on the PartyRole case (the only one I want to tackle at the
moment)

> 
> That page defines the requirements for any and all EntityNameRole entity,
> including PartyRole. And the validity of what was stated there has not been
> contested up to now. Not even by those objecting to changes to PartyRole
> (as it is included in the page) before the date/time of the page, and who
> have remained silent since the availability of the page. I wanted to wait a
> bit longer, so that every contributor (and other readers of the dev ml)
> could have an informed opinion, before suggesting to claim consensus on
> that. But alas...

I did not gave date on purpose, there is no hurry, it was a way to
recenter the discussion about this specific case.
> 
> So it stands to reason that getting current existing and failing
> EntityNameRole entities (including the PartyRole entity) compliant is
> implied and thus warranted. And thus tickets can stay as they are. Just the
> order of improvements coming in is a concern that needs to be addressed
> when they come in. And if such concerns can be addressed and eliminated
> beforehand, so much the better.
> 
> Furthermore, one key aspect I would like to mention here. You mentioned in
> your comment (see [1]): 'The current applications IMO are not meant to be
> used as is'.
> This is a very wrong point of view, as the many users/contributors in user
> ml see differently.

That is mine, and claiming it is wrong because others see it differently
is not a valid argument to me. 

Claiming that in webtools and partymgr there can be FK errors while
deleting PartyRole, is IMO not a good argument since those component are
*technical* ones that should not be used by *non technical* end users.

The idea is not the same for more business component like HR for
example, where I agree should be more usable for business end user.

> Otherwise they would not raise a thread about the
> workings of OFBiz, about functionalities not being good enough. Or a ticket
> in JIRA. They expect OFBiz as a business solutions to be usable as is, as a
> minimal viable product (MVP). They don't expect it to be perfect when they
> start using it. They'll trust that it will come along in due time.  And
> they also don't expect it to have all the bells and whistles a particular
> developer thinks necessary (while adding no value to the user). But, any
> improvement brought forward to benefit all can/should go in. That is what
> they expect.

> And integrators downstream can take that and enhance for their own audience
> (current and future) as they see fit. It is not up to the integrators (as
> you proclaimed in the same posting: 'It is our choices as Integrators to
> decide') to decide what goes into OFBiz that works for all users, not just
> their own clients. System integrators don't contribute to an project to the
> ASF. Even if they would be able to do so, at the end the using company
> decides).
You are interpreting my words. I was not talking about contribution, but
about integrators using Apache OFBiz for their customer. The decision I
was mentioning was about how they design their product to fill the need
for their customer, where there is not truth but choice to be made.

I remember discussion with you and others in Budapest (old good time)
that the applications are too big, present many features that
demonstrate the power of OFBiz, and this fact leads to being hardly
usable without customization. 
In my experience, anytime I redevelop specific plugins for my end user
to simplify to their needs, that is the choice I made as an integrator
human being (not my company).

> We need to work on that perception of contributors with privileges, as it
> seems that this mindset (Integrators decide) is dictates the direction of
> this project.

I never meant that, i'm sure you know it, that is kinda rude.

Can we please focus on the subject ?

Thanks,

Gil



signature.asc
Description: PGP signature

[Conclusion] PartyRole usage in OFBiz

[Gil Portenseigne]

Hello,

I will try to summarize the ongoing thread, to produce a conclusion or
potential plan. Sorry in advance, if I forgot some points.

About the improvement of adding lifespan in PartyRole entity, the "Won't do"
seems to get the consensus, since this improvement do not follow logical
purpose (might for audit), and will introduce regressions and bugs risks if
implemented.

The discussion went to a new subjects, like using PartyRelationship for party
selection screens.
Opinion about removing PartyRole FK from EntityRole entities has been expressed.
Those both topics can be lead into separate thread if needed, to let anyone
envision it without being polluted by the previous discussion in the thread.

If no one object I will close Jira about PartyRole lifespan.

Thanks for your sharing, and Regards.

Gil





signature.asc
Description: PGP signature

Re: [VOTE] Apache OFBiz 18.12.02 (second attempt)

[Gil Portenseigne]

+1

Thanks

On Tue, Nov 16, 2021 at 05:26:52PM +0100, Jacopo Cappellato wrote:
> This is the second vote thread to publish "Apache OFBiz 18.12.02", the
> second release from the release18.12 branch.
> 
> The release files can be downloaded from here:
> https://dist.apache.org/repos/dist/dev/ofbiz/
> and are:
> * apache-ofbiz-18.12.02.zip
> * KEYS: text file with keys
> * apache-ofbiz-18.12.02.zip.asc: the detached signature file
> * apache-ofbiz-18.12.02.zip.sha512: checksum file
> 
> Please download and test the zip file and its signatures (for instructions
> on testing the signatures see http://www.apache.org/info/verification.html).
> 
> Vote:
> [ +1] release as Apache OFBiz 18.12.02
> [ -1] do not release
> 
> This vote will be open for 5 days.
> 
> For more details about this process please refer to
> http://www.apache.org/foundation/voting.html
> 
> Best Regards,
> 
> Jacopo


signature.asc
Description: PGP signature

PartyRole usage in OFBiz

[Gil Portenseigne]

Hello,

I'm starting a new thread to discuss with the community about an Improvement 
that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was conclude by a 
lazy consensus not to implement PartyRole lifespan into OFBiz.
Recently, this improvement was discussed again in Jira [3], and partly 
commited, before being reverted when big blocking side effect where discovered.
A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto PartyRole 
entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the community 
consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if we need to 
organize or if we need to close pending Jira with reference to this discussion ?

Thanks,
Gil
[1] https://issues.apache.org/jira/browse/OFBIZ-5959
[2] 
https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
[3] https://issues.apache.org/jira/browse/OFBIZ-5980 
(https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274)
[4] 
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

Re: [VOTE] Apache OFBiz 18.12.01

[Gil Portenseigne]

+1 

Thanks,

Gil
On Sat, Oct 23, 2021 at 05:08:32PM +0200, Jacopo Cappellato wrote:
> This is the vote thread to publish "Apache OFBiz 18.12.01", the first
> release from the release17.12 branch.
> 
> The release files can be downloaded from here:
> https://dist.apache.org/repos/dist/dev/ofbiz/
> and are:
> * apache-ofbiz-18.12.01.zip
> * KEYS: text file with keys
> * apache-ofbiz-18.12.01.zip.asc: the detached signature file
> * apache-ofbiz-18.12.01.zip.sha512: checksum file
> 
> Please download and test the zip file and its signatures (for instructions
> on testing the signatures see http://www.apache.org/info/verification.html).
> 
> Vote:
> [ +1] release as Apache OFBiz 18.12.01
> [ -1] do not release
> 
> This vote will be open for 5 days.
> 
> For more details about this process please refer to
> http://www.apache.org/foundation/voting.html
> 
> Best Regards,
> 
> Jacopo


signature.asc
Description: PGP signature

Re: [apache/ofbiz-framework] Run failed: Java CI with Gradle - trunk (c0f8783)

[Gil Portenseigne]

Hello,

I got a notification of CI that use jdk 1.8 for trunk.

Is there any action that i can do to configure java 11 or more ?

Thanks,

Gil

On Thu, Sep 23, 2021 at 06:03:33AM -0700, Gil Portenseigne wrote:
> [apache/ofbiz-framework] Java CI with Gradle workflow run
> 
> Repository: apache/ofbiz-framework
> Workflow: Java CI with Gradle
> Duration: 3 minutes and 3.0 seconds
> Finished: 2021-09-23 13:03:22 UTC
> 
> View results: 
> https://github.com/apache/ofbiz-framework/actions/runs/1265900307
> 
> Jobs:
>   * build failed (1 annotation)
> 
> -- 
> You are receiving this because this workflow ran on your branch.
> Manage your GitHub Actions notifications: 
> https://github.com/settings/notifications


signature.asc
Description: PGP signature

Re: [DISCUSSION] Do we start the R18 publish process ?

[Gil Portenseigne]

+1 

Thanks,

Gil
On Mon, Sep 20, 2021 at 10:13:04AM +0200, Nicolas Malin wrote:
> The main is on the title :)
> 
> At this time some issue are always present [1], so we have to decide
> whether to launch and move them to the next.
> 
> My feeling is after some time on it, we can go ahead and keep their fix
> for the next when it would be possible.
> 
> Nicolas
> 
> -- 
> logoNrd 
>   Nicolas Malin
> The apache way  : *Charity* Apache’s mission
> is providing software for the public good.
> informat...@nereide.fr
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> 
> Apache OFBiz |The Apache Way
> |réseau LE 


signature.asc
Description: PGP signature

Re: Freemarker auto-escaping

[Gil Portenseigne]

Hello, 

I used to define `<#ftl output_format="XML">` on top of ftl files for
this purpose.

But having this on file extension looks nice to me.

Thanks Jacques for the head up.

Gil

On Wed, Sep 08, 2021 at 02:59:27PM +0200, Jacques Le Roux wrote:
> Hi,
> 
> Long ago we opened https://issues.apache.org/jira/browse/OFBIZ-7675 for that
> 
> Few days ago Dániel Dékány (VP and main contributor to Apache Freemarker 
> project) wrote at FREEMARKER-189 (https://s.apache.org/fitxs):
> 
>< the Manual). [...] Then people can't accidentally forget adding them>>
> 
> I was reluctant do use all auto-escaping features. But I believe we should
> follow Forrest Rae
> 's
> suggestion at OFBIZ-7041 
> that we turn Freemarker autoescaping on. Quoting him there:
> 
>< formats. The <#escape> directive has been deprecated. Notice the comment at 
> the
>very end of this page:
>"FreeMarker automatically escapes all values printed ... if it's properly 
> configured (that's the responsibility of the programmers; see here how
>)."
>Would be good to turn autoescaping on, and set the configuration to match 
> .ftl as HTML and .fo.ftl as XML.>>
> 
> I mean the last part of Forrest Rae 
> 's 
> proposition, ie :
> 
> 1. removes all "?html" expression and renames all nameIt.ftl files to 
> nameIt.ftlh
> 2. removes all<#escape x as x?xml> ...    couples and renames all 
> nameIt.fo.ftl files to nameIt.fo.ftlx
> 
> I think these changes are safe (to be tested of course).
> 
> What do you think?
> 
> Thanks
> 
> Jacques
> 


signature.asc
Description: PGP signature

Groovy integration tests

[Gil Portenseigne]

Hello,

Currently using release 18.12 for some project we got the habit to
develop using integration test while developing in groovy.

For that usage we use mainly :
groovy-test-suite

That allow coding tests in groovy script that do not need to be compiled
for their execution and executing them from webtools [1] (small
improvement will be contributed soon), there is no need to reboot the
local dev OFBiz instance for each modification in that test.

But these type of test has been removed with OFBIZ-11165 [2], while I
thinks that these resources are better compiled, during development
process, not having to restart OFBiz is nice.

So if nobody is against, I will reintroduce it in trunk with a note
explaining the `dev` usage.

WDYT

Regards,

Gil

[1] https://localhost:8443/webtools/control/TestSuiteInfo
[2] https://issues.apache.org/jira/browse/OFBIZ-11165


signature.asc
Description: PGP signature

Re: Logical dependency tree for ofbiz components OFBIZ-12309

[Gil Portenseigne]

Hello Eugen,

[...]

> > I have on my mind to elaborate a framework-core an acceptable minimal
> > circular dependencies and some other present as three dependency
> > 
> >* core : common - base - start - entity - service - security - webapp
> >* entityext : core
> >* datafile: core
> >* testtools: core
> >* catalina: core
> >* widget: core
> >* webtools: widget, testtools, datafile, catalina
> > 
> > I know this isn't your final objective but can it be an acceptable spot ?
> 
> Thanks. It's a very good place to start.
> We might be able to introduce a 'core' gradle project that contains those
> and depend on that one in the others.
> 
> I would move out start module.
> It seems to be responsible for starting up the app.
> I imagine components have an interface (the Container).
> All ofbiz plugins/modules implement this so there should not be a dependency
> on implementations.
> Perhaps this is a good point to start - separating the container and
> depending on it in other modules.
> 
> start will start ofbiz and load modules list from xml + look them up on the
> classpath.
> 
> WDYT? How would the list above change with a container API module?

About dependency between base and start. Today, Start is packaged in
`org.apache.ofbiz.base`, it seems to have been designed to be the only
alternative for OFBiz server launch (no other implementation possible).

Indeed, this component is the one that stock the launch information
(portoffset etc.). To make it happen, there have to be defined interfaces
from which actual codebase would be one implementation.

Is that what you envision, if so this could be a good first example of
circular dependency removal.

Other example, regarding common component, that contains common elements
applicable to any other component like Unit of measure, lookups, emails.

For those, the services can be based upon screen to generate the desired
results inducing a dependency toward the widget component. 

Moreover, lots of display information are propagated by Visual theme,
(during login, emails, freemarker engine preparation). We might need to
integrate all of these into base component using interface OR split into
the good/new component OR decide that OFBiz nature is to live with
widgets in its core.


> 
> Another helpful thing is to establish the boundaries of each project.
> What should each module do and what it should NOT do?

* service : contains all soa configuration and engine to manage services
* entity : contains all database / entity management
* common : contains functional widget, data, services that can be used
  by all other components
* base : contains technical low level code for all OFBiz components
* start : launching, stopping OFBiz server instance, managing start
  configuration
* security : as is named, tools to manage user security
* webapp : engine to manage exchange between servlet and controller
  definition
* entityext : container that extend the entity engine on some element
  not vital for OFBiz to run like entity sync, cache distribution, ...
* datafile: tools to create/read big data file base on xml definition
* testtools: integration test engine
* catalina: container for embedded tomcat
* widget: screen rendering based on xml definition
* webtools: web interface to analyse and manage different OFBiz engines


Thanks Eugen,

Nicolas and Gil


signature.asc
Description: PGP signature

Re: Next rather than old demo

[Gil Portenseigne]

Hello Jacques,

I agree it's better to show the present and future.

Thanks,

Gil


On Mon, Sep 06, 2021 at 11:47:18AM +0300, Eugen Stan wrote:
> On 03.09.2021 20:00, Jacques Le Roux wrote:
> > Hi,
> > 
> > We have an old demo. It's the previous stable. I think we should rather
> > think about the future than the past.
> > 
> > So I propose to change and replace the old demo by a next demo. It would
> > be the next release to be done. For instance at the moment old is R16
> > and next would be R18, etc.
> > 
> > I have already used the same for the documentation:
> > https://ci.apache.org/projects/ofbiz/site/
> > 
> > What do you think?
> > 
> > TIA
> > 
> > Jacques
> > 
> 
> I think it's a good idea.
> I imagine people who care about the old have already an instance running and
> can deploy it themselves.
> Stable and next would be great.
> 
> Regards,
> -- 
> Eugen Stan
> +40720 898 747 / netdava.com



signature.asc
Description: PGP signature

Re: [VOTE] Apache OFBiz 17.12.08

[Gil Portenseigne]

+1

Checksum, signature and tests are OK

Thanks,

Gil

On Mon, Aug 02, 2021 at 12:24:13PM +0200, Jacques Le Roux wrote:
> +1
> 
> Back and front ends OK
> 
> Checksums OK
> 
> $ ./verify-ofbiz-release.sh apache-ofbiz-17.12.08.zip
> sha check of file: apache-ofbiz-17.12.08.zip
> Using sha file: apache-ofbiz-17.12.08.zip.sha512
> apache-ofbiz-17.12.08.zip: 624E1793 ED05C3F7 39F28D57 16A1BED8 D79A7787
> 33D047D1 537F07B2 AC05EA2D 425175F3 D8304D04 0B1B7CA1 33651100 14F331DA
> A7140EC0 D4C18AB1 2496E0E4
> apache-ofbiz-17.12.08.zip: 624E1793 ED05C3F7 39F28D57 16A1BED8 D79A7787
> 33D047D1 537F07B2 AC05EA2D 425175F3 D8304D04 0B1B7CA1 33651100 14F331DA
> A7140EC0 D4C18AB1 2496E0E4
> sha checksum OK
> 
> GPG verification output
> gpg: Signature made Mon Aug  2 10:01:25 2021
> gpg:    using RSA key 7A580908847AF9E0
> gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
> "
> 
> Jacques
> 
> Le 02/08/2021 à 11:22, Jacopo Cappellato a écrit :
> > This is the vote thread to release a new bug fix release for the
> > release17.12 branch. This new release, "Apache OFBiz 17.12.08" will
> > supersede the previous release from the same branch.
> > 
> > The release files can be downloaded from here:
> > https://dist.apache.org/repos/dist/dev/ofbiz/
> > and are:
> > * apache-ofbiz-17.12.08.zip
> > * KEYS: text file with keys
> > * apache-ofbiz-17.12.08.zip.asc: the detached signature file
> > * apache-ofbiz-17.12.08.zip.sha512: checksum file
> > 
> > Please download and test the zip file and its signatures (for instructions
> > on testing the signatures see http://www.apache.org/info/verification.html).
> > 
> > Vote:
> > [ +1] release as Apache OFBiz 17.12.08
> > [ -1] do not release
> > 
> > This vote will be open for 5 days.
> > 
> > For more details about this process please refer to
> > http://www.apache.org/foundation/voting.html
> > 
> > Best Regards,
> > 
> > Jacopo
> 


signature.asc
Description: PGP signature

Re: I'm working on an OFBiz helm chart for kubernetes

[Gil Portenseigne]

Hello Eugen, and thanks Pierre for the reminder :)

I just wanted to mention there was a previous effort to implement
environment variable configuration [1]. This has not yet be pushed into
trunk, but is used by our customer projects.

You could check the patch and test if it helps you ease the
configuration process.

Regards, 

Gil

[1] https://issues.apache.org/jira/browse/OFBIZ-9498

On Thu, Jul 01, 2021 at 10:57:22AM +0200, Pierre Smits wrote:
> Hi Ioan,
> 
> My apologies for the late reaction.
> 
> IMO we can forget about the Derby route for this. Derby is not production
> grade, and often adopters/implementers already have their preferred RDBMS
> for production in play or decided upon.  Configuration of such is the
> entityengine.xml file, and deployment of such for the various
> environments/instances like UAT or PROD can easily managed and deployed via
> VCS.
> 
> Best regards,
> Pierre Smits
> 
> 
> On Sun, May 9, 2021 at 9:13 PM Eugen Stan  wrote:
> 
> >
> >
> > Hello,
> >
> > NOTE: I previously sent this email from an un-subscribed email address,
> > please ignore that one.
> >
> > I'm working on a Helm chart for OFBiz
> > https://github.com/ieugen/charts/tree/main/ofbiz .
> >
> > The goal is to have OFBiz running in Kubernetes.
> >
> > Right now it's a rough start: it starts OFBiz with Derby and that's
> > about it.
> >
> > I'll keep pushing updates as soon as I have them.
> >
> > I'm interested in your feedback.
> > If you plan on testing it and using it let me know.
> > I do accept and encourage collaboration.
> >
> > If this is interesting I might push it upstream but it uses the binary
> > build of OFBiz in Docker.
> >
> >
> > I'm using docker images built from trunk on jdk-11.
> > There are amd64 and arm64 (Raspberry PI4) images.
> >
> > Some issues that need solving are the many configuration files that
> > OFBiz has.
> >
> > This details creates a lot of configuration when deploying in Docker /
> > Kubernetes as they need to be mounted in a volume with many entries or
> > multiple volumes.
> >
> > There are many potential solutions to this but it boils down to:
> > * It would be nice to load max 1-2 or 3 configuration file with multiple
> > sections instead of the currently many configs split over the code base.
> > * It would be nice to support configuration (overwrite) via ENV vars for
> > some things like DB connection.
> >
> >
> > Regards.
> > Eugen
> >


signature.asc
Description: PGP signature

Re: Introduce a "Good First Issue" Jira Label

[Gil Portenseigne]

Hello,

Good idea,

To add some more about GoodForNewContributors, it seems well used in 
GitLab platform :


https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=good+for+new+contributors

So sticking with it seems nice to me.

Thanks

Le 07/05/2021 à 15:53, Aditya Sharma a écrit :

Hi team,

Good First Issue label can be used to identify any issue to be a good fit
for a new contributor. These issues can be a great way to get started with
a project. Then label is widely used by projects on GitHub[2] and quite
useful.

I propose to introduce a "Good First Issue" like a label to avail more
contributions from new people. I noticed there is already a label for
GoodForNewContributors[2] used by some projects. We can use the same or
have one created as "Good First Issue" as per the conventions all over the
world.

WDYAT?

1. https://github.com/topics/good-first-issue
2.
https://issues.apache.org/jira/browse/REEF-21?jql=labels%20%3D%20GoodForNewContributors

Thanks and Regards,
Aditya Sharma

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.07

[Gil Portenseigne]

Hello,

+1

Tests are OK, basic usage OK, SHA and signature OK

Regards,

Gil




Le 13/04/2021 à 10:39, Jacopo Cappellato a écrit :

  This is the vote thread to release a new bug fix release for the
release17.12 branch. This new release, "Apache OFBiz 17.12.07" will
supersede all the previous releases from the same branch.

The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-17.12.07.zip
* KEYS: text file with keys
* apache-ofbiz-17.12.07.zip.asc: the detached signature file
* apache-ofbiz-17.12.07.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:

[ +1] release as Apache OFBiz 17.12.07
[ -1] do not release

This vote will be open for 5 days.

For more details about this process please read
http://www.apache.org/foundation/voting.html

Re: Releasing 17.12.05, 18.12.01 and freezing R20

[Gil Portenseigne]

+1 for Michael !

Cheers

On Mon, Dec 21, 2020 at 02:57:25PM +0100, Michael Brohl wrote:
> +1 for the initial proposal
> 
> with an additional idea: maybe better skip r20 and make a r21 right at the
> beginning of the year with the chance to release also in 21.
> 
> This would allow us to catch up and have a more up-to-date release cycle. It
> seems a bit outdated to read that r18 is released in 2021...
> 
> What do you think?
> 
> Also +1 for 3 years support of r17 and 5 years support starting with r18.
> 
> Thanks,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> Am 21.12.20 um 10:54 schrieb Jacques Le Roux:
> > Hi Deepak,
> > 
> > The reason I propose that is because it's more and more difficult to
> > backport to R17, when for R18 it's still OK. Also 3 years seems good
> > enough for me.
> > 
> > Of course if people think 5 years would be better then the backporting
> > question should be discussed...
> > 
> > We could revise that later, because there was much change between R17 an
> > trunk and there are less and less now. So we could support R18 for 5
> > years
> > 
> > Jacques
> > 
> > Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
> > > +1
> > > 
> > > I have a question regarding the following point, rest looks good to me.
> > > 
> > > What is the minimum supported year for a release?
> > > Do we have any policy regarding this?
> > > 
> > > We should support a release for at least 5 year.
> > > 
> > > Thoughts?
> > > 
> > > Thanks & Regards
> > > -- 
> > > Deepak Dixit
> > > ofbiz.apache.org
> > > 
> > > 
> > > On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
> > > jacopo.cappell...@gmail.com> wrote:
> > > 


signature.asc
Description: PGP signature

Chapter 3 : promoting decorator

[Gil Portenseigne]

Hello devs,

This mail introduce the last Chapter of our story that describe in
which context we created some new decorators.

First, we want to recall the common-theme effort objectives :

The common-theme component is the default theme that define every
screens that are available for theme surcharge, without technology
information (css/html, vuejs or something like that).

Every theme is based onto this common-theme that structure the
application. Any theme can empower this structure its way, using it’s
one technology.

The idea is simple, isolating screen definition from technology syntax, let the
technology implementation to the theme.

Xml Screen and form definition must only be description of the
structure. The “how it is render” is defined by default by the
common-theme, and might be overloaded by a chosen theme.

From these objectives arise the need to list structural descriptive
decorator that exists or are added by our effort :

The *FindScreenDecorator* : is the existing search screen decorator in
OFBiz, it is composed in three sections :
* A menu (party creation for instance : menu-bar)
* Search criteria (search-option)
* Results (search-results)

The new *DetailsScreenDecorator* : is a new decorator to show a sum up of
an object and its related data. Composed in five sections :
* A menu (menu-bar)
* A tab menu : to give access to related data into details section
  (tab-bar)
* A summary that display main data of the object (summary)
* An action menu (object modification, duplicate or specific actions :
  actions)
* The detail : area that will display related data (details)

This structure, in addition to give the display control to the theme,
offer the developer not to think about the area to use when he wants to
display more data concerning the object. 

Moreover, when performing actions, the developer do not need to know
about the area to refresh, since the screen-engine has been improved to
manage it for him.

The new *EmbeddedScreenDecorator* : is a new decorator used to inject in
an structure page area a specific screen.

Its goal is to define what kind of data the screen will have to render
to allow the theme to adapt the technology for data rendering.
The sections are :
* A menu (menu-bar)
* An action menu (search filtering, history display…)
* single : display of a single form
* content : display a content (Image or document)
* list : display a list of data

Those can be loaded by functional decorator that take charge of basic
data retrieval :

As an example :
*EmbeddedProductCategoryScreenDecorator*
That is a specific decorator that implements the
*EmbeddedScreenDecorator* and do the data retrieval of productCategory
object :















This avoid for every embedded screen using productCategory code
duplication in data retrieval.  The same logic can be applied to
*DetailsScreenDecorator*.

To see all that in action we are working into a simple demo, in a
classical theme and an simple improved theme, we currently are creating
a sum-up presentation with illustration and more details like
code/video.

I hope we will be able to share it with you soon enough.

Best Regards



signature.asc
Description: PGP signature

Re: Chapter two: Rules to dynamize screen

[Gil Portenseigne]

Hello James,

No worry i wasn't active due to the situation we are aware of...

I plan to get back into the subject in the coming weeks.

Regards,

Gil

On Fri, May 15, 2020 at 04:08:07PM -, James Yong wrote:
> Hi Gil,
> 
> Sorry for the late reply. 
> I agree that button actions should be decoupled from forms.
> Shall we continue with Part 3?
> 
> Regards,
> James
> 
> On 2020/01/10 17:58:59, Gil Portenseigne  wrote: 
> > Hello !
> > 
> > In previous thread we focused on the process of how to define a dynamic
> > workflow that raises some questions.
> > 
> > Let's go back to our principles: we have to find simple things, limit
> > the possibilities (do little but good) and remember that on the
> > backoffice it's end-users who are focused on specific tasks.
> > 
> > To make it simple, implement screen dynamism that will generate
> > alterations of the dom, to limit side effects, we establish the
> > following principles:
> >   * We can only ask for an update of the area known by the calling
> > element.
> > 
> > Knowing that the element of coherence in the screen engine is the
> > screen itself, we can refine this rule on the following basis
> >   * An element triggering a screen update, can only update elements
> > present within the screen where it belongs.
> > 
> > Why did we made this choice? We will see it below, but the goal is
> > always to make writing easier for the developer by avoiding him to
> > wonder what is the value of the area to be refreshed.
> > 
> > If for various reasons we need to update an area outside the screen
> > where the call is located, it is better to ask for a global refresh of
> > the page. (Always simpler for the developer)
> > 
> > Another point to aim for simplicity, which zone to update?
> > We can identify several actions:
> >  * I'm on an item and I want to see related items data
> >  * I'm on an item and I want to refresh that item data
> > 
> > The first case is a defined relation, I will refresh this area with
> > this screen, area that will be generally determined by the decorator.
> > Then, we will talk about the so-called embedded screens: "embedded
> > screen".
> > 
> > The second case is about updating oneself following some sort of
> > procedure, I have to refresh myself. Nothing is best than "knowing it
> > yourself".
> > 
> > It was needed to implement an optimization to facilitate the application
> > of these principles. The idea is that in most cases, the developer
> > doesn't have to think about which zone he needs to specify to display
> > his data.
> > 
> > In order to apply the operation in a homogeneous way, we added new
> > structuring decorators in the common-theme with dedicated zone
> > identifiers allowing each implementation to exploit the refresh.
> > 
> > For example, for a detail screen of an entity (e.g. product categories),
> > we use a "DetailScreenDecorator" decorator. The main refresh area
> > "Associated Objects Details" is the main dynamic area of the screen.
> > We are going to identify precise areas so that each theme can be used in
> > knowledge:
> > * breadcrumb: to display how we see the path to an entity
> > * summary: to display a quick information on this entity
> > * action: different actions available to this entity
> > * navigation: links or other element who help user to navigate on
> >   the entity relation
> > * detail: to display a relation
> > 
> > In our searchn once the list of needs is done, we have exploited the
> > areas for our theme as follows:
> > 
> > 
> >+-+
> >| Catalog -> Category  (BreadCrumb)   |
> >| +-+ |
> >| |   ++| |
> >| |   | Quick Menu || |
> >| |   ++| |
> >| | | |
> >| |  Category Summary   | |
> &

Re: Adopting Github Workflow

[Gil Portenseigne]

Hi,

On Wed, Mar 11, 2020 at 05:08:47PM +0100, Michael Brohl wrote:
> > 
> > - Adopt Github Pull Request (PR) as the unique channel for code contribution
> 
> -1
> 
> I don't see a reason why we should not allow patches also. It will make it
> easier for people to contribute who are not able (or willing) to run their
> own GitHub repository.
> 
> We should encourage people to use PR's but not force it (at least, not
> immediately...).
Agree encouraging is better, but that will become invalid if it is
chosen to use Github as the new way to report issues/improvement
contribution. In that case the patch is a more complex way to
contribute and discuss contributions.
> 
> 
> > - Require tickets only for bug reports
> 
> -1
> 
> Jira tickets for improvements/new features are extremely helpful to have
> everything in one place (with the addition to a link to the mailing list
> discussion), track the efforts, watch issues etc.
> 
> How would you manage the work then?
> 
Agree that being restrictive is not good.


> 
> > - Replace JIRA with Github issues
> 
> -1
> 
> Why should we have two different issue management systems when we can have
> everything in one place? What advantages do you see for doing so?
> 
> I also would not rely too heavily on GitHub because it is not an official
> ASF resource and IMO Jira is a huge knowledge base of the project.
> 
If i understood well the proposal is to *replace* one by another, to
avoid the usage of multiple tools (for PR and issues).
The problematic is the lost of history and like was said github being
external to Apache.

But what Jira do offer that github do not ? Is that possible to keep
Jira as a legacy bugTracker for history sake ? Is that to much work for
us to adapt to this new tool. Do other apache project use github as
their bugTracker, and is that an issue ? This has to be analysed.
> 
> > - Use Github API to get the stats for OFBiz monthly reports
> 
> Can you elaborate what you mean/ how you would do it?
> 
I guess that building reports onto number of PR merged/closed, number of
commit, listing of github issue by type (those that exists, that
matters), etc. 

Thanks



signature.asc
Description: PGP signature

Re: Git history problem

[Gil Portenseigne]

+1

IMO i prefer to rebase and check the commit i push in my local repo.

Thanks


Le 11 mars 2020 16:52:36 GMT+01:00, Mathieu Lirzin  
a écrit :
>>> The simple solution to prevent this is to get into the habit of
>>> linearizing history, meaning always rebasing and clean history
>before
>>> merging into trunk.
>>
>> I guess the GH merge button option "Rebase and merge" is what we are
>> looking to enforce with the request to Infra, right?
>
>I personnally think we should have *no button* because the committers
>should cleanup the commits (reword, squash, ...) before merging to
>trunk, but "rebase and merge" is an improvement compared to basic
>"merge".

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Groovy Migration : createRequirementFromItemATP

[Gil Portenseigne]

Hello !

While migrating createRequirementFromItemATP, i stumbled upon a comment
from David Jones : 
> NOTE DEJ20090902: this service is not called
> anywhere, instead the createATPRequirementsForOrder service (written in
> Java) is called; why this is the case I don't know... -->

I investigate a bit and find out the commit
https://github.com/apache/ofbiz-framework/commit/edc1c0398f77157f590ad99d52e90fc29e251190
That seems to refactor the service.

As createRequirementFromItemATP minilang service seems not used in
project (outside one integration test), should we not deprecated it in
next release (18.12) and remove it in trunk ?

WDYT ?

Regards,

Gil


signature.asc
Description: PGP signature

Re: buildbot failure in on ofbizTrunkFramework

[Gil Portenseigne]

I introduced a test error with my new test, i'll look into it.

Gil

On Fri, Mar 06, 2020 at 03:48:10PM +, build...@apache.org wrote:
> The Buildbot has detected a new failure on builder ofbizTrunkFramework while 
> building ofbiz-framework. Full details are available at:
> https://ci.apache.org/builders/ofbizTrunkFramework/builds/1311
> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: asf947_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
> triggered this build
> Build Source Stamp: [branch trunk] 53a8b812607f9987a1063f18062a5318cafe444c
> Blamelist: Gil Portenseigne 
> 
> BUILD FAILED: failed shell_2
> 
> Sincerely,
>  -The Buildbot
> 
> 
> 


signature.asc
Description: PGP signature

Re: Important Notice on Mailbox Account upgrade for notificati...@ofbiz.apache.org

[Gil Portenseigne]

Nope, same here.



signature.asc
Description: PGP signature

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

[Gil Portenseigne]

+1

On Thu, Feb 27, 2020 at 06:09:34PM +0100, Michael Brohl wrote:
> +1
> 
> ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01 
> ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip
> sha check of file: apache-ofbiz-17.12.01.zip
> Using sha file: apache-ofbiz-17.12.01.zip.sha512
> apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> 5B8A5358 36208F4A D26DEB40
> apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> 5B8A5358 36208F4A D26DEB40
> sha checksum OK
> 
> GPG verification output
> gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID 847AF9E0
> gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY)
> " [ultimate]
> 
> 
> ./gradlew loadAll testIntegration
> 
> ...
> 
> :testIntegration
> 
> BUILD SUCCESSFUL
> 
> 
> Thanks,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> Am 27.02.20 um 10:49 schrieb Jacopo Cappellato:
> > This is the vote thread (3nd attempt) to release "Apache OFBiz 17.12.01":
> > this is the first release, containing the framework, applications and all
> > the plugins from the 17.12 release branches.
> > 
> > The release files can be downloaded from here:
> > https://dist.apache.org/repos/dist/dev/ofbiz/
> > 
> > and are:
> > * apache-ofbiz-17.12.01.zip
> > * KEYS: text file with keys
> > * apache-ofbiz-17.12.01.zip.asc: the detached signature file
> > * apache-ofbiz-17.12.01.zip.sha512: checksum file
> > 
> > Please download the zip file, build and test OFBiz and verify the signature
> > and checksum (for instructions on testing the signatures see
> > http://www.apache.org/info/verification.html).
> > 
> > Vote:
> > 
> > [ +1] release as Apache OFBiz 17.12.01
> > [ -1] do not release
> > 
> > This vote will be open for 5 days.
> > For more details about this process please read
> > http://www.apache.org/foundation/voting.html
> > 
> 




signature.asc
Description: PGP signature

Re: Impersonation feature, was: Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

[Gil Portenseigne]

You understand correctly, and moreover a specific permission must be
granted to allow the user to impersonate another one. And we even added
another security to not allow impersonating a user with more permission
than ourselves.

When we contributed the feature, it was discussed, and improved
regarding the concern that were expressed. And i'm glad that was done
this way (improvement through discussion).

Gil

On Fri, Feb 28, 2020 at 09:01:30AM +0100, Michael Brohl wrote:
> *creating a new thread to leave the vote thread untouched*
> 
> 
> In my understanding from the previous threads about the impersonation
> features, it is disabled by default and must be enabled explicitly.
> 
> Using this feature and dealing with the consequences is up to the user then.
> So I see no valid concern to have this feature in the codebase.
> 
> Am I missing something?
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> Am 28.02.20 um 08:49 schrieb Gil Portenseigne:
> > Hello Pierre,
> > 
> > If you are talking about impersonation feature, that is not in the 17.12
> > branch.
> > 
> > In either way, administrative tools, if we got access to it, allow what
> > your are saying. But there is no security issue that grant these
> > privilege we are aware of. If you do, please share to the security list.
> > 
> > I'm open to discuss about the "criminal" aspect of the impersonation
> > feature, but not on this thread.
> > 
> > Gil
> > 
> > On Fri, Feb 28, 2020 at 02:54:01AM +0100, Pierre Smits wrote:
> > > -1
> > > 
> > > As this release contains software elements that will enable criminal
> > > parties to gain access to the implemented OFBiz system of a user (a
> > > business organisation) and impersonate valid users with the intent to 
> > > bring
> > > harm to the aforementioned business organisation through transactions
> > > registered by the impersonated valid user..
> > > 
> > > Met vriendelijke groet,
> > > 
> > > Pierre Smits
> 




signature.asc
Description: PGP signature

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

[Gil Portenseigne]

Hello Pierre,

If you are talking about impersonation feature, that is not in the 17.12
branch.

In either way, administrative tools, if we got access to it, allow what
your are saying. But there is no security issue that grant these
privilege we are aware of. If you do, please share to the security list.

I'm open to discuss about the "criminal" aspect of the impersonation
feature, but not on this thread.

Gil

On Fri, Feb 28, 2020 at 02:54:01AM +0100, Pierre Smits wrote:
> -1
> 
> As this release contains software elements that will enable criminal
> parties to gain access to the implemented OFBiz system of a user (a
> business organisation) and impersonate valid users with the intent to bring
> harm to the aforementioned business organisation through transactions
> registered by the impersonated valid user..
> 
> Met vriendelijke groet,
> 
> Pierre Smits


signature.asc
Description: PGP signature

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #2

[Gil Portenseigne]

A bit late but +1 !

Thanks

On Fri, Feb 21, 2020 at 09:24:02AM +0100, Jacopo Cappellato wrote:
> This is the vote thread (2nd attempt) to release "Apache OFBiz 17.12.01":
> this is the first release, containing the framework, applications and all
> the plugins from the 17.12 release branches.
> 
> The release files can be downloaded from here:
> https://dist.apache.org/repos/dist/dev/ofbiz/
> 
> and are:
> * apache-ofbiz-17.12.01.zip
> * KEYS: text file with keys
> * apache-ofbiz-17.12.01.zip.asc: the detached signature file
> * apache-ofbiz-17.12.01.zip.sha512: checksum file
> 
> Please download the zip file, build and test OFBiz and verify the signature
> and checksum (for instructions on testing the signatures see
> http://www.apache.org/info/verification.html).
> 
> Vote:
> 
> [ +1] release as Apache OFBiz 17.12.01
> [ -1] do not release
> 
> This vote will be open for 4 days.
> For more details about this process please read
> http://www.apache.org/foundation/voting.html


signature.asc
Description: PGP signature

Re: PMC/Committer resignation

[Gil Portenseigne]

I second Nicolas opinion. I hope that we will evolve and that will allow
you to come back in the community in the future.

Let me thank you again for your time and kind help.

Gil

On Sat, Feb 22, 2020 at 02:51:28PM +0100, Nicolas Malin wrote:
> It's sad new that you sharing.
> 
> This community lose with your resignation huge skill to move forward.
> 
> Nicolas
> 
> On 22/02/2020 12:35, Mathieu Lirzin wrote:
> > Hello,
> >
> > As of today, I am resigning from my PMC and Committer role.
> >
> > My initial involvement with OFBiz started in April 2018 as an internship
> > in the Néréide team to work on the support RESTful Web APIs.  While
> > working on that topic I discovered soon enough that this objective would
> > take a very long time to achieve because of the huge technical debt that
> > has grown over time in the framework internals.  Moreover I have
> > observed that my colleagues were swamped in the accidental complexity of
> > OFBiz (polyglot programming model, cumbersome DSLs, weak typing, ...)
> > which is impacting negatively their ability to deliver value to their
> > client.
> >
> > Following those observations, I have spent a huge amount of my time
> > (including my weekends) trying to understand, remove, refactor existing
> > code to improve OFBiz simplicity which is a pre-requisite for staying
> > relevant in the future.
> >
> > The recent events/discussions lead me to the conclusion that my efforts
> > towards the goal of simplifying OFBiz will simply not be able to succeed
> > due of the required slow review process and the global lack of
> > interest/consensus on that topic.
> >
> > As a consequence I am unable to continue to participate positively in
> > this community anymore.
> >
> > Kind regards,
> >

pub   RSA 3072/ECF12FF4 2019-12-16 Nicolas Malin 
> sub   RSA 3072/40C9B367 2019-12-16
> 


signature.asc
Description: PGP signature

Re: checkstyle improvements

[Gil Portenseigne]

Inline,

> > I'm kinda prefer the "opposite approach", but we need to discuss if this
> > improvement is worth the history lost.
> > 
> > In the example you chose, i see no issue capitalizing module,
> > resource and other. Updating the rule offer the ability to write a
> > constant like : MoDuLe  :-).
> 
> So you are suggesting to use the default configuration for constant names
> and do a refactoring to make the private constants like module, ressource,
> ressource_error follow this configuration (capitalized with underscores)?
> This would result lots of modifications.
I agree, and those because having a rule that do not protect against
strange code, seems not a good fit for Checkstyle.
> 
> I've also seen a configuration option apply the pattern only to
> public/protected constants which could be an alternative to reduce the
> amount of changes, at least in the first iterations.
> 
> I am open for these alternatives, as long as we can manage to get it into
> the codebase smoothly.
Yes that is an option.

> 
> 
> > 
> > Lots of errors are about line that are 120+ length, missing or uneeded
> > space etc.
> > 
> > So that will lead to loads of unrisky modifications. With the usage of
> > IDE with checkstyle plugin this can be done nicely.
> 
> I've seen several plugins for Eclipse, any suggestions of a plugin which is
> able to use our configuration?

I got idea Checkstyle plugin (CheckStyle-Idea) to work with a slight
modification of our configuration, moving "LineLength" module under
"Checker" module [1]

And got it working nicely with the same result as gradle task.
But i'm pretty sure that Eclipse ones will do the job.

But this modification break the gradle task... so we need to clear that
out.

[...]
> > 
> > And like Daniel said, it is a good subject for a community week effort.
> 
> +1
> 
> To make this work out and keep it manageable, we should define some "rules"
> how to approach this.
> 
> For example, I'm thinking of
> 
> - a clear separation of checkstyle modifications and other code corrections
> which might come to mind when reading the code
+1
> 
> - checkstyle modifications should not change the functionality/program code
> in any way. Which means that open API should not be changed either (e.g.
> public constants that might be used in third party functionality). If we
> want to change them, we should deprecate the old and remove in the upcoming
> release branch. So this needs some caution.

That's the hard part.
> 
> - formatting only where it is necessary (no reformatting of the whole file)
+1

Thanks

[1] https://github.com/checkstyle/eclipse-cs/issues/190


signature.asc
Description: PGP signature

Re: checkstyle improvements

[Gil Portenseigne]

Hello Pierre,

It is interesting but i guess that will be the next step.

Thanks

On Fri, Feb 14, 2020 at 09:04:49AM +0100, Pierre Smits wrote:
> It seems many projects (including those Apache projects in the Hadoop
> sphere) use the works of the Apache Yetus (see [1]) project to do
> pre-commit checks (including IIUC checkstyle, in an automate way) on patch
> files attached to JIRA tickets and Pull Requests in Github against the
> latest commit in the branch. This may be helpful to lessen the burden on
> the contributor. When configured correctly, the test results appear in the
> ticket. Apache HBASE is such a project using Yetus, See as an example [2]
> where test results are included through comments of 'Hadoop QA'.
> 
> Maybe we should consider this for our project?
> 
> 
> [1] https://yetus.apache.org
> [2]
> https://issues.apache.org/jira/browse/HBASE-14498?jql=project%20%3D%20HBASE%20AND%20status%20%3D%20%22Patch%20Available%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Best regards,
> 
> Pierre Smits
> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
> <https://ofbiz.apache.org/>, since 2008
> 
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> Apache Steve <https://steve.apache.org>, committer
> 
> 
> On Thu, Feb 13, 2020 at 9:13 PM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
> 
> > Hello Michael,
> >
> > Adapting checkstyle configuration is less impacting to our codebase but
> > make us stay different from the java standard.
> > That is the easier path, that will not affect code history.
> >
> > But about getting nearer from the java standard is IMO a nice to have, to
> > make pure java developer feel better discovering OFBiz.
> > I'm kinda prefer the "opposite approach", but we need to discuss if this
> > improvement is worth the history lost.
> >
> > In the example you chose, i see no issue capitalizing module,
> > resource and other. Updating the rule offer the ability to write a
> > constant like : MoDuLe  :-).
> >
> > Lots of errors are about line that are 120+ length, missing or uneeded
> > space etc.
> >
> > So that will lead to loads of unrisky modifications. With the usage of
> > IDE with checkstyle plugin this can be done nicely.
> > I check that over the near thousand of java file concerned more than 80%
> > have less than 50 issue... So we can focus our effort onto the big files
> > using a branch to test the idea and ease the issue.
> >
> > And like Daniel said, it is a good subject for a community week effort.
> >
> > I'd really like to be able to efficiently use this feature, in one way
> > or the other, so thank you for starting this discussion.
> >
> > Regards,
> >
> > Gil
> >
> >
> > On Thu, Feb 13, 2020 at 05:44:40PM +0100, Michael Brohl wrote:
> > > Hi *,
> > >
> > > checkstyle currently reports a huge amount of errors. We currently have
> > an
> > > error count setup in the configuration to prevent the build from failing
> > > because of the present errors.
> > >
> > > Some thoughts/questions to the community:
> > >
> > > * should we take an approach to fine-tune the  configuration so that it
> > > better fits the project style?
> > >
> > > As an example, constants are currently not allowed to be named "module",
> > > "resource" etc. which is a common pattern in our code. Changing from
> > > ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ to ^[a-zA-Z][a-zA-Z0-9]*(_[a-zA-Z0-9]+)*$
> > > would allow the common naming.
> > >
> > > The opposite approach would be to rename those to fit the default
> > settings.
> > >
> > > * should we start an initiative to remove the valid errors like we did
> > with
> > > the FindBugs initiative some time ago?
> > >
> > >
> > > Thanks for your feedback,
> > >
> > > Michael Brohl
> > >
> > > ecomify GmbH - www.ecomify.de
> > >
> > >
> >
> >
> >


signature.asc
Description: PGP signature

Re: checkstyle improvements

[Gil Portenseigne]

Hello Michael,

Adapting checkstyle configuration is less impacting to our codebase but
make us stay different from the java standard.
That is the easier path, that will not affect code history.

But about getting nearer from the java standard is IMO a nice to have, to
make pure java developer feel better discovering OFBiz.
I'm kinda prefer the "opposite approach", but we need to discuss if this
improvement is worth the history lost.

In the example you chose, i see no issue capitalizing module,
resource and other. Updating the rule offer the ability to write a
constant like : MoDuLe  :-).

Lots of errors are about line that are 120+ length, missing or uneeded
space etc.

So that will lead to loads of unrisky modifications. With the usage of
IDE with checkstyle plugin this can be done nicely.
I check that over the near thousand of java file concerned more than 80%
have less than 50 issue... So we can focus our effort onto the big files
using a branch to test the idea and ease the issue.

And like Daniel said, it is a good subject for a community week effort.

I'd really like to be able to efficiently use this feature, in one way
or the other, so thank you for starting this discussion.

Regards,

Gil


On Thu, Feb 13, 2020 at 05:44:40PM +0100, Michael Brohl wrote:
> Hi *,
> 
> checkstyle currently reports a huge amount of errors. We currently have an
> error count setup in the configuration to prevent the build from failing
> because of the present errors.
> 
> Some thoughts/questions to the community:
> 
> * should we take an approach to fine-tune the  configuration so that it
> better fits the project style?
> 
> As an example, constants are currently not allowed to be named "module",
> "resource" etc. which is a common pattern in our code. Changing from
> ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ to ^[a-zA-Z][a-zA-Z0-9]*(_[a-zA-Z0-9]+)*$
> would allow the common naming.
> 
> The opposite approach would be to rename those to fit the default settings.
> 
> * should we start an initiative to remove the valid errors like we did with
> the FindBugs initiative some time ago?
> 
> 
> Thanks for your feedback,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 




signature.asc
Description: PGP signature

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Gil Portenseigne]

It's an error while cherry picking the bugFix from trunk.

I will revert.

On Wed, Feb 12, 2020 at 12:10:46PM +0100, Gil Portenseigne wrote:
> Yes, i'm on it...
> On Wed, Feb 12, 2020 at 11:56:14AM +0100, Jacques Le Roux wrote:
> > It's OK, but we have now a compilation in R17: 
> > https://ci.apache.org/builders/ofbizBranch17Framework
> > 
> > Please Gil have a look
> > 
> > Thanks
> > 
> > Le 12/02/2020 à 09:00, Jacques Le Roux a écrit :
> > > Hi Michael,
> > > 
> > > There were no issues before your commit:
> > > 
> > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins
> > > 
> > > And it was not squashed with another one:
> > > 
> > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150
> > > 
> > > I suspect a Buildbot error, I'm testing locally to confirm. I'll also 
> > > launch the same on Buildbot
> > > 
> > > Jacques
> > > 
> > > Le 12/02/2020 à 07:57, Michael Brohl a écrit :
> > > > Hi all,
> > > > 
> > > > the errors reported during the build (test classes not found) do not 
> > > > seem to have been introduced by my latest change.
> > > > 
> > > > Any ideas where this come from?
> > > > 
> > > > See 
> > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150/steps/shell_5/logs/stdio
> > > > 
> > > > Best regards,
> > > > 
> > > > Michael Brohl
> > > > 
> > > > ecomify GmbH - www.ecomify.de
> > > > 
> > > > Am 11.02.20 um 23:51 schrieb build...@apache.org:
> > > > > The Buildbot has detected a new failure on builder 
> > > > > ofbizTrunkFrameworkPlugins while building ofbiz-framework. Full 
> > > > > details are available at:
> > > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150
> > > > > 
> > > > > Buildbot URL: https://ci.apache.org/
> > > > > 
> > > > > Buildslave for this Build: asf946_ubuntu
> > > > > 
> > > > > Build Reason: downstream
> > > > > Build Source Stamp: [branch trunk] 
> > > > > 3788f6766a01eb476c15d32e6b9d9127061d12f4
> > > > > Blamelist: Michael Brohl 
> > > > > 
> > > > > BUILD FAILED: failed shell_5
> > > > > 
> > > > > Sincerely,
> > > > >   -The Buildbot
> > > > > 
> > > > > 
> > > > > 
> > > > 




signature.asc
Description: PGP signature

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Gil Portenseigne]

Yes, i'm on it...
On Wed, Feb 12, 2020 at 11:56:14AM +0100, Jacques Le Roux wrote:
> It's OK, but we have now a compilation in R17: 
> https://ci.apache.org/builders/ofbizBranch17Framework
> 
> Please Gil have a look
> 
> Thanks
> 
> Le 12/02/2020 à 09:00, Jacques Le Roux a écrit :
> > Hi Michael,
> > 
> > There were no issues before your commit:
> > 
> > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins
> > 
> > And it was not squashed with another one:
> > 
> > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150
> > 
> > I suspect a Buildbot error, I'm testing locally to confirm. I'll also 
> > launch the same on Buildbot
> > 
> > Jacques
> > 
> > Le 12/02/2020 à 07:57, Michael Brohl a écrit :
> > > Hi all,
> > > 
> > > the errors reported during the build (test classes not found) do not seem 
> > > to have been introduced by my latest change.
> > > 
> > > Any ideas where this come from?
> > > 
> > > See 
> > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150/steps/shell_5/logs/stdio
> > > 
> > > Best regards,
> > > 
> > > Michael Brohl
> > > 
> > > ecomify GmbH - www.ecomify.de
> > > 
> > > Am 11.02.20 um 23:51 schrieb build...@apache.org:
> > > > The Buildbot has detected a new failure on builder 
> > > > ofbizTrunkFrameworkPlugins while building ofbiz-framework. Full details 
> > > > are available at:
> > > > https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1150
> > > > 
> > > > Buildbot URL: https://ci.apache.org/
> > > > 
> > > > Buildslave for this Build: asf946_ubuntu
> > > > 
> > > > Build Reason: downstream
> > > > Build Source Stamp: [branch trunk] 
> > > > 3788f6766a01eb476c15d32e6b9d9127061d12f4
> > > > Blamelist: Michael Brohl 
> > > > 
> > > > BUILD FAILED: failed shell_5
> > > > 
> > > > Sincerely,
> > > >   -The Buildbot
> > > > 
> > > > 
> > > > 
> > > 


signature.asc
Description: PGP signature

Re: In preparation for the first release from 17.12

[Gil Portenseigne]

Yes, it is a good way to go.

Thanks Jacopo

On Tue, Feb 11, 2020 at 03:38:46PM +0100, Jacopo Cappellato wrote:
> So far it seems that we are in favor of releasing the full version
> (framework + plugins) named "Apache OFBiz 17.12.01" and then also the
> version without the plugins.
> If this is the direction we will take, would it be ok if we first focus and
> release the full version "Apache OFBiz 17.12.01" (framework + plugins) and
> we postpone the preparation/vote for the framework only version? In this
> way we could all focus on one release and could publish it soon (vote
> starting this week or the next) and make sure that we do it right; once it
> will be published and once we will have all the details documented in our
> download page we could focus on the preparation for the new sections and
> explanations for the framework only version so that our users don't get
> confused.
> 
> Jacopo
> 
> 
> On Sat, Feb 8, 2020 at 11:04 AM Jacopo Cappellato <
> jacopo.cappell...@gmail.com> wrote:
> 
> > Hi all,
> >
> > based on various threads in this list, the time we will prepare the first
> > release from the 17.12 branch is getting close and, since this is the first
> > one in which the plugins are separated from the framework, there are a
> > few decisions to take.
> >
> > Should we release two products or just one as in the past?
> > Two products mean:
> > "Apache OFBiz Framework 17.12.01"
> > and
> > "Apache OFBiz Plugins 17.12.01"
> > One product mean"
> > "Apache OFBiz 17.12.01" (framework + plugins)
> >
> > Alternatively, we could publish the two products at different times; first
> > publish "Apache OFBiz Framework 17.12.01" and then later in the year
> > publish "Apache OFBiz Plugins 17.12.01"; if this is going to happen then we
> > could have for example multiple releases of the Plugins based on the same
> > release of the framework.
> >
> > One other option is to release independently each plugin (or the ones that
> > we consider stable enough) rather than all the plugins in one file.
> >
> > Thanks,
> >
> > Jacopo
> >
> >


signature.asc
Description: PGP signature

Re: In preparation for the first release from 17.12

[Gil Portenseigne]

+1

Regards,

Gil

On Mon, Feb 10, 2020 at 05:02:18PM +0100, Nicolas Malin wrote:
> Hi,
> 
> I most in favor to propose two products like :
> 
>     "Apache OFBiz Framework 17.12.01" (framework)
> and
>     "Apache OFBiz Full 17.12.01" (framework + plugins)
> 
> For advanced user, they would use the framework only and retrieve wanted
> plugins.
> 
> For discovery, the full version would be available and recommended.
> 
> I don't think that publish plugins alone or each plugin alone would be
> an interest for user
> 
> Nicolas
> 
> On 08/02/2020 11:04, Jacopo Cappellato wrote:
> > Hi all,
> >
> > based on various threads in this list, the time we will prepare the first
> > release from the 17.12 branch is getting close and, since this is the first
> > one in which the plugins are separated from the framework, there are a
> > few decisions to take.
> >
> > Should we release two products or just one as in the past?
> > Two products mean:
> > "Apache OFBiz Framework 17.12.01"
> > and
> > "Apache OFBiz Plugins 17.12.01"
> > One product mean"
> > "Apache OFBiz 17.12.01" (framework + plugins)
> >
> > Alternatively, we could publish the two products at different times; first
> > publish "Apache OFBiz Framework 17.12.01" and then later in the year
> > publish "Apache OFBiz Plugins 17.12.01"; if this is going to happen then we
> > could have for example multiple releases of the Plugins based on the same
> > release of the framework.
> >
> > One other option is to release independently each plugin (or the ones that
> > we consider stable enough) rather than all the plugins in one file.
> >
> > Thanks,
> >
> > Jacopo
> >

pub   RSA 3072/ECF12FF4 2019-12-16 Nicolas Malin 
> sub   RSA 3072/40C9B367 2019-12-16
> 


signature.asc
Description: PGP signature

Re: svn commit: r1828233 - /ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java

[Gil Portenseigne]

+1 for the fix.

On Tue, Feb 04, 2020 at 12:22:48PM +0100, Michael Brohl wrote:
> During a migration I found that this bugfix was not backported to the 17.12
> release branch.
> 
> Should I do it now?
> 
> Regards,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> Am 03.04.18 um 15:06 schrieb mbr...@apache.org:
> > Author: mbrohl
> > Date: Tue Apr  3 13:06:28 2018
> > New Revision: 1828233
> > 
> > URL: http://svn.apache.org/viewvc?rev=1828233=rev
> > Log:
> > Fixed: Prevent possible NullPointerException.
> > 
> > Modified:
> >  
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> > 
> > Modified: 
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> > URL: 
> > http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java?rev=1828233=1828232=1828233=diff
> > ==
> > --- 
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> >  (original)
> > +++ 
> > ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
> >  Tue Apr  3 13:06:28 2018
> > @@ -210,8 +210,11 @@ public class FinAccountServices {
> >   Timestamp now = UtilDateTime.nowTimestamp();
> >   // now use our values
> > -String finAccountCode = 
> > FinAccountHelper.getNewFinAccountCode(accountCodeLength.intValue(), 
> > delegator);
> > -inContext.put("finAccountCode", finAccountCode);
> > +String finAccountCode = null;
> > +if (UtilValidate.isNotEmpty(accountCodeLength)) {
> > +finAccountCode = 
> > FinAccountHelper.getNewFinAccountCode(accountCodeLength.intValue(), 
> > delegator);
> > +inContext.put("finAccountCode", finAccountCode);
> > +}
> >   // with pin codes, the account code becomes the ID and the 
> > pin becomes the code
> >   if ("Y".equalsIgnoreCase(requirePinCode)) {
> > 
> > 
> 




signature.asc
Description: PGP signature

Re: Github & notifications

[Gil Portenseigne]

+1

If we do not decide of replacing Jira with Github or another BT, we must
keep Jira for contribution tracking.

There might be a jira integration in github for that ?

Gil

On Mon, Feb 03, 2020 at 12:16:11PM +0100, Michael Brohl wrote:
> I'm automatically informed about the pull requests, I think that all
> committers get those emails.
> 
> IMO, we should make the creation of a Jira mandatory independent of the
> contribution channel (patch or PR). That would inform everyone about the
> contribution and we have a valid starting point for questions, discussion
> etc. regarding the contribution.
> 
> I feel that solely handling this on Github does not increase transparency.
> 
> Regards,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> Am 03.02.20 um 12:07 schrieb Pierre Smits:
> > Hi All,
> > 
> > With the move to Git, we can expect more pull request from Github (see also
> > other threads where postings regarding feature branches appeared).
> > Unfortunately, currently no notifications appear in a mailing list when
> > those PullRequests are initiated.
> > 
> > It seems to me that, if we  want to get more engagements (from github
> > contributors), aspects such as PullRequests should sent a notification to
> > the dev ml. Otherwise these PullRequests remain in limbo, and we risk of
> > losing these contributors.
> > 
> > 
> > Best regards,
> > 
> > Pierre Smits
> > 
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without privileges)
> > since 2008*
> > Apache Steve , committer
> > 
> 




signature.asc
Description: PGP signature

Re: [PROPOSAL] Environment variable configuration

[Gil Portenseigne]

Hello,

Thanks for proposing your tried and tested configuration solution. The
idea of discussion the original proposal about OFBiz configuration with
environment variable stayed in my head.

In the light of your solution and with our implementation feedback (git
branching configuration + env variable), and others contributors
feedback, we might elaborate the best to ease configuration management.

Thanks and Regards.

Gil


On Sun, Feb 02, 2020 at 04:40:14PM +0100, Michael Brohl wrote:
> Hi everyone,
> 
> the recent discussions reminded me of this thread again. There were a few
> people who were curious how we do configuration management and deployment
> (now in production for about 10 years). It is working for projects based on
> releases 13, 16, 17, 18 and trunk (with either Ant or Gradle).
> 
> Although we have our ways to maintain this as not being part of the official
> OFBiz codebase, I still think it is a good approach worth contributing.
> 
> Is this interesting for the community?
> 
> If there is significant interest I would try to re-write the proposal I did
> in [1], updated to the newest Gradle mechanism and several aspects for multi
> stage projects.
> 
> Cheers,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> [1] 
> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> 
> 
> Am 17.11.17 um 22:18 schrieb Michael Brohl:
> > Hi Jacques,
> > 
> > it takes some effort to make an OFBiz standard compatible patch of the
> > mechanism because we have several additions to the configurations. I
> > would take the effort if the community wants to adapt it but it's too
> > much work for just giving an idea.
> > 
> > I have explained the mechanism in [1]. There it is based on Ant but we
> > already use it in projects with Gradle.
> > 
> > We were looking for other solutions during the migration to Gradle but
> > haven't found a better approach considering all pros and cons (database
> > configuration, environment variables etc.). We use it for years on our
> > test- and production environments and it makes the handling of different
> > system specific configurations very easy.
> > 
> > We are thinking about the introduction of an additional configuration
> > level so that we have the base configuration (containing all
> > properties), a project configuration level and the system specific
> > configurations. This helps us to additionally maintain projects using
> > different sets of plugins.
> > 
> > I'm happy to explain more if something is unclear.
> > 
> > Regards,
> > 
> > Michael
> > 
> > 
> > [1] 
> > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> > 
> > 
> > Am 03.11.17 um 11:39 schrieb Jacques Le Roux:
> > > That's quite interesting Michael,
> > > 
> > > Would you share in a Jira? Then we could get to merge all
> > > experiences and find a consensu.
> > > 
> > > Jacques
> > > 
> > > 
> > > Le 03/11/2017 à 10:10, Michael Brohl a écrit :
> > > > Just an update triggered by the question from Swapnil [1]: our
> > > > configuration mechanism mentioned below is now on Gradle so it
> > > > would be compatible with 16.11 and later.
> > > > 
> > > > Regards,
> > > > 
> > > > Michael
> > > > 
> > > > [1] 
> > > > https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
> > > > 
> > > > 
> > > > Am 05.07.17 um 17:56 schrieb Michael Brohl:
> > > > > Hi Gil,
> > > > > 
> > > > > we have similar challenges and modified OFBiz to deal with
> > > > > it easily. We offered to contribute this long time ago
> > > > > (2008) but it was decided against [1]. It was suggested to
> > > > > use patches instead but I think it's too complicated to
> > > > > manage several patch sets for different environments.
> > > > > 
> > > > > We now use a staged configure mechanism which uses a base
> > > > > build file, auto detected machine name and provided
> > > > > parameters to decide which configurations should be pulled
> > > > > for the environment. It's currently Ant based and therefore
> > > > > does not fit into the current build mechanism (on the todo
> > > >

Re: Removing “base/config/component-load.xml”

[Gil Portenseigne]

I agree with Jacques, i tried several times to participate in the
discussion but i am confused about the situation.

About this situation, Michael, we get your point about the process of
discuss things before modifying not trivial code and I do agree with
that. But there can always be mistakes.

I'm pretty sure that Mathieu's intentions are well guided, and reading
this last email about the bad process of Mathieu contribution make me
feel bad for him.

I hope we can get past this, now that it is clear, and work together
about the technical aspects, which will make it easier for people to
intervene.

Thanks and best regards.

Gil



On Fri, Jan 31, 2020 at 04:47:41PM +0100, Jacques Le Roux wrote:
> This is exactly the reason why I would prefer to start a new. Things get 
> confusing.
> 
> I'd finally prefer a new clean thread with the pro and cons for everybody to
> make an opinion which would allow to start a vote, since a consensus can't
> be reached
> 
> I hope Mathieu could write the pro...
> 
> If we agree on that one of us can star the new clean thread and we can focus 
> on the underneath of the problem w/o digressing
> 
> I know it's another effort for you and Mathieu, but I can't see a better way 
> to avoid drowning less concerned people in details.
> 
> We really need to focus, thanks
> 
> Jacques
> 
> Le 31/01/2020 à 16:11, Michael Brohl a écrit :
> > Pleas see my previous email, the discussion thread link is there (citating 
> > your own statement...)
> > 
> > Thanks,
> > 
> > Michael
> > 
> > 
> > Am 31.01.20 um 15:34 schrieb Jacques Le Roux:
> > > Le 31/01/2020 à 15:04, Michael Brohl a écrit :
> > > > Hi Jacques,
> > > > 
> > > > inline...
> > > > > 
> > > > > Maybe better to create a new thread?
> > > > 
> > > > We already have a thread for it, started on 22. August 2019. I
> > > > would very much appreciate if experienced users/developers would
> > > > join this discussion (which I have missed being on vacation at
> > > > the time and, having not much response, did not get my attention
> > > > until now).
> > > 
> > > Could you please send a link to this thread or its title? I could not 
> > > find it easily
> > > 
> > > Thanks
> > > 
> > > Jacques
> > > 
> > 


signature.asc
Description: PGP signature

Re: [VOTE] [RELEASE] Apache OFBiz 16.11.07

[Gil Portenseigne]

+1

Thanks

On Fri, Jan 31, 2020 at 12:16:54AM +0530, Deepak Dixit wrote:
> +1
> 
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
> 
> 
> On Thu, Jan 30, 2020 at 9:56 PM Nicolas Malin 
> wrote:
> 
> > +1
> >
> > Same result from my local
> >
> > Nicolas
> >
> > On 30/01/2020 16:06, Michael Brohl wrote:
> > > +1
> > >
> > >
> > > ~/Projects/apache-ofbiz/check-release-16.11.07 
> > > ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-16.11.07.zip
> > > sha check of file: apache-ofbiz-16.11.07.zip
> > > Using sha file: apache-ofbiz-16.11.07.zip.sha512
> > > apache-ofbiz-16.11.07.zip: EF6D32A6 7A2C2776 50FBE2B4 47E43D45
> > > BB503EA5 2C84A604 9CA62AD3 6F180589 1C9C7CC3 F4EE67D2 1393957F
> > > E51B9525 0A203A6F D093698E 7B8A9A5B DACC8920
> > > apache-ofbiz-16.11.07.zip: EF6D32A6 7A2C2776 50FBE2B4 47E43D45
> > > BB503EA5 2C84A604 9CA62AD3 6F180589 1C9C7CC3 F4EE67D2 1393957F
> > > E51B9525 0A203A6F D093698E 7B8A9A5B DACC8920
> > > sha checksum OK
> > >
> > > GPG verification output
> > > gpg: Signature made Thu Jan 30 12:24:18 2020 CET using RSA key ID
> > > 847AF9E0
> > > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY)
> > > " [ultimate]
> > >
> > >
> > > ~/Projects/apache-ofbiz/check-release-16.11.07/apache-ofbiz-16.11.07 
> > > ./gradlew loadDefault testIntegration
> > >
> > > ...
> > >
> > > BUILD SUCCESSFUL
> > >
> > > Total time: 3 mins 45.218 secs
> > >
> > >
> > > Thanks,
> > >
> > > Michael
> > >
> > >
> > >
> > >
> > > Michael Brohl
> > > Geschäftsführer
> > >
> > > Fon  +49 521 448 157-91
> > > Fax  +49 521 448 157-99
> > > Mobil+49 160 3664918
> > > Xing xing.com/profile/Michael_Brohl
> > > LinkedIn linkedin.com/in/michaelbrohl
> > >
> > > Company and Management Headquarters:
> > > ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
> > > Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de
> > >
> > > Court Registration: Amtsgericht Bielefeld HRB 41683
> > > Chief Executive Officer: Martin Becker, Michael Brohl
> > >
> > > Am 30.01.20 um 15:13 schrieb Jacopo Cappellato:
> > >>   This is the vote thread to release a new bug fix release for the
> > >> release16.11 branch. This new release, "Apache OFBiz 16.11.07" will
> > >> supersede all the previous releases from the same branch.
> > >> Please consider that this may be the last release in the 16.11 series
> > >> and
> > >> in the future releases will be published from the newer series only.
> > >>
> > >> The release files can be downloaded from here:
> > >> https://dist.apache.org/repos/dist/dev/ofbiz/
> > >>
> > >> and are:
> > >> * apache-ofbiz-16.11.07.zip
> > >> * KEYS: text file with keys
> > >> * apache-ofbiz-16.11.07.zip.asc: the detached signature file
> > >> * apache-ofbiz-16.11.07.zip.sha512: checksum file
> > >>
> > >> Please download and test the zip file and its signatures (for
> > >> instructions
> > >> on testing the signatures see
> > >> http://www.apache.org/info/verification.html).
> > >>
> > >> Vote:
> > >> [ +1] release as Apache OFBiz 16.11.07
> > >> [ -1] do not release
> > >>
> > >> This vote will be open for 5 days.
> > >> For more details about this process refer to
> > >> http://www.apache.org/foundation/voting.html
> > >>
> > >> Kind Regards,
> > >>
> > >> Jacopo
> > >>
> > >
> >


signature.asc
Description: PGP signature

Re: [DISCUSSION] R16 and R17: email password issue and releases

[Gil Portenseigne]

I wonder if it is bad for the project to have 2 years between two
releases, 16 => 18 => 20

WDYT ?

Gil

On Fri, Jan 24, 2020 at 05:31:14PM +0100, Jacques Le Roux wrote:
> Le 24/01/2020 à 15:09, Nicolas Malin a écrit :
> > On 24/01/2020 14:57, Jacques Le Roux wrote:
> > 
> > > I must say I'm mostly against because of the surplus of effort
> > > necessary to backport to both R17 and R18
> > > 
> > > About R20, as Pierre Smits mentioned in Slack should we not create a
> > > R19 before ;)
> > If we follow the years, 2019 is now behind.
> 
> Actually it's not a set in stone rule, we could still create a R19 branch, 
> why wait one year more, and at least 2 years to publish R20?
> 
> Jacques


signature.asc
Description: PGP signature

Re: [VOTE] Do not release R17 and directly publish R18 instead.

[Gil Portenseigne]

+1

On Fri, Jan 24, 2020 at 11:27:15AM +0100, Jacques Le Roux wrote:
> Hi,
> 
> R16 is now an old distribution and has almost reached its end of support. We
> can soon expect a last release but we need to think about the next to be
> released package
> 
> Some would prefer to release R17 before releasing R18, some would prefer to 
> bypass R17 release and directly publish R18 instead.
> 
> Vote:
> [ +1] Do not release R17 and directly publish R18 instead.
> [ -1]  Release R17 before releasing R18
> 
> We had already 3 months to discuss without reaching a consensus, so this vote 
> will be only open for a week.
> 
> Note that it's not a formal vote to release R17 or R18, as that is another 
> process documented at
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> 
> Thank you for your attention
> 
> Jacques
> 


signature.asc
Description: PGP signature

Chapter two: Rules to dynamize screen

[Gil Portenseigne]

Hello !

In previous thread we focused on the process of how to define a dynamic
workflow that raises some questions.

Let's go back to our principles: we have to find simple things, limit
the possibilities (do little but good) and remember that on the
backoffice it's end-users who are focused on specific tasks.

To make it simple, implement screen dynamism that will generate
alterations of the dom, to limit side effects, we establish the
following principles:
  * We can only ask for an update of the area known by the calling
element.

Knowing that the element of coherence in the screen engine is the
screen itself, we can refine this rule on the following basis
  * An element triggering a screen update, can only update elements
present within the screen where it belongs.

Why did we made this choice? We will see it below, but the goal is
always to make writing easier for the developer by avoiding him to
wonder what is the value of the area to be refreshed.

If for various reasons we need to update an area outside the screen
where the call is located, it is better to ask for a global refresh of
the page. (Always simpler for the developer)

Another point to aim for simplicity, which zone to update?
We can identify several actions:
 * I'm on an item and I want to see related items data
 * I'm on an item and I want to refresh that item data

The first case is a defined relation, I will refresh this area with
this screen, area that will be generally determined by the decorator.
Then, we will talk about the so-called embedded screens: "embedded
screen".

The second case is about updating oneself following some sort of
procedure, I have to refresh myself. Nothing is best than "knowing it
yourself".

It was needed to implement an optimization to facilitate the application
of these principles. The idea is that in most cases, the developer
doesn't have to think about which zone he needs to specify to display
his data.

In order to apply the operation in a homogeneous way, we added new
structuring decorators in the common-theme with dedicated zone
identifiers allowing each implementation to exploit the refresh.

For example, for a detail screen of an entity (e.g. product categories),
we use a "DetailScreenDecorator" decorator. The main refresh area
"Associated Objects Details" is the main dynamic area of the screen.
We are going to identify precise areas so that each theme can be used in
knowledge:
* breadcrumb: to display how we see the path to an entity
* summary: to display a quick information on this entity
* action: different actions available to this entity
* navigation: links or other element who help user to navigate on
  the entity relation
* detail: to display a relation

In our searchn once the list of needs is done, we have exploited the
areas for our theme as follows:


   +-+
   | Catalog -> Category  (BreadCrumb)   |
   | +-+ |
   | |   ++| |
   | |   | Quick Menu || |
   | |   ++| |
   | | | |
   | |  Category Summary   | |
   | | | |
   | +-+ |
   | |
   | +-+ |
   | |Tab Menu | menu1 | menu2 | menu3 | |
   | |-| |
   | || |
   | | | |
   | |  Associated Objects Details | |
   | | | |
   | | | |
   | | | |
   | | | |
   | +-+ |
   +-+


The decorator will set a variable "detailArea" in the context of this
screen, which contains the id of the div to refresh to present a new
screen (products of the category for example).

The positioning of this type of variable facilitates the constraint on
the developer to refresh an area of the screen, if he wants to code the
Tab menu in a simplified way.

Also we are speaking about technical decorator, because we think that it
is necessary to add business decorators implementing those, facilitating
the recovery of information from the main object that is processed.

But we will discuss this in another mail Chapter 3 : promoting decorator
usage

Best Regards,

Leila, Nicolas and Gil




signature.asc
Description: PGP signature

Re: [DISCUSSION] Make Back-Office screens dynamic

[Gil Portenseigne]

Hello James,

Thanks for the reference we will look into that.

Regards,

On Fri, Jan 10, 2020 at 03:50:23PM -, James Yong wrote:
> Hi Gil,
> 
> I wonder if this library helps for a start:
> https://github.com/joshualjohnson/jquery.x
> 
> Regards,
> James
> 


signature.asc
Description: PGP signature

Re: [DISCUSSION] Make Back-Office screens dynamic

[Gil Portenseigne]

Thanks Gavin for sharing, i have a clearer view now :).

Le 17:05 - mardi 17 déc., Gavin Mabie a écrit :
> Hi Gil
> 
> I used a type=groovy service to resolve the form location eg.
> /*
> *@paramater formLocaction (where the form resides in the system)
> *@parameter formName (passed as request parameter)
> * returns an Ofbiz form entity with all the normal functionalties
> associated with ModelForm
> * this is returned to the http request as a JSON objecct
> */
> ModelForm form = FormFactory.getFormFromLocation(formLocation, formName,
> entityModelReader, dispatchContext);
> 
> Angular handles the response through a formField service which reads each
> Ofbiz formfields (JSON object) and creates a Angular reactive form from
> there. The Angualr formFields Service mirrors the Ofbiz field types etc.
> 
> Regards
> 
> Gavin
> 
> 
> 
> 
> 
> 
> 
> On Tue, Dec 17, 2019 at 4:21 PM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
> 
> > Hello Gavin,
> >
> > Thanks for four feedback, that's very interesting !
> >
> > Could you elaborate about the OFBiz forms usage you did in your angular
> > implementation ?
> > You just used view-map with simple screen/form ?
> >
> > Cheers !
> >
> > Gil
> >
> > Le 12:26 - mardi 17 déc., Gavin Mabie a écrit :
> > > Hi Taher
> > >
> > > I've been using Angular for custom apps over the past year.  This is my
> > > approach:
> > >
> > > 1. Ofbiz deployed as an AppServer:
> > > 1.1 Ofbiz controller resolves API request calls;
> > > 1.2 Ofbiz Service Engine executes Services;
> > > 1.3 Entity Engine for persistence;
> > > 1.4 Returns JSON object - including Ofbiz context;;
> > > 1.5 Ofbiz Forms used for additional business logic, fields etc;
> > > 1.6 Ofbiz Screens not used at all.
> > >
> > > 2. Angular (On Apache HTTPD or Ionic/Cordova/JQueryMobile or even
> > > JAVAFX(haven't tried this, but it's possible)):
> > > 2.1 Typescripting types for Ofbiz entities used;
> > > 2.2 Angular services for API calls corresponding to controller
> > > request-mappings;
> > > 2.3 Dynamic Angular Forms - based on Ofbiz Form defs;
> > > 2.4 Other static content;
> > >
> > > 3. Authentication
> > > 3.1 With JWT;
> > > 3.2 Sessionless & no cookies;
> > > 3.3 Ofbiz LoginWorker & Permission Engine for authorization;
> > >
> > > The big takeaway here is that Ofbiz Screens aren't used at all.  Ofbiz
> > > Forms are used to set fields, execute services and deal with issues like
> > > locale etc.
> > >
> > > Cheers
> > >
> > > gavin
> > >
> > >
> > >
> > >
> > > On Sat, Dec 14, 2019 at 6:52 PM Taher Alkhateeb <
> > slidingfilame...@gmail.com>
> > > wrote:
> > >
> > > > Hello Gil,
> > > >
> > > > Great research on the subject, thank you for sharing.
> > > >
> > > > I could be wrong here, but at a first glance it seems you want to
> > > > essentially create a tag " > > > another screen dynamically upon clicking / activating the URL. If my
> > > > understanding is correct, then most likely they way you want to
> > > > implement this is probably some web request to the backend which
> > > > renders back a partial screen that you insert into the DOM right?
> > > >
> > > > If what I describe above is close to your idea, then I think the
> > > > implementation might be relying on the server to do the work of
> > > > painting instead of relying on the browser to do the heavy lifting.
> > > > This also only works with one widget, which is the URL widget as
> > > > opposed to having a general purpose dynamic behavior in the system
> > > > (assuming this is desired).
> > > >
> > > > However, having a general purpose dynamic behavior means we need a
> > > > method to bind variables to values at the front end without consulting
> > > > the back-end. This reduces the load on the server and provides a
> > > > faster / richer experience to the user. But it would be too painful to
> > > > rely on plain javascript or jQuery to achieve such a result which is
> > > > the reason why frameworks like React, Vue, and others emerged as
> > > > modern SPA frameworks. Adopting an SPA framework would provide dynamic
> > > > behavior (everywhere) instead of certain widgets, an

Re: [DISCUSSION] Make Back-Office screens dynamic

[Gil Portenseigne]

Hello Gavin,

Thanks for four feedback, that's very interesting !

Could you elaborate about the OFBiz forms usage you did in your angular
implementation ?
You just used view-map with simple screen/form ?

Cheers !

Gil

Le 12:26 - mardi 17 déc., Gavin Mabie a écrit :
> Hi Taher
> 
> I've been using Angular for custom apps over the past year.  This is my
> approach:
> 
> 1. Ofbiz deployed as an AppServer:
> 1.1 Ofbiz controller resolves API request calls;
> 1.2 Ofbiz Service Engine executes Services;
> 1.3 Entity Engine for persistence;
> 1.4 Returns JSON object - including Ofbiz context;;
> 1.5 Ofbiz Forms used for additional business logic, fields etc;
> 1.6 Ofbiz Screens not used at all.
> 
> 2. Angular (On Apache HTTPD or Ionic/Cordova/JQueryMobile or even
> JAVAFX(haven't tried this, but it's possible)):
> 2.1 Typescripting types for Ofbiz entities used;
> 2.2 Angular services for API calls corresponding to controller
> request-mappings;
> 2.3 Dynamic Angular Forms - based on Ofbiz Form defs;
> 2.4 Other static content;
> 
> 3. Authentication
> 3.1 With JWT;
> 3.2 Sessionless & no cookies;
> 3.3 Ofbiz LoginWorker & Permission Engine for authorization;
> 
> The big takeaway here is that Ofbiz Screens aren't used at all.  Ofbiz
> Forms are used to set fields, execute services and deal with issues like
> locale etc.
> 
> Cheers
> 
> gavin
> 
> 
> 
> 
> On Sat, Dec 14, 2019 at 6:52 PM Taher Alkhateeb 
> wrote:
> 
> > Hello Gil,
> >
> > Great research on the subject, thank you for sharing.
> >
> > I could be wrong here, but at a first glance it seems you want to
> > essentially create a tag " > another screen dynamically upon clicking / activating the URL. If my
> > understanding is correct, then most likely they way you want to
> > implement this is probably some web request to the backend which
> > renders back a partial screen that you insert into the DOM right?
> >
> > If what I describe above is close to your idea, then I think the
> > implementation might be relying on the server to do the work of
> > painting instead of relying on the browser to do the heavy lifting.
> > This also only works with one widget, which is the URL widget as
> > opposed to having a general purpose dynamic behavior in the system
> > (assuming this is desired).
> >
> > However, having a general purpose dynamic behavior means we need a
> > method to bind variables to values at the front end without consulting
> > the back-end. This reduces the load on the server and provides a
> > faster / richer experience to the user. But it would be too painful to
> > rely on plain javascript or jQuery to achieve such a result which is
> > the reason why frameworks like React, Vue, and others emerged as
> > modern SPA frameworks. Adopting an SPA framework would provide dynamic
> > behavior (everywhere) instead of certain widgets, and it can be
> > expanded to even include page navigation and whatnot. Of course this
> > is more work than what you're suggesting here. but if we continue with
> > such small improvements, you might end up having lots of javascript
> > (maybe that's already the case) which might increase the difficulty of
> > adopting an SPA framework in the future.
> >
> > So it comes down to this question (which I don't necessarily have an
> > answer to):
> >
> > Do you want an SPA framework now or in the future, or do you want to
> > continue with status quo into the future? If you want an SPA
> > framework, then we should minimize the usage of custom javascript
> > everywhere and adopt a framework that completely replaces all the
> > javascript that currently exists for all the widgets. If not, then we
> > can proceed with your proposition and any others in the future knowing
> > that an overhaul is not needed.
> >
> > Cheers,
> >
> > Taher Alkhateeb
> >
> > On Fri, Dec 13, 2019 at 6:52 PM Gil Portenseigne
> >  wrote:
> > >
> > > Chapter One: How to manage the updating area
> > >
> > > Hello,
> > >
> > > After different discussions already listed by Taher [1-9], Leila,
> > > Nicolas and me tried another approach.
> > > Instead of analyzing how to implement different functionalities offered
> > > by modern js framework, we did analyzed how end user use, in general,
> > > OFBiz and where we, as an integrator, waste more time to create a
> > > screen.
> > >
> > > To help on this huge task, we set some basic rules :
> > > * Work only on screens supported by the theme, defined mainl

Re: [DISCUSSION] Make Back-Office screens dynamic

[Gil Portenseigne]

Hello Taher,

The proposition you saw with your first glance is about :
  * Intent : describing into a link/menu definition, the way that the
dynamically rendered form will refresh the screen upon submission
success
  * Implementation : adding a tag that will generate a refreshment event
on submission within the screen that is inserted into the DOM by the
augmented link (like a success callback).


That is one step of the proposal, but yes i think you got it well.

We have to make clear that our intent is not to add lot of new widget
augmentations to get dynamic screens. This new tag that should have been
named "callback-update-area", would complete the already existing
" Hello Gil,
> 
> Great research on the subject, thank you for sharing.
> 
> I could be wrong here, but at a first glance it seems you want to
> essentially create a tag " another screen dynamically upon clicking / activating the URL. If my
> understanding is correct, then most likely they way you want to
> implement this is probably some web request to the backend which
> renders back a partial screen that you insert into the DOM right?
> 
> If what I describe above is close to your idea, then I think the
> implementation might be relying on the server to do the work of
> painting instead of relying on the browser to do the heavy lifting.
> This also only works with one widget, which is the URL widget as
> opposed to having a general purpose dynamic behavior in the system
> (assuming this is desired).
> 
> However, having a general purpose dynamic behavior means we need a
> method to bind variables to values at the front end without consulting
> the back-end. This reduces the load on the server and provides a
> faster / richer experience to the user. But it would be too painful to
> rely on plain javascript or jQuery to achieve such a result which is
> the reason why frameworks like React, Vue, and others emerged as
> modern SPA frameworks. Adopting an SPA framework would provide dynamic
> behavior (everywhere) instead of certain widgets, and it can be
> expanded to even include page navigation and whatnot. Of course this
> is more work than what you're suggesting here. but if we continue with
> such small improvements, you might end up having lots of javascript
> (maybe that's already the case) which might increase the difficulty of
> adopting an SPA framework in the future.
> 
> So it comes down to this question (which I don't necessarily have an answer 
> to):
> 
> Do you want an SPA framework now or in the future, or do you want to
> continue with status quo into the future? If you want an SPA
> framework, then we should minimize the usage of custom javascript
> everywhere and adopt a framework that completely replaces all the
> javascript that currently exists for all the widgets. If not, then we
> can proceed with your proposition and any others in the future knowing
> that an overhaul is not needed.
> 
> Cheers,
> 
> Taher Alkhateeb
> 
> On Fri, Dec 13, 2019 at 6:52 PM Gil Portenseigne
>  wrote:
> >
> > Chapter One: How to manage the updating area
> >
> > Hello,
> >
> > After different discussions already listed by Taher [1-9], Leila,
> > Nicolas and me tried another approach.
> > Instead of analyzing how to implement different functionalities offered
> > by modern js framework, we did analyzed how end user use, in general,
> > OFBiz and where we, as an integrator, waste more time to create a
> > screen.
> >
> > To help on this huge task, we set some basic rules :
> > * Work only on screens supported by the theme, defined mainly in xml
> > * This concerns only screens used for back-office applications,
> >   oriented to manage data
> > * A developer does not have to know all of js language (or other)
> >   but can concentrate on the process/view with the end user to
> >   manage a data
> >
> >
> > After a first brainstorm, we have identified three major cases :
> > 1. Navigation and data display
> > 2. View event result (data modification, calculation service, ...)
> > 3. Update an area to refresh data (after data modification)
> >
> > Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
> > will be simple to add), we concentrate our attention on case 3.
> >
> > To update an area, we follow this pattern
> >
> > 1. We start from a context that display different information
> >
> > 2. That context display a submit form, use a link or another
> > mechanism to call an OFBiz event
> >
> > 3. After receiving the event return, we refresh the desired area
> > with p

[DISCUSSION] Make Back-Office screens dynamic

[Gil Portenseigne]

Chapter One: How to manage the updating area

Hello,

After different discussions already listed by Taher [1-9], Leila,
Nicolas and me tried another approach.
Instead of analyzing how to implement different functionalities offered
by modern js framework, we did analyzed how end user use, in general,
OFBiz and where we, as an integrator, waste more time to create a
screen.

To help on this huge task, we set some basic rules :
* Work only on screens supported by the theme, defined mainly in xml
* This concerns only screens used for back-office applications,
  oriented to manage data
* A developer does not have to know all of js language (or other)
  but can concentrate on the process/view with the end user to
  manage a data


After a first brainstorm, we have identified three major cases :
1. Navigation and data display
2. View event result (data modification, calculation service, ...)
3. Update an area to refresh data (after data modification)

Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
will be simple to add), we concentrate our attention on case 3.

To update an area, we follow this pattern

1. We start from a context that display different information

2. That context display a submit form, use a link or another
mechanism to call an OFBiz event

3. After receiving the event return, we refresh the desired area
with parameters that can come from origin context or from event
return.


Currently with the screen widget, we can use within a form the element
``.

The problem with this use, is that your form needs to know the origin
context, to identify what are the areas to update and what are the
target to use for the refresh.

So your form needs to know where it comes from, what information need to
be updated in OFBiz and what will be updated after.

This increases complexity for the developer in the way that current form
implementation manages :
  * the data and target to communicate with the server
  * the behaviour (refreshment) to apply when receiving server response.

Example :


...





If you want to reuse the same form, you need to create another screen
with a new form to redefine the on-event-update-area (for instance
create a PartyRole).

We change the thinking, because since it is the starting context that
better knows itself, it's the starting context that will realize the
updating operation. The starting context is the screen/menu that call
this form.

In general a form is contained in a screen (classic) that is called
through a link. So we move the idea on this link :








And the form :


   
   ...


With this logic you can define a new usage of createPartyRole
without redefining a form just :









After some use we identified as pro and con feedback :
* updating form is reusable and contains only code related to the
  form action
* link being in origin context, the developer knows where he is and
  where he wants to go
* Menu oriented management offers a quick vision on how the screen will 
works

* update-area seems to be a too technical name
* we always have to manage area to update manually
* too many areas to update become a headache and not only for the developer

We did not explain how we have done it, to try to focus the discussion
on the principles.

It would be a pleasure to have some criticism of this approach, and we
would try, in a second chapter to introduce other concepts that appeared
after the screens were made more dynamic and others to lowers the
identified cons.

Thanks,

The Néréide Team

[1] https://s.apache.org/rf94
[2] https://s.apache.org/g5zr
[3] https://s.apache.org/XpBO
[4] https://s.apache.org/YIL1
[5] https://s.apache.org/836D
[6] https://s.apache.org/DhyB
[7] https://s.apache.org/Lv9E
[8] https://s.apache.org/zKIo
[9] https://s.apache.org/D6jx

Re: Github PRs and Jira

[Gil Portenseigne]

Hello,


> 
> > I guess that using existent Github should be ok for official pull
> > request, if not, it's always ok to have and attached patch or
> > other gitlab reference.
> 
> You mean "Github reference" I guess ?
> 

For this one a really mean gitlab reference like the nereide public
gitlab project we already shared (one or two time) in the past :).

Gil

Re: Github PRs and Jira

[Gil Portenseigne]

+1 to use gitlab features to work around code, that will help
collaboration.

I don't know if there is an Apache alternative to get the features without
Microsoft. But having two official tools to get contribution is not desired.

I guess that using existent Github should be ok for official pull
request, if not, it's always ok to have and attached patch or
other gitlab reference.

Gil

Le 11:55 - mardi 03 déc., Jacques Le Roux a écrit :
> Le 03/12/2019 à 08:21, Jacopo Cappellato a écrit :
> > Now that we have migrated to Git, in my opinion we should really consider
> > to adopt the workflow based on PR as our primary method for accepting
> > contributions. I understand that it is a relevant change for the community,
> > but I also see many advantages and a more natural (for Git) workflow for
> > contributors and committers. Contributors would fork from the official repo
> > and would submit pull requests that the committers would merge into the
> > official branches.
> > 
> I tend to agree, it's simple to merge and commit. We will still maybe need
> Jiras when discussions are needed, or in all cases to fill the blog monthly
> posts?
> 
> I guess using Github (ie Microsoft :D) is not a problem for the community?
> 
> Opinions are welcome
> 
> Jacques
> 

Audit max-retry failure async job

[Gil Portenseigne]

Subject : Audit max-retry failure async job

Hi all,

While working for a customer, we need to send data to an external API. For
this purpose we did trigger an Async service with a max-retry to 3, to be
resilient with external API unavailability.

The fact is that, with this implementation, we do not manage max retried
services failures.

One way to do it, is to not rely on Jobs but use a new external Api call tools
(might be based upon communicationEvent...), not my first choice since the
implementation is already done.

Another idea, more simple, is to implement a new seca trigger where the event
could be ‘async-last-failure’, to trigger another service which role can be
to alert/log/replay... I did not yet analyse if this is easily feasible.

Any ideas ?

Best Regards

Gil

Re: Change commit message template?

[Gil Portenseigne]

Hello,

When we first decided on the current template, i did understood that
jira number was at the end of the first line, that was logical in my
view. I was mistaken and did not discussed it by then.

Setting Jira number at the end of the first line is fine for me.

Gil

Le 21:16 - dimanche 17 nov., Taher Alkhateeb a écrit :
> Hi Jacques,
> 
> I'm not sure what convention over configuration has to do with what
> you're saying :)
> 
> Anyway, it makes sense. Most GIT editors consider the first line to be
> subject, and third line onward is the body of the message. So perhaps
> we can move the (OFBIZ-) to the end of the first line or maybe
> make it the last line in the body or something like that.
> 
> 
> On Sun, Nov 17, 2019 at 7:05 PM Jacques Le Roux
>  wrote:
> >
> > Hi,
> >
> > While working in Eclipse with Git (ie using eGit which is not my favourite 
> > tool). I found a warning telling me:
> >
> > "Second line should be empty to separate commit message header from 
> > body"
> >
> > It was argued that it's only a convention[1], but don't we prefer 
> > "convention over configuration"?
> >
> > I suggest to change our template according to the convention, ie separate 
> > the title from the issue number or put the number on the same line (split
> > sometimes) than the title
> >
> > [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=475845
> >
> > What do you think?
> >
> > Jacques
> >

Re: [ofbiz-framework] 02/02: Fixed: Update the SvnCheckout Gradle task to used Github svn repo (OFBIZ-11276)

[Gil Portenseigne]

Thanks Jacques, i understood it was temporary and tested it, i was just
curious :)

It is strange to see a git url in svnCheckout utility.

Gil

Le 10:47 - vendredi 08 nov., Jacques Le Roux a écrit :
> Hi Gil,
> 
> Yes sure, here it is https://s.apache.org/lwptd
> 
> I said it's a temporary feature I used. But I begin to wonder now.
> 
> Since at the ASF the official Gitbox is tightly coupled with Github, I think 
> we also are able to commit changes through this way.
> 
> So I wonder if we should rush into splitting the plugins in Git repos when we 
> can still use svn as before...
> 
> I'll do one simple commit in ecommerce I need to do, to check this assertion.
> 
> Jacques
> 
> Le 08/11/2019 à 09:42, Gil Portenseigne a écrit :
> > Hello Jacques,
> > 
> > Could you provide a reference to the github feature you mentionned ?
> > 
> > Thanks
> > 
> > Gil
> > 
> > Le 19:02 - mercredi 06 nov., jler...@apache.org a écrit :
> > > This is an automated email from the ASF dual-hosted git repository.
> > > 
> > > jleroux pushed a commit to branch trunk
> > > in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> > > 
> > > commit 4815de7d92cbd6acbcd88c8524f54dc884bd00d4
> > > Author: Jacques Le Roux 
> > > AuthorDate: Wed Nov 6 17:26:47 2019 +0100
> > > 
> > >  Fixed: Update the SvnCheckout Gradle task to used Github svn repo
> > >  (OFBIZ-11276)
> > >  Relies on a Github specific feature which allows to use and automated
> > >  mirrored svn repo.
> > >  (cherry picked from commit 0c489aa609d07acdcfe7ff41f167ca2040046c77)
> > > ---
> > >   build.gradle | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/build.gradle b/build.gradle
> > > index 3259468..700498d 100644
> > > --- a/build.gradle
> > > +++ b/build.gradle
> > > @@ -884,7 +884,7 @@ task pullPluginSource(group: ofbizPlugin, 
> > > description: 'Download and install a p
> > >   if (project.hasProperty('pluginId')) {
> > >   task pullPluginFromSvn(type: SvnCheckout) {
> > > -svnUrl = 
> > > "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk/${pluginId};
> > > +svnUrl = 
> > > "https://github.com/apache/ofbiz-plugins/trunk/${pluginId};
> > >   workspaceDir = "${pluginsDir}/${pluginId}"
> > >   }
> > >   dependsOn pullPluginFromSvn
> > > @@ -901,7 +901,7 @@ task pullAllPluginsSource(group: ofbizPlugin,
> > >   doLast { delete "${pluginsDir}" }
> > >   }
> > >   task pullPluginsFromSvn(type: SvnCheckout, dependsOn: 
> > > deleteBeforePulling) {
> > > -svnUrl = 
> > > "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk;
> > > +svnUrl = "https://github.com/apache/ofbiz-plugins/trunk;
> > >   workspaceDir = "${pluginsDir}"
> > >   }
> > >   dependsOn pullPluginsFromSvn
> > > 

Re: [ofbiz-framework] 02/02: Fixed: Update the SvnCheckout Gradle task to used Github svn repo (OFBIZ-11276)

[Gil Portenseigne]

Hello Jacques,

Could you provide a reference to the github feature you mentionned ?

Thanks

Gil

Le 19:02 - mercredi 06 nov., jler...@apache.org a écrit :
> This is an automated email from the ASF dual-hosted git repository.
> 
> jleroux pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
> 
> commit 4815de7d92cbd6acbcd88c8524f54dc884bd00d4
> Author: Jacques Le Roux 
> AuthorDate: Wed Nov 6 17:26:47 2019 +0100
> 
> Fixed: Update the SvnCheckout Gradle task to used Github svn repo
> (OFBIZ-11276)
> 
> Relies on a Github specific feature which allows to use and automated
> mirrored svn repo.
> 
> (cherry picked from commit 0c489aa609d07acdcfe7ff41f167ca2040046c77)
> ---
>  build.gradle | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/build.gradle b/build.gradle
> index 3259468..700498d 100644
> --- a/build.gradle
> +++ b/build.gradle
> @@ -884,7 +884,7 @@ task pullPluginSource(group: ofbizPlugin, description: 
> 'Download and install a p
>  
>  if (project.hasProperty('pluginId')) {
>  task pullPluginFromSvn(type: SvnCheckout) {
> -svnUrl = 
> "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk/${pluginId};
> +svnUrl = 
> "https://github.com/apache/ofbiz-plugins/trunk/${pluginId};
>  workspaceDir = "${pluginsDir}/${pluginId}"
>  }
>  dependsOn pullPluginFromSvn
> @@ -901,7 +901,7 @@ task pullAllPluginsSource(group: ofbizPlugin,
>  doLast { delete "${pluginsDir}" }
>  }
>  task pullPluginsFromSvn(type: SvnCheckout, dependsOn: 
> deleteBeforePulling) {
> -svnUrl = "https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk;
> +svnUrl = "https://github.com/apache/ofbiz-plugins/trunk;
>  workspaceDir = "${pluginsDir}"
>  }
>  dependsOn pullPluginsFromSvn
> 

Re: Git repo for each ofbiz plugin

[Gil Portenseigne]

Hello Deepak, all,

I do not have a strong opinion about separating plugins into independent
git repositories but here are my thought :

Plugins integration in OFBiz is intended to be used with a maven
repository that hosts the plugin releases for the users. See as a
reference the ‘OFBiz Plugins tasks’ or README.adoc about ‘OFBiz plugin
system’.

We did not implemented an official maven repository for plugin releases,
so there is no simple way to install a plugin without using VCS. There
might be tasks to be done to have an nice answer to how an user can
install a sole plugin from a downloaded release archive.

Having separated repositories can offer the ability to clone one plugin
easily, but at the cost of separating history from other plugins and
framework, and increasing maintenance effort. In that case, some
scripting could be done, to automate update on all plugins in your
repos. Also we might consider using git submodules [1] into framework to
ease plugins management, but i'm not familiar enough with that feature.

Without maven i tend to lean toward separate repository, but like i
said, no strong opinion.

By the way, thanks for your work regarding git migration.

Regards,

Gil

[1] https://git-scm.com/docs/git-submodule



Le 16:20 - jeudi 07 nov., Deepak Dixit a écrit :
> Agree we may some issues, we need to find out and fix if found.
> 
> As per current git repo, How user can only checkout and use ecommerce or bi
> or any single component?
> 
> It was possible in with svn, but in git we need separate repository :)
> 
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
> 
> 
> On Thu, Nov 7, 2019 at 1:16 PM Jacques Le Roux 
> wrote:
> 
> > Le 07/11/2019 à 08:16, Deepak Dixit a écrit :
> > >> For instance, some features in applications are dependent on ecommerce
> > >> (maybe some other plugins). And a lot of
> > >> data used by applications are in ecommerce, and maybe even other
> > plugins.
> > >>
> > > I think we already had an effort to remove plugin dependencies from
> > > framework/applications.
> > >
> > > --
> > > Deepak Dixit
> > Sincerely I don't see much efforts put in this issue. And IMO it needs to
> > be resolved before thinking about splitting the plugins. I expect some
> > issues else...
> >
> > Jacques
> >
> >

Re: Upgrading Groovy 2.4.16 → 2.5.8

[Gil Portenseigne]

Hello Mathieu,

I've test the upgrade and saw no issue, so +1.

Gil



Le 18:19 - dimanche 27 oct., Mathieu Lirzin a écrit :
> Hello,
> 
> I have open OFBIZ-11263 [1] to upgrade Groovy to its latest stable
> release on ‘trunk’.
> 
> I did not detect any issue with the upgrade so I intend to commit the
> patch in the following days.  If you are aware of an issue please jump
> in.
> 
> Thanks.
> 
> [1] https://issues.apache.org/jira/browse/OFBIZ-11263
> 
> -- 
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [DISCUSSION] R16 and R17: email password issue and releases

[Gil Portenseigne]

Hello,

I think that the one year stabilisation period needed for a new branch
to be released is not that far for R18 (less than two month), so I
suppose that skipping R17 to avoid maintaining two release branches is a
good call.

Gil


Le 13:29 - samedi 28 sept., Jacques Le Roux a écrit :
> Hi,
> 
> As reported by Rashi Dhagat in OFBIZ-11215 "Email password is not working" in 
> R16, and actually nor in R17.
> 
> It has been fixed in trunk and R18 with OFBIZ-4361. As mentioned there, it's 
> hard to backport to R17 not even speaking about R16!
> 
> I wonder if a case like that would not make R16 deprecated and start to 
> release R18, skipping R17.
> 
> Of course if people has the time, the nerves and the guts to backport to R17 
> and R16 they are welcome
> 
> What do you think?
> 
> Jacques
> 

Refactoring ServiceSemaphore (OFBIZ-11204)

[Gil Portenseigne]

Hello,

In one of our customer project, where we are using multiple OFBiz
instances to run backend jobs, in which some are using service semaphore
system.

While these semaphore jobs are run quite intensively by several OFBiz
process, we stumble upon a lot of 'Error' logs that are polluting other
production log, in the fact that these are not really error, but a
failure trying to insert a lock into ServiceSemaphore table, that leads
to another waiting loop.

I then proposed a refactoring of the implementation (jira OFBIZ-11204),
that works currently fine in our production environment.

Since semaphore feature is a quite critical one, some reviews would be
appreciated before commiting it in the codebase.

Regards,

Gil

Re: Avoiding to log Uel stacktraces (was: svn commit: r1867635 - /ofbiz/ofbiz-framework/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/string/UelFunctions.java)

[Gil Portenseigne]

Hello Mathieu !

Done, thanks for your review, i hope it is more clear.

Gil

Le 16:23 - vendredi 27 sept., Mathieu Lirzin a écrit :
> Hello Gil,
> 
> p...@apache.org writes:
> 
> > Author: pgil
> > Date: Fri Sep 27 13:52:43 2019
> > New Revision: 1867635
> >
> > URL: http://svn.apache.org/viewvc?rev=1867635=rev
> > Log:
> > Improved: Refactor UelFunctions.java to remove error management via 
> > Exception 
> > (OFBIZ-11213)
> >
> > This refacto was done to avoid logging stackTrace exception, when it is 
> > possible 
> > to manage it without exception.
> 
> The "avoid logging stackTrace exception" part of your commit message
> gives the impression that the motivation for this rewrite is to hide
> programming errors inside Uel and not necessarily to make the
> implementation more understandeable.
> 
> Can you give more context regarding this issue of unwanted/unnecessary
> logged stacktraces and explain why you choose the solution of silently
> hiding the "stacktrace" instead of fixing the code inside the Uel?
> 
> Thanks.
> 
> -- 
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Default transaction timeout on screen widget

[Gil Portenseigne]

Same feeling here, i just see it as a smell to analyse, to detect bad
design, system failure (disk access...) or regression.

Regards
Gil

Le 20:45 - mardi 17 sept., Scott Gray a écrit :
> Has anyone ever had a good experience with transaction timeouts?  I feel
> like they achieve nothing useful in that:
> 1. They don't interrupt any work that is taking too long (they just prevent
> it from being committed)
> 2. By the time the exception is thrown, all the work is already done and
> the result is that it just gets thrown away in exchange for an error
> 
> Surely there's a positive side to them, and I've just never seen it?
> 
> But Nicolas, in your case I think the solution lies elsewhere.  I don't
> think it's ever ok for a screen to take over a minute to load and tie up
> the http connection all that time.  Slow pages happen to all of us, but IMO
> the solution always lies in making the screen faster, limiting the amount
> of data that can be processed in a single request or by making the request
> asynchronous.
> 
> Regards
> Scott
> 
> On Wed, 11 Sep 2019 at 06:57, Nicolas Malin 
> wrote:
> 
> > Hi all,
> >
> > Since I increase the sensibility of error message [1], we have on
> > different screen that take some time to rendering an  error throw due to
> > transaction timeout.
> >
> > By default each screen is rendering with the default timeout (60s) that
> > isn't enough when you have big data compilation or some external service
> > latency.
> >
> > Of course it's possible to analyze each case with purpose to increase
> > the screen velocity or set a transaction-timeout on screen definition,
> > but as first easy step what do you think if we add a default transaction
> > timeout for screen to 10 minutes with possibility to override by
> > properties ?
> >
> > Example:
> >
> > *
> >
> >
> > framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelScreen.java
> > @@ -122,7 +123,7 @@ public class ModelScreen extends ModelWidget {
> >   // wrap the whole screen rendering in a transaction, should
> > improve performance in querying and such
> >   Map parameters =
> > UtilGenerics.cast(context.get("parameters"));
> >   boolean beganTransaction = false;
> > -int transactionTimeout = -1;
> > +int transactionTimeout =
> > UtilProperties.getPropertyAsInteger("widget",
> > "widget.transaction.timeout.default", 600);
> >   if (parameters != null) {
> >   String transactionTimeoutPar =
> > parameters.get("TRANSACTION_TIMEOUT");
> >   if (transactionTimeoutPar != null) {
> > @@ -152,12 +153,7 @@ public class ModelScreen extends ModelWidget {
> >   // If transaction timeout is present, use it to start the
> > transaction
> >   // If transaction timeout is set to zero, no transaction
> > is started
> >   if (useTransaction) {
> > -if (transactionTimeout < 0) {
> > -beganTransaction = TransactionUtil.begin();
> > -}
> > -if (transactionTimeout > 0) {
> > -beganTransaction =
> > TransactionUtil.begin(transactionTimeout);
> > -}
> > +beganTransaction =
> > TransactionUtil.begin(transactionTimeout);
> >   }
> >
> >   // render the screen, starting with the top-level section
> >
> > ***
> >
> > Any remarks ?
> >
> > In parallel i will investigate why the error message catch is so sensible.
> >
> > Nicolas
> >
> > [1] http://svn.apache.org/viewvc?view=revision=1856175
> >
> > --
> > logoNrd 
> > Nicolas Malin
> > The apache way  : *Charity* Apache’s mission
> > is providing software for the public good.
> > informat...@nereide.fr
> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >
> > Apache OFBiz |The Apache Way
> > |réseau LE 
> >

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Gil Portenseigne]

Hello Jacques,

I also discussed about it with Mathieu and i find it very interesting.

The main advantage I see is, beside compilation, the integration in your
IDE, that was not optimum, and the possibility to re-use methods from
these script migrated to explicit classes.

So +1

Gil


Le 12:28 - lundi 16 sept., Jacques Le Roux a écrit :
> Hi Devs,
> 
> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" I 
> discussed with Mathieu and we had some ideas.
> 
> Mathieu suggested to move Groovy scripts from /groovyScripts/ 
> to/src/main/groovy/.
> 
> I was initially reluctant because I love to be able to change things on the
> fly. That's why I liked Minilang and still like widgets, Freemarker
> templates and Groovy Scripts.
> 
> We also know the advantages of compilation. But then I thought: why not have 
> best of both Groovy worlds: compile and on the fly.
> 
> I tried and it works. So here is the (simple) plan:
> 
> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> 2. We add the necessary packages names
> 3. Devs can then open "gradlew --continuous" in a terminal and let it like 
> that. It will continuously build on any changes in Gradle sourcesets
> 
> So, if you modify a Groovy scripts while running an OFBiz instance, the
> changes will be reflected in the instance and you can check possible syntax
> or alike issues in the terminal running the continuous build. It's very fast
> since only changes have an impact on the build.
> 
> I'm sure there are other benefits to follow "the common convention of
> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> suggested Mathieu.
> 
> I see no disadvantages, do you? If nobody disagree with this idea, I'll 
> create a Jira for that.
> 
> Feedback welcome, thanks
> 
> Jacques
> 

Re: svn commit: r1858243 - in /ofbiz/ofbiz-plugins/trunk: ecommerce/minilang/customer/CustomerEvents.xml example/template/reports/BarCode.fo.ftl

[Gil Portenseigne]

Hello Suraj,

You commited something about maritalStatus id this commit. I guess its
part of another JIRA.

Regards

Le 06:18 - samedi 27 avril, sur...@apache.org a écrit :
> Author: surajk
> Date: Sat Apr 27 06:18:17 2019
> New Revision: 1858243
> 
> URL: http://svn.apache.org/viewvc?rev=1858243=rev
> Log:
> Improved: Use code128 instead of code39 for barcode generation.
> (OFBIZ-10896)
> Currently, we are using code39 to generate barcodes but there are some 
> limitations of code39 as it only able to encrypt letters from A to Z, digits 
> from 0 to 9 and an additional set of special characters – “. $ % + – / *”.
> Thanks Pawan Verma for reporting, analysis and providing the patch. Thanks 
> everyone else for providing their inputs during discussion on Dev ML.
> 
> Modified:
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> 
> Modified: 
> ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml?rev=1858243=1858242=1858243=diff
> ==
> --- ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml 
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/ecommerce/minilang/customer/CustomerEvents.xml 
> Sat Apr 27 06:18:17 2019
> @@ -550,7 +550,7 @@ under the License.
>  
>  
>  
> -
> +
>  
>  
>   type="Long"> property="EcommerceYearsWithEmployeeNotValid"/>
> 
> Modified: ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl?rev=1858243=1858242=1858243=diff
> ==
> --- ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl 
> (original)
> +++ ofbiz/ofbiz-plugins/trunk/example/template/reports/BarCode.fo.ftl Sat Apr 
> 27 06:18:17 2019
> @@ -38,10 +38,10 @@ under the License.
>  
>http://barcode4j.krysalis.org/ns;
>message="${exampleId}">
> -
> +
>0.75in
>.375mm
> -
> +
>  
>bottom
>Helvetica
> 
> 

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

[Gil Portenseigne]

A big post for saying that the feature i just wanted to recall about do
not fit your need :).

I used it in the past for a critical audit, and was happy with it.


Le 14:23 - vendredi 26 avril, Pierre Smits a écrit :
> Gill, all,
> 
> The entity_audit_log feature also sprung into my mind shortly after I
> posted my comment.
> 

[...]

> And last but not least: he fourth -1 regarding the
> 'enable_audit_log'-feature is that it doesn't appear to be working as
> expected. I did a cursory test with an order some moments ago in ofbiz (see
> [1]) and it does not capture the old values on the line items. But I may be
> misunderstanding the screen/process there.

In my experience i got old and new value, date and userLogin.

Regards,

Re: [PROPOSAL] DataModel - Improve Internal Fields injection

[Gil Portenseigne]

Hello Pierre,

If you have specific need of Auditing, after suspition of malicious
users, you can enable entity_audit_log feature on the desired table.
At a cost of performance loss.

I do not understand why impersonation feature appears here, since it is
a administrator specific feature. If an admin is malicious, having those
fields cannot prevent him to destroy/modify/create or do whatever with
the data.

Like you can guess, my opinion, is not to put those fields onto all
entity in OFBiz.

I agree that security is important, and OFBiz admin must grant the good
permission to the trusted users.

If you find out that specific entity miss those fields, it can be added
case by case. But i do not feel ok into a global feature.

Regards

Gil 

Le 11:17 - vendredi 26 avril, Pierre Smits a écrit :
> The two fields are extremely useful (even indispensable) regarding auditing
> and data analysis. Consider security assessments and fraud
> detection/prevention.
> 
> In trunk, only 48 entities have those fields in following breakdown:
> Component Model Entities Having UserLogin fields %
> datamodel accounting 160 3 1,88%
> datamodel content 64 7 10,94%
> datamodel humanres 41 1 2,44%
> datamodel manufacturing 7   0,00%
> datamodel marketing 32 8 25,00%
> datamodel order 106 10 9,43%
> datamodel party 81 2 2,47%
> datamodel product 168 11 6,55%
> datamodel facility 38 4 10,53%
> datamodel workeffort 40 1 2,50%
>   In apps 737 47 6,38%
>   in framework 98 1 1,02%
> Total   835 48 5,75%
> 
> That means that for the majority of the entities (more than 90%) our
> adopters (using the data models OOTB) have no way of telling who created a
> record and who modified it last. And we are talking about entities
> regarding invoices, payments, gl transaction entries, orders, quotes,
> product definitions, inventory quantities and locations, receipts,
> deliveries etc., all which contain business critical data.
> 
> But also, with the recently feature regarding impersonation added to our
> code base which allow other users to change records through OFBiz having
> those two fields on each entity becomes business critical.
> 
> IMO the OFBiz should have these two fields established on each entity OOTB.
> 
> Because, if we don't have that, our potential adopters while assessing our
> product may walk away, and our existing adopter - even after an upgrade to
> a more recent or future release without this - will have an extremely hard
> time analysing who created and changed records (the what, where and when
> questions) when confronted with nefarious (criminal) users.
> 
> Best regards,
> 
> Pierre Smits
> 
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> *Apache OFBiz , contributor (without privileges)
> since 2008*
> Apache Steve , committer
> 
> 
> On Fri, Apr 26, 2019 at 9:00 AM Pritam Kute 
> wrote:
> 
> > IMO, adding 'createdByUserLogin' and 'lastModifiedByUserLogin' fields to
> > every entity is not that useful. Like for example, if we consider the
> > "Visit" entity, I am not able to find any advantage of having these fields
> > in this entity. But, it should be added to some crucial entities like
> > OrderHeader, OrderItem, ProductPrice(which is already there) to track the
> > things like who dod the last price updates or order updates.
> >
> > Kind Regards,
> > --
> > Pritam Kute
> >
> >
> > On Thu, Apr 25, 2019 at 6:10 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Le 25/04/2019 à 14:17, Suraj Khurana a écrit :
> > > > IMO, this is configurable as Jacques pointed, so need to take any
> > action.
> > > > In fact, I would suggest showing these fields while searching for any
> > > data
> > > > from entity-engine in webtools, because they are really helpful while
> > > > working in a dev environment for debugging.
> > >
> > > This could be configurable indeed (less need in production for instance
> > so
> > > default would be false)
> > >
> > > Jacques
> > >
> > > >
> > > > Just my two cents !!!
> > > >
> > > > --
> > > > Best Regards,
> > > > Suraj Khurana
> > > > TECHNICAL CONSULTANT
> > > > mobile: +91 9669750002
> > > > email: suraj.khur...@hotwax.co
> > > > www.hotwax.co
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 24, 2019 at 7:14 PM Jacques Le Roux <
> > > > jacques.le.r...@les7arts.com> wrote:
> > > >
> > > >> A bit out of subject, just to complete the discussion because nobody
> > > spoke
> > > >> about.
> > > >>
> > > >> The entities are defined with no-auto-stamp="false" by default so it's
> > > >> possible to change this default.
> > > >>
> > > >> Of course 'createdByUserLogin' and 'lastModifiedByUserLogin' fields
> > are
> > > >> not concerned, it was just to complete
> > > >>
> > > >> Jacques
> > > >>
> > > >>
> > > >> Le 24/04/2019 à 13:36, Rishi Solanki a écrit :
> > > 

Re: Send E-Mails

[Gil Portenseigne]

What I understand is that to keep granted right after the migration if
our confluence id is différent from our apache id, we must fill in a
INFRA Jira to make the switch ?


Le 09:23 - mardi 26 mars, Jacques Le Roux a écrit :
> Makes sense Pierre,
> 
> Please Gil checks https://issues.apache.org/jira/browse/INFRA-18028
> 
> HTH
> 
> Jacques
> 
> Le 26/03/2019 à 09:16, Pierre Smits a écrit :
> > Hi Gil,
> > 
> > Does this maybe have something to do with recent migration by INFRA to have
> > ApacheIds (LDAP)+password being usable as login credentials? I can't edit
> > either.
> > 
> > Best regards,
> > 
> > Pierre Smits
> > 
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>,  10 years a contributor without
> > privileges*
> > Apache Steve <https://steve.apache.org>, committer
> > 
> > 
> > On Tue, Mar 26, 2019 at 8:56 AM Gil Portenseigne <
> > gil.portensei...@nereide.fr> wrote:
> > 
> > > Hello there,
> > > 
> > > Do somes actions have been taken on documenting the existence of
> > > SystemProperty ?
> > > 
> > > I like the idea of migrating documentation into embedded one.
> > > 
> > > I just wanted to add a note into https://s.apache.org/BPJ5 that alert
> > > about SystemProperty, but i seem to miss the modification permission...
> > > can someone grant me access ?
> > > 
> > > Thanks
> > > 
> > > Gil
> > > 
> > > 
> > > Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit :
> > > > Actually, I think whatever need to be documented is best placed in our
> > > > embedded documentation. We should probably consider freezing all new
> > > > documentation in any place that is not the embedded documentation and 
> > > > try
> > > > to migrate everything to it. So email setting docs could be placed
> > > > somewhere in our user manual.
> > > > 
> > > > On Fri, May 11, 2018, 11:51 AM Jacques Le Roux <
> > > jacques.le.r...@les7arts.com>
> > > > wrote:
> > > > 
> > > > > Hi Rishi,
> > > > > 
> > > > > 
> > > > > Le 09/05/2018 ą 11:12, Rishi Solanki a écrit :
> > > > > > Community, I think we should mention the SystemProperty where
> > > required in
> > > > > > Production Setup Guide or may be we can add version of production
> > > setup
> > > > > > guide which will tells user upto which release this production setup
> > > > > guide
> > > > > > will work. I know we discuss this kind of effort in past for all the
> > > > > > documents and we agree on some point. But this is quicker to manage
> > > > > > Production Setup Guide, if we agree then I can do it.
> > > > > Yes good idea, a simple information for concerned versions in the
> > > current
> > > > > Production Setup Guide fits with me
> > > > > 
> > > > > Jacques
> > > > > > I'm fine with either change the existing one or maintain the
> > > version. But
> > > > > > first we should have one which works always with latest. Thanks!
> > > > > > 
> > > > > > 
> > > > > > Rishi Solanki
> > > > > > Sr Manager, Enterprise Software Development
> > > > > > HotWax Systems Pvt. Ltd.
> > > > > > Direct: +91-9893287847
> > > > > > http://www.hotwaxsystems.com
> > > > > > www.hotwax.co
> > > > > > 
> > > > > > On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de <
> > > i...@agentur-m3.de>
> > > > > > wrote:
> > > > > > 
> > > > > > > Hello,
> > > > > > > 
> > > > > > > here is a problem with my e-mail base-configuration.
> > > > > > > 
> > > > > > > I configured email according to the setup guide:
> > > > > > > 
> > > > > > > 
> > > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+
> > > > > > > Production+Setup+Guide#ApacheOFBizTechnicalProduction
> > > > > > 

Re: Send E-Mails

[Gil Portenseigne]

Thanks Jacques :)


Le 09:21 - mardi 26 mars, Jacques Le Roux a écrit :
> Hi Gil,
> 
> Let me check
> 
> Jacques
> 
> Le 26/03/2019 à 08:56, Gil Portenseigne a écrit :
> > Hello there,
> > 
> > Do somes actions have been taken on documenting the existence of
> > SystemProperty ?
> > 
> > I like the idea of migrating documentation into embedded one.
> > 
> > I just wanted to add a note into https://s.apache.org/BPJ5 that alert
> > about SystemProperty, but i seem to miss the modification permission...
> > can someone grant me access ?
> > 
> > Thanks
> > 
> > Gil
> > 
> > 
> > Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit :
> > > Actually, I think whatever need to be documented is best placed in our
> > > embedded documentation. We should probably consider freezing all new
> > > documentation in any place that is not the embedded documentation and try
> > > to migrate everything to it. So email setting docs could be placed
> > > somewhere in our user manual.
> > > 
> > > On Fri, May 11, 2018, 11:51 AM Jacques Le Roux 
> > > 
> > > wrote:
> > > 
> > > > Hi Rishi,
> > > > 
> > > > 
> > > > Le 09/05/2018 à 11:12, Rishi Solanki a écrit :
> > > > > Community, I think we should mention the SystemProperty where 
> > > > > required in
> > > > > Production Setup Guide or may be we can add version of production 
> > > > > setup
> > > > > guide which will tells user upto which release this production setup
> > > > guide
> > > > > will work. I know we discuss this kind of effort in past for all the
> > > > > documents and we agree on some point. But this is quicker to manage
> > > > > Production Setup Guide, if we agree then I can do it.
> > > > Yes good idea, a simple information for concerned versions in the 
> > > > current
> > > > Production Setup Guide fits with me
> > > > 
> > > > Jacques
> > > > > I'm fine with either change the existing one or maintain the version. 
> > > > > But
> > > > > first we should have one which works always with latest. Thanks!
> > > > > 
> > > > > 
> > > > > Rishi Solanki
> > > > > Sr Manager, Enterprise Software Development
> > > > > HotWax Systems Pvt. Ltd.
> > > > > Direct: +91-9893287847
> > > > > http://www.hotwaxsystems.com
> > > > > www.hotwax.co
> > > > > 
> > > > > On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de 
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > here is a problem with my e-mail base-configuration.
> > > > > > 
> > > > > > I configured email according to the setup guide:
> > > > > > 
> > > > > > 
> > > > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+
> > > > > > Production+Setup+Guide#ApacheOFBizTechnicalProduction
> > > > > > SetupGuide-EmailServerSettings
> > > > > > 
> > > > > > 
> > > > > > Unfortunately no email seems to be sent from server
> > > > > > (the send email button in partymgr works fine now (thanks to 
> > > > > > Jacques!),
> > > > > > but no email reaches client). No error message, no error in log.
> > > > > > 
> > > > > > Also I tried to register in the ecommerce system and send
> > > > > > an "Forgot Your Password" email, but none of the emails were sent.
> > > > > > 
> > > > > > To get more info about the problem, I wrote a groovy script and 
> > > > > > copied
> > > > > > parts of the sendEmail-code from EmailServices.java.
> > > > > > The script below surprisingly works fine and sends emails!
> > > > > > 
> > > > > > So I don't understand, why OFBiz itself does not send mails.
> > > > > > Is there any further configuration necessary?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > The script (which sends mails):
> > > > > > 
> > > > > > import javax.mail

Re: Send E-Mails

[Gil Portenseigne]

Hello there,

Do somes actions have been taken on documenting the existence of
SystemProperty ?

I like the idea of migrating documentation into embedded one.

I just wanted to add a note into https://s.apache.org/BPJ5 that alert
about SystemProperty, but i seem to miss the modification permission...
can someone grant me access ?

Thanks

Gil


Le 12:50 - vendredi 11 mai, Taher Alkhateeb a écrit :
> Actually, I think whatever need to be documented is best placed in our
> embedded documentation. We should probably consider freezing all new
> documentation in any place that is not the embedded documentation and try
> to migrate everything to it. So email setting docs could be placed
> somewhere in our user manual.
> 
> On Fri, May 11, 2018, 11:51 AM Jacques Le Roux 
> wrote:
> 
> > Hi Rishi,
> >
> >
> > Le 09/05/2018 à 11:12, Rishi Solanki a écrit :
> > > Community, I think we should mention the SystemProperty where required in
> > > Production Setup Guide or may be we can add version of production setup
> > > guide which will tells user upto which release this production setup
> > guide
> > > will work. I know we discuss this kind of effort in past for all the
> > > documents and we agree on some point. But this is quicker to manage
> > > Production Setup Guide, if we agree then I can do it.
> > Yes good idea, a simple information for concerned versions in the current
> > Production Setup Guide fits with me
> >
> > Jacques
> > >
> > > I'm fine with either change the existing one or maintain the version. But
> > > first we should have one which works always with latest. Thanks!
> > >
> > >
> > > Rishi Solanki
> > > Sr Manager, Enterprise Software Development
> > > HotWax Systems Pvt. Ltd.
> > > Direct: +91-9893287847
> > > http://www.hotwaxsystems.com
> > > www.hotwax.co
> > >
> > > On Wed, May 9, 2018 at 3:33 AM, i...@agentur-m3.de 
> > > wrote:
> > >
> > >> Hello,
> > >>
> > >> here is a problem with my e-mail base-configuration.
> > >>
> > >> I configured email according to the setup guide:
> > >>
> > >>
> > https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+
> > >> Production+Setup+Guide#ApacheOFBizTechnicalProduction
> > >> SetupGuide-EmailServerSettings
> > >>
> > >>
> > >> Unfortunately no email seems to be sent from server
> > >> (the send email button in partymgr works fine now (thanks to Jacques!),
> > >> but no email reaches client). No error message, no error in log.
> > >>
> > >> Also I tried to register in the ecommerce system and send
> > >> an "Forgot Your Password" email, but none of the emails were sent.
> > >>
> > >> To get more info about the problem, I wrote a groovy script and copied
> > >> parts of the sendEmail-code from EmailServices.java.
> > >> The script below surprisingly works fine and sends emails!
> > >>
> > >> So I don't understand, why OFBiz itself does not send mails.
> > >> Is there any further configuration necessary?
> > >>
> > >>
> > >>
> > >> The script (which sends mails):
> > >>
> > >> import javax.mail.Session;
> > >>
> > >> import javax.activation.DataHandler;
> > >> import javax.activation.DataSource;
> > >> import javax.mail.Message;
> > >> import javax.mail.MessagingException;
> > >> import javax.mail.SendFailedException;
> > >> import javax.mail.Session;
> > >> import javax.mail.Transport;
> > >> import javax.mail.internet.InternetAddress;
> > >> import javax.mail.internet.MimeBodyPart;
> > >> import javax.mail.internet.MimeMessage;
> > >> import javax.mail.internet.MimeMultipart;
> > >> import javax.xml.parsers.ParserConfigurationException;
> > >> import javax.xml.transform.stream.StreamSource;
> > >>
> > >> import org.apache.fop.apps.Fop;
> > >> import org.apache.fop.apps.MimeConstants;
> > >> import org.apache.ofbiz.base.util.Debug;
> > >> import org.apache.ofbiz.base.util.GeneralException;
> > >> import org.apache.ofbiz.base.util.HttpClient;
> > >> import org.apache.ofbiz.base.util.HttpClientException;
> > >> import org.apache.ofbiz.base.util.UtilGenerics;
> > >> import org.apache.ofbiz.base.util.UtilMisc;
> > >> import org.apache.ofbiz.base.util.UtilProperties;
> > >> import org.apache.ofbiz.base.util.UtilValidate;
> > >> import org.apache.ofbiz.base.util.collections.MapStack;
> > >> import org.apache.ofbiz.base.util.string.FlexibleStringExpander;
> > >> import org.apache.ofbiz.entity.Delegator;
> > >> import org.apache.ofbiz.entity.GenericValue;
> > >> import org.apache.ofbiz.entity.util.EntityUtilProperties;
> > >> import org.apache.ofbiz.service.DispatchContext;
> > >> import org.apache.ofbiz.service.GenericServiceException;
> > >> import org.apache.ofbiz.service.LocalDispatcher;
> > >> import org.apache.ofbiz.service.ServiceUtil;
> > >> import org.apache.ofbiz.service.mail.MimeMessageWrapper;
> > >> import org.apache.ofbiz.webapp.view.ApacheFopWorker;
> > >> import org.apache.ofbiz.widget.renderer.macro.MacroScreenRenderer;
> > >> import org.apache.ofbiz.widget.renderer.ScreenRenderer;
> > >> import 

Re: Welcome to Mathieu Lirzin as new committer!

[Gil Portenseigne]

Welcome Mathieu, and Congratulations !

Gil

Le 20:15 - mardi 19 févr., Taher Alkhateeb a écrit :
> The OFBiz PMC has invited Mathieu Lirzin to become a new committer and
> we are happy to announce that he has accepted this role.
> 
> Some of the reasons for inviting Mathieu include:
> 
> - He is invested in the OFBiz project and has delivered substantial
> work to the code base.
> - He has demonstrated solid technical skills.
> - He adopts a professional attitude towards coding and software development.
> - He engages thoughtfully with others and likes to work with the community.
> 
> Please join me in welcoming and congratulating Mathieu!
> 
> Cheers,
> Taher Alkhateeb

Re: buildbot failure in on ofbizTrunkFrameworkPlugins

[Gil Portenseigne]

Hello,

I just checked again with  ‘./gradlew cleanAll loadAll testIntegration’,
A got build successful... no failure.

Gil

Le 20:11 - vendredi 28 déc., Jacques Le Roux a écrit :
> Hi Gil,
> 
> Are we sure there is not a test issue with this commit?
> 
> Locally I can't reproduce the same but I have also 4 failures, could you 
> please check on your side?
> 
> Thanks
> 
> Jacques
> 
> Le 28/12/2018 à 15:28, build...@apache.org a écrit :
> > The Buildbot has detected a new failure on builder 
> > ofbizTrunkFrameworkPlugins while building . Full details are available at:
> >  https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/625
> > 
> > Buildbot URL: https://ci.apache.org/
> > 
> > Buildslave for this Build: silvanus_ubuntu
> > 
> > Build Reason: downstream
> > Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1849853
> > Blamelist: pgil
> > 
> > BUILD FAILED: failed shell_4
> > 
> > Sincerely,
> >   -The Buildbot
> > 
> > 
> > 
> > 

OFBIZ-10691 Refactoring ‘EntityCondition’

[Gil Portenseigne]

Hello,

There is a very nice contribution from Mathieu Lirzin about refactoring
EntityCondition class hierarchy, to make it more legit and
understandable.

It is well documented and validated against integration test and basic
usage

This lies in OFBIZ-10691 Jira, if you want to have a look, i will commit it
next week.

Also Mathieu ask to not squash the patches within the Jira, and i'm
particularly in favor of it, since it is not the custom to do it in
OFBiz, i wanted to make it clear :).

Regards,

Gil 

Re: [DISCUSSION] Checking debug levels in Java and Groovy files

[Gil Portenseigne]

Hello,

The difference with the documentation and Mathieu's example is the
presence of String concatenation. Here lies the performance improvment.

If there a simple String is used, the if is uneeded :)

Regards

Gil

Le 19:58 - mardi 11 déc., Taher Alkhateeb a écrit :
> The official documentation mentions that performance is hit [1] with metrics.
> 
> [1] 
> https://logging.apache.org/log4j/2.x/performance.html#asyncLoggingWithParams
> On Tue, Dec 11, 2018 at 7:19 PM Mathieu Lirzin
>  wrote:
> >
> > He gets exactly the same performance results (1.08× ns/op) with either
> > of the following options:
> >
> >1) Debug.log("...")
> >2) if (Debug.isEnabled()) { Debug.log("...") }
> >3) Debug.log(() -> "...")
> >

Re: svn commit: r1845086 [2/2] - in /ofbiz/ofbiz-framework/trunk/applications: accounting/webapp/accounting/WEB-INF/ content/webapp/content/WEB-INF/ order/webapp/ordermgr/WEB-INF/ party/webapp/partymg

[Gil Portenseigne]

Hello Suraj,

Is there a reason to keep empty path for service event ?

Regards

Gil

Le lundi 29 oct. 2018 à 08:14:55 (-), sur...@apache.org a écrit :
> Modified: 
> ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml?rev=1845086=1845085=1845086=diff
> ==
> --- 
> ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml
>  (original)
> +++ 
> ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/workeffort/WEB-INF/controller.xml
>  Mon Oct 29 08:14:55 2018
> @@ -482,21 +482,21 @@ under the License.
>  
>  
>  
> -
> +
>  
>  
>  
>  
>  
>  
> -
> +
>  
>  
>  
>  
>  
>  
> -
> +
>  
>  
>  
> @@ -509,21 +509,21 @@ under the License.
>  
>  
>  
> -
> +
>   value="EditWorkEffortGoodStandards"/>
>   value="EditWorkEffortGoodStandards"/>
>  
>  
>  
>  
> -
> +
>   value="EditWorkEffortGoodStandards"/>
>   value="EditWorkEffortGoodStandards"/>
>  
>  
>  
>  
> -
> +
>   value="EditWorkEffortGoodStandards"/>
>   value="EditWorkEffortGoodStandards"/>
>  
> 
> 

Re: Pursuing the “120 chars max” guideline (was: svn commit: r1844729 - in /ofbiz/ofbiz-framework/trunk/framework/webapp: dtd/site-conf.xsd src/main/java/org/apache/ofbiz/webapp/control/RequestHandler

[Gil Portenseigne]

Hello,

+1 to follow the 120char guideline for any commit that the purpose it
not to refactor line length :).

Gil


Le vendredi 26 oct. 2018 à 11:13:48 (+0200), Mathieu Lirzin a écrit :
> Hello Jacques,
> 
> Jacques Le Roux  writes:
> 
> > Yes you are right, the whole file should be reformatted.
> >
> > This "around 120 chars max" rule is "new" (few years) and most of the
> > code there is more than a decade.
> 
> OK, sure.
> 
> > If nobody disagree we could have a task Jira to reformat the code of
> > the most important classes (with subtasks maybe, or simply patches for
> > concerned classes).
> 
> I sympathise but I am not sure about this strategy, which depending on
> the capabilities of your VCS might obscure the commit history.  I would
> recommend to simply use the “120 chars max” guideline for newly added
> code and when refactoring existing one.
> 
> WDYT?
> 
> -- 
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Groovy DSL runService Exception Management ?

[Gil Portenseigne]

Thanks Jacopo and Taher for your answers.

I understand now the goal of this and will try to use it to
allow less verbosity in service error handling management in Groovy DSL.

Indeed, in a way, each service using groovy should throw
ExecutionServiceException that should be managed within the
service engine itself.

In that way, there won't be needed systematic test against service return
in groovy and that is a good thing.


Gil

Le dimanche 21 oct. 2018 à 08:02:35 (+0200), Jacopo Cappellato a écrit :
> On Thu, Oct 18, 2018 at 10:45 AM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
> 
> > Hello !
> >
> > While we are working on Groovy migration at Nereide, we figured out that
> > using ‘run service’ DSL method instead of returning the errorMap, a
> > ‘ExecutionServiceException’ is thrown
> 
> [...]
> > I wonder if exception management is more costly than simple return.
> > May the GroovyEngine should handle the exception ? I do not grasp yet
> > the benenit of this implementation.
> >
> 
>  Hi Gil,
> 
> if I recall correctly, the original goal was to implement a behavior
> similar to the default one of Minilang: if an error is thrown during the
> execution of the "call-service" directive in Minilang then the script
> execution is halted (see the definition of the property "break-on-error").
> 
> I hope it makes sense,
> 
> Jacopo

Groovy DSL runService Exception Management ?

[Gil Portenseigne]

Hello !

While we are working on Groovy migration at Nereide, we figured out that
using ‘run service’ DSL method instead of returning the errorMap, a
‘ExecutionServiceException’ is thrown :

if (ServiceUtil.isError(result)) {
throw new
ExecutionServiceException(ServiceUtil.getErrorMessage(result))
}

Can anyone explain the intention behind that implementation ?

I suppose that we need to catch any service call like :

try {
serviceResult = run service: 'createQuoteAdjustment', with:
[*: quoteAdjustement, quoteId: quoteIdTo]
} catch (ExecutionServiceException e) {
return ServiceUtil.returnError(e.getMessage())
}

instead of : 

serviceResult = run service: 'createQuoteAdjustment', with:
[*: quoteAdjustement, quoteId: quoteIdTo]

if (ServiceUtil.isError(serviceResult)) {
return serviceResult
}

I wonder if exception management is more costly than simple return.
May the GroovyEngine should handle the exception ? I do not grasp yet
the benenit of this implementation.

What is the good way to handle service errors within services in Groovy?

Thanks

Gil

Re: svn commit: r1843780 - in /ofbiz/ofbiz-framework/trunk/framework/entity/src: main/java/org/apache/ofbiz/entity/condition/ test/java/org/apache/ofbiz/entity/

[Gil Portenseigne]

Hello, 
I think that is an incompatibiliy with Windows newline char (\n vs
\r\n).

Thanks for the feedback, I'll improve that soon.

Gil

Le lundi 15 oct. 2018 à 18:09:30 (+0200), Jacques Le Roux a écrit :
> Hi Gil,
> 
> Not yet sure it's only me (Windows) but I get this locally
> 
> org.apache.ofbiz.entity.EntityConditionVisitorTests > basicTest FAILED
>     org.junit.ComparisonFailure at EntityConditionVisitorTests.java:83
> 
> Buildbot should run soon (after r1843921), and tells us...
> 
> Jacques
> 
> 
> Le 13/10/2018 à 21:50, p...@apache.org a écrit :
> > Author: pgil
> > Date: Sat Oct 13 19:50:27 2018
> > New Revision: 1843780
> > 
> > URL: http://svn.apache.org/viewvc?rev=1843780=rev
> > Log:
> > Improved: Rewrite EntityConditionVisitor interface to respect visitor 
> > Pattern
> > (OFBIZ-10593)
> > 
> > Remove visit methods from current EntityConditionBase type hierarchy.
> > Add or rewrite accept method in EntityCondition type hierachy.
> > Add documentation in EntityConditionVisitor, introducing implementation 
> > examples.
> > Add junit test validating documented examples.
> > Thanks to Mathieu Lirzin for your contribution, and Jacques for the review.
> > 
> > Added:
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/test/java/org/apache/ofbiz/entity/EntityConditionVisitorTests.java
> >(with props)
> > Modified:
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityComparisonOperator.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityCondition.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityConditionBuilder.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityConditionFunction.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityConditionList.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityConditionListBase.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityConditionSubSelect.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityConditionValue.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityConditionVisitor.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityDateFilterCondition.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityExpr.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityFieldMap.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityFieldValue.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityFunction.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityJoinOperator.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityOperator.java
> >  
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityWhereString.java
> > 
> > Modified: 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityComparisonOperator.java
> > URL: 
> > http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityComparisonOperator.java?rev=1843780=1843779=1843780=diff
> > ==
> > --- 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityComparisonOperator.java
> >  (original)
> > +++ 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityComparisonOperator.java
> >  Sat Oct 13 19:50:27 2018
> > @@ -78,12 +78,6 @@ public abstract class EntityComparisonOp
> >   }
> >   @Override
> > -public void visit(EntityConditionVisitor visitor, L lhs, R rhs) {
> > -visitor.accept(lhs);
> > -visitor.accept(rhs);
> > -}
> > -
> > -@Override
> >   public void addSqlValue(StringBuilder sql, ModelEntity entity, 
> > List entityConditionParams, boolean compat, L lhs, R 
> > rhs, Datasource datasourceInfo) {
> >   // if this is an IN operator and the rhs Object isEmpty, add 
> > "1=0" instead of the normal SQL.  Note that "FALSE" does not work with all 
> > databases.
> > 
> > Modified: 
> >