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

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

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

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

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

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

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

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,

Re: Implement AutoCloseable interface in SQLProcessor Class

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

Re: Implement AutoCloseable interface in SQLProcessor Class

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,

Implement AutoCloseable interface in SQLProcessor Class

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

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

Re: CodeNarc Gradle plugin

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

Re: FindBugs for Groovy?

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

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

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?

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

Re: CodeNarc Gradle plugin

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

Re: FindBugs for Groovy?

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]

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

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

Re: FindBugs for Groovy?

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

FindBugs for Groovy?

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

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

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