Re: svn commit: r1811699 - /ofbiz/ofbiz-framework/trunk/framework/service/src/main/java/org/apache/ofb iz/service/config/model/ThreadPool.java

[Jacques Le Roux]

Hi Scott, Michael,

It's late but I'm still reading  Java Concurrency in Practice (not now, but actually  often :)) and I agree with (all) answers at 
https://stackoverflow.com/questions/13834692/threads-configuration-based-on-no-of-cpu-cores


It's indeed not a trivial task to determine the best value, and the reference 
above in serviceengine.xml should not hurt.
We can keep 5 but I believe have to explain why at the upper level. It's a very important value and not all people (often) read Java Concurrency in 
Practice


What do you think?

Jacques


Le 12/10/2017 à 22:12, Scott Gray a écrit :

Honestly I think the topic is generic enough that OFBiz doesn't need to
provide any information at all.  Thread pool sizing is not exclusive to
OFBiz and it would be strange for anyone to modify the numbers without
first researching sources that provide far more detail than a few sentences
in our config files will ever cover.

Regards
Scott

On 12 October 2017 at 12:49, Michael Brohl  wrote:


Hi Jacques,

yes, in general I think it's best to document at the place where users do
the configuration.

In this case, I cannot say if the statement makes any sense. It can be
from ancient times where you only had single core systems not making sense
anymore and it can also be correct today.

Maybe someone with more knowledege in this area can give us more info.

Regards,

Michael


Am 12.10.17 um 14:17 schrieb Jacques Le Roux:

Right, thanks Michael

Thought some documentation is present in ThreadPool.java, I think we
should document that at the service serviceengine.xml level

I mean, in general, we should document at the level used to configure,
not below.

Here for instance something like "Values higher than 5 might slow things
down depending of your cores numbers"

Also before written so we would have to verify why the 5 value was picked

What do you think?

Jacques


Le 12/10/2017 à 13:03, Michael Brohl a écrit :


Hi Jacques,

as you said, it's just a default and the value can be configured through
"max-threads".

I would leave it as is.

Regards,

Michael


Am 11.10.17 um 07:58 schrieb Jacques Le Roux:


MAX_THREADS = 5

Re: svn commit: r1811699 - /ofbiz/ofbiz-framework/trunk/framework/service/src/main/java/org/apache/ofb iz/service/config/model/ThreadPool.java

[Scott Gray]

Honestly I think the topic is generic enough that OFBiz doesn't need to
provide any information at all.  Thread pool sizing is not exclusive to
OFBiz and it would be strange for anyone to modify the numbers without
first researching sources that provide far more detail than a few sentences
in our config files will ever cover.

Regards
Scott

On 12 October 2017 at 12:49, Michael Brohl  wrote:

> Hi Jacques,
>
> yes, in general I think it's best to document at the place where users do
> the configuration.
>
> In this case, I cannot say if the statement makes any sense. It can be
> from ancient times where you only had single core systems not making sense
> anymore and it can also be correct today.
>
> Maybe someone with more knowledege in this area can give us more info.
>
> Regards,
>
> Michael
>
>
> Am 12.10.17 um 14:17 schrieb Jacques Le Roux:
>
> Right, thanks Michael
>>
>> Thought some documentation is present in ThreadPool.java, I think we
>> should document that at the service serviceengine.xml level
>>
>> I mean, in general, we should document at the level used to configure,
>> not below.
>>
>> Here for instance something like "Values higher than 5 might slow things
>> down depending of your cores numbers"
>>
>> Also before written so we would have to verify why the 5 value was picked
>>
>> What do you think?
>>
>> Jacques
>>
>>
>> Le 12/10/2017 à 13:03, Michael Brohl a écrit :
>>
>>> Hi Jacques,
>>>
>>> as you said, it's just a default and the value can be configured through
>>> "max-threads".
>>>
>>> I would leave it as is.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 11.10.17 um 07:58 schrieb Jacques Le Roux:
>>>
 MAX_THREADS = 5

>>>
>>>
>>>
>>
>
>

Re: svn commit: r1811699 - /ofbiz/ofbiz-framework/trunk/framework/service/src/main/java/org/apache/ofb iz/service/config/model/ThreadPool.java

[Michael Brohl]

