buildbot success in on ofbiz-trunk

[buildbot]

The Buildbot has detected a restored build on builder ofbiz-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/1438

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

Buildslave for this Build: orcus_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot

buildbot failure in on ofbiz-trunk

[buildbot]

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

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

Buildslave for this Build: orcus_ubuntu

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

BUILD FAILED: failed shell_1

Sincerely,
 -The Buildbot

Re: Groovy and semicolon at EOL

[Jacques Le Roux]

Personally I will go this way: I will add or changes lines without putting 
semicolons.

I'm in favour of bulk changing files, but I'd prefer by component or webapp to 
ease reviews.

Jacques


Le 16/09/2016 à 15:36, Rishi Solanki a écrit :

I was saying #2 as per the comment from Taher 

Quick Reference:

One reply from Taher ... in the same thread.
==

Okay, given the priorities and work we have at the moment, I suggest we
keep semicolons and use it as the standard unless someone volunteers to
make a full switch. WDYT?
==



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I guess you mean 2) by file, then it's OK with me. Though I'd no be
against having semicolon inconsistency in Groovy files, which was my
initial question. So no strong opinion about 2 here.

Jacques



Le 16/09/2016 à 11:31, Rishi Solanki a écrit :


To summarize the overall conversation;
1) We have decided to bulk remove semicolons from groovy.
2) Until #1 is not complete, we would keep adding semicolon for
consistency.




Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Actually I was wrong on this. Thanks to Jacopo I noticed that both

Subclipse and Tortoise allow you to select a range of revisions when you
look for annotations.

So  it's no longer an issue for me and we can bulk remove trailing
semicolons in Groovy files if we want.

Sorry for the confusion

Jacques



Le 14/09/2016 à 04:42, Scott Gray a écrit :

I don't particularly care one way or another if groovy files have a

semi-colon at the end.  I don't even care about consistency because it
is
such a minor thing.

I say remove them if they're on a line you happen to be editing,
otherwise
just leave them be.

Regarding the annotations, there's plenty of ways to search commit logs
and
personally I've never found blame to be very useful.  I don't think it
should be a reason to block any future bulk S/R cleanups.  We've had
plenty
in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
removal, etc.) and we should continue to do it to keep things clean.

For searching diffs, before using git-svn I used to use: svn log -diff
 and then use the search in the terminal to find the
string
I'm looking for.

Regards
Scott

On 14 September 2016 at 07:33, Jacques Le Roux <
jacques.le.r...@les7arts.com

wrote:

Le 13/09/2016 à 21:28, Jacques Le Roux a écrit :

OK found that the same than in Subclipse also exists in TortoiseSVN


But you need to use a command line (weird for a GUI), eg (from
TortoiseSVN root folder)

Actually wrong, simply pick a file in Windows file explorer using


TortoiseSVN  context menu, et voilà!
I confirm, totally comparable to Subclipse annotations

Jacques



TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi


z\applications\product\src\main\java\org\apache\ofbiz\
product\catalog\CatalogWorker.java"

All is explained here https://tortoisesvn.net/docs/r
elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics

   From the resulting UI (comparable to Subclipse) I guess changing all
lines of a file will have the same effect.
Even if indeed the annotations are not lost, they are very hard to use
if
you need to compare revision by revision.

Jacques


Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :

BTW thinking about it, don't you have something similar in IntellIJ?


I found an (old) image there https://markphip.blogspot.fr/2
006/12/subclipse-live-annotations.html

Jacques


Le 13/09/2016 à 20:16, Jacques Le Roux a écrit :

Thanks Jacopo,


I found how to use it in TortoiseSVN (it starts from the log view)
It's complementary to what Subclipse gives and so interesting but
not
comparable.

You don't have this global view Subclipse offers with each
annotation
by line from start (r1) to HEAD.
Very useful with colored annotations in the same column than lines
numbers. But it unfortunately contains only the last revision if all
lines
have been modified together in that revision.
Note: to see it you need to use "Show Quick Diff" ("Revision" and
"Combined Colors" are then default options, hovering is enough for
me).
Same than you decide to show line numbers in this column... More for
those who are still using Eclipse...

Jacques

Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :

Some examples:


svn blame README.md

after review you run

svn blame README.md -r 1:1757044

and then

svn blame README.md -r 1:1757042

and so on to get back in history... nothing is lost, annotations
are
always
there.

Jacopo

PS: I think there is some trick to do the same with TortoiseSVN
but I
can't
tell you the details since I don't use it

On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le 

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

I agree we should have a AL2 (and not ASL2 I learnt) header in README.md.

For the rest it really depends on the content and we can't apply a global rule. Only "creative" ones should have a header. Of course "creative" is 
subjective, but I guess in most cases we will agree.


Jacques


Le 16/09/2016 à 13:46, Taher Alkhateeb a écrit :

Well, for the README.md you can add the license using the HTML version in
APACHE2_HEADER. For the rest of the README files you can use the standard
header.

On Fri, Sep 16, 2016 at 2:41 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 16/09/2016 à 12:31, Jacopo Cappellato a écrit :


On Fri, Sep 16, 2016 at 12:24 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

I simply wonder how we, as a community, can decide on this subject if no

vote can be done.

Jacques

Jacques, please do not be elusive... I am simply asking you if this vote

is
still valid or you have cancelled it.

Jacopo

OK, I cancelled the vote because "it makes no sense to force to have an

ASL2 headers in ALL readme files", now what?

Jacques

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

[Jacques Le Roux]

Ah yes good idea, old Ant reflex, I will

Jacques


Le 16/09/2016 à 22:23, Taher Alkhateeb a écrit :

Jacques .. I think it is bad practice to put commented out code. If this is
really necessary we can put a task for it if needed.

On Fri, Sep 16, 2016 at 11:15 PM,  wrote:


Author: jleroux
Date: Fri Sep 16 20:15:43 2016
New Revision: 1761076

URL: http://svn.apache.org/viewvc?rev=1761076=rev
Log:
Documents: adds a small commented out snippet in build.gradle for when
Xlint:unchecked and -Xlint:deprecation are needed


Modified:
 ofbiz/trunk/build.gradle

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

==
--- ofbiz/trunk/build.gradle (original)
+++ ofbiz/trunk/build.gradle Fri Sep 16 20:15:43 2016
@@ -39,6 +39,16 @@ javadoc.failOnError = false
  sourceCompatibility = '1.8'
  targetCompatibility = '1.8'

+/* Please don't remove. This is useful when you want to see
+   unchecked warnings and deprecated members or classes in log.
+allprojects {
+gradle.projectsEvaluated {
+tasks.withType(JavaCompile) {
+options.compilerArgs << "-Xlint:unchecked" <<
"-Xlint:deprecation"
+}
+}
+}*/
+
  // Enforces UTF-8 java compilation encoding on Windows platform
  tasks.withType(JavaCompile) {
  options.encoding = 'UTF-8'
@@ -814,10 +824,10 @@ task gitInfoFooter(group: committerGroup
  revision = revisionOutput.toString()
  gitFooterFile.delete()
  gitFooterFile.createNewFile()
-gitFooterFile << "Branch: ${branch}"
-gitFooterFile << "Revision: ${revision}"
-gitFooterFile << "Built on: ${timestamp}" + System.lineSeparator()
-gitFooterFile << "Java Version: ${org.gradle.internal.jvm.Jvm.
current()}"
+gitFooterFile << '${uiLabelMap.Branch} : ' + "${branch}" +
System.lineSeparator()
+gitFooterFile << '${uiLabelMap.Revision} : ' + "${revision}" +
System.lineSeparator()
+gitFooterFile << '${uiLabelMap.BuiltOn} : ' + "${timestamp}" +
System.lineSeparator()
+gitFooterFile << '${uiLabelMap.JavaVersion} : ' +
"${org.gradle.internal.jvm.Jvm.current()}"
  }

  task svnInfoFooter(group: committerGroup, description: 'Update the
Subversion revision info in the footer if Subversion is used') << {
@@ -838,10 +848,10 @@ task svnInfoFooter(group: committerGroup
  def info = new XmlParser().parseText(svnOutput.toString())
  svnFooterFile.delete()
  svnFooterFile.createNewFile()
-svnFooterFile << "Branch: ${info.entry.url.text()}" +
System.lineSeparator()
-svnFooterFile << "Revision: ${info.entry.commit.@revision}" +
System.lineSeparator()
-svnFooterFile << "Built on: ${timestamp}" + System.lineSeparator()
-svnFooterFile << "Java Version: ${org.gradle.internal.jvm.Jvm.
current()}"
+svnFooterFile << '${uiLabelMap.Branch} : ' +
"${info.entry.url.text()}" + System.lineSeparator()
+svnFooterFile << '${uiLabelMap.Revision} : ' +
"${info.entry.commit.@revision}" + System.lineSeparator()
+svnFooterFile << '${uiLabelMap.BuiltOn} : ' + "${timestamp}" +
System.lineSeparator()
+svnFooterFile << '${uiLabelMap.JavaVersion} : ' +
"${org.gradle.internal.jvm.Jvm.current()}"
  }

  // == hidden support tasks ==

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

[Taher Alkhateeb]

Jacques .. I think it is bad practice to put commented out code. If this is
really necessary we can put a task for it if needed.

On Fri, Sep 16, 2016 at 11:15 PM,  wrote:

> Author: jleroux
> Date: Fri Sep 16 20:15:43 2016
> New Revision: 1761076
>
> URL: http://svn.apache.org/viewvc?rev=1761076=rev
> Log:
> Documents: adds a small commented out snippet in build.gradle for when
> Xlint:unchecked and -Xlint:deprecation are needed
>
>
> Modified:
> ofbiz/trunk/build.gradle
>
> Modified: ofbiz/trunk/build.gradle
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
> 1761076=1761075=1761076=diff
> 
> ==
> --- ofbiz/trunk/build.gradle (original)
> +++ ofbiz/trunk/build.gradle Fri Sep 16 20:15:43 2016
> @@ -39,6 +39,16 @@ javadoc.failOnError = false
>  sourceCompatibility = '1.8'
>  targetCompatibility = '1.8'
>
> +/* Please don't remove. This is useful when you want to see
> +   unchecked warnings and deprecated members or classes in log.
> +allprojects {
> +gradle.projectsEvaluated {
> +tasks.withType(JavaCompile) {
> +options.compilerArgs << "-Xlint:unchecked" <<
> "-Xlint:deprecation"
> +}
> +}
> +}*/
> +
>  // Enforces UTF-8 java compilation encoding on Windows platform
>  tasks.withType(JavaCompile) {
>  options.encoding = 'UTF-8'
> @@ -814,10 +824,10 @@ task gitInfoFooter(group: committerGroup
>  revision = revisionOutput.toString()
>  gitFooterFile.delete()
>  gitFooterFile.createNewFile()
> -gitFooterFile << "Branch: ${branch}"
> -gitFooterFile << "Revision: ${revision}"
> -gitFooterFile << "Built on: ${timestamp}" + System.lineSeparator()
> -gitFooterFile << "Java Version: ${org.gradle.internal.jvm.Jvm.
> current()}"
> +gitFooterFile << '${uiLabelMap.Branch} : ' + "${branch}" +
> System.lineSeparator()
> +gitFooterFile << '${uiLabelMap.Revision} : ' + "${revision}" +
> System.lineSeparator()
> +gitFooterFile << '${uiLabelMap.BuiltOn} : ' + "${timestamp}" +
> System.lineSeparator()
> +gitFooterFile << '${uiLabelMap.JavaVersion} : ' +
> "${org.gradle.internal.jvm.Jvm.current()}"
>  }
>
>  task svnInfoFooter(group: committerGroup, description: 'Update the
> Subversion revision info in the footer if Subversion is used') << {
> @@ -838,10 +848,10 @@ task svnInfoFooter(group: committerGroup
>  def info = new XmlParser().parseText(svnOutput.toString())
>  svnFooterFile.delete()
>  svnFooterFile.createNewFile()
> -svnFooterFile << "Branch: ${info.entry.url.text()}" +
> System.lineSeparator()
> -svnFooterFile << "Revision: ${info.entry.commit.@revision}" +
> System.lineSeparator()
> -svnFooterFile << "Built on: ${timestamp}" + System.lineSeparator()
> -svnFooterFile << "Java Version: ${org.gradle.internal.jvm.Jvm.
> current()}"
> +svnFooterFile << '${uiLabelMap.Branch} : ' +
> "${info.entry.url.text()}" + System.lineSeparator()
> +svnFooterFile << '${uiLabelMap.Revision} : ' +
> "${info.entry.commit.@revision}" + System.lineSeparator()
> +svnFooterFile << '${uiLabelMap.BuiltOn} : ' + "${timestamp}" +
> System.lineSeparator()
> +svnFooterFile << '${uiLabelMap.JavaVersion} : ' +
> "${org.gradle.internal.jvm.Jvm.current()}"
>  }
>
>  // == hidden support tasks ==
>
>
>

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Jacques Le Roux]

Thanks Taher for trying on Windows :)

