Re: svn commit: r1700119 [1/26] - in /ofbiz/trunk: ./ runtime/indexes/ specialpurpose/ specialpurpose/solr/ specialpurpose/solr/conf/ specialpurpose/solr/config/ specialpurpose/solr/entitydef/ special

2016-09-05 Thread Shi Jinghai 
Hi Jacopo,

Let me clean the OFBizSolrContextFilter now.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacopo Cappellato [mailto:jacopo.cappell...@hotwaxsystems.com] 
发送时间: 2016年9月5日 22:20
收件人: dev@ofbiz.apache.org
主题: Re: svn commit: r1700119 [1/26] - in /ofbiz/trunk: ./ runtime/indexes/ 
specialpurpose/ specialpurpose/solr/ specialpurpose/solr/conf/ 
specialpurpose/solr/config/ specialpurpose/solr/entitydef/ 
specialpurpose/solr/lib/ specialpurpose/solr/lib/compile/ s...

Hi Jinghai,

I have noticed that when you have committed the Solr component you have created 
a class named OFBizSolrContextFilter.java that is mostly the copy of 
ContextFilter: as a consequence the logic implemented in its utility methods 
has been duplicated.
I didn't check, but it is possible that other code in this commit is affected 
by the same anti pattern.
This is making the maintenance of the code more difficult: for example, I am in 
the process of cleaning/refactoring the code in ContextFilter and I am not sure 
how to deal with the same copy of it in OFBizSolrContextFilter.

Is there anything you can do to fix this?

Thank you,

Jacopo


On Sun, Aug 30, 2015 at 3:27 PM,  wrote:

> Author: shijh
> Date: Sun Aug 30 13:27:07 2015
> New Revision: 1700119
>
> URL: http://svn.apache.org/r1700119
> Log:
> OFBIZ-5042 Apache Solr Implementation.
> 1. Put the patch into trunk.
> 2. Added access control to solr /admin/ pages.
> 3. Upgraded solr to 4.9.0 to match Lucene version in trunk.
> 4. Removed solr.solr.home, used
> SolrResourceLoader loader = new SolrResourceLoader("
> specialpurpose/solr/conf");
> instead.
>
> Added:
> ...

   ofbiz/trunk/specialpurpose/solr/src/org/ofbiz/solr/
> webapp/OFBizSolrContextFilter.java   (with props)
>

Re: Michael Brohl joins OFBiz PMC

2016-09-05 Thread Wai 
Congratulations!
Wai



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Michael-Brohl-joins-OFBiz-PMC-tp4692278p4692811.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: svn commit: r1700119 [1/26] - in /ofbiz/trunk: ./ runtime/indexes/ specialpurpose/ specialpurpose/solr/ specialpurpose/solr/conf/ specialpurpose/solr/config/ specialpurpose/solr/entitydef/ special

2016-09-05 Thread Jacopo Cappellato 
Hi Jinghai,

I have noticed that when you have committed the Solr component you have
created a class named OFBizSolrContextFilter.java that is mostly the copy
of ContextFilter: as a consequence the logic implemented in its utility
methods has been duplicated.
I didn't check, but it is possible that other code in this commit is
affected by the same anti pattern.
This is making the maintenance of the code more difficult: for example, I
am in the process of cleaning/refactoring the code in ContextFilter and I
am not sure how to deal with the same copy of it in OFBizSolrContextFilter.

Is there anything you can do to fix this?

Thank you,

Jacopo


On Sun, Aug 30, 2015 at 3:27 PM,  wrote:

> Author: shijh
> Date: Sun Aug 30 13:27:07 2015
> New Revision: 1700119
>
> URL: http://svn.apache.org/r1700119
> Log:
> OFBIZ-5042 Apache Solr Implementation.
> 1. Put the patch into trunk.
> 2. Added access control to solr /admin/ pages.
> 3. Upgraded solr to 4.9.0 to match Lucene version in trunk.
> 4. Removed solr.solr.home, used
> SolrResourceLoader loader = new SolrResourceLoader("
> specialpurpose/solr/conf");
> instead.
>
> Added:
> ...

   ofbiz/trunk/specialpurpose/solr/src/org/ofbiz/solr/
> webapp/OFBizSolrContextFilter.java   (with props)
>

Re: svn commit: r1759250 - /ofbiz/trunk/build.gradle

2016-09-05 Thread Jacques Le Roux 

Taher,

Actually it was the description of the issue I created back then. I saw it after routinely copying it, but did not change it, because I had to move. I 
will edit the commit comment, to have something meaningful there.


Jacques


Le 05/09/2016 à 14:30, Taher Alkhateeb a écrit :

Hi Jacques,

I don't understand your concern described below? What is the problem of
having jars not related to OFBiz in gradle's cache? What is the problem?

Regards,

Taher Alkhateeb

On Sep 5, 2016 3:24 PM,  wrote:


Author: jleroux
Date: Mon Sep  5 12:24:21 2016
New Revision: 1759250

URL: http://svn.apache.org/viewvc?rev=1759250=rev
Log:
A slightly modified Taher's patch for "Load the OWASP dependency checker
Gradle plugin efficiently" I reported at OFBIZ-7930

As I warned at https://cwiki.apache.org/confluence/display/OFBIZ/
About+OWASP+Dependency+Check it's currently difficult to separate the
OFBiz jars from other jars in the .gradle\caches contains which may contain
jars unrelated to OFBiz. Notably Eclipse jars if you use the Gradle Eclipse
task and more if you use Gradle for other reasons than OFBiz.
I did not find yet a way to avoid to have all external jars in
.gradle\caches and I wonder if it's even possible. What I would like to
have is the external jars mandatory for OFBiz to work in an isolated place.
For instance a sub folder of the main Gradle build folder. I picked
$buildDir/externalJars.

Taher:  I have a clean working solution now that does not affect users who
do not want the OWASP plugin.


jleroux: I have simply formatted the "if(" to "if ("

Modified:
 ofbiz/trunk/build.gradle

Modified: ofbiz/trunk/build.gradle
URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
1759250=1759249=1759250=diff

==
--- ofbiz/trunk/build.gradle (original)
+++ ofbiz/trunk/build.gradle Mon Sep  5 12:24:21 2016
@@ -269,6 +269,28 @@ eclipse.classpath.file.whenMerged { clas
  }
  tasks.eclipse.dependsOn(cleanEclipse)

+/* OWASP plugin
+ *
+ * If project property "enableOwasp" is flagged then
+ * gradle will download required dependencies and
+ * activate Gradle's OWASP plugin and its related tasks.
+ *
+ * Syntax: gradlew -PenableOwasp dependencyCheck
+ */
+buildscript {
+if (project.hasProperty('enableOwasp')) {
+repositories {
+mavenCentral()
+}
+dependencies {
+classpath 'org.owasp:dependency-check-gradle:1.4.0'
+}
+}
+}
+if (project.hasProperty('enableOwasp')) {
+apply plugin: 'org.owasp.dependencycheck'
+}
+
  /* 
   * Tasks
   *  */

Re: Michael Brohl joins OFBiz PMC

2016-09-05 Thread Pranay Pandey 
Congratulations Michael!

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Mon, Sep 5, 2016 at 6:01 PM, Vogelsme  wrote:

> Congratulations Michael! ;)
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.
> com/Michael-Brohl-joins-OFBiz-PMC-tp4692278p4692806.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

Re: Michael Brohl joins OFBiz PMC

2016-09-05 Thread Vogelsme 
Congratulations Michael! ;) 



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Michael-Brohl-joins-OFBiz-PMC-tp4692278p4692806.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: svn commit: r1759250 - /ofbiz/trunk/build.gradle