Hi Jacques,

yes, in general I think it's best to document at the place where users 
do the configuration.


In this case, I cannot say if the statement makes any sense. It can be 
from ancient times where you only had single core systems not making 
sense anymore and it can also be correct today.


Maybe someone with more knowledege in this area can give us more info.

Regards,

Michael


Am 12.10.17 um 14:17 schrieb Jacques Le Roux:

Right, thanks Michael

Thought some documentation is present in ThreadPool.java, I think we 
should document that at the service serviceengine.xml level


I mean, in general, we should document at the level used to configure, 
not below.


Here for instance something like "Values higher than 5 might slow 
things down depending of your cores numbers"


Also before written so we would have to verify why the 5 value was picked

What do you think?

Jacques


Le 12/10/2017 à 13:03, Michael Brohl a écrit :

Hi Jacques,

as you said, it's just a default and the value can be configured 
through "max-threads".


I would leave it as is.

Regards,

Michael


Am 11.10.17 um 07:58 schrieb Jacques Le Roux:

MAX_THREADS = 5










smime.p7s
Description: S/MIME Cryptographic Signature

Re: Planning for the creation of the new 17.xx branch(es)

[Nicolas Malin]

Hi,

Agree to create the release 17.11 with a separate products framework & 
plugins.


It's woulb be nice to create this release one week after the next 
community days :)


Nicolas


Le 10/10/2017 à 09:35, Jacopo Cappellato a écrit :

Hi all,

I think it is time to start thinking about if, when, how we should create
the new release branch out of the trunk. Actually, for the first time, we
should probably create two branches: one for the framework and one for the
plugins.
What do you think?

In my opinion we could try to get all the changes we want to have in the
trunk to be included in the branch by end of November: this means that the
the creation of the branch could happen at the end of November.
If this is the case then the names could be:
release17.11-framework
release17.11-plugins