I think our last messages crossed on Wire. When you sent your message I had just identified the real issue (thanks to Jacopo on HipChat) and committed 
the fix.


I should have spotted this issue on BuildBot in 1st place but I was convinced I did already commit the change in EntityListIterator class after I put 
this comment one week ago


''Next step is to have EntityListIterator to implement AutoCloseable, fortunately it has 
a clean close() method, so it's more about where it's used...""

https://issues.apache.org/jira/browse/OFBIZ-8202?focusedCommentId=15476153=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1547615

I actually also replaced a tab by spaces. This is done automatically by my 
Eclipse config.

Jacques


Le 16/09/2016 à 17:41, Taher Alkhateeb a écrit :

Hi Jacques, in reply:

- The build does not compile on windows (until you made the correction) !
This is NOT related to the OS as I mentioned, but related to erroneous code.
- You unnecessarily inserted a tab character next to the delegator.

Please be careful, quality matters more than quantity. I had to repeat what
I said many times to convince you.

On Fri, Sep 16, 2016 at 6:19 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Sorry Taher, was my bad. I forgot I did not commit the change in
EntityListIterator that I had pending for a week

Done

Jacques



Le 16/09/2016 à 17:03, Jacques Le Roux a écrit :


HEAD of course, see tools/test.bat

BTW I checked I have jdk1.8.0_74 installed. 101 is the JRE I have also
installed by the Java auto update.

So I thought it could be due to a JDK version (weird because
try-with-ressources is not new)

And BTW the xlint below is with my last commit reverted. I was to commit
it to not block Linux users, doing so now

Jacques


Le 16/09/2016 à 16:51, Taher Alkhateeb a écrit :


What revision are you on?

On Fri, Sep 16, 2016 at 5:51 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

And if you are interested here is with |-Xlint:unchecked and

-Xlint:deprecation|