2016-09-05 Thread Taher Alkhateeb 
Hi Jacques,

I don't understand your concern described below? What is the problem of
having jars not related to OFBiz in gradle's cache? What is the problem?

Regards,

Taher Alkhateeb

On Sep 5, 2016 3:24 PM,  wrote:

> Author: jleroux
> Date: Mon Sep  5 12:24:21 2016
> New Revision: 1759250
>
> URL: http://svn.apache.org/viewvc?rev=1759250=rev
> Log:
> A slightly modified Taher's patch for "Load the OWASP dependency checker
> Gradle plugin efficiently" I reported at OFBIZ-7930
>
> As I warned at https://cwiki.apache.org/confluence/display/OFBIZ/
> About+OWASP+Dependency+Check it's currently difficult to separate the
> OFBiz jars from other jars in the .gradle\caches contains which may contain
> jars unrelated to OFBiz. Notably Eclipse jars if you use the Gradle Eclipse
> task and more if you use Gradle for other reasons than OFBiz.
> I did not find yet a way to avoid to have all external jars in
> .gradle\caches and I wonder if it's even possible. What I would like to
> have is the external jars mandatory for OFBiz to work in an isolated place.
> For instance a sub folder of the main Gradle build folder. I picked
> $buildDir/externalJars.
>
> Taher:  I have a clean working solution now that does not affect users who
> do not want the OWASP plugin.
>
>
> jleroux: I have simply formatted the "if(" to "if ("
>
> Modified:
> ofbiz/trunk/build.gradle
>
> Modified: ofbiz/trunk/build.gradle
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
> 1759250=1759249=1759250=diff
> 
> ==
> --- ofbiz/trunk/build.gradle (original)
> +++ ofbiz/trunk/build.gradle Mon Sep  5 12:24:21 2016
> @@ -269,6 +269,28 @@ eclipse.classpath.file.whenMerged { clas
>  }
>  tasks.eclipse.dependsOn(cleanEclipse)
>
> +/* OWASP plugin
> + *
> + * If project property "enableOwasp" is flagged then
> + * gradle will download required dependencies and
> + * activate Gradle's OWASP plugin and its related tasks.
> + *
> + * Syntax: gradlew -PenableOwasp dependencyCheck
> + */
> +buildscript {
> +if (project.hasProperty('enableOwasp')) {
> +repositories {
> +mavenCentral()
> +}
> +dependencies {
> +classpath 'org.owasp:dependency-check-gradle:1.4.0'
> +}
> +}
> +}
> +if (project.hasProperty('enableOwasp')) {
> +apply plugin: 'org.owasp.dependencycheck'
> +}
> +
>  /* 
>   * Tasks
>   *  */
>
>
>

Re: Taking action on problems with using JIRA

2016-09-05 Thread Jacques Le Roux 

Hi Sharan,

I saw you created 
https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+Jira

In this thread I suggested

We could start by extracting this section 
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-ManageJIRA%27sissues 
to a new "Manage Jira issues" page and reference it from both

https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
and (or maybe only?)
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
BTW I'll carve in stone (put in page) my comment there (ie no longer a soon 10 years old proposition)! 


I suggest we can now use this section content in this new page, and then 
redirect to the new page.

Thanks

Jacques

Le 05/09/2016 à 13:56, Jacques Le Roux a écrit :
I think one thing we should consider before all the rest is Jiras issues with patches. Those are more valuable than others and patches have a 
disconcerting tendency to become stale, we should avoid that.


I have a rule for that (I did not invent it, thanks Internet): the 10 min rule. If I (expect I) can do it in 10 min, they I do. Of course sometimes 
you happen to shave the yak, and you can't use the rule all the day long.


Also I guess the reason why most Jiras are of major priority is because don't care when they create it. Like they don't care when choosing between 
"Fixed", "Done", "Implemented" when closing, which is obviously of a less importance


My 2cts

Jacques


Le 05/09/2016 à 13:06, Sharan Foga a écrit :

Hi Taher

+1

You have raised some good actionable points here. I think you are right that the Jira guidelines need be completely separated out into something 
that is clear and can be used as an easy reference.


I will create a wiki page to start pulling the information together.

Thanks
Sharan

On 2016-09-03 07:56 (+0200), Taher Alkhateeb  wrote:

Hi Everyone,

As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
50 trivial open JIRAs and I note:

- I think none of the blocker and critical JIRAs belong in that category.
- It is also unrealistic to have 733 major issues. it is like saying we
have that many serious problems
- I think a realistic distribution would have a pyramid count with a max
(pyramid base) being trivial JIRAs.
- A substantial number of jiras is old and no longer applicable.
- A substantial number of jiras is vague and not understandable, poorly
written, without enough details to work on.
- A substantial amount of jiras are placeholders for something to do
without proper thinking and planning, which would make them unrealistic or
not applicable.
- Some JIRAs are extremely granular. For example a task broken to subtasks
each for a tiny amount of work that is not worth the time and effort of
making so many tasks.

So I think our issue tracking system is not properly used and we have many
JIRAs that are not useful and distracting. I propose the following actions:

- Add a wiki page (if one does not exist) documenting:
   - Guidelines for writing JIRA mentioning clarity, provision of solution.
   - A clear definition of priorities (blocker, critical, major, minor,
trivial) with some examples.
   - A description of meaning of assignee and how to use it
   - A description of other metadata and how to properly use it (tags,
components, affects version, etc...)
- we need to close all old, not applicable, vague and poorly written JIRAs
as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
with guidelines.
- We need to fix priorities of all remaining JIRAs as per wiki guidelines

This would give us a realistic view of the _real_ issues in OFBiz instead
of drowning in so many JIRAs many of which are hindering rather than
helping.

What do you think?

Taher Alkhateeb

Re: Taking action on problems with using JIRA

2016-09-05 Thread Jacques Le Roux 
I think one thing we should consider before all the rest is Jiras issues with patches. Those are more valuable than others and patches have a 
disconcerting tendency to become stale, we should avoid that.


I have a rule for that (I did not invent it, thanks Internet): the 10 min rule. If I (expect I) can do it in 10 min, they I do. Of course sometimes 
you happen to shave the yak, and you can't use the rule all the day long.


Also I guess the reason why most Jiras are of major priority is because don't care when they create it. Like they don't care when choosing between 
"Fixed", "Done", "Implemented" when closing, which is obviously of a less importance


My 2cts

Jacques


Le 05/09/2016 à 13:06, Sharan Foga a écrit :

Hi Taher

+1

You have raised some good actionable points here. I think you are right that 
the Jira guidelines need be completely separated out into something that is 
clear and can be used as an easy reference.

I will create a wiki page to start pulling the information together.

Thanks
Sharan

On 2016-09-03 07:56 (+0200), Taher Alkhateeb  wrote:

Hi Everyone,

As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
50 trivial open JIRAs and I note:

- I think none of the blocker and critical JIRAs belong in that category.
- It is also unrealistic to have 733 major issues. it is like saying we
have that many serious problems
- I think a realistic distribution would have a pyramid count with a max
(pyramid base) being trivial JIRAs.
- A substantial number of jiras is old and no longer applicable.
- A substantial number of jiras is vague and not understandable, poorly
written, without enough details to work on.
- A substantial amount of jiras are placeholders for something to do
without proper thinking and planning, which would make them unrealistic or
not applicable.
- Some JIRAs are extremely granular. For example a task broken to subtasks
each for a tiny amount of work that is not worth the time and effort of
making so many tasks.

So I think our issue tracking system is not properly used and we have many
JIRAs that are not useful and distracting. I propose the following actions:

- Add a wiki page (if one does not exist) documenting:
   - Guidelines for writing JIRA mentioning clarity, provision of solution.
   - A clear definition of priorities (blocker, critical, major, minor,
trivial) with some examples.
   - A description of meaning of assignee and how to use it
   - A description of other metadata and how to properly use it (tags,
components, affects version, etc...)
- we need to close all old, not applicable, vague and poorly written JIRAs
as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
with guidelines.
- We need to fix priorities of all remaining JIRAs as per wiki guidelines

This would give us a realistic view of the _real_ issues in OFBiz instead
of drowning in so many JIRAs many of which are hindering rather than
helping.

What do you think?

Taher Alkhateeb

Re: [jira] [Commented] (OFBIZ-8045) Accounting: Consistent form name

2016-09-05 Thread Michael Brohl 

Thanks, Jacques,

I will do the work during our Community Day so we'll have some time to 
wait for additional comments.


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 05.09.16 um 13:51 schrieb Jacques Le Roux:

Michael,

I'd wait 2 days before applying a lazy consensus, ie if nobody chime 
in, please commit...


Jacques


Le 05/09/2016 à 13:40, Akash Jain a écrit :

+1 for the single commit!

Thanks and Regards
--
Akash Jain

On Mon, Sep 5, 2016 at 2:56 PM, Michael Brohl 
wrote:


Thanks for your suggestions, Akash and Jacques.

To be clear, my question is only for these specific changes which I 
plan

do review and commit.

They are all of the same nature, easy to review and a single commit 
would
avoid to write a lot of similar commit messages, references to 
different

revisions in Jira etc. It would be simply more efficient.

This should not be applied as a general rule I think, I generally 
prefer

more granular commits for different changes.

Other opinions?

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 05.09.16 um 11:00 schrieb Jacques Le Roux:

BTW, this was not exactly Michael's question (apart your 1st point). We

can have several sub-tasks but commit all of them in one shoot.

Others opinions? Anyway I don't think we can have a global 
agreement (for

every Jiras) on this, because it really dependd on the content of the
subtasks patches.

Jacques


Le 05/09/2016 à 10:36, Jacques Le Roux a écrit :


Makes sense Akash, thanks!

Jacques


Le 05/09/2016 à 07:39, Akash Jain a écrit :


I think both ways are fine but personally I like to do this kind of
changes
component wise because,
-- it's easy to review
-- more users and committers can involve
-- easy for beginners to contribute

Thanks and Regards
--
Akash Jain

On Sun, Sep 4, 2016 at 6:30 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

I wonder, it would be a bit easier to commit but the review could be

harder, a moot point I'd say

Jacques


Le 04/09/2016 à 13:47, Michael Brohl a écrit :

This might disappear in the many notifications so I'd like to 
asked the

below question also here in the dev list.
What do you think?

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 04.09.16 um 13:41 schrieb Michael Brohl (JIRA):

   [ 
https://issues.apache.org/jira/browse/OFBIZ-8045?page=com.

atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
l=15462791#comment-15462791 ]

Michael Brohl commented on OFBIZ-8045:
--

I think about doing these changes and all the other similar 
ones in

one
single commit and not issue by issue, what do others think about
this?

Accounting: Consistent form name




   Key: OFBIZ-8045
   URL: https://issues.apache.org/jira
/browse/OFBIZ-8045
   Project: OFBiz
Issue Type: Sub-task
Components: accounting
  Reporter: Tanmay Muley
  Assignee: Michael Brohl
  Priority: Minor
   Fix For: Trunk

   Attachments: OFBIZ-8045.patch, OFBIZ-8045.patch,
OFBIZ-8045.patch


Change all form names to upper camel case for consistency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)















smime.p7s
Description: S/MIME Cryptographic Signature

Re: [jira] [Commented] (OFBIZ-8045) Accounting: Consistent form name

2016-09-05 Thread Jacques Le Roux 

Michael,

I'd wait 2 days before applying a lazy consensus, ie if nobody chime in, please 
commit...

Jacques


Le 05/09/2016 à 13:40, Akash Jain a écrit :

+1 for the single commit!

Thanks and Regards
--
Akash Jain

On Mon, Sep 5, 2016 at 2:56 PM, Michael Brohl 
wrote:


Thanks for your suggestions, Akash and Jacques.

To be clear, my question is only for these specific changes which I plan
do review and commit.

They are all of the same nature, easy to review and a single commit would
avoid to write a lot of similar commit messages, references to different
revisions in Jira etc. It would be simply more efficient.

This should not be applied as a general rule I think, I generally prefer
more granular commits for different changes.

Other opinions?

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 05.09.16 um 11:00 schrieb Jacques Le Roux:

BTW, this was not exactly Michael's question (apart your 1st point). We

can have several sub-tasks but commit all of them in one shoot.

Others opinions? Anyway I don't think we can have a global agreement (for
every Jiras) on this, because it really dependd on the content of the
subtasks patches.

Jacques


Le 05/09/2016 à 10:36, Jacques Le Roux a écrit :


Makes sense Akash, thanks!

Jacques


Le 05/09/2016 à 07:39, Akash Jain a écrit :


I think both ways are fine but personally I like to do this kind of
changes
component wise because,
-- it's easy to review
-- more users and committers can involve
-- easy for beginners to contribute

Thanks and Regards
--
Akash Jain

On Sun, Sep 4, 2016 at 6:30 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

I wonder, it would be a bit easier to commit but the review could be

harder, a moot point I'd say

Jacques


Le 04/09/2016 à 13:47, Michael Brohl a écrit :

This might disappear in the many notifications so I'd like to asked the

below question also here in the dev list.
What do you think?

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 04.09.16 um 13:41 schrieb Michael Brohl (JIRA):

   [ https://issues.apache.org/jira/browse/OFBIZ-8045?page=com.

atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
l=15462791#comment-15462791 ]

Michael Brohl commented on OFBIZ-8045:
--

I think about doing these changes and all the other similar ones in
one
single commit and not issue by issue, what do others think about
this?

Accounting: Consistent form name




   Key: OFBIZ-8045
   URL: https://issues.apache.org/jira
/browse/OFBIZ-8045
   Project: OFBiz
Issue Type: Sub-task
Components: accounting
  Reporter: Tanmay Muley
  Assignee: Michael Brohl
  Priority: Minor
   Fix For: Trunk

   Attachments: OFBIZ-8045.patch, OFBIZ-8045.patch,
OFBIZ-8045.patch


Change all form names to upper camel case for consistency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (OFBIZ-8045) Accounting: Consistent form name

2016-09-05 Thread Akash Jain 
+1 for the single commit!

Thanks and Regards
--
Akash Jain

On Mon, Sep 5, 2016 at 2:56 PM, Michael Brohl 
wrote:

> Thanks for your suggestions, Akash and Jacques.
>
> To be clear, my question is only for these specific changes which I plan
> do review and commit.
>
> They are all of the same nature, easy to review and a single commit would
> avoid to write a lot of similar commit messages, references to different
> revisions in Jira etc. It would be simply more efficient.
>
> This should not be applied as a general rule I think, I generally prefer
> more granular commits for different changes.
>
> Other opinions?
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 05.09.16 um 11:00 schrieb Jacques Le Roux:
>
> BTW, this was not exactly Michael's question (apart your 1st point). We
>> can have several sub-tasks but commit all of them in one shoot.
>>
>> Others opinions? Anyway I don't think we can have a global agreement (for
>> every Jiras) on this, because it really dependd on the content of the
>> subtasks patches.
>>
>> Jacques
>>
>>
>> Le 05/09/2016 à 10:36, Jacques Le Roux a écrit :
>>
>>> Makes sense Akash, thanks!
>>>
>>> Jacques
>>>
>>>
>>> Le 05/09/2016 à 07:39, Akash Jain a écrit :
>>>
 I think both ways are fine but personally I like to do this kind of
 changes
 component wise because,
 -- it's easy to review
 -- more users and committers can involve
 -- easy for beginners to contribute

 Thanks and Regards
 --
 Akash Jain

 On Sun, Sep 4, 2016 at 6:30 PM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 I wonder, it would be a bit easier to commit but the review could be
> harder, a moot point I'd say
>
> Jacques
>
>
> Le 04/09/2016 à 13:47, Michael Brohl a écrit :
>
> This might disappear in the many notifications so I'd like to asked the
>> below question also here in the dev list.
>> What do you think?
>>
>> Thanks,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>> Am 04.09.16 um 13:41 schrieb Michael Brohl (JIRA):
>>
>>   [ https://issues.apache.org/jira/browse/OFBIZ-8045?page=com.
>>> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
>>> l=15462791#comment-15462791 ]
>>>
>>> Michael Brohl commented on OFBIZ-8045:
>>> --
>>>
>>> I think about doing these changes and all the other similar ones in
>>> one
>>> single commit and not issue by issue, what do others think about
>>> this?
>>>
>>> Accounting: Consistent form name
>>>
 

   Key: OFBIZ-8045
   URL: https://issues.apache.org/jira
 /browse/OFBIZ-8045
   Project: OFBiz
Issue Type: Sub-task
Components: accounting
  Reporter: Tanmay Muley
  Assignee: Michael Brohl
  Priority: Minor
   Fix For: Trunk

   Attachments: OFBIZ-8045.patch, OFBIZ-8045.patch,
 OFBIZ-8045.patch


 Change all form names to upper camel case for consistency.


>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>>>
>>>
>>
>>
>>>
>>>
>>
>
>

Re: Taking action on problems with using JIRA

2016-09-05 Thread Sharan Foga 
Hi Taher

+1 

You have raised some good actionable points here. I think you are right that 
the Jira guidelines need be completely separated out into something that is 
clear and can be used as an easy reference.

I will create a wiki page to start pulling the information together.

Thanks
Sharan

On 2016-09-03 07:56 (+0200), Taher Alkhateeb  
wrote: 
> Hi Everyone,
> 
> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
> 50 trivial open JIRAs and I note:
> 
> - I think none of the blocker and critical JIRAs belong in that category.
> - It is also unrealistic to have 733 major issues. it is like saying we
> have that many serious problems
> - I think a realistic distribution would have a pyramid count with a max
> (pyramid base) being trivial JIRAs.
> - A substantial number of jiras is old and no longer applicable.
> - A substantial number of jiras is vague and not understandable, poorly
> written, without enough details to work on.
> - A substantial amount of jiras are placeholders for something to do
> without proper thinking and planning, which would make them unrealistic or
> not applicable.
> - Some JIRAs are extremely granular. For example a task broken to subtasks
> each for a tiny amount of work that is not worth the time and effort of
> making so many tasks.
> 
> So I think our issue tracking system is not properly used and we have many
> JIRAs that are not useful and distracting. I propose the following actions:
> 
> - Add a wiki page (if one does not exist) documenting:
>   - Guidelines for writing JIRA mentioning clarity, provision of solution.
>   - A clear definition of priorities (blocker, critical, major, minor,
> trivial) with some examples.
>   - A description of meaning of assignee and how to use it
>   - A description of other metadata and how to properly use it (tags,
> components, affects version, etc...)
> - we need to close all old, not applicable, vague and poorly written JIRAs
> as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
> with guidelines.
> - We need to fix priorities of all remaining JIRAs as per wiki guidelines
> 
> This would give us a realistic view of the _real_ issues in OFBiz instead
> of drowning in so many JIRAs many of which are hindering rather than
> helping.
> 
> What do you think?
> 
> Taher Alkhateeb
>

Re: [jira] [Commented] (OFBIZ-8045) Accounting: Consistent form name

2016-09-05 Thread Scott Gray 
A single commit is fine IMO if the changes are all focused on something
specific.  The only style of commit I would object to are ones that
incorporate a non-trivial number of unrelated changes, otherwise whatever
works best for the committer is fine by me.

Regards
Scott

On 5 September 2016 at 21:26, Michael Brohl 
wrote:

> Thanks for your suggestions, Akash and Jacques.
>
> To be clear, my question is only for these specific changes which I plan
> do review and commit.
>
> They are all of the same nature, easy to review and a single commit would
> avoid to write a lot of similar commit messages, references to different
> revisions in Jira etc. It would be simply more efficient.
>
> This should not be applied as a general rule I think, I generally prefer
> more granular commits for different changes.
>
> Other opinions?
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 05.09.16 um 11:00 schrieb Jacques Le Roux:
>
> BTW, this was not exactly Michael's question (apart your 1st point). We
>> can have several sub-tasks but commit all of them in one shoot.
>>
>> Others opinions? Anyway I don't think we can have a global agreement (for
>> every Jiras) on this, because it really dependd on the content of the
>> subtasks patches.
>>
>> Jacques
>>
>>
>> Le 05/09/2016 à 10:36, Jacques Le Roux a écrit :
>>
>>> Makes sense Akash, thanks!
>>>
>>> Jacques
>>>
>>>
>>> Le 05/09/2016 à 07:39, Akash Jain a écrit :
>>>
 I think both ways are fine but personally I like to do this kind of
 changes
 component wise because,
 -- it's easy to review
 -- more users and committers can involve
 -- easy for beginners to contribute

 Thanks and Regards
 --
 Akash Jain

 On Sun, Sep 4, 2016 at 6:30 PM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 I wonder, it would be a bit easier to commit but the review could be
> harder, a moot point I'd say
>
> Jacques
>
>
> Le 04/09/2016 à 13:47, Michael Brohl a écrit :
>
> This might disappear in the many notifications so I'd like to asked the
>> below question also here in the dev list.
>> What do you think?
>>
>> Thanks,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>> Am 04.09.16 um 13:41 schrieb Michael Brohl (JIRA):
>>
>>   [ https://issues.apache.org/jira/browse/OFBIZ-8045?page=com.
>>> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
>>> l=15462791#comment-15462791 ]
>>>
>>> Michael Brohl commented on OFBIZ-8045:
>>> --
>>>
>>> I think about doing these changes and all the other similar ones in
>>> one
>>> single commit and not issue by issue, what do others think about
>>> this?
>>>
>>> Accounting: Consistent form name
>>>
 

   Key: OFBIZ-8045
   URL: https://issues.apache.org/jira
 /browse/OFBIZ-8045
   Project: OFBiz
Issue Type: Sub-task
Components: accounting
  Reporter: Tanmay Muley
  Assignee: Michael Brohl
  Priority: Minor
   Fix For: Trunk

   Attachments: OFBIZ-8045.patch, OFBIZ-8045.patch,
 OFBIZ-8045.patch


 Change all form names to upper camel case for consistency.


>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>>>
>>>
>>
>>
>>>
>>>
>>
>
>

Re: [jira] [Commented] (OFBIZ-8045) Accounting: Consistent form name

2016-09-05 Thread Michael Brohl 

Thanks for your suggestions, Akash and Jacques.

To be clear, my question is only for these specific changes which I plan 
do review and commit.


They are all of the same nature, easy to review and a single commit 
would avoid to write a lot of similar commit messages, references to 
different revisions in Jira etc. It would be simply more efficient.


This should not be applied as a general rule I think, I generally prefer 
more granular commits for different changes.


Other opinions?

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 05.09.16 um 11:00 schrieb Jacques Le Roux:
BTW, this was not exactly Michael's question (apart your 1st point). 
We can have several sub-tasks but commit all of them in one shoot.


Others opinions? Anyway I don't think we can have a global agreement 
(for every Jiras) on this, because it really dependd on the content of 
the subtasks patches.


Jacques


Le 05/09/2016 à 10:36, Jacques Le Roux a écrit :

Makes sense Akash, thanks!

Jacques


Le 05/09/2016 à 07:39, Akash Jain a écrit :
I think both ways are fine but personally I like to do this kind of 
changes

component wise because,
-- it's easy to review
-- more users and committers can involve
-- easy for beginners to contribute

Thanks and Regards
--
Akash Jain

On Sun, Sep 4, 2016 at 6:30 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I wonder, it would be a bit easier to commit but the review could be
harder, a moot point I'd say

Jacques


Le 04/09/2016 à 13:47, Michael Brohl a écrit :

This might disappear in the many notifications so I'd like to 
asked the

below question also here in the dev list.
What do you think?

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 04.09.16 um 13:41 schrieb Michael Brohl (JIRA):


  [ https://issues.apache.org/jira/browse/OFBIZ-8045?page=com.
atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
l=15462791#comment-15462791 ]

Michael Brohl commented on OFBIZ-8045:
--

I think about doing these changes and all the other similar ones 
in one
single commit and not issue by issue, what do others think about 
this?


Accounting: Consistent form name



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

  Project: OFBiz
   Issue Type: Sub-task
   Components: accounting
 Reporter: Tanmay Muley
 Assignee: Michael Brohl
 Priority: Minor
  Fix For: Trunk

  Attachments: OFBIZ-8045.patch, OFBIZ-8045.patch,
OFBIZ-8045.patch


Change all form names to upper camel case for consistency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)














smime.p7s
Description: S/MIME Cryptographic Signature

Re: Michael Brohl joins OFBiz PMC

2016-09-05 Thread Sebastian Leitner 
Congratulations Michael!

Kind regards,
Sebastian


Sebastian Leitner
Diplom-Wirtschaftsinformatiker
Bereichsleiter Digital

Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Germany
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 151 1256 86 05
 

 


Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de

Amtsgericht Bielefeld HRB 35946
Geschäftsführer: Michael Seehrich, Benjamin Sarges

https://www.lynx.de/haftungsausschluss




From:   "Sharan Foga" 
To: 
Date:   02.09.2016 12:36
Subject:Michael Brohl joins OFBiz PMC



Hi Everyone

Please join me in welcoming Michael Brohl as our newest member of the
OFBiz PMC.

Congratulations Michael and welcome! :-)

Thanks
Sharan

Re: [jira] [Commented] (OFBIZ-8045) Accounting: Consistent form name

2016-09-05 Thread Jacques Le Roux 

BTW, this was not exactly Michael's question (apart your 1st point). We can 
have several sub-tasks but commit all of them in one shoot.

Others opinions? Anyway I don't think we can have a global agreement (for every Jiras) on this, because it really dependd on the content of the 
subtasks patches.


Jacques


Le 05/09/2016 à 10:36, Jacques Le Roux a écrit :

Makes sense Akash, thanks!

Jacques


Le 05/09/2016 à 07:39, Akash Jain a écrit :

I think both ways are fine but personally I like to do this kind of changes
component wise because,
-- it's easy to review
-- more users and committers can involve
-- easy for beginners to contribute

Thanks and Regards
--
Akash Jain

On Sun, Sep 4, 2016 at 6:30 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I wonder, it would be a bit easier to commit but the review could be
harder, a moot point I'd say

Jacques


Le 04/09/2016 à 13:47, Michael Brohl a écrit :


This might disappear in the many notifications so I'd like to asked the
below question also here in the dev list.
What do you think?

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 04.09.16 um 13:41 schrieb Michael Brohl (JIRA):


  [ https://issues.apache.org/jira/browse/OFBIZ-8045?page=com.
atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
l=15462791#comment-15462791 ]

Michael Brohl commented on OFBIZ-8045:
--

I think about doing these changes and all the other similar ones in one
single commit and not issue by issue, what do others think about this?

Accounting: Consistent form name



  Key: OFBIZ-8045
  URL: https://issues.apache.org/jira/browse/OFBIZ-8045
  Project: OFBiz
   Issue Type: Sub-task
   Components: accounting
 Reporter: Tanmay Muley
 Assignee: Michael Brohl
 Priority: Minor
  Fix For: Trunk

  Attachments: OFBIZ-8045.patch, OFBIZ-8045.patch,
OFBIZ-8045.patch


Change all form names to upper camel case for consistency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: OFBiz logo files in repo?

2016-09-05 Thread Pierre Smits 
The ofbiz logo in the code base is used as:

   - an icon in the browser window (.ico file)
   - default logo in the themes, when there is none set in the company
   record.



Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Sep 5, 2016 at 10:43 AM, Taher Alkhateeb  wrote:

> I think the wiki is okay, maybe the website repo is okay, but not in trunk
> unless it serves a purpose (used somewhere in some screen)
>
> On Mon, Sep 5, 2016 at 11:40 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi,
> >
> > Previously we had some OFBiz logo files in repo, should we put the new
> > files there or simply remove the old and have logos only in wiki?
> >
> > Jacques
> >
> >
>

Re: OFBiz logo files in repo?

2016-09-05 Thread Taher Alkhateeb 
I think the wiki is okay, maybe the website repo is okay, but not in trunk
unless it serves a purpose (used somewhere in some screen)

On Mon, Sep 5, 2016 at 11:40 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> Previously we had some OFBiz logo files in repo, should we put the new
> files there or simply remove the old and have logos only in wiki?
>
> Jacques
>
>

OFBiz logo files in repo?

2016-09-05 Thread Jacques Le Roux 

Hi,

Previously we had some OFBiz logo files in repo, should we put the new files 
there or simply remove the old and have logos only in wiki?

Jacques

Re: [jira] [Commented] (OFBIZ-8045) Accounting: Consistent form name

2016-09-05 Thread Jacques Le Roux 

Makes sense Akash, thanks!

Jacques


Le 05/09/2016 à 07:39, Akash Jain a écrit :

I think both ways are fine but personally I like to do this kind of changes
component wise because,
-- it's easy to review
-- more users and committers can involve
-- easy for beginners to contribute

Thanks and Regards
--
Akash Jain

On Sun, Sep 4, 2016 at 6:30 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I wonder, it would be a bit easier to commit but the review could be
harder, a moot point I'd say

Jacques


Le 04/09/2016 à 13:47, Michael Brohl a écrit :


This might disappear in the many notifications so I'd like to asked the
below question also here in the dev list.
What do you think?

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 04.09.16 um 13:41 schrieb Michael Brohl (JIRA):


  [ https://issues.apache.org/jira/browse/OFBIZ-8045?page=com.
atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
l=15462791#comment-15462791 ]

Michael Brohl commented on OFBIZ-8045:
--

I think about doing these changes and all the other similar ones in one
single commit and not issue by issue, what do others think about this?

Accounting: Consistent form name



  Key: OFBIZ-8045
  URL: https://issues.apache.org/jira/browse/OFBIZ-8045
  Project: OFBiz
   Issue Type: Sub-task
   Components: accounting
 Reporter: Tanmay Muley
 Assignee: Michael Brohl
 Priority: Minor
  Fix For: Trunk

  Attachments: OFBIZ-8045.patch, OFBIZ-8045.patch,
OFBIZ-8045.patch


Change all form names to upper camel case for consistency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Michael Brohl joins OFBiz PMC

2016-09-05 Thread Swapnil Mane 
Many congratulations Michael :-)

- Best Regards,
Swapnil M Mane

On Fri, Sep 2, 2016 at 4:06 PM, Sharan Foga  wrote:

> Hi Everyone
>
> Please join me in welcoming Michael Brohl as our newest member of the
> OFBiz PMC.
>
> Congratulations Michael and welcome! :-)
>
> Thanks
> Sharan
>

Re: Michael Brohl joins OFBiz PMC

2016-09-05 Thread Akash Jain 
Many Congratulations Michael!

Thanks and Regards
--
Akash Jain

On Fri, Sep 2, 2016 at 4:06 PM, Sharan Foga  wrote:

> Hi Everyone
>
> Please join me in welcoming Michael Brohl as our newest member of the
> OFBiz PMC.
>
> Congratulations Michael and welcome! :-)
>
> Thanks
> Sharan
>

Re: Michael Brohl joins OFBiz PMC

2016-09-05 Thread gil portenseigne 

Congratulations Michael !

Gil


On 04/09/2016 09:49, Gavin Mabie wrote:

Congratulations Michael.


On Fri, Sep 2, 2016 at 1:32 PM, Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:


Many-Many Congrats Michael. :-)

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
http://www.hotwaxsystems.com/

On Fri, Sep 2, 2016 at 4:06 PM, Sharan Foga  wrote:


Hi Everyone

Please join me in welcoming Michael Brohl as our newest member of the
OFBiz PMC.

Congratulations Michael and welcome! :-)

Thanks
Sharan