The above is for the release *branches* only, not for the actual releases.
We could decide at a later point if the actual releases will be shipped as
two separate products (e.g. "Apache OFBiz Framework 17.11.01" and "Apache
OFBiz Plugins 17.11.01") or merged into one (e.g. "Apache OFBiz 17.11.01").

Best regards,

Jacopo

Re: Implement AutoCloseable interface in SQLProcessor Class

[Yash Sharma]

Thank You, Jacques, I have created a Jira Ticket for the same OFBIZ-9841
 and will provide the
patch soon.


On Thu, Oct 12, 2017 at 9:04 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 12/10/2017 à 16:09, Yash Sharma a écrit :
> > Hello All,
> >
> > SQLProcessor class has a close method which does work of closing of
> > ResultSet, PreparedStatement and Connection, we can use AutoCloseable
> > interface to do that.
> >
> > Please share your thoughts.
> Hi Yash,
>
> I see no reasons why we would not, cleaner and safer code
>
> Jacques
>
> --
Thanks,
*Pradhan Yash Sharma*

Re: Implement AutoCloseable interface in SQLProcessor Class

[Jacques Le Roux]

Le 12/10/2017 à 16:09, Yash Sharma a écrit :

Hello All,

SQLProcessor class has a close method which does work of closing of
ResultSet, PreparedStatement and Connection, we can use AutoCloseable
interface to do that.

Please share your thoughts.

Hi Yash,

I see no reasons why we would not, cleaner and safer code

Jacques

Implement AutoCloseable interface in SQLProcessor Class

[Yash Sharma]

Hello All,

SQLProcessor class has a close method which does work of closing of
ResultSet, PreparedStatement and Connection, we can use AutoCloseable
interface to do that.

Please share your thoughts.
-- 
Thanks,
*Pradhan Yash Sharma*

Re: svn commit: r1811699 - /ofbiz/ofbiz-framework/trunk/framework/service/src/main/java/org/apache/ofb iz/service/config/model/ThreadPool.java

[Jacques Le Roux]

Right, thanks Michael

Thought some documentation is present in ThreadPool.java, I think we should 
document that at the service serviceengine.xml level

I mean, in general, we should document at the level used to configure, not 
below.

Here for instance something like "Values higher than 5 might slow things down 
depending of your cores numbers"

Also before written so we would have to verify why the 5 value was picked

What do you think?

Jacques


Le 12/10/2017 à 13:03, Michael Brohl a écrit :

Hi Jacques,

as you said, it's just a default and the value can be configured through 
"max-threads".

I would leave it as is.

Regards,

Michael


Am 11.10.17 um 07:58 schrieb Jacques Le Roux:

MAX_THREADS = 5

Re: CodeNarc Gradle plugin

[Jacques Le Roux]

Hi Michael,

I answered in your new "FindBugs for Groovy?" threads

I thought I had a codenarc.patch somewhere but I could not find it yet. I'll 
search again and let you know...

Jacques


Le 12/10/2017 à 12:44, Michael Brohl a écrit :

Hi Jacques,

just stumbled over this while searching for a way to analyze Groovy code in 
OFBiz.

Can you tell us what the problem was?

Thanks,

Michael


Am 18.09.17 um 13:12 schrieb Jacques Le Roux:

Hi,

I wanted to test the CodeNarc Gradle plugin https://docs.gradle.org/current/userguide/codenarc_plugin.html to see how it would complete the work 
done with FindBugs


But, despite some efforts, I was unable to make it work with OFBiz

Has someone an experience with it? Should we care?

Jacques

Re: FindBugs for Groovy?

[Jacques Le Roux]

Hi Taher, Michael,

I don't remember exactly the issues I crossed; but I tend to agree that 
following conventions often helps!

Jacques


Le 12/10/2017 à 12:48, Taher Alkhateeb a écrit :

Oh, without digging into details it's probably not going to be easy.
Not because the tool is insufficient but because of problems in the
way we integrate groovy in OFBiz. It's not standardized, and we use it
as a DSL with code snippets scattered around. Ideally, our groovy code
should reside for example in src/main/groovy and src/test/groovy for
example whereas we have it in non-standard locations both in webapps
and in other directories.

I could be wrong but I suspect that it would not be easy to find a
solution out of the box because of the unusual setup I mentioned
above.

On Thu, Oct 12, 2017 at 1:42 PM, Michael Brohl  wrote:

Hi Taher,

yes, this would be a solution but I remembered Jacques having problems to
make it work with OFBiz [1].

I'll pick up the thread to get to know the problem.

Thanks,

Michael


[1]
https://lists.apache.org/thread.html/40240117ca0e24ef3f4b14a3c6c7c491a49b4071dfe08923cd4751a8@%3Cdev.ofbiz.apache.org%3E


Am 12.10.17 um 12:05 schrieb Taher Alkhateeb:


Hi Michael,

Why not naybe something like codenarc [1]. They have a gradle builtin
plugin [2].
[1] http://codenarc.sourceforge.net/
[2] https://docs.gradle.org/current/userguide/codenarc_plugin.html

On Oct 12, 2017 12:59 PM, "Michael Brohl" 
wrote:


Hi all,

we are heavily doing code analysis with FindBugs and made progress with
the Java packages, see [1].

We have decided to convert mini lang to Groovy files and it seems that
people start writing new services using the Groovy DSL. I see one
drawback
that we cannot use static code analysis tools to check code quality.

Does someone know a way compatible with OFBiz to also analyze Groovy
files?

Any hint is appreciated.

Thanks,

Michael


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

Re: svn commit: r1811699 - /ofbiz/ofbiz-framework/trunk/framework/service/src/main/java/org/apache/ofb iz/service/config/model/ThreadPool.java

[Michael Brohl]

Hi Jacques,

as you said, it's just a default and the value can be configured through 
"max-threads".


I would leave it as is.

Regards,

Michael


Am 11.10.17 um 07:58 schrieb Jacques Le Roux:

MAX_THREADS = 5





smime.p7s
Description: S/MIME Cryptographic Signature

Re: FindBugs for Groovy?

[Taher Alkhateeb]

Oh, without digging into details it's probably not going to be easy.
Not because the tool is insufficient but because of problems in the
way we integrate groovy in OFBiz. It's not standardized, and we use it
as a DSL with code snippets scattered around. Ideally, our groovy code
should reside for example in src/main/groovy and src/test/groovy for
example whereas we have it in non-standard locations both in webapps
and in other directories.

I could be wrong but I suspect that it would not be easy to find a
solution out of the box because of the unusual setup I mentioned
above.

On Thu, Oct 12, 2017 at 1:42 PM, Michael Brohl  wrote:
> Hi Taher,
>
> yes, this would be a solution but I remembered Jacques having problems to
> make it work with OFBiz [1].
>
> I'll pick up the thread to get to know the problem.
>
> Thanks,
>
> Michael
>
>
> [1]
> https://lists.apache.org/thread.html/40240117ca0e24ef3f4b14a3c6c7c491a49b4071dfe08923cd4751a8@%3Cdev.ofbiz.apache.org%3E
>
>
> Am 12.10.17 um 12:05 schrieb Taher Alkhateeb:
>
>> Hi Michael,
>>
>> Why not naybe something like codenarc [1]. They have a gradle builtin
>> plugin [2].
>> [1] http://codenarc.sourceforge.net/
>> [2] https://docs.gradle.org/current/userguide/codenarc_plugin.html
>>
>> On Oct 12, 2017 12:59 PM, "Michael Brohl" 
>> wrote:
>>
>>> Hi all,
>>>
>>> we are heavily doing code analysis with FindBugs and made progress with
>>> the Java packages, see [1].
>>>
>>> We have decided to convert mini lang to Groovy files and it seems that
>>> people start writing new services using the Groovy DSL. I see one
>>> drawback
>>> that we cannot use static code analysis tools to check code quality.
>>>
>>> Does someone know a way compatible with OFBiz to also analyze Groovy
>>> files?
>>>
>>> Any hint is appreciated.
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9450
>>>
>>>
>>>
>>>
>
>

Re: CodeNarc Gradle plugin

[Michael Brohl]

Hi Jacques,

just stumbled over this while searching for a way to analyze Groovy code 
in OFBiz.


Can you tell us what the problem was?

Thanks,

Michael


Am 18.09.17 um 13:12 schrieb Jacques Le Roux:

Hi,

I wanted to test the CodeNarc Gradle plugin 
https://docs.gradle.org/current/userguide/codenarc_plugin.html to see 
how it would complete the work done with FindBugs


But, despite some efforts, I was unable to make it work with OFBiz

Has someone an experience with it? Should we care?

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature

Re: FindBugs for Groovy?

[Michael Brohl]

Hi Taher,

yes, this would be a solution but I remembered Jacques having problems 
to make it work with OFBiz [1].


I'll pick up the thread to get to know the problem.

Thanks,

Michael


[1] 
https://lists.apache.org/thread.html/40240117ca0e24ef3f4b14a3c6c7c491a49b4071dfe08923cd4751a8@%3Cdev.ofbiz.apache.org%3E



Am 12.10.17 um 12:05 schrieb Taher Alkhateeb:

Hi Michael,

Why not naybe something like codenarc [1]. They have a gradle builtin
plugin [2].
[1] http://codenarc.sourceforge.net/
[2] https://docs.gradle.org/current/userguide/codenarc_plugin.html

On Oct 12, 2017 12:59 PM, "Michael Brohl"  wrote:


Hi all,

we are heavily doing code analysis with FindBugs and made progress with
the Java packages, see [1].

We have decided to convert mini lang to Groovy files and it seems that
people start writing new services using the Groovy DSL. I see one drawback
that we cannot use static code analysis tools to check code quality.

Does someone know a way compatible with OFBiz to also analyze Groovy files?

Any hint is appreciated.

Thanks,

Michael


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









smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Proposal] Add a Redis plugin to codebase (OFBIZ-9829)

[Michael Brohl]

Hi Jinghai,

first of all thanks for your contribution. I appreciate your work, even 
if I do not agree with the process (see Jira issue).


So please understand my critical questions as an attempt to assure a 
good process and quality for the project and not a refusal of your work 
or this plugin in general.


For a proper proposal, please provide more informations on the solution 
and why it is useful for the project. You can see the community as a 
customer and you have to convince us that the solution is worth being 
introduced to OFBiz and being maintained further. In the past, we had 
several half-baked additions to the codebase which were committed and 
not maintained anymore.


I would like to avoid this and the best way (IMO) is to be more 
restrictive when introducing new code to the project.


For this plugin, at first glance, I'm missing the following informations 
and quality aspects:


- the big picture: the motivation and use cases for this plugin and 
OFBiz integration
- a documentation (brief descriptions of Redis et al or just links to 
these projects are not a documentation)

- why you have chosen Redis and the Redisson client and not some other
- a sample integration into OFBiz (to prove it is working and to show 
how it is used)

- tests
- source code documentation

This is just a shot from my first impressions, others may  follow.

Looking forward to a good collaboration on this.

Thanks,

Michael


Am 12.10.17 um 03:38 schrieb Shi Jinghai:

Hi community,

There's a patch on Redis plugin in 
https://issues.apache.org/jira/browse/OFBIZ-9829.

Redis is key-value in-memory database widely used in Ecommerce and CRM.

Michael asked me to discuss whether it's necessary to include it in OFBiz 
codebase. If not, I'll revert it.

Thanks for your feedback,

Shi Jinghai







smime.p7s
Description: S/MIME Cryptographic Signature

Re: FindBugs for Groovy?

[Taher Alkhateeb]

Hi Michael,

Why not naybe something like codenarc [1]. They have a gradle builtin
plugin [2].
[1] http://codenarc.sourceforge.net/
[2] https://docs.gradle.org/current/userguide/codenarc_plugin.html

On Oct 12, 2017 12:59 PM, "Michael Brohl"  wrote:

> Hi all,
>
> we are heavily doing code analysis with FindBugs and made progress with
> the Java packages, see [1].
>
> We have decided to convert mini lang to Groovy files and it seems that
> people start writing new services using the Groovy DSL. I see one drawback
> that we cannot use static code analysis tools to check code quality.
>
> Does someone know a way compatible with OFBiz to also analyze Groovy files?
>
> Any hint is appreciated.
>
> Thanks,
>
> Michael
>
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-9450
>
>
>
>

FindBugs for Groovy?

[Michael Brohl]

Hi all,

we are heavily doing code analysis with FindBugs and made progress with 
the Java packages, see [1].


We have decided to convert mini lang to Groovy files and it seems that 
people start writing new services using the Groovy DSL. I see one 
drawback that we cannot use static code analysis tools to check code 
quality.


Does someone know a way compatible with OFBiz to also analyze Groovy files?

Any hint is appreciated.

Thanks,

Michael


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





smime.p7s
Description: S/MIME Cryptographic Signature

Fwd: Implementing GST tax in Ofbiz - CGST , SGST , IGST

[Vaibhav Jain]

Moving discussion to DEV list
==

Hello Rajesh/Everyone,

GST(India) can be implemented in OFBiz as follow:

After GST tax will apply on the basis of HSN code of product not on the
product directly. So we can associate HSN code with tax slab in
ProductCategoryRollup entity like



As we need to define tax slab, ProductCategory entity can be used to
categorise the tax slabs like



Now tax slab is associated with HSN. So, product will be associated with
HSN code in ProductCategoryMember entity like



 All the HSN code can be stored in ProductCategory entity



Tax authority can be stored in PartyTaxAuthInfo entity like






GST can be configurable in OFBiz using ProductStoreTaxSetting entity
We can write a separate service to calculate GST and configure at
ProductStore level using taxServiceName attribute of ProductStoreTaxSetting
entity.

Just for Info
Right now In PO and SO OFBiz does not entertain both SHIP_ORIG_LOCATION and
SHIP_DESTINATION_LOCATION. We need to introduce this as well to calculate
the GST.

Thanks & Regards

Vaibhav Jain
Hotwax Systems,
vaibhav.j...@hotwaxsystems.com

On Mon, Oct 9, 2017 at 8:13 PM, Rajesh Mallah 
wrote:

> Hi ,
>
> I need help regarding how to apply taxes   broadly based on the
> fact whether the supplier and consumer are in same state or not.
>
> We are able to apply taxes based on GEO ID of the customer but
> what is really required is the below:
>
> If Supplier.state == Customer.state
>   add adjustment SGST @  X%
>   add adjustment CGST @  X%
> else
>   add adjustment IGST  @  X+X%
>
>
> where:
> CGST --> Central Goods & Services Tax
> SGST --> State Goods & Services Tax
> IGST  --> Integrated Goods & Services Tax
>
>
> Any help on this regard is solicited.
>
>
> regds
> mallah.
>