C:\projectASF-Mars\ofbiz>gradlew build
:compileJava
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\test\GenericTestCaseBase.java:353: warning:
[unchecked]
Possible heap pollution from parameterized vararg type T
  public static  List list(T... list) {
  ^
where T is a type-variable:
  T extends Object declared in method list(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\test\GenericTestCaseBase.java:363: warning:
[unchecked]
Possible heap pollution from parameterized vararg type T
  public static  Set set(T... list) {
^
where T is a type-variable:
  T extends Object declared in method set(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\util\UtilGenerics.java:159: warning: [unchecked]
Possible heap pollution from parameterized vararg type Object
  public static  Map toMap(Class keyType,
Object... data) {
  ^
where Object,K are type-variables:
  Object extends java.lang.Object declared in method
toMap(Class,Object...)
  K extends java.lang.Object declared in method
toMap(Class,Object...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityCondition.java:59: warning:
[unchecked] Possible heap pollution from parameterized vararg type T
  public static  EntityConditionList
makeCondition(EntityJoinOperator operator, T... conditionList) {
^
where T is a type-variable:
  T extends EntityCondition declared in method
makeCondition(EntityJoinOperator,T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityCondition.java:63: warning:
[unchecked] Possible heap pollution from parameterized vararg type T
  public static  EntityConditionList
makeCondition(T... conditionList) {
^
where T is a type-variable:
  T extends EntityCondition declared in method makeCondition(T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityFieldMap.java:50: warning:
[unchecked] Possible heap pollution from parameterized vararg type V
  public  EntityFieldMap(EntityComparisonOperator compOp,
EntityJoinOperator joinOp, V... keysValues) {
  ^
where V is a type-variable:
  V extends Object declared in constructor
EntityFieldMap(EntityCompar
isonOperator,EntityJoinOperator,V...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\connection\DebugManagedDataSource.java:34: warning:
[unchecked] unwrap(Class) in PoolingDataSource implements
unw
rap(Class) in Wrapper
public class DebugManagedDataSource 

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Taher Alkhateeb]

Hi Jacques, in reply:

- The build does not compile on windows (until you made the correction) !
This is NOT related to the OS as I mentioned, but related to erroneous code.
- You unnecessarily inserted a tab character next to the delegator.

Please be careful, quality matters more than quantity. I had to repeat what
I said many times to convince you.

On Fri, Sep 16, 2016 at 6:19 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Sorry Taher, was my bad. I forgot I did not commit the change in
> EntityListIterator that I had pending for a week
>
> Done
>
> Jacques
>
>
>
> Le 16/09/2016 à 17:03, Jacques Le Roux a écrit :
>
>> HEAD of course, see tools/test.bat
>>
>> BTW I checked I have jdk1.8.0_74 installed. 101 is the JRE I have also
>> installed by the Java auto update.
>>
>> So I thought it could be due to a JDK version (weird because
>> try-with-ressources is not new)
>>
>> And BTW the xlint below is with my last commit reverted. I was to commit
>> it to not block Linux users, doing so now
>>
>> Jacques
>>
>>
>> Le 16/09/2016 à 16:51, Taher Alkhateeb a écrit :
>>
>>> What revision are you on?
>>>
>>> On Fri, Sep 16, 2016 at 5:51 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> And if you are interested here is with |-Xlint:unchecked and
 -Xlint:deprecation|

 C:\projectASF-Mars\ofbiz>gradlew build
 :compileJava
 C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
 apache\ofbiz\base\test\GenericTestCaseBase.java:353: warning:
 [unchecked]
 Possible heap pollution from parameterized vararg type T
  public static  List list(T... list) {
  ^
where T is a type-variable:
  T extends Object declared in method list(T...)
 C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
 apache\ofbiz\base\test\GenericTestCaseBase.java:363: warning:
 [unchecked]
 Possible heap pollution from parameterized vararg type T
  public static  Set set(T... list) {
^
where T is a type-variable:
  T extends Object declared in method set(T...)
 C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
 apache\ofbiz\base\util\UtilGenerics.java:159: warning: [unchecked]
 Possible heap pollution from parameterized vararg type Object
  public static  Map toMap(Class keyType,
 Object... data) {
  ^
where Object,K are type-variables:
  Object extends java.lang.Object declared in method
 toMap(Class,Object...)
  K extends java.lang.Object declared in method
 toMap(Class,Object...)
 C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
 apache\ofbiz\entity\condition\EntityCondition.java:59: warning:
 [unchecked] Possible heap pollution from parameterized vararg type T
  public static  EntityConditionList
 makeCondition(EntityJoinOperator operator, T... conditionList) {
 ^
where T is a type-variable:
  T extends EntityCondition declared in method
 makeCondition(EntityJoinOperator,T...)
 C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
 apache\ofbiz\entity\condition\EntityCondition.java:63: warning:
 [unchecked] Possible heap pollution from parameterized vararg type T
  public static  EntityConditionList
 makeCondition(T... conditionList) {
 ^
where T is a type-variable:
  T extends EntityCondition declared in method makeCondition(T...)
 C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
 apache\ofbiz\entity\condition\EntityFieldMap.java:50: warning:
 [unchecked] Possible heap pollution from parameterized vararg type V
  public  EntityFieldMap(EntityComparisonOperator compOp,
 EntityJoinOperator joinOp, V... keysValues) {
  ^
where V is a type-variable:
  V extends Object declared in constructor
 EntityFieldMap(EntityCompar
 isonOperator,EntityJoinOperator,V...)
 C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
 apache\ofbiz\entity\connection\DebugManagedDataSource.java:34: warning:
 [unchecked] unwrap(Class) in PoolingDataSource implements
 unw
 rap(Class) in Wrapper
 public class DebugManagedDataSource extends ManagedDataSource {
 ^
return type requires unchecked conversion from Object to T#2
where T#1,T#2 are type-variables:
  T#1 extends Object declared in method unwrap(Class)
  T#2 extends Object declared in method unwrap(Class)
 C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
 apache\ofbiz\entity\connection\DebugManagedDataSource.java:39: warning:
 [unchecked] unchecked call to 

buildbot success in on ofbiz-trunk

[buildbot]

The Buildbot has detected a restored build on builder ofbiz-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/1432

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

Buildslave for this Build: orcus_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Jacques Le Roux]

Sorry Taher, was my bad. I forgot I did not commit the change in 
EntityListIterator that I had pending for a week

Done

Jacques


Le 16/09/2016 à 17:03, Jacques Le Roux a écrit :

HEAD of course, see tools/test.bat

BTW I checked I have jdk1.8.0_74 installed. 101 is the JRE I have also 
installed by the Java auto update.

So I thought it could be due to a JDK version (weird because 
try-with-ressources is not new)

And BTW the xlint below is with my last commit reverted. I was to commit it to 
not block Linux users, doing so now

Jacques


Le 16/09/2016 à 16:51, Taher Alkhateeb a écrit :

What revision are you on?

On Fri, Sep 16, 2016 at 5:51 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


And if you are interested here is with |-Xlint:unchecked and
-Xlint:deprecation|

C:\projectASF-Mars\ofbiz>gradlew build
:compileJava
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\test\GenericTestCaseBase.java:353: warning: [unchecked]
Possible heap pollution from parameterized vararg type T
 public static  List list(T... list) {
 ^
   where T is a type-variable:
 T extends Object declared in method list(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\test\GenericTestCaseBase.java:363: warning: [unchecked]
Possible heap pollution from parameterized vararg type T
 public static  Set set(T... list) {
   ^
   where T is a type-variable:
 T extends Object declared in method set(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\util\UtilGenerics.java:159: warning: [unchecked]
Possible heap pollution from parameterized vararg type Object
 public static  Map toMap(Class keyType,
Object... data) {
 ^
   where Object,K are type-variables:
 Object extends java.lang.Object declared in method
toMap(Class,Object...)
 K extends java.lang.Object declared in method
toMap(Class,Object...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityCondition.java:59: warning:
[unchecked] Possible heap pollution from parameterized vararg type T
 public static  EntityConditionList
makeCondition(EntityJoinOperator operator, T... conditionList) {
^
   where T is a type-variable:
 T extends EntityCondition declared in method
makeCondition(EntityJoinOperator,T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityCondition.java:63: warning:
[unchecked] Possible heap pollution from parameterized vararg type T
 public static  EntityConditionList
makeCondition(T... conditionList) {
^
   where T is a type-variable:
 T extends EntityCondition declared in method makeCondition(T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityFieldMap.java:50: warning:
[unchecked] Possible heap pollution from parameterized vararg type V
 public  EntityFieldMap(EntityComparisonOperator compOp,
EntityJoinOperator joinOp, V... keysValues) {
 ^
   where V is a type-variable:
 V extends Object declared in constructor EntityFieldMap(EntityCompar
isonOperator,EntityJoinOperator,V...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\connection\DebugManagedDataSource.java:34: warning:
[unchecked] unwrap(Class) in PoolingDataSource implements unw
rap(Class) in Wrapper
public class DebugManagedDataSource extends ManagedDataSource {
^
   return type requires unchecked conversion from Object to T#2
   where T#1,T#2 are type-variables:
 T#1 extends Object declared in method unwrap(Class)
 T#2 extends Object declared in method unwrap(Class)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\connection\DebugManagedDataSource.java:39: warning:
[unchecked] unchecked call to ManagedDataSource(ObjectPool
,TransactionReg

istry) as a member of the raw type ManagedDataSource
 super(pool, transactionRegistry);
  ^
   where C is a type-variable:
 C extends Connection declared in class ManagedDataSource
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\util\EntityUtil.java:357: warning: [unchecked]
unchecked cast
 T newValue = (T) value.clone();
 ^
   required: T
   found:Object
   where T is a type-variable:
 T extends GenericEntity declared in method
localizedOrderBy(Collection,List,Locale)
C:\projectASF-Mars\ofbiz\framework\service\src\main\java\
org\apache\ofbiz\service\ServiceUtil.java:650: warning: [unchecked]
Possible heap pollution from parameterized vararg type T
 public static  Map makeContext(T...

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Jacques Le Roux]

HEAD of course, see tools/test.bat

BTW I checked I have jdk1.8.0_74 installed. 101 is the JRE I have also 
installed by the Java auto update.

So I thought it could be due to a JDK version (weird because 
try-with-ressources is not new)

And BTW the xlint below is with my last commit reverted. I was to commit it to 
not block Linux users, doing so now

Jacques


Le 16/09/2016 à 16:51, Taher Alkhateeb a écrit :

What revision are you on?

On Fri, Sep 16, 2016 at 5:51 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


And if you are interested here is with |-Xlint:unchecked and
-Xlint:deprecation|

C:\projectASF-Mars\ofbiz>gradlew build
:compileJava
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\test\GenericTestCaseBase.java:353: warning: [unchecked]
Possible heap pollution from parameterized vararg type T
 public static  List list(T... list) {
 ^
   where T is a type-variable:
 T extends Object declared in method list(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\test\GenericTestCaseBase.java:363: warning: [unchecked]
Possible heap pollution from parameterized vararg type T
 public static  Set set(T... list) {
   ^
   where T is a type-variable:
 T extends Object declared in method set(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
apache\ofbiz\base\util\UtilGenerics.java:159: warning: [unchecked]
Possible heap pollution from parameterized vararg type Object
 public static  Map toMap(Class keyType,
Object... data) {
 ^
   where Object,K are type-variables:
 Object extends java.lang.Object declared in method
toMap(Class,Object...)
 K extends java.lang.Object declared in method
toMap(Class,Object...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityCondition.java:59: warning:
[unchecked] Possible heap pollution from parameterized vararg type T
 public static  EntityConditionList
makeCondition(EntityJoinOperator operator, T... conditionList) {
^
   where T is a type-variable:
 T extends EntityCondition declared in method
makeCondition(EntityJoinOperator,T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityCondition.java:63: warning:
[unchecked] Possible heap pollution from parameterized vararg type T
 public static  EntityConditionList
makeCondition(T... conditionList) {
^
   where T is a type-variable:
 T extends EntityCondition declared in method makeCondition(T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\condition\EntityFieldMap.java:50: warning:
[unchecked] Possible heap pollution from parameterized vararg type V
 public  EntityFieldMap(EntityComparisonOperator compOp,
EntityJoinOperator joinOp, V... keysValues) {
 ^
   where V is a type-variable:
 V extends Object declared in constructor EntityFieldMap(EntityCompar
isonOperator,EntityJoinOperator,V...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\connection\DebugManagedDataSource.java:34: warning:
[unchecked] unwrap(Class) in PoolingDataSource implements unw
rap(Class) in Wrapper
public class DebugManagedDataSource extends ManagedDataSource {
^
   return type requires unchecked conversion from Object to T#2
   where T#1,T#2 are type-variables:
 T#1 extends Object declared in method unwrap(Class)
 T#2 extends Object declared in method unwrap(Class)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\connection\DebugManagedDataSource.java:39: warning:
[unchecked] unchecked call to ManagedDataSource(ObjectPool
,TransactionReg

istry) as a member of the raw type ManagedDataSource
 super(pool, transactionRegistry);
  ^
   where C is a type-variable:
 C extends Connection declared in class ManagedDataSource
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
apache\ofbiz\entity\util\EntityUtil.java:357: warning: [unchecked]
unchecked cast
 T newValue = (T) value.clone();
 ^
   required: T
   found:Object
   where T is a type-variable:
 T extends GenericEntity declared in method
localizedOrderBy(Collection,List,Locale)
C:\projectASF-Mars\ofbiz\framework\service\src\main\java\
org\apache\ofbiz\service\ServiceUtil.java:650: warning: [unchecked]
Possible heap pollution from parameterized vararg type T
 public static  Map makeContext(T...
args) {
^
   where T is a type-variable:
 T extends Object declared in method makeContext(T...)
C:\projectASF-Mars\ofbiz\framework\widget\src\main\java\org\

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Jacques Le Roux]

And if you are interested here is with |-Xlint:unchecked and -Xlint:deprecation|

C:\projectASF-Mars\ofbiz>gradlew build
:compileJava
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\apache\ofbiz\base\test\GenericTestCaseBase.java:353: warning: [unchecked] Possible heap 
pollution from parameterized vararg type T

public static  List list(T... list) {
^
  where T is a type-variable:
T extends Object declared in method list(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\apache\ofbiz\base\test\GenericTestCaseBase.java:363: warning: [unchecked] Possible heap 
pollution from parameterized vararg type T

public static  Set set(T... list) {
  ^
  where T is a type-variable:
T extends Object declared in method set(T...)
C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\apache\ofbiz\base\util\UtilGenerics.java:159: warning: [unchecked] Possible heap pollution 
from parameterized vararg type Object

public static  Map toMap(Class keyType, Object... 
data) {
^
  where Object,K are type-variables:
Object extends java.lang.Object declared in method 
toMap(Class,Object...)
K extends java.lang.Object declared in method 
toMap(Class,Object...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\apache\ofbiz\entity\condition\EntityCondition.java:59: warning: [unchecked] Possible heap 
pollution from parameterized vararg type T

public static  EntityConditionList 
makeCondition(EntityJoinOperator operator, T... conditionList) {
^
  where T is a type-variable:
T extends EntityCondition declared in method 
makeCondition(EntityJoinOperator,T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\apache\ofbiz\entity\condition\EntityCondition.java:63: warning: [unchecked] Possible heap 
pollution from parameterized vararg type T

public static  EntityConditionList 
makeCondition(T... conditionList) {
^
  where T is a type-variable:
T extends EntityCondition declared in method makeCondition(T...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\apache\ofbiz\entity\condition\EntityFieldMap.java:50: warning: [unchecked] Possible heap 
pollution from parameterized vararg type V

public  EntityFieldMap(EntityComparisonOperator compOp, 
EntityJoinOperator joinOp, V... keysValues) {
^
  where V is a type-variable:
V extends Object declared in constructor 
EntityFieldMap(EntityComparisonOperator,EntityJoinOperator,V...)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\apache\ofbiz\entity\connection\DebugManagedDataSource.java:34: warning: [unchecked] 
unwrap(Class) in PoolingDataSource implements unw

rap(Class) in Wrapper
public class DebugManagedDataSource extends ManagedDataSource {
   ^
  return type requires unchecked conversion from Object to T#2
  where T#1,T#2 are type-variables:
T#1 extends Object declared in method unwrap(Class)
T#2 extends Object declared in method unwrap(Class)
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\apache\ofbiz\entity\connection\DebugManagedDataSource.java:39: warning: [unchecked] 
unchecked call to ManagedDataSource(ObjectPool,TransactionReg

istry) as a member of the raw type ManagedDataSource
super(pool, transactionRegistry);
 ^
  where C is a type-variable:
C extends Connection declared in class ManagedDataSource
C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\apache\ofbiz\entity\util\EntityUtil.java:357:
 warning: [unchecked] unchecked cast
T newValue = (T) value.clone();
^
  required: T
  found:Object
  where T is a type-variable:
T extends GenericEntity declared in method 
localizedOrderBy(Collection,List,Locale)
C:\projectASF-Mars\ofbiz\framework\service\src\main\java\org\apache\ofbiz\service\ServiceUtil.java:650: warning: [unchecked] Possible heap pollution 
from parameterized vararg type T

public static  Map makeContext(T... args) 
{
^
  where T is a type-variable:
T extends Object declared in method makeContext(T...)
C:\projectASF-Mars\ofbiz\framework\widget\src\main\java\org\apache\ofbiz\widget\renderer\fo\ScreenFopViewHandler.java:143: warning: [unchecked] 
unchecked call to put(K,V) as a member of the raw type Map

foUserAgent.getRendererOptions().put(PDFEncryptionOption.ENCRYPTION_PARAMS, 
pdfEncryptionParams);
^
  where K,V are type-variables:
K extends Object declared in interface Map
V extends Object declared in interface Map
C:\projectASF-Mars\ofbiz\applications\workeffort\src\main\java\org\apache\ofbiz\workeffort\workeffort\WorkEffortServices.java:377: warning: 
[unchecked] unchecked 

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Taher Alkhateeb]

What revision are you on?

On Fri, Sep 16, 2016 at 5:51 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> And if you are interested here is with |-Xlint:unchecked and
> -Xlint:deprecation|
>
> C:\projectASF-Mars\ofbiz>gradlew build
> :compileJava
> C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
> apache\ofbiz\base\test\GenericTestCaseBase.java:353: warning: [unchecked]
> Possible heap pollution from parameterized vararg type T
> public static  List list(T... list) {
> ^
>   where T is a type-variable:
> T extends Object declared in method list(T...)
> C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
> apache\ofbiz\base\test\GenericTestCaseBase.java:363: warning: [unchecked]
> Possible heap pollution from parameterized vararg type T
> public static  Set set(T... list) {
>   ^
>   where T is a type-variable:
> T extends Object declared in method set(T...)
> C:\projectASF-Mars\ofbiz\framework\base\src\main\java\org\
> apache\ofbiz\base\util\UtilGenerics.java:159: warning: [unchecked]
> Possible heap pollution from parameterized vararg type Object
> public static  Map toMap(Class keyType,
> Object... data) {
> ^
>   where Object,K are type-variables:
> Object extends java.lang.Object declared in method
> toMap(Class,Object...)
> K extends java.lang.Object declared in method
> toMap(Class,Object...)
> C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
> apache\ofbiz\entity\condition\EntityCondition.java:59: warning:
> [unchecked] Possible heap pollution from parameterized vararg type T
> public static  EntityConditionList
> makeCondition(EntityJoinOperator operator, T... conditionList) {
> ^
>   where T is a type-variable:
> T extends EntityCondition declared in method
> makeCondition(EntityJoinOperator,T...)
> C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
> apache\ofbiz\entity\condition\EntityCondition.java:63: warning:
> [unchecked] Possible heap pollution from parameterized vararg type T
> public static  EntityConditionList
> makeCondition(T... conditionList) {
> ^
>   where T is a type-variable:
> T extends EntityCondition declared in method makeCondition(T...)
> C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
> apache\ofbiz\entity\condition\EntityFieldMap.java:50: warning:
> [unchecked] Possible heap pollution from parameterized vararg type V
> public  EntityFieldMap(EntityComparisonOperator compOp,
> EntityJoinOperator joinOp, V... keysValues) {
> ^
>   where V is a type-variable:
> V extends Object declared in constructor EntityFieldMap(EntityCompar
> isonOperator,EntityJoinOperator,V...)
> C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
> apache\ofbiz\entity\connection\DebugManagedDataSource.java:34: warning:
> [unchecked] unwrap(Class) in PoolingDataSource implements unw
> rap(Class) in Wrapper
> public class DebugManagedDataSource extends ManagedDataSource {
>^
>   return type requires unchecked conversion from Object to T#2
>   where T#1,T#2 are type-variables:
> T#1 extends Object declared in method unwrap(Class)
> T#2 extends Object declared in method unwrap(Class)
> C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
> apache\ofbiz\entity\connection\DebugManagedDataSource.java:39: warning:
> [unchecked] unchecked call to ManagedDataSource(ObjectPool >,TransactionReg
> istry) as a member of the raw type ManagedDataSource
> super(pool, transactionRegistry);
>  ^
>   where C is a type-variable:
> C extends Connection declared in class ManagedDataSource
> C:\projectASF-Mars\ofbiz\framework\entity\src\main\java\org\
> apache\ofbiz\entity\util\EntityUtil.java:357: warning: [unchecked]
> unchecked cast
> T newValue = (T) value.clone();
> ^
>   required: T
>   found:Object
>   where T is a type-variable:
> T extends GenericEntity declared in method
> localizedOrderBy(Collection,List,Locale)
> C:\projectASF-Mars\ofbiz\framework\service\src\main\java\
> org\apache\ofbiz\service\ServiceUtil.java:650: warning: [unchecked]
> Possible heap pollution from parameterized vararg type T
> public static  Map makeContext(T...
> args) {
> ^
>   where T is a type-variable:
> T extends Object declared in method makeContext(T...)
> C:\projectASF-Mars\ofbiz\framework\widget\src\main\java\org\
> apache\ofbiz\widget\renderer\fo\ScreenFopViewHandler.java:143: warning:
> [unchecked] unchecked call to put(K,V) as a member of the raw type Map
> foUserAgent.getRendererOptions().put(PDFEncryptionOption.ENCRYPTION_PARAMS,
> pdfEncryptionParams);
>

Re: [VOTE] ASL2 header in README files?

[Pierre Smits]

You are wrong there.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Sep 16, 2016 at 12:57 PM, Michael Brohl 
wrote:

> Pierre,
>
> it seems you are not sure about it, assuming from your question in
> legal-discuss here: https://lists.apache.org/threa
> d.html/cdc08a88d47709738c4aa7595a3dc2446e7aa5450d4b6ffc8cc56
> b52@%3Clegal-discuss.apache.org%3E
>
> Regards,
> Michael
>
> Am 16.09.16 um 10:43 schrieb Pierre Smits:
>
>> -1 regarding the use of the ASL2 license for readme files. Because it is
>> the wrong license for that kind of work.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM 
>>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> So we can't decide as a community? Weird :-o
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 16/09/2016 à 10:21, Jacopo Cappellato a écrit :
>>>
>>> On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 Hi Devs,

> There are mixed opinions about putting or not the ASL2 header in OFBiz
> README files.
>
> One one hand we can read at http://www.apache.org/legal/sr
> c-headers.html#faq-exceptions that README files don't require a header
>
> But to protect our work we can decide to put a header in all README
> files
> (with or w/o suffixes). It's all or none to be consistent.
>
> Since License is an important matter I think a vote is necessary to
> define
> our policy.
>
> So please vote
>
> [+1] include a header in all README files
>
> [-1] do not include a header in any README files
>
> [0] Undecided
>
> I will close this vote in a week, thanks for your time !
>
> Jacques
>
>
> In my opinion this vote is not valid and should be cancelled.
>
 My reasoning is the following: the result of this vote may be against
 the
 ASF license policy and as a project we are not allowed to change the ASF
 license policy by vote. In fact our codebase is licensed by the ASF and
 not
 by OFBiz.

 Why am I saying that the result of this vote may be against the ASF
 license
 policy?

 If we decide to "not include a header in any README files" then we will
 violate the following [*]:

 "A file without any degree of creativity in either its literal elements
 or
 its structure is not protected by copyright law; therefore, such a file
 does not require a license header. If in doubt about the extent of the
 file's creativity, add the license header to the file."

 In fact it would be difficult to state that the following file (for
 example) does't contain "any degree of creativity":

 http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup

 In fact it contains useful documentation that was contributed by
 different
 people who spent time crafting its content.

 When in doubt, we should add the license header (as stated in the
 document
 that Jacques and I referenced); or we can omit it if we judge that the
 file
 doesn't contain any degree of creativity.
 But definitely we can't blindly decide by vote for all the files
 matching
 a
 name (i.e. README) as proposed by Jacques in this vote.
 Since deciding on a case by case may be tricky and even subjective, my
 *personal* preference would be to add to all the files the license
 header.

 Kind regards,

 Jacopo

 [*] http://www.apache.org/legal/src-headers.html#faq-exceptions



>
>

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Jacques Le Roux]

Sorry, I used locally tools/test.bat which is

svn up && gradlew cleanAll eclipse loadDefault testIntegration

And it works perfectly

It also compiles w/o problems with "gradlew clean build":

C:\projectASF-Mars\ofbiz>gradlew clean build
:clean
:compileJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:createBaseTestServiceProviderJar
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
:check
:build

BUILD SUCCESSFUL

Total time: 46.61 secs
C:\projectASF-Mars\ofbiz>

Again thanks for your help

Jacques


Le 16/09/2016 à 16:28, Taher Alkhateeb a écrit :

Jacques it seems you don't get it. The problem is not an OS problem. The
problem is in your code, it's all wrong on many levels. And by the way, the
system does not even compile (on windows and linux!)

On Fri, Sep 16, 2016 at 5:21 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Taher for support,

Tests pass locally on Windows 7 with java version "1.8.0_101"



--
2016-09-16 15:07:08,916 |main |ContainerLoader
|I| Stopped container component-container-test

Trying to override old definition of datatype junitreport
:testIntegration

BUILD SUCCESSFUL

Total time: 6 mins 56.874 secs
C:\projectASF-Mars\ofbiz>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)



--
But not locally on Ubuntu 13.10 with java version "1.8.0_91"

BUILD FAILED

Total time: 9 mins 30.59 secs
jacques@jacques-VirtualBox:~/asfprojects/ofbiz$ java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)


--

Nor on "our" Buildbot which uses Ubuntu 10.4.x (LTS) with 1.8.0_40


--

Certainly another Windows quirk

Seriously, I tried to update the JDK locally using
sudo apt-get install oracle-java8-installer
it says I have the latest.

Infra can offer a custom Debian for java version "1.8.0_102", but this
needs more investigation, and is on its way

Jacques


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


Jacques are you even compiling (let alone testing) before committing? Do
you know what you're doing here?

On Fri, Sep 16, 2016 at 2:53 PM,  wrote:

Author: jleroux

Date: Fri Sep 16 11:53:27 2016
New Revision: 1761023

URL: http://svn.apache.org/viewvc?rev=1761023=rev
Log:
Improves: Use try-with-resources statement wherever it's possible
(OFBIZ-8202)

These are a non functional changes for the accounting component

Modified:
  ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java
  ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/payment/PaymentGatewayServices.java

Modified: ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/
accounting/src/main/java/org/apache/ofbiz/accounting/
finaccount/FinAccountServices.java?rev=1761023=1761022&
r2=1761023=diff

==
--- ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java (original)
+++ ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java Fri Sep 16
11:53:27 2016
@@ -376,10 +376,7 @@ public class FinAccountServices {
   EntityCondition.makeCondition("finAccountId",
EntityOperator.EQUALS, finAccountId));
   EntityCondition condition =
EntityCondition.makeCondition(exprs,
EntityOperator.AND);

-EntityListIterator eli = null;
-try {
-eli = EntityQuery.use(delegator).
from("FinAccountTrans").where(condition).orderBy("-transactionDate").
queryIterator();
-
+try (EntityListIterator eli  =
EntityQuery.use(delegator).
from("FinAccountTrans").where(condition).orderBy("-transacti
onDate").queryIterator())
{
   GenericValue trans;
   while (remainingBalance.compareTo(Fi
nAccountHelper.ZERO)
< 0 && (trans = eli.next()) != null) {
 

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Taher Alkhateeb]

Jacques it seems you don't get it. The problem is not an OS problem. The
problem is in your code, it's all wrong on many levels. And by the way, the
system does not even compile (on windows and linux!)

On Fri, Sep 16, 2016 at 5:21 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Taher for support,
>
> Tests pass locally on Windows 7 with java version "1.8.0_101"
>
> 
> 
> --
> 2016-09-16 15:07:08,916 |main |ContainerLoader
>|I| Stopped container component-container-test
>
> Trying to override old definition of datatype junitreport
> :testIntegration
>
> BUILD SUCCESSFUL
>
> Total time: 6 mins 56.874 secs
> C:\projectASF-Mars\ofbiz>java -version
> java version "1.8.0_101"
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
>
> 
> 
> --
> But not locally on Ubuntu 13.10 with java version "1.8.0_91"
>
> BUILD FAILED
>
> Total time: 9 mins 30.59 secs
> jacques@jacques-VirtualBox:~/asfprojects/ofbiz$ java -version
> java version "1.8.0_91"
> Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
> 
> 
> --
>
> Nor on "our" Buildbot which uses Ubuntu 10.4.x (LTS) with 1.8.0_40
> 
> 
> --
>
> Certainly another Windows quirk
>
> Seriously, I tried to update the JDK locally using
> sudo apt-get install oracle-java8-installer
> it says I have the latest.
>
> Infra can offer a custom Debian for java version "1.8.0_102", but this
> needs more investigation, and is on its way
>
> Jacques
>
>
> Le 16/09/2016 à 14:09, Taher Alkhateeb a écrit :
>
>> Jacques are you even compiling (let alone testing) before committing? Do
>> you know what you're doing here?
>>
>> On Fri, Sep 16, 2016 at 2:53 PM,  wrote:
>>
>> Author: jleroux
>>> Date: Fri Sep 16 11:53:27 2016
>>> New Revision: 1761023
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1761023=rev
>>> Log:
>>> Improves: Use try-with-resources statement wherever it's possible
>>> (OFBIZ-8202)
>>>
>>> These are a non functional changes for the accounting component
>>>
>>> Modified:
>>>  ofbiz/trunk/applications/accounting/src/main/java/org/
>>> apache/ofbiz/accounting/finaccount/FinAccountServices.java
>>>  ofbiz/trunk/applications/accounting/src/main/java/org/
>>> apache/ofbiz/accounting/payment/PaymentGatewayServices.java
>>>
>>> Modified: ofbiz/trunk/applications/accounting/src/main/java/org/
>>> apache/ofbiz/accounting/finaccount/FinAccountServices.java
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/
>>> accounting/src/main/java/org/apache/ofbiz/accounting/
>>> finaccount/FinAccountServices.java?rev=1761023=1761022&
>>> r2=1761023=diff
>>> 
>>> ==
>>> --- ofbiz/trunk/applications/accounting/src/main/java/org/
>>> apache/ofbiz/accounting/finaccount/FinAccountServices.java (original)
>>> +++ ofbiz/trunk/applications/accounting/src/main/java/org/
>>> apache/ofbiz/accounting/finaccount/FinAccountServices.java Fri Sep 16
>>> 11:53:27 2016
>>> @@ -376,10 +376,7 @@ public class FinAccountServices {
>>>   EntityCondition.makeCondition("finAccountId",
>>> EntityOperator.EQUALS, finAccountId));
>>>   EntityCondition condition =
>>> EntityCondition.makeCondition(exprs,
>>> EntityOperator.AND);
>>>
>>> -EntityListIterator eli = null;
>>> -try {
>>> -eli = EntityQuery.use(delegator).
>>> from("FinAccountTrans").where(condition).orderBy("-transactionDate").
>>> queryIterator();
>>> -
>>> +try (EntityListIterator eli  =
>>> EntityQuery.use(delegator).
>>> from("FinAccountTrans").where(condition).orderBy("-transacti
>>> onDate").queryIterator())
>>> {
>>>   GenericValue trans;
>>>   while (remainingBalance.compareTo(Fi
>>> nAccountHelper.ZERO)
>>> < 0 && (trans = eli.next()) != null) {
>>>   String orderId = trans.getString("orderId");
>>> @@ -475,14 +472,6 @@ public class FinAccountServices {
>>>   } catch (GeneralException e) {
>>>   Debug.logError(e, module);
>>>   return ServiceUtil.returnError(e.getMessage());
>>> -} finally {
>>> -if (eli != null) {
>>> -  

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/account ing: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Jacques Le Roux]

Thanks Taher for support,

Tests pass locally on Windows 7 with java version "1.8.0_101"

--
2016-09-16 15:07:08,916 |main |ContainerLoader   
|I| Stopped container component-container-test

Trying to override old definition of datatype junitreport
:testIntegration

BUILD SUCCESSFUL

Total time: 6 mins 56.874 secs
C:\projectASF-Mars\ofbiz>java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

--
But not locally on Ubuntu 13.10 with java version "1.8.0_91"

BUILD FAILED

Total time: 9 mins 30.59 secs
jacques@jacques-VirtualBox:~/asfprojects/ofbiz$ java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
--

Nor on "our" Buildbot which uses Ubuntu 10.4.x (LTS) with 1.8.0_40
--

Certainly another Windows quirk

Seriously, I tried to update the JDK locally using
sudo apt-get install oracle-java8-installer
it says I have the latest.

Infra can offer a custom Debian for java version "1.8.0_102", but this needs 
more investigation, and is on its way

Jacques

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

Jacques are you even compiling (let alone testing) before committing? Do
you know what you're doing here?

On Fri, Sep 16, 2016 at 2:53 PM,  wrote:


Author: jleroux
Date: Fri Sep 16 11:53:27 2016
New Revision: 1761023

URL: http://svn.apache.org/viewvc?rev=1761023=rev
Log:
Improves: Use try-with-resources statement wherever it's possible
(OFBIZ-8202)

These are a non functional changes for the accounting component

Modified:
 ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java
 ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/payment/PaymentGatewayServices.java

Modified: ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/
accounting/src/main/java/org/apache/ofbiz/accounting/
finaccount/FinAccountServices.java?rev=1761023=1761022&
r2=1761023=diff

==
--- ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java (original)
+++ ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/finaccount/FinAccountServices.java Fri Sep 16
11:53:27 2016
@@ -376,10 +376,7 @@ public class FinAccountServices {
  EntityCondition.makeCondition("finAccountId",
EntityOperator.EQUALS, finAccountId));
  EntityCondition condition = 
EntityCondition.makeCondition(exprs,
EntityOperator.AND);

-EntityListIterator eli = null;
-try {
-eli = EntityQuery.use(delegator).
from("FinAccountTrans").where(condition).orderBy("-transactionDate").
queryIterator();
-
+try (EntityListIterator eli  = EntityQuery.use(delegator).
from("FinAccountTrans").where(condition).orderBy("-transactionDate").queryIterator())
{
  GenericValue trans;
  while (remainingBalance.compareTo(FinAccountHelper.ZERO)
< 0 && (trans = eli.next()) != null) {
  String orderId = trans.getString("orderId");
@@ -475,14 +472,6 @@ public class FinAccountServices {
  } catch (GeneralException e) {
  Debug.logError(e, module);
  return ServiceUtil.returnError(e.getMessage());
-} finally {
-if (eli != null) {
-try {
-eli.close();
-} catch (GenericEntityException e) {
-Debug.logWarning(e, module);
-}
-}
  }

  // check to make sure we balanced out

Modified: ofbiz/trunk/applications/accounting/src/main/java/org/
apache/ofbiz/accounting/payment/PaymentGatewayServices.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/
accounting/src/main/java/org/apache/ofbiz/accounting/payment/
PaymentGatewayServices.java?rev=1761023=1761022=1761023=diff

Re: Groovy and semicolon at EOL

[Rishi Solanki]

I was saying #2 as per the comment from Taher 

Quick Reference:

One reply from Taher ... in the same thread.
==

Okay, given the priorities and work we have at the moment, I suggest we
keep semicolons and use it as the standard unless someone volunteers to
make a full switch. WDYT?
==



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Fri, Sep 16, 2016 at 3:14 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> I guess you mean 2) by file, then it's OK with me. Though I'd no be
> against having semicolon inconsistency in Groovy files, which was my
> initial question. So no strong opinion about 2 here.
>
> Jacques
>
>
>
> Le 16/09/2016 à 11:31, Rishi Solanki a écrit :
>
>> To summarize the overall conversation;
>> 1) We have decided to bulk remove semicolons from groovy.
>> 2) Until #1 is not complete, we would keep adding semicolon for
>> consistency.
>>
>>
>>
>>
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxsystems.com
>>
>> On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> Actually I was wrong on this. Thanks to Jacopo I noticed that both
>>> Subclipse and Tortoise allow you to select a range of revisions when you
>>> look for annotations.
>>>
>>> So  it's no longer an issue for me and we can bulk remove trailing
>>> semicolons in Groovy files if we want.
>>>
>>> Sorry for the confusion
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>>>
>>> I don't particularly care one way or another if groovy files have a
 semi-colon at the end.  I don't even care about consistency because it
 is
 such a minor thing.

 I say remove them if they're on a line you happen to be editing,
 otherwise
 just leave them be.

 Regarding the annotations, there's plenty of ways to search commit logs
 and
 personally I've never found blame to be very useful.  I don't think it
 should be a reason to block any future bulk S/R cleanups.  We've had
 plenty
 in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
 removal, etc.) and we should continue to do it to keep things clean.

 For searching diffs, before using git-svn I used to use: svn log -diff
  and then use the search in the terminal to find the
 string
 I'm looking for.

 Regards
 Scott

 On 14 September 2016 at 07:33, Jacques Le Roux <
 jacques.le.r...@les7arts.com

 wrote:
> Le 13/09/2016 à 21:28, Jacques Le Roux a écrit :
>
> OK found that the same than in Subclipse also exists in TortoiseSVN
>
>> But you need to use a command line (weird for a GUI), eg (from
>> TortoiseSVN root folder)
>>
>> Actually wrong, simply pick a file in Windows file explorer using
>>
> TortoiseSVN  context menu, et voilà!
> I confirm, totally comparable to Subclipse annotations
>
> Jacques
>
>
>
> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
>
>> z\applications\product\src\main\java\org\apache\ofbiz\
>> product\catalog\CatalogWorker.java"
>>
>> All is explained here https://tortoisesvn.net/docs/r
>> elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics
>>
>>   From the resulting UI (comparable to Subclipse) I guess changing all
>> lines of a file will have the same effect.
>> Even if indeed the annotations are not lost, they are very hard to use
>> if
>> you need to compare revision by revision.
>>
>> Jacques
>>
>>
>> Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :
>>
>> BTW thinking about it, don't you have something similar in IntellIJ?
>>
>>> I found an (old) image there https://markphip.blogspot.fr/2
>>> 006/12/subclipse-live-annotations.html
>>>
>>> Jacques
>>>
>>>
>>> Le 13/09/2016 à 20:16, Jacques Le Roux a écrit :
>>>
>>> Thanks Jacopo,
>>>
 I found how to use it in TortoiseSVN (it starts from the log view)
 It's complementary to what Subclipse gives and so interesting but
 not
 comparable.

 You don't have this global view Subclipse offers with each
 annotation
 by line from start (r1) to HEAD.
 Very useful with colored annotations in the same column than lines
 numbers. But it unfortunately contains only the last revision if all
 lines
 have been modified together in that revision.
 Note: to see it you need to use "Show Quick Diff" ("Revision" and
 "Combined Colors" are then default options, hovering is enough for
 me).
 Same than you decide to show line numbers in this column... More for
 those who are still using Eclipse...

Re: svn commit: r1761023 - in /ofbiz/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting: finaccount/FinAccountServices.java payment/PaymentGatewayServices.java

[Taher Alkhateeb]

Jacques are you even compiling (let alone testing) before committing? Do
you know what you're doing here?

On Fri, Sep 16, 2016 at 2:53 PM,  wrote:

> Author: jleroux
> Date: Fri Sep 16 11:53:27 2016
> New Revision: 1761023
>
> URL: http://svn.apache.org/viewvc?rev=1761023=rev
> Log:
> Improves: Use try-with-resources statement wherever it's possible
> (OFBIZ-8202)
>
> These are a non functional changes for the accounting component
>
> Modified:
> ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/finaccount/FinAccountServices.java
> ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/payment/PaymentGatewayServices.java
>
> Modified: ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/finaccount/FinAccountServices.java
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/
> accounting/src/main/java/org/apache/ofbiz/accounting/
> finaccount/FinAccountServices.java?rev=1761023=1761022&
> r2=1761023=diff
> 
> ==
> --- ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/finaccount/FinAccountServices.java (original)
> +++ ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/finaccount/FinAccountServices.java Fri Sep 16
> 11:53:27 2016
> @@ -376,10 +376,7 @@ public class FinAccountServices {
>  EntityCondition.makeCondition("finAccountId",
> EntityOperator.EQUALS, finAccountId));
>  EntityCondition condition = 
> EntityCondition.makeCondition(exprs,
> EntityOperator.AND);
>
> -EntityListIterator eli = null;
> -try {
> -eli = EntityQuery.use(delegator).
> from("FinAccountTrans").where(condition).orderBy("-transactionDate").
> queryIterator();
> -
> +try (EntityListIterator eli  = EntityQuery.use(delegator).
> from("FinAccountTrans").where(condition).orderBy("-transactionDate").queryIterator())
> {
>  GenericValue trans;
>  while (remainingBalance.compareTo(FinAccountHelper.ZERO)
> < 0 && (trans = eli.next()) != null) {
>  String orderId = trans.getString("orderId");
> @@ -475,14 +472,6 @@ public class FinAccountServices {
>  } catch (GeneralException e) {
>  Debug.logError(e, module);
>  return ServiceUtil.returnError(e.getMessage());
> -} finally {
> -if (eli != null) {
> -try {
> -eli.close();
> -} catch (GenericEntityException e) {
> -Debug.logWarning(e, module);
> -}
> -}
>  }
>
>  // check to make sure we balanced out
>
> Modified: ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/payment/PaymentGatewayServices.java
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/
> accounting/src/main/java/org/apache/ofbiz/accounting/payment/
> PaymentGatewayServices.java?rev=1761023=1761022=1761023=diff
> 
> ==
> --- ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/payment/PaymentGatewayServices.java (original)
> +++ ofbiz/trunk/applications/accounting/src/main/java/org/
> apache/ofbiz/accounting/payment/PaymentGatewayServices.java Fri Sep 16
> 11:53:27 2016
> @@ -2688,16 +2688,10 @@ public class PaymentGatewayServices {
>  LocalDispatcher dispatcher = dctx.getDispatcher();
>  GenericValue userLogin = (GenericValue) context.get("userLogin");
>
> -// get a list of all payment prefs still pending
> -List exprs = UtilMisc.toList(
> EntityCondition.makeCondition("statusId", EntityOperator.EQUALS,
> "PAYMENT_NOT_AUTH"),
> -EntityCondition.makeCondition("processAttempt",
> EntityOperator.GREATER_THAN, Long.valueOf(0)));
> -
> -EntityListIterator eli = null;
> -try {
> -eli = EntityQuery.use(delegator).
> from("OrderPaymentPreference")
> +try (EntityListIterator eli = EntityQuery.use(delegator).
> from("OrderPaymentPreference")
>  .where(EntityCondition.makeCondition("statusId",
> EntityOperator.EQUALS, "PAYMENT_NOT_AUTH"),
>  EntityCondition.makeCondition("processAttempt",
> EntityOperator.GREATER_THAN, Long.valueOf(0)))
> -.orderBy("orderId").queryIterator();
> +.orderBy("orderId").queryIterator()) {
>  List processList = new LinkedList();
>  if (eli != null) {
>  Debug.logInfo("Processing failed order re-auth(s)",
> module);
> @@ -2717,14 +2711,6 @@ public class 

buildbot exception in on ofbiz-trunk

[buildbot]

The Buildbot has detected a build exception on builder ofbiz-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/1430

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

Buildslave for this Build: orcus_ubuntu

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

BUILD FAILED: exception shell upload_2

Sincerely,
 -The Buildbot

Re: [VOTE] ASL2 header in README files?

[Taher Alkhateeb]

Well, for the README.md you can add the license using the HTML version in
APACHE2_HEADER. For the rest of the README files you can use the standard
header.

On Fri, Sep 16, 2016 at 2:41 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 16/09/2016 à 12:31, Jacopo Cappellato a écrit :
>
>> On Fri, Sep 16, 2016 at 12:24 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> I simply wonder how we, as a community, can decide on this subject if no
>>> vote can be done.
>>>
>>> Jacques
>>>
>>> Jacques, please do not be elusive... I am simply asking you if this vote
>> is
>> still valid or you have cancelled it.
>>
>> Jacopo
>>
>> OK, I cancelled the vote because "it makes no sense to force to have an
> ASL2 headers in ALL readme files", now what?
>
> Jacques
>
>

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

Le 16/09/2016 à 12:31, Jacopo Cappellato a écrit :

On Fri, Sep 16, 2016 at 12:24 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I simply wonder how we, as a community, can decide on this subject if no
vote can be done.

Jacques


Jacques, please do not be elusive... I am simply asking you if this vote is
still valid or you have cancelled it.

Jacopo


OK, I cancelled the vote because "it makes no sense to force to have an ASL2 headers 
in ALL readme files", now what?

Jacques

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

I cancel this vote because it makes no sense to force to have an ASL2 headers 
in ALL readme files as I described them

Jacques


Le 16/09/2016 à 12:31, Jacopo Cappellato a écrit :

On Fri, Sep 16, 2016 at 12:24 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I simply wonder how we, as a community, can decide on this subject if no
vote can be done.

Jacques


Jacques, please do not be elusive... I am simply asking you if this vote is
still valid or you have cancelled it.

Jacopo

Re: [VOTE] ASL2 header in README files?

[Michael Brohl]

Pierre,

it seems you are not sure about it, assuming from your question in 
legal-discuss here: 
https://lists.apache.org/thread.html/cdc08a88d47709738c4aa7595a3dc2446e7aa5450d4b6ffc8cc56b52@%3Clegal-discuss.apache.org%3E 



Regards,
Michael

Am 16.09.16 um 10:43 schrieb Pierre Smits:

-1 regarding the use of the ASL2 license for readme files. Because it is
the wrong license for that kind of work.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


So we can't decide as a community? Weird :-o

Jacques



Le 16/09/2016 à 10:21, Jacopo Cappellato a écrit :


On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Devs,

There are mixed opinions about putting or not the ASL2 header in OFBiz
README files.

One one hand we can read at http://www.apache.org/legal/sr
c-headers.html#faq-exceptions that README files don't require a header

But to protect our work we can decide to put a header in all README files
(with or w/o suffixes). It's all or none to be consistent.

Since License is an important matter I think a vote is necessary to
define
our policy.

So please vote

[+1] include a header in all README files

[-1] do not include a header in any README files

[0] Undecided

I will close this vote in a week, thanks for your time !

Jacques


In my opinion this vote is not valid and should be cancelled.

My reasoning is the following: the result of this vote may be against the
ASF license policy and as a project we are not allowed to change the ASF
license policy by vote. In fact our codebase is licensed by the ASF and
not
by OFBiz.

Why am I saying that the result of this vote may be against the ASF
license
policy?

If we decide to "not include a header in any README files" then we will
violate the following [*]:

"A file without any degree of creativity in either its literal elements or
its structure is not protected by copyright law; therefore, such a file
does not require a license header. If in doubt about the extent of the
file's creativity, add the license header to the file."

In fact it would be difficult to state that the following file (for
example) does't contain "any degree of creativity":

http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup

In fact it contains useful documentation that was contributed by different
people who spent time crafting its content.

When in doubt, we should add the license header (as stated in the document
that Jacques and I referenced); or we can omit it if we judge that the
file
doesn't contain any degree of creativity.
But definitely we can't blindly decide by vote for all the files matching
a
name (i.e. README) as proposed by Jacques in this vote.
Since deciding on a case by case may be tricky and even subjective, my
*personal* preference would be to add to all the files the license header.

Kind regards,

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions







smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] ASL2 header in README files?

[Jacopo Cappellato]

On Fri, Sep 16, 2016 at 12:24 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

>
> I simply wonder how we, as a community, can decide on this subject if no
> vote can be done.
>
> Jacques
>

Jacques, please do not be elusive... I am simply asking you if this vote is
still valid or you have cancelled it.

Jacopo

Re: [VOTE] ASL2 header in README files?

[Pierre Smits]

Some love to discuss (and digress), Jacques.

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Sep 16, 2016 at 12:24 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 16/09/2016 à 12:08, Jacopo Cappellato a écrit :
>
>> On Fri, Sep 16, 2016 at 12:04 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> Le 16/09/2016 à 11:22, Jacopo Cappellato a écrit :
>>>
>>> On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 So we can't decide as a community? Weird :-o

> Jacques
>
> Jacques, are you saying that we are allowed, as a community, to decide
 to
 not include the license header to files containing some degree of
 creativity (despite to what is stated here [*])?

 Jacopo

 [*] http://www.apache.org/legal/src-headers.html#faq-exceptions

 Not at all, I simply wonder what we will decide finally?

>>> jacques
>>>
>>> I am confused: what is the question you are asking? Do you think that
>> this
>> vote should go on?
>>
>> Jacopo
>>
>> I simply wonder how we, as a community, can decide on this subject if no
> vote can be done.
>
> Jacques
>
>

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

Le 16/09/2016 à 12:08, Jacopo Cappellato a écrit :

On Fri, Sep 16, 2016 at 12:04 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 16/09/2016 à 11:22, Jacopo Cappellato a écrit :


On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

So we can't decide as a community? Weird :-o

Jacques


Jacques, are you saying that we are allowed, as a community, to decide to
not include the license header to files containing some degree of
creativity (despite to what is stated here [*])?

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions

Not at all, I simply wonder what we will decide finally?

jacques


I am confused: what is the question you are asking? Do you think that this
vote should go on?

Jacopo


I simply wonder how we, as a community, can decide on this subject if no vote 
can be done.

Jacques

Re: [VOTE] ASL2 header in README files?

[Jacopo Cappellato]

On Fri, Sep 16, 2016 at 12:04 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 16/09/2016 à 11:22, Jacopo Cappellato a écrit :
>
>> On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> So we can't decide as a community? Weird :-o
>>>
>>> Jacques
>>>
>>
>> Jacques, are you saying that we are allowed, as a community, to decide to
>> not include the license header to files containing some degree of
>> creativity (despite to what is stated here [*])?
>>
>> Jacopo
>>
>> [*] http://www.apache.org/legal/src-headers.html#faq-exceptions
>>
>> Not at all, I simply wonder what we will decide finally?
>
> jacques
>

I am confused: what is the question you are asking? Do you think that this
vote should go on?

Jacopo

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

Le 16/09/2016 à 11:22, Jacopo Cappellato a écrit :

On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


So we can't decide as a community? Weird :-o

Jacques


Jacques, are you saying that we are allowed, as a community, to decide to
not include the license header to files containing some degree of
creativity (despite to what is stated here [*])?

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions


Not at all, I simply wonder what we will decide finally?

jacques

Re: Groovy and semicolon at EOL

[Jacques Le Roux]

I guess you mean 2) by file, then it's OK with me. Though I'd no be against having semicolon inconsistency in Groovy files, which was my initial 
question. So no strong opinion about 2 here.


Jacques


Le 16/09/2016 à 11:31, Rishi Solanki a écrit :

To summarize the overall conversation;
1) We have decided to bulk remove semicolons from groovy.
2) Until #1 is not complete, we would keep adding semicolon for consistency.




Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Actually I was wrong on this. Thanks to Jacopo I noticed that both
Subclipse and Tortoise allow you to select a range of revisions when you
look for annotations.

So  it's no longer an issue for me and we can bulk remove trailing
semicolons in Groovy files if we want.

Sorry for the confusion

Jacques



Le 14/09/2016 à 04:42, Scott Gray a écrit :


I don't particularly care one way or another if groovy files have a
semi-colon at the end.  I don't even care about consistency because it is
such a minor thing.

I say remove them if they're on a line you happen to be editing, otherwise
just leave them be.

Regarding the annotations, there's plenty of ways to search commit logs
and
personally I've never found blame to be very useful.  I don't think it
should be a reason to block any future bulk S/R cleanups.  We've had
plenty
in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
removal, etc.) and we should continue to do it to keep things clean.

For searching diffs, before using git-svn I used to use: svn log -diff
 and then use the search in the terminal to find the string
I'm looking for.

Regards
Scott

On 14 September 2016 at 07:33, Jacques Le Roux <
jacques.le.r...@les7arts.com


wrote:
Le 13/09/2016 à 21:28, Jacques Le Roux a écrit :

OK found that the same than in Subclipse also exists in TortoiseSVN

But you need to use a command line (weird for a GUI), eg (from
TortoiseSVN root folder)

Actually wrong, simply pick a file in Windows file explorer using

TortoiseSVN  context menu, et voilà!
I confirm, totally comparable to Subclipse annotations

Jacques



TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi

z\applications\product\src\main\java\org\apache\ofbiz\
product\catalog\CatalogWorker.java"

All is explained here https://tortoisesvn.net/docs/r
elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics

  From the resulting UI (comparable to Subclipse) I guess changing all
lines of a file will have the same effect.
Even if indeed the annotations are not lost, they are very hard to use
if
you need to compare revision by revision.

Jacques


Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :

BTW thinking about it, don't you have something similar in IntellIJ?

I found an (old) image there https://markphip.blogspot.fr/2
006/12/subclipse-live-annotations.html

Jacques


Le 13/09/2016 à 20:16, Jacques Le Roux a écrit :

Thanks Jacopo,

I found how to use it in TortoiseSVN (it starts from the log view)
It's complementary to what Subclipse gives and so interesting but not
comparable.

You don't have this global view Subclipse offers with each annotation
by line from start (r1) to HEAD.
Very useful with colored annotations in the same column than lines
numbers. But it unfortunately contains only the last revision if all
lines
have been modified together in that revision.
Note: to see it you need to use "Show Quick Diff" ("Revision" and
"Combined Colors" are then default options, hovering is enough for
me).
Same than you decide to show line numbers in this column... More for
those who are still using Eclipse...

Jacques

Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :

Some examples:

svn blame README.md

after review you run

svn blame README.md -r 1:1757044

and then

svn blame README.md -r 1:1757042

and so on to get back in history... nothing is lost, annotations are
always
there.

Jacopo

PS: I think there is some trick to do the same with TortoiseSVN but I
can't
tell you the details since I don't use it

On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :


On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <


jacques.le.r...@les7arts.com> wrote:

...

Before applying a such change, I'd really like to know if everybody

is
aware of what that means when it comes to svn annotations. I
repeat: we
will then lose all the svn annotations history in all the Groovy
files.
...

Jacques, are you aware that you can pass the -r argument to the

blame/annotate command?

Jacopo

I must say I never use that when looking at annotations in a file
in

Eclipse. It's maybe useful in certain circumstances, but I hardly

see
when.
And once all the lines a file has been modified in one commit, I
guess -r
does not help at all, anyway you get only this 

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

Le 16/09/2016 à 10:21, Jacopo Cappellato a écrit :

On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Devs,

There are mixed opinions about putting or not the ASL2 header in OFBiz
README files.

One one hand we can read at http://www.apache.org/legal/sr
c-headers.html#faq-exceptions that README files don't require a header

But to protect our work we can decide to put a header in all README files
(with or w/o suffixes). It's all or none to be consistent.

Since License is an important matter I think a vote is necessary to define
our policy.

So please vote

[+1] include a header in all README files

[-1] do not include a header in any README files

[0] Undecided

I will close this vote in a week, thanks for your time !

Jacques



In my opinion this vote is not valid and should be cancelled.
My reasoning is the following: the result of this vote may be against the
ASF license policy and as a project we are not allowed to change the ASF
license policy by vote. In fact our codebase is licensed by the ASF and not
by OFBiz.

Why am I saying that the result of this vote may be against the ASF license
policy?

If we decide to "not include a header in any README files" then we will
violate the following [*]:

"A file without any degree of creativity in either its literal elements or
its structure is not protected by copyright law; therefore, such a file
does not require a license header. If in doubt about the extent of the
file's creativity, add the license header to the file."

In fact it would be difficult to state that the following file (for
example) does't contain "any degree of creativity":

http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup

In fact it contains useful documentation that was contributed by different
people who spent time crafting its content.

When in doubt, we should add the license header (as stated in the document
that Jacques and I referenced); or we can omit it if we judge that the file
doesn't contain any degree of creativity.
But definitely we can't blindly decide by vote for all the files matching a
name (i.e. README) as proposed by Jacques in this vote.
Since deciding on a case by case may be tricky and even subjective, my
*personal* preference would be to add to all the files the license header.

Kind regards,

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions



Thinking about it, I think I asked the wrong question because of my consistency 
obsession.

Actually if we are able to decide that the README. MD should have a license (which I agree with); I don't see why we should not be able to decide that 
a file like the README in runtime/log does not need a license.


My point is we don't need to add useless lines in OFBiz, even for the sake of 
consistency.
On the other hand it's much easier to decide to add the ASL2 license everywhere 
because we can automate it with a S/R

But mmm, are we not somehow deciding something like if we have voted for adding 
"ASL2 header in README files"?

Jacques

Re: Groovy and semicolon at EOL

[Rishi Solanki]

To summarize the overall conversation;
1) We have decided to bulk remove semicolons from groovy.
2) Until #1 is not complete, we would keep adding semicolon for consistency.




Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Thu, Sep 15, 2016 at 10:00 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Actually I was wrong on this. Thanks to Jacopo I noticed that both
> Subclipse and Tortoise allow you to select a range of revisions when you
> look for annotations.
>
> So  it's no longer an issue for me and we can bulk remove trailing
> semicolons in Groovy files if we want.
>
> Sorry for the confusion
>
> Jacques
>
>
>
> Le 14/09/2016 à 04:42, Scott Gray a écrit :
>
>> I don't particularly care one way or another if groovy files have a
>> semi-colon at the end.  I don't even care about consistency because it is
>> such a minor thing.
>>
>> I say remove them if they're on a line you happen to be editing, otherwise
>> just leave them be.
>>
>> Regarding the annotations, there's plenty of ways to search commit logs
>> and
>> personally I've never found blame to be very useful.  I don't think it
>> should be a reason to block any future bulk S/R cleanups.  We've had
>> plenty
>> in the past (Double -> BigDecimal, Delegator -> EntityQuery, whitespace
>> removal, etc.) and we should continue to do it to keep things clean.
>>
>> For searching diffs, before using git-svn I used to use: svn log -diff
>>  and then use the search in the terminal to find the string
>> I'm looking for.
>>
>> Regards
>> Scott
>>
>> On 14 September 2016 at 07:33, Jacques Le Roux <
>> jacques.le.r...@les7arts.com
>>
>>> wrote:
>>> Le 13/09/2016 à 21:28, Jacques Le Roux a écrit :
>>>
>>> OK found that the same than in Subclipse also exists in TortoiseSVN

 But you need to use a command line (weird for a GUI), eg (from
 TortoiseSVN root folder)

 Actually wrong, simply pick a file in Windows file explorer using
>>> TortoiseSVN  context menu, et voilà!
>>> I confirm, totally comparable to Subclipse annotations
>>>
>>> Jacques
>>>
>>>
>>>
>>> TortoiseProc.exe /command:blame /path:"C:\projectASF-Mars\ofbi
 z\applications\product\src\main\java\org\apache\ofbiz\
 product\catalog\CatalogWorker.java"

 All is explained here https://tortoisesvn.net/docs/r
 elease/TortoiseSVN_en/tsvn-automation.html#tsvn-automation-basics

  From the resulting UI (comparable to Subclipse) I guess changing all
 lines of a file will have the same effect.
 Even if indeed the annotations are not lost, they are very hard to use
 if
 you need to compare revision by revision.

 Jacques


 Le 13/09/2016 à 20:21, Jacques Le Roux a écrit :

 BTW thinking about it, don't you have something similar in IntellIJ?
>
> I found an (old) image there https://markphip.blogspot.fr/2
> 006/12/subclipse-live-annotations.html
>
> Jacques
>
>
> Le 13/09/2016 à 20:16, Jacques Le Roux a écrit :
>
> Thanks Jacopo,
>>
>> I found how to use it in TortoiseSVN (it starts from the log view)
>> It's complementary to what Subclipse gives and so interesting but not
>> comparable.
>>
>> You don't have this global view Subclipse offers with each annotation
>> by line from start (r1) to HEAD.
>> Very useful with colored annotations in the same column than lines
>> numbers. But it unfortunately contains only the last revision if all
>> lines
>> have been modified together in that revision.
>> Note: to see it you need to use "Show Quick Diff" ("Revision" and
>> "Combined Colors" are then default options, hovering is enough for
>> me).
>> Same than you decide to show line numbers in this column... More for
>> those who are still using Eclipse...
>>
>> Jacques
>>
>> Le 13/09/2016 à 17:40, Jacopo Cappellato a écrit :
>>
>> Some examples:
>>>
>>> svn blame README.md
>>>
>>> after review you run
>>>
>>> svn blame README.md -r 1:1757044
>>>
>>> and then
>>>
>>> svn blame README.md -r 1:1757042
>>>
>>> and so on to get back in history... nothing is lost, annotations are
>>> always
>>> there.
>>>
>>> Jacopo
>>>
>>> PS: I think there is some trick to do the same with TortoiseSVN but I
>>> can't
>>> tell you the details since I don't use it
>>>
>>> On Tue, Sep 13, 2016 at 5:16 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> Le 13/09/2016 à 16:45, Jacopo Cappellato a écrit :
>>>
 On Tue, Sep 13, 2016 at 4:36 PM, Jacques Le Roux <

> jacques.le.r...@les7arts.com> wrote:
>
> ...
>
> Before applying a such change, I'd really like to know if everybody
>> is
>> aware of what that means when it comes to svn 

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

+1


Le 16/09/2016 à 10:32, Jacopo Cappellato a écrit :

Also, if I recall, it was initially decided to not include a license header
to the main README.md file in the root folder: however now that the file
represents an important part of the OFBiz documentation, I think we should
revisit that decision and add a license header to it.

Jacopo

On Fri, Sep 16, 2016 at 10:21 AM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Devs,

There are mixed opinions about putting or not the ASL2 header in OFBiz
README files.

One one hand we can read at http://www.apache.org/legal/sr
c-headers.html#faq-exceptions that README files don't require a header

But to protect our work we can decide to put a header in all README files
(with or w/o suffixes). It's all or none to be consistent.

Since License is an important matter I think a vote is necessary to
define our policy.

So please vote

[+1] include a header in all README files

[-1] do not include a header in any README files

[0] Undecided

I will close this vote in a week, thanks for your time !

Jacques



In my opinion this vote is not valid and should be cancelled.
My reasoning is the following: the result of this vote may be against the
ASF license policy and as a project we are not allowed to change the ASF
license policy by vote. In fact our codebase is licensed by the ASF and not
by OFBiz.

Why am I saying that the result of this vote may be against the ASF
license policy?

If we decide to "not include a header in any README files" then we will
violate the following [*]:

"A file without any degree of creativity in either its literal elements
or its structure is not protected by copyright law; therefore, such a file
does not require a license header. If in doubt about the extent of the
file's creativity, add the license header to the file."

In fact it would be difficult to state that the following file (for
example) does't contain "any degree of creativity":

http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup

In fact it contains useful documentation that was contributed by different
people who spent time crafting its content.

When in doubt, we should add the license header (as stated in the document
that Jacques and I referenced); or we can omit it if we judge that the file
doesn't contain any degree of creativity.
But definitely we can't blindly decide by vote for all the files matching
a name (i.e. README) as proposed by Jacques in this vote.
Since deciding on a case by case may be tricky and even subjective, my
*personal* preference would be to add to all the files the license header.

Kind regards,

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

What license would you propose? Remember we are an Apache project, which of course does not mean we must use the ASL2 license, but simplifies 
potential users evaluation regarding the licensing aspect.


Jacques


Le 16/09/2016 à 10:43, Pierre Smits a écrit :

-1 regarding the use of the ASL2 license for readme files. Because it is
the wrong license for that kind of work.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


So we can't decide as a community? Weird :-o

Jacques



Le 16/09/2016 à 10:21, Jacopo Cappellato a écrit :


On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Devs,

There are mixed opinions about putting or not the ASL2 header in OFBiz
README files.

One one hand we can read at http://www.apache.org/legal/sr
c-headers.html#faq-exceptions that README files don't require a header

But to protect our work we can decide to put a header in all README files
(with or w/o suffixes). It's all or none to be consistent.

Since License is an important matter I think a vote is necessary to
define
our policy.

So please vote

[+1] include a header in all README files

[-1] do not include a header in any README files

[0] Undecided

I will close this vote in a week, thanks for your time !

Jacques


In my opinion this vote is not valid and should be cancelled.

My reasoning is the following: the result of this vote may be against the
ASF license policy and as a project we are not allowed to change the ASF
license policy by vote. In fact our codebase is licensed by the ASF and
not
by OFBiz.

Why am I saying that the result of this vote may be against the ASF
license
policy?

If we decide to "not include a header in any README files" then we will
violate the following [*]:

"A file without any degree of creativity in either its literal elements or
its structure is not protected by copyright law; therefore, such a file
does not require a license header. If in doubt about the extent of the
file's creativity, add the license header to the file."

In fact it would be difficult to state that the following file (for
example) does't contain "any degree of creativity":

http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup

In fact it contains useful documentation that was contributed by different
people who spent time crafting its content.

When in doubt, we should add the license header (as stated in the document
that Jacques and I referenced); or we can omit it if we judge that the
file
doesn't contain any degree of creativity.
But definitely we can't blindly decide by vote for all the files matching
a
name (i.e. README) as proposed by Jacques in this vote.
Since deciding on a case by case may be tricky and even subjective, my
*personal* preference would be to add to all the files the license header.

Kind regards,

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions

Re: Remove unused labels?

[Jacques Le Roux]

Le 16/09/2016 à 11:18, Taher Alkhateeb a écrit :

Hi Jacques,

Yeah I looked at your explanation, still doable, in fact, it seems to be a
great thing to do in Groovy. A couple of hours in authoring a script could
iterate through all the variations and clean them up, and that could be
part of our tools. We would really benefit from writing scripts to cleanup
our XML, I'm going to add this to my future todo list.

Anyway, for the record I'm not suggesting we _must_ do it in one shot, just
suggesting it would be better / easier to do it that way and then automate
it with a script that we can use in the future as part of QA.


Yes I agree that a such tool which would give the same result or better than 
what we already have would be great!

Jacques



On Fri, Sep 16, 2016 at 8:28 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Did you have a look at OFBIZ-8154 and the related code :-o ?

Jacques



Le 16/09/2016 à 07:16, Taher Alkhateeb a écrit :


Simple, loop over the labels, and for each label if it exists anywhere
don't delete it, else, delete it.

On Sep 16, 2016 8:15 AM, "Jacques Le Roux" 
wrote:

You need to know which patterns to use, the difficulty is not technical

but functional

Jacques


Le 16/09/2016 à 07:04, Taher Alkhateeb a écrit :

Why would you think it is difficult? Seems like good old pattern matching

to me.

On Sep 15, 2016 10:28 PM, "Jacques Le Roux" <
jacques.le.r...@les7arts.com
wrote:

Le 15/09/2016 à 21:19, Taher Alkhateeb a écrit :


I think unused labels should be removed. I also think it is not too
hard


to
find and delete all such labels in one shot. We can develop a script
to
do
that and use it on a recurring basis actually.

Actually this already exists, and it's maybe not as simple as you
would


think, see https://issues.apache.org/jira/browse/OFBIZ-8154

Jacques

Unfortunately we have unused XML not only in labels but many other XML

resources making them dead code. This is an area ripe for refactoring.

On Sep 15, 2016 10:13 PM, "Pierre Smits" 
wrote:

Maybe we should discuss each individual label? Or do you believe you
can

use your own judgement to do the right thing?

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Thu, Sep 15, 2016 at 9:09 PM, Pierre Smits <
pierre.sm...@gmail.com>
wrote:

That goes to show that not much attention was paid when they got in.

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Thu, Sep 15, 2016 at 8:50 PM, jler...@apache.org <
jler...@apache.org
wrote:

Hi,

While working on OFBIZ-8154 I noticed that the labels beginning by

"HumanResServices." are never used.

So, it's a pity, but I think they should be removed. Actually my

question


is more if we agree about removing all unused labels, not only those
ones.
Thanks

Re: [VOTE] ASL2 header in README files?

[Taher Alkhateeb]

Hi Jacopo, yeah it's good to have that file. I meant specifically for
"Markdown" because we had an issue of formatting. After a bit of research I
realized that HTML comments in Markdown will be ignored in most Markdown
readers including github's reader. In fact we should update that file to
include Markdown as a target for the HTML comments

On Fri, Sep 16, 2016 at 12:02 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> On Fri, Sep 16, 2016 at 10:38 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
> > I agree Jacopo. After a little bit of research I realized that we can add
> > the header license without affecting the format by using html comment
> > format 
> >
> > Therefore I think it is wise to keep the license header in all of our
> files
> >
>
> yes Taher, we have a collection of license headers we can pick from here:
>
> http://svn.apache.org/repos/asf/ofbiz/trunk/APACHE2_HEADER
>
> :-)
>

Re: [VOTE] ASL2 header in README files?

[Jacopo Cappellato]

On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> So we can't decide as a community? Weird :-o
>
> Jacques


Jacques, are you saying that we are allowed, as a community, to decide to
not include the license header to files containing some degree of
creativity (despite to what is stated here [*])?

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions

Re: Remove unused labels?

[Taher Alkhateeb]

Hi Jacques,

Yeah I looked at your explanation, still doable, in fact, it seems to be a
great thing to do in Groovy. A couple of hours in authoring a script could
iterate through all the variations and clean them up, and that could be
part of our tools. We would really benefit from writing scripts to cleanup
our XML, I'm going to add this to my future todo list.

Anyway, for the record I'm not suggesting we _must_ do it in one shot, just
suggesting it would be better / easier to do it that way and then automate
it with a script that we can use in the future as part of QA.

On Fri, Sep 16, 2016 at 8:28 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Did you have a look at OFBIZ-8154 and the related code :-o ?
>
> Jacques
>
>
>
> Le 16/09/2016 à 07:16, Taher Alkhateeb a écrit :
>
>> Simple, loop over the labels, and for each label if it exists anywhere
>> don't delete it, else, delete it.
>>
>> On Sep 16, 2016 8:15 AM, "Jacques Le Roux" 
>> wrote:
>>
>> You need to know which patterns to use, the difficulty is not technical
>>> but functional
>>>
>>> Jacques
>>>
>>>
>>> Le 16/09/2016 à 07:04, Taher Alkhateeb a écrit :
>>>
>>> Why would you think it is difficult? Seems like good old pattern matching
 to me.

 On Sep 15, 2016 10:28 PM, "Jacques Le Roux" <
 jacques.le.r...@les7arts.com
 wrote:

 Le 15/09/2016 à 21:19, Taher Alkhateeb a écrit :

> I think unused labels should be removed. I also think it is not too
> hard
>
>> to
>> find and delete all such labels in one shot. We can develop a script
>> to
>> do
>> that and use it on a recurring basis actually.
>>
>> Actually this already exists, and it's maybe not as simple as you
>> would
>>
> think, see https://issues.apache.org/jira/browse/OFBIZ-8154
>
> Jacques
>
> Unfortunately we have unused XML not only in labels but many other XML
>
> resources making them dead code. This is an area ripe for refactoring.
>>
>> On Sep 15, 2016 10:13 PM, "Pierre Smits" 
>> wrote:
>>
>> Maybe we should discuss each individual label? Or do you believe you
>> can
>>
>> use your own judgement to do the right thing?
>>>
>>> Pierre Smits
>>>
>>> ORRTIZ.COM 
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplace
>>> http://oem.ofbizci.net/oci-2/
>>>
>>> On Thu, Sep 15, 2016 at 9:09 PM, Pierre Smits <
>>> pierre.sm...@gmail.com>
>>> wrote:
>>>
>>> That goes to show that not much attention was paid when they got in.
>>>
>>> Pierre Smits

 ORRTIZ.COM 
 OFBiz based solutions & services

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

 On Thu, Sep 15, 2016 at 8:50 PM, jler...@apache.org <
 jler...@apache.org
 wrote:

 Hi,

 While working on OFBIZ-8154 I noticed that the labels beginning by
> "HumanResServices." are never used.
>
> So, it's a pity, but I think they should be removed. Actually my
>
> question
>
 is more if we agree about removing all unused labels, not only those
 ones.
 Thanks


>
>

Re: [VOTE] ASL2 header in README files?

[Jacopo Cappellato]

On Fri, Sep 16, 2016 at 10:38 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> I agree Jacopo. After a little bit of research I realized that we can add
> the header license without affecting the format by using html comment
> format 
>
> Therefore I think it is wise to keep the license header in all of our files
>

yes Taher, we have a collection of license headers we can pick from here:

http://svn.apache.org/repos/asf/ofbiz/trunk/APACHE2_HEADER

:-)

Re: [VOTE] ASL2 header in README files?

[Pierre Smits]

-1 regarding the use of the ASL2 license for readme files. Because it is
the wrong license for that kind of work.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Sep 16, 2016 at 10:41 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> So we can't decide as a community? Weird :-o
>
> Jacques
>
>
>
> Le 16/09/2016 à 10:21, Jacopo Cappellato a écrit :
>
>> On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> Hi Devs,
>>>
>>> There are mixed opinions about putting or not the ASL2 header in OFBiz
>>> README files.
>>>
>>> One one hand we can read at http://www.apache.org/legal/sr
>>> c-headers.html#faq-exceptions that README files don't require a header
>>>
>>> But to protect our work we can decide to put a header in all README files
>>> (with or w/o suffixes). It's all or none to be consistent.
>>>
>>> Since License is an important matter I think a vote is necessary to
>>> define
>>> our policy.
>>>
>>> So please vote
>>>
>>> [+1] include a header in all README files
>>>
>>> [-1] do not include a header in any README files
>>>
>>> [0] Undecided
>>>
>>> I will close this vote in a week, thanks for your time !
>>>
>>> Jacques
>>>
>>>
>>> In my opinion this vote is not valid and should be cancelled.
>> My reasoning is the following: the result of this vote may be against the
>> ASF license policy and as a project we are not allowed to change the ASF
>> license policy by vote. In fact our codebase is licensed by the ASF and
>> not
>> by OFBiz.
>>
>> Why am I saying that the result of this vote may be against the ASF
>> license
>> policy?
>>
>> If we decide to "not include a header in any README files" then we will
>> violate the following [*]:
>>
>> "A file without any degree of creativity in either its literal elements or
>> its structure is not protected by copyright law; therefore, such a file
>> does not require a license header. If in doubt about the extent of the
>> file's creativity, add the license header to the file."
>>
>> In fact it would be difficult to state that the following file (for
>> example) does't contain "any degree of creativity":
>>
>> http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup
>>
>> In fact it contains useful documentation that was contributed by different
>> people who spent time crafting its content.
>>
>> When in doubt, we should add the license header (as stated in the document
>> that Jacques and I referenced); or we can omit it if we judge that the
>> file
>> doesn't contain any degree of creativity.
>> But definitely we can't blindly decide by vote for all the files matching
>> a
>> name (i.e. README) as proposed by Jacques in this vote.
>> Since deciding on a case by case may be tricky and even subjective, my
>> *personal* preference would be to add to all the files the license header.
>>
>> Kind regards,
>>
>> Jacopo
>>
>> [*] http://www.apache.org/legal/src-headers.html#faq-exceptions
>>
>>
>

Re: [VOTE] ASL2 header in README files?

[Jacques Le Roux]

So we can't decide as a community? Weird :-o

Jacques


Le 16/09/2016 à 10:21, Jacopo Cappellato a écrit :

On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Devs,

There are mixed opinions about putting or not the ASL2 header in OFBiz
README files.

One one hand we can read at http://www.apache.org/legal/sr
c-headers.html#faq-exceptions that README files don't require a header

But to protect our work we can decide to put a header in all README files
(with or w/o suffixes). It's all or none to be consistent.

Since License is an important matter I think a vote is necessary to define
our policy.

So please vote

[+1] include a header in all README files

[-1] do not include a header in any README files

[0] Undecided

I will close this vote in a week, thanks for your time !

Jacques



In my opinion this vote is not valid and should be cancelled.
My reasoning is the following: the result of this vote may be against the
ASF license policy and as a project we are not allowed to change the ASF
license policy by vote. In fact our codebase is licensed by the ASF and not
by OFBiz.

Why am I saying that the result of this vote may be against the ASF license
policy?

If we decide to "not include a header in any README files" then we will
violate the following [*]:

"A file without any degree of creativity in either its literal elements or
its structure is not protected by copyright law; therefore, such a file
does not require a license header. If in doubt about the extent of the
file's creativity, add the license header to the file."

In fact it would be difficult to state that the following file (for
example) does't contain "any degree of creativity":

http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup

In fact it contains useful documentation that was contributed by different
people who spent time crafting its content.

When in doubt, we should add the license header (as stated in the document
that Jacques and I referenced); or we can omit it if we judge that the file
doesn't contain any degree of creativity.
But definitely we can't blindly decide by vote for all the files matching a
name (i.e. README) as proposed by Jacques in this vote.
Since deciding on a case by case may be tricky and even subjective, my
*personal* preference would be to add to all the files the license header.

Kind regards,

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions

Re: [VOTE] ASL2 header in README files?

[Taher Alkhateeb]

I agree Jacopo. After a little bit of research I realized that we can add
the header license without affecting the format by using html comment
format 

Therefore I think it is wise to keep the license header in all of our files

On Sep 16, 2016 11:32 AM, "Jacopo Cappellato" <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Also, if I recall, it was initially decided to not include a license header
> to the main README.md file in the root folder: however now that the file
> represents an important part of the OFBiz documentation, I think we should
> revisit that decision and add a license header to it.
>
> Jacopo
>
> On Fri, Sep 16, 2016 at 10:21 AM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Hi Devs,
> >>
> >> There are mixed opinions about putting or not the ASL2 header in OFBiz
> >> README files.
> >>
> >> One one hand we can read at http://www.apache.org/legal/sr
> >> c-headers.html#faq-exceptions that README files don't require a header
> >>
> >> But to protect our work we can decide to put a header in all README
> files
> >> (with or w/o suffixes). It's all or none to be consistent.
> >>
> >> Since License is an important matter I think a vote is necessary to
> >> define our policy.
> >>
> >> So please vote
> >>
> >> [+1] include a header in all README files
> >>
> >> [-1] do not include a header in any README files
> >>
> >> [0] Undecided
> >>
> >> I will close this vote in a week, thanks for your time !
> >>
> >> Jacques
> >>
> >>
> > In my opinion this vote is not valid and should be cancelled.
> > My reasoning is the following: the result of this vote may be against the
> > ASF license policy and as a project we are not allowed to change the ASF
> > license policy by vote. In fact our codebase is licensed by the ASF and
> not
> > by OFBiz.
> >
> > Why am I saying that the result of this vote may be against the ASF
> > license policy?
> >
> > If we decide to "not include a header in any README files" then we will
> > violate the following [*]:
> >
> > "A file without any degree of creativity in either its literal elements
> > or its structure is not protected by copyright law; therefore, such a
> file
> > does not require a license header. If in doubt about the extent of the
> > file's creativity, add the license header to the file."
> >
> > In fact it would be difficult to state that the following file (for
> > example) does't contain "any degree of creativity":
> >
> > http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup
> >
> > In fact it contains useful documentation that was contributed by
> different
> > people who spent time crafting its content.
> >
> > When in doubt, we should add the license header (as stated in the
> document
> > that Jacques and I referenced); or we can omit it if we judge that the
> file
> > doesn't contain any degree of creativity.
> > But definitely we can't blindly decide by vote for all the files matching
> > a name (i.e. README) as proposed by Jacques in this vote.
> > Since deciding on a case by case may be tricky and even subjective, my
> > *personal* preference would be to add to all the files the license
> header.
> >
> > Kind regards,
> >
> > Jacopo
> >
> > [*] http://www.apache.org/legal/src-headers.html#faq-exceptions
> >
> >
> >
> >
> >
>

Re: [VOTE] ASL2 header in README files?

[Jacopo Cappellato]

Also, if I recall, it was initially decided to not include a license header
to the main README.md file in the root folder: however now that the file
represents an important part of the OFBiz documentation, I think we should
revisit that decision and add a license header to it.

Jacopo

On Fri, Sep 16, 2016 at 10:21 AM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Hi Devs,
>>
>> There are mixed opinions about putting or not the ASL2 header in OFBiz
>> README files.
>>
>> One one hand we can read at http://www.apache.org/legal/sr
>> c-headers.html#faq-exceptions that README files don't require a header
>>
>> But to protect our work we can decide to put a header in all README files
>> (with or w/o suffixes). It's all or none to be consistent.
>>
>> Since License is an important matter I think a vote is necessary to
>> define our policy.
>>
>> So please vote
>>
>> [+1] include a header in all README files
>>
>> [-1] do not include a header in any README files
>>
>> [0] Undecided
>>
>> I will close this vote in a week, thanks for your time !
>>
>> Jacques
>>
>>
> In my opinion this vote is not valid and should be cancelled.
> My reasoning is the following: the result of this vote may be against the
> ASF license policy and as a project we are not allowed to change the ASF
> license policy by vote. In fact our codebase is licensed by the ASF and not
> by OFBiz.
>
> Why am I saying that the result of this vote may be against the ASF
> license policy?
>
> If we decide to "not include a header in any README files" then we will
> violate the following [*]:
>
> "A file without any degree of creativity in either its literal elements
> or its structure is not protected by copyright law; therefore, such a file
> does not require a license header. If in doubt about the extent of the
> file's creativity, add the license header to the file."
>
> In fact it would be difficult to state that the following file (for
> example) does't contain "any degree of creativity":
>
> http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup
>
> In fact it contains useful documentation that was contributed by different
> people who spent time crafting its content.
>
> When in doubt, we should add the license header (as stated in the document
> that Jacques and I referenced); or we can omit it if we judge that the file
> doesn't contain any degree of creativity.
> But definitely we can't blindly decide by vote for all the files matching
> a name (i.e. README) as proposed by Jacques in this vote.
> Since deciding on a case by case may be tricky and even subjective, my
> *personal* preference would be to add to all the files the license header.
>
> Kind regards,
>
> Jacopo
>
> [*] http://www.apache.org/legal/src-headers.html#faq-exceptions
>
>
>
>
>

Re: [VOTE] ASL2 header in README files?

[Jacopo Cappellato]

On Fri, Sep 16, 2016 at 9:43 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Devs,
>
> There are mixed opinions about putting or not the ASL2 header in OFBiz
> README files.
>
> One one hand we can read at http://www.apache.org/legal/sr
> c-headers.html#faq-exceptions that README files don't require a header
>
> But to protect our work we can decide to put a header in all README files
> (with or w/o suffixes). It's all or none to be consistent.
>
> Since License is an important matter I think a vote is necessary to define
> our policy.
>
> So please vote
>
> [+1] include a header in all README files
>
> [-1] do not include a header in any README files
>
> [0] Undecided
>
> I will close this vote in a week, thanks for your time !
>
> Jacques
>
>
In my opinion this vote is not valid and should be cancelled.
My reasoning is the following: the result of this vote may be against the
ASF license policy and as a project we are not allowed to change the ASF
license policy by vote. In fact our codebase is licensed by the ASF and not
by OFBiz.

Why am I saying that the result of this vote may be against the ASF license
policy?

If we decide to "not include a header in any README files" then we will
violate the following [*]:

"A file without any degree of creativity in either its literal elements or
its structure is not protected by copyright law; therefore, such a file
does not require a license header. If in doubt about the extent of the
file's creativity, add the license header to the file."

In fact it would be difficult to state that the following file (for
example) does't contain "any degree of creativity":

http://svn.apache.org/viewvc/ofbiz/trunk/README.md?view=markup

In fact it contains useful documentation that was contributed by different
people who spent time crafting its content.

When in doubt, we should add the license header (as stated in the document
that Jacques and I referenced); or we can omit it if we judge that the file
doesn't contain any degree of creativity.
But definitely we can't blindly decide by vote for all the files matching a
name (i.e. README) as proposed by Jacques in this vote.
Since deciding on a case by case may be tricky and even subjective, my
*personal* preference would be to add to all the files the license header.

Kind regards,

Jacopo

[*] http://www.apache.org/legal/src-headers.html#faq-exceptions

Re: Guest Access Link for OFBiz HipChat Room

[Jacques Le Roux]

Pierre,

I plan to put it in the "Resources & Tools" section

What would you suggest as content text to explain the link?

Thanks

Jacques


Le 02/09/2016 à 10:45, Pierre Smits a écrit :

I suggest to put a link (button) on the home page of our site.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Sep 2, 2016 at 10:24 AM, Sharan Foga  wrote:


Hi Everyone

Please see below for the guest access link to the OFBiz HipChat room.

https://www.hipchat.com/g4vOayvmc

Thanks
Sharan

[VOTE] ASL2 header in README files?

[Jacques Le Roux]

Hi Devs,

There are mixed opinions about putting or not the ASL2 header in OFBiz README 
files.

One one hand we can read at 
http://www.apache.org/legal/src-headers.html#faq-exceptions that README files 
don't require a header

But to protect our work we can decide to put a header in all README files (with 
or w/o suffixes). It's all or none to be consistent.

Since License is an important matter I think a vote is necessary to define our 
policy.

So please vote

[+1] include a header in all README files

[-1] do not include a header in any README files

[0] Undecided

I will close this vote in a week, thanks for your time !

Jacques

Re: Removing the ecomclone webapp from the ecommerce component

[Michael Brohl]

+1

Michael

> Am 16.09.2016 um 05:55 schrieb Jacopo Cappellato 
> :
> 
> In the "ecommerce" component there are two web applications:
> - ecommerce: the actual web application
> - ecomclone: a clone of the above, that leverages the controller's
> "include" feature to extend the main web application
> For what I know the ecomclone webapp has been initially created to to test
> and provide an example of the "include" feature; since then the feature has
> been widely used and now essentially all the OFBiz applications make use of
> it (by including the common-controller.xml) or extending/overriding other
> applications.
> 
> My proposal is to remove ecomclone since it is no more needed.
> 
> Any objection or concerns?
> 
> Thanks,
> 
> Jacopo


smime.p7s
Description: S/MIME cryptographic signature

Re: Removing the ecomclone webapp from the ecommerce component

[Pierre Smits]

+1

Op vrijdag 16 september 2016 heeft Taher Alkhateeb <
slidingfilame...@gmail.com> het volgende geschreven:

> +1
>
> On Sep 16, 2016 7:52 AM, "Jacques Le Roux"  >
> wrote:
>
> > Le 16/09/2016 à 05:55, Jacopo Cappellato a écrit :
> >
> >> In the "ecommerce" component there are two web applications:
> >> - ecommerce: the actual web application
> >> - ecomclone: a clone of the above, that leverages the controller's
> >> "include" feature to extend the main web application
> >> For what I know the ecomclone webapp has been initially created to to
> test
> >> and provide an example of the "include" feature; since then the feature
> >> has
> >> been widely used and now essentially all the OFBiz applications make use
> >> of
> >> it (by including the common-controller.xml) or extending/overriding
> other
> >> applications.
> >>
> >> My proposal is to remove ecomclone since it is no more needed.
> >>
> >> Any objection or concerns?
> >>
> >> Thanks,
> >>
> >> Jacopo
> >>
> >> Actually there are 3 web applications with also ecomseo which uses the
> > include feature to leverage the ecommerce webapp by adding SEO friendly
> > URLs and other SEO aspects.
> > So I see no reasons to keep ecomclone since ecomseo demonstrates how to
> > use include, without any other request maps, like does ecomclone.
> > +1
> >
> > Jacques
> >
> >
>


-- 
Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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