date:20150424


[ 
https://issues.apache.org/jira/browse/OFBIZ-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510628#comment-14510628
 ] 

Nicolas Malin commented on OFBIZ-5169:
--

Thanks Jacopo I appreciate to have an other opinion.
I open the issue OFBIZ-6298 for that

 Removing Javolution from framework components
 -

 Key: OFBIZ-5169
 URL: https://issues.apache.org/jira/browse/OFBIZ-5169
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Varun Bhansaly
Priority: Minor
 Attachments: framework-FastList-removed.patch


 a. Remove static instances of Javolution objects.
 b. Remove other uses of Javolution objects.



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

[jira] [Commented] (OFBIZ-6298) Java collection use optimized


[ 
https://issues.apache.org/jira/browse/OFBIZ-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510624#comment-14510624
 ] 

Nicolas Malin commented on OFBIZ-6298:
--

{quote} 
[~deepak] : We should use the LinkedHashMap for controller pre/post processor 
eventLists (ConfigXMLReader.java:180) as HashMap does not maintain the 
iteration order. 
{quote}

 Java collection use optimized
 -

 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor
  Labels: collection, performance

 With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
 realize a second pass to control what instantiation would be better.
 For List between LinkedList, ArrayList
 {quote}
 Using ArrayList, rather than LinkedList, as a default is a good approach 
 because ArrayList will work better in most situations (in terms of 
 algorithmic runtimes and memory footprints).
 However I think it is important to wisely choose ArrayList or LinkedList 
 based on the context, because sometimes a linked list may be a better choice: 
 I am not saying we should do it now and we can tackle this at a later moment, 
 possibly focusing only on list that can be very big and analyzing their usage 
 to see if array or linked list is better; it would be also nice, when we use 
 ArrayList, to see if we can predict the capacity of the list and allocate it 
 at creation: if we can do this we will have a more predictable memory usage 
 and less unpredictable peaks under heavy load (when the array capacity is 
 reached and the array is copied to a new one with double capacity).
 {quote}
 more documentation on :
  * 
 https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
  * 
 http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist
 For Map between HashMap and LinkedHashMap :
 {quote}
 Javolution Map Iterators return items in insertion sequence (HashMap does 
 not), so any code relying on the original insertion order must use a 
 LinkedHashMap.
 {quote}
  * 
 http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap
 If you detect an optimization, please comments this issues



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

[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException

2015-04-24 Thread Gareth Carter (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510663#comment-14510663
 ] 

Gareth Carter commented on OFBIZ-6291:
--

What I have found is the cast to BigDecimal is fastest only if the object being 
cast is always BigDecimal, casting another object (eg java.lang.String) without 
type check (eg, catching and ignoring ClassCastException) is much slower. But 
these are in the nanosecond range of performance, hardly an argument to use one 
method or another. I just think it would be better to check for types rather 
than throwing an uncaught exception and not doing anything

I appreciate all committers are busy with life, work or other. This is a 
trivial issue, I don't believe this will have any functional impact, its just 
an improvement in code readability and follows better practices.

I still have reservations about compareBigDecimals but this is another issue to 
discuss somewhere else



 Update code to check for types rather than throw ClassCastException
 ---

 Key: OFBIZ-6291
 URL: https://issues.apache.org/jira/browse/OFBIZ-6291
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: LocalizedConverters.patch, minilang_compare.patch, 
 minilang_compare_r1675655.patch


 framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java
 framework/base/src/org/ofbiz/base/util/ObjectType.java
 framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java
 all throw ClassCastExceptions and are ignored instead of checking types
 This caused issues in debugging when adding a ClassCastException breakpoint



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

[jira] [Commented] (OFBIZ-6299) Field order is not correct in the auto-complete for look-ups.

2015-04-24 Thread Adrian Crum (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510749#comment-14510749
 ] 

Adrian Crum commented on OFBIZ-6299:


Please do not use Javolution classes in new contributions.

 Field order is not correct in the auto-complete for look-ups.
 -

 Key: OFBIZ-6299
 URL: https://issues.apache.org/jira/browse/OFBIZ-6299
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Francis Douet
Priority: Minor
  Labels: lookup
 Attachments: OFBIZ-6299.patch


 Field order is not correct in the auto-complete all look-ups, for example if 
 I set the searchFields as such:
 set field=searchFields value=[partyId, firstName, lastName]/
 The look-up auto-complete and tooltip will display the last name first.



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

[jira] [Updated] (OFBIZ-6299) Field order is not correct in the auto-complete for look-ups.


 [ 
https://issues.apache.org/jira/browse/OFBIZ-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Douet updated OFBIZ-6299:
-
Attachment: OFBIZ-6299.patch

 Field order is not correct in the auto-complete for look-ups.
 -

 Key: OFBIZ-6299
 URL: https://issues.apache.org/jira/browse/OFBIZ-6299
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Francis Douet
Priority: Minor
  Labels: lookup
 Attachments: OFBIZ-6299.patch


 Field order is not correct in the auto-complete all look-ups, for example if 
 I set the searchFields as such:
 set field=searchFields value=[partyId, firstName, lastName]/
 The look-up auto-complete and tooltip will display the last name first.



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

[jira] [Commented] (OFBIZ-6299) Field order is not correct in the auto-complete for look-ups.


[ 
https://issues.apache.org/jira/browse/OFBIZ-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510780#comment-14510780
 ] 

Francis Douet commented on OFBIZ-6299:
--

Sorry! I changed the patch.

 Field order is not correct in the auto-complete for look-ups.
 -

 Key: OFBIZ-6299
 URL: https://issues.apache.org/jira/browse/OFBIZ-6299
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Francis Douet
Priority: Minor
  Labels: lookup
 Attachments: OFBIZ-6299.patch


 Field order is not correct in the auto-complete all look-ups, for example if 
 I set the searchFields as such:
 set field=searchFields value=[partyId, firstName, lastName]/
 The look-up auto-complete and tooltip will display the last name first.



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

[jira] [Created] (OFBIZ-6299) Field order is not correct in the auto-complete for look-ups.

Francis Douet created OFBIZ-6299:


 Summary: Field order is not correct in the auto-complete for 
look-ups.
 Key: OFBIZ-6299
 URL: https://issues.apache.org/jira/browse/OFBIZ-6299
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Francis Douet
Priority: Minor


Field order is not correct in the auto-complete all look-ups, for example if I 
set the searchFields as such:
set field=searchFields value=[partyId, firstName, lastName]/
The look-up auto-complete and tooltip will display the last name first.



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

[jira] [Updated] (OFBIZ-6299) Field order is not correct in the auto-complete for look-ups.


 [ 
https://issues.apache.org/jira/browse/OFBIZ-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Douet updated OFBIZ-6299:
-
Attachment: OFBIZ-6299.patch

 Field order is not correct in the auto-complete for look-ups.
 -

 Key: OFBIZ-6299
 URL: https://issues.apache.org/jira/browse/OFBIZ-6299
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Francis Douet
Priority: Minor
  Labels: lookup
 Attachments: OFBIZ-6299.patch


 Field order is not correct in the auto-complete all look-ups, for example if 
 I set the searchFields as such:
 set field=searchFields value=[partyId, firstName, lastName]/
 The look-up auto-complete and tooltip will display the last name first.



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

[jira] [Updated] (OFBIZ-6299) Field order is not correct in the auto-complete for look-ups.


 [ 
https://issues.apache.org/jira/browse/OFBIZ-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Douet updated OFBIZ-6299:
-
Attachment: (was: OFBIZ-6299.patch)

 Field order is not correct in the auto-complete for look-ups.
 -

 Key: OFBIZ-6299
 URL: https://issues.apache.org/jira/browse/OFBIZ-6299
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Francis Douet
Priority: Minor
  Labels: lookup
 Attachments: OFBIZ-6299.patch


 Field order is not correct in the auto-complete all look-ups, for example if 
 I set the searchFields as such:
 set field=searchFields value=[partyId, firstName, lastName]/
 The look-up auto-complete and tooltip will display the last name first.



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

[jira] [Created] (OFBIZ-6298) Java collection use optimized

Nicolas Malin created OFBIZ-6298:


 Summary: Java collection use optimized
 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor


With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
realize a second pass to control what instantiation would be better.

For List between LinkedList, ArrayList
{quote}
Using ArrayList, rather than LinkedList, as a default is a good approach 
because ArrayList will work better in most situations (in terms of algorithmic 
runtimes and memory footprints).
However I think it is important to wisely choose ArrayList or LinkedList based 
on the context, because sometimes a linked list may be a better choice: I am 
not saying we should do it now and we can tackle this at a later moment, 
possibly focusing only on list that can be very big and analyzing their usage 
to see if array or linked list is better; it would be also nice, when we use 
ArrayList, to see if we can predict the capacity of the list and allocate it at 
creation: if we can do this we will have a more predictable memory usage and 
less unpredictable peaks under heavy load (when the array capacity is reached 
and the array is copied to a new one with double capacity).
{quote}
more documentation on :
 * https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
 * 
http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist

For Map between HashMap and LinkedHashMap :
{quote}
Javolution Map Iterators return items in insertion sequence (HashMap does not), 
so any code relying on the original insertion order must use a LinkedHashMap.
{quote}

 * 
http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap

If you detect an optimization, please comments this issues



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

[jira] [Commented] (OFBIZ-6298) Java collection use optimized

2015-04-24 Thread Deepak Dixit (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510632#comment-14510632
 ] 

Deepak Dixit commented on OFBIZ-6298:
-

Hi Nicolas,

Its [~deepak.dixit] :)

 Java collection use optimized
 -

 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor
  Labels: collection, performance

 With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
 realize a second pass to control what instantiation would be better.
 For List between LinkedList, ArrayList
 {quote}
 Using ArrayList, rather than LinkedList, as a default is a good approach 
 because ArrayList will work better in most situations (in terms of 
 algorithmic runtimes and memory footprints).
 However I think it is important to wisely choose ArrayList or LinkedList 
 based on the context, because sometimes a linked list may be a better choice: 
 I am not saying we should do it now and we can tackle this at a later moment, 
 possibly focusing only on list that can be very big and analyzing their usage 
 to see if array or linked list is better; it would be also nice, when we use 
 ArrayList, to see if we can predict the capacity of the list and allocate it 
 at creation: if we can do this we will have a more predictable memory usage 
 and less unpredictable peaks under heavy load (when the array capacity is 
 reached and the array is copied to a new one with double capacity).
 {quote}
 more documentation on :
  * 
 https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
  * 
 http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist
 For Map between HashMap and LinkedHashMap :
 {quote}
 Javolution Map Iterators return items in insertion sequence (HashMap does 
 not), so any code relying on the original insertion order must use a 
 LinkedHashMap.
 {quote}
  * 
 http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap
 If you detect an optimization, please comments this issues



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

[jira] [Assigned] (OFBIZ-6299) Field order is not correct in the auto-complete for look-ups.


 [ 
https://issues.apache.org/jira/browse/OFBIZ-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Malin reassigned OFBIZ-6299:


Assignee: Nicolas Malin

 Field order is not correct in the auto-complete for look-ups.
 -

 Key: OFBIZ-6299
 URL: https://issues.apache.org/jira/browse/OFBIZ-6299
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Francis Douet
Assignee: Nicolas Malin
Priority: Minor
  Labels: lookup
 Attachments: OFBIZ-6299.patch


 Field order is not correct in the auto-complete all look-ups, for example if 
 I set the searchFields as such:
 set field=searchFields value=[partyId, firstName, lastName]/
 The look-up auto-complete and tooltip will display the last name first.



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

[jira] [Comment Edited] (OFBIZ-6298) Java collection use optimized


[ 
https://issues.apache.org/jira/browse/OFBIZ-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510624#comment-14510624
 ] 

Nicolas Malin edited comment on OFBIZ-6298 at 4/24/15 8:17 AM:
---

{quote} 
[~deepak.dixit] : We should use the LinkedHashMap for controller pre/post 
processor eventLists (ConfigXMLReader.java:180) as HashMap does not maintain 
the iteration order. 
{quote}


was (Author: soledad):
{quote} 
[~deepak] : We should use the LinkedHashMap for controller pre/post processor 
eventLists (ConfigXMLReader.java:180) as HashMap does not maintain the 
iteration order. 
{quote}

 Java collection use optimized
 -

 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor
  Labels: collection, performance

 With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
 realize a second pass to control what instantiation would be better.
 For List between LinkedList, ArrayList
 {quote}
 Using ArrayList, rather than LinkedList, as a default is a good approach 
 because ArrayList will work better in most situations (in terms of 
 algorithmic runtimes and memory footprints).
 However I think it is important to wisely choose ArrayList or LinkedList 
 based on the context, because sometimes a linked list may be a better choice: 
 I am not saying we should do it now and we can tackle this at a later moment, 
 possibly focusing only on list that can be very big and analyzing their usage 
 to see if array or linked list is better; it would be also nice, when we use 
 ArrayList, to see if we can predict the capacity of the list and allocate it 
 at creation: if we can do this we will have a more predictable memory usage 
 and less unpredictable peaks under heavy load (when the array capacity is 
 reached and the array is copied to a new one with double capacity).
 {quote}
 more documentation on :
  * 
 https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
  * 
 http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist
 For Map between HashMap and LinkedHashMap :
 {quote}
 Javolution Map Iterators return items in insertion sequence (HashMap does 
 not), so any code relying on the original insertion order must use a 
 LinkedHashMap.
 {quote}
  * 
 http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap
 If you detect an optimization, please comments this issues



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

[jira] [Commented] (OFBIZ-6298) Java collection use optimized


[ 
https://issues.apache.org/jira/browse/OFBIZ-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510635#comment-14510635
 ] 

Nicolas Malin commented on OFBIZ-6298:
--

Arff, sorry 

 Java collection use optimized
 -

 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor
  Labels: collection, performance

 With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
 realize a second pass to control what instantiation would be better.
 For List between LinkedList, ArrayList
 {quote}
 Using ArrayList, rather than LinkedList, as a default is a good approach 
 because ArrayList will work better in most situations (in terms of 
 algorithmic runtimes and memory footprints).
 However I think it is important to wisely choose ArrayList or LinkedList 
 based on the context, because sometimes a linked list may be a better choice: 
 I am not saying we should do it now and we can tackle this at a later moment, 
 possibly focusing only on list that can be very big and analyzing their usage 
 to see if array or linked list is better; it would be also nice, when we use 
 ArrayList, to see if we can predict the capacity of the list and allocate it 
 at creation: if we can do this we will have a more predictable memory usage 
 and less unpredictable peaks under heavy load (when the array capacity is 
 reached and the array is copied to a new one with double capacity).
 {quote}
 more documentation on :
  * 
 https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
  * 
 http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist
 For Map between HashMap and LinkedHashMap :
 {quote}
 Javolution Map Iterators return items in insertion sequence (HashMap does 
 not), so any code relying on the original insertion order must use a 
 LinkedHashMap.
 {quote}
  * 
 http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap
 If you detect an optimization, please comments this issues



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

[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException

2015-04-24 Thread Adrian Crum (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510685#comment-14510685
 ] 

Adrian Crum commented on OFBIZ-6291:


Mini-language is a scripting language. One of the nice things about scripting 
languages is you can compare things like decimal values without worrying about 
the underlying implementation. That is what the current implementation does: 2 
== 2.0 == 2.00.

If we were to compare BigDecimal precision, then we lose the scripting 
abstraction, PLUS pretty much everything that uses Mini-language will break.

If you need to compare BigDecimal precision, then you can use a scriptlet: 
groovy:fooBigDecimal.equals(barBigDecimal).


 Update code to check for types rather than throw ClassCastException
 ---

 Key: OFBIZ-6291
 URL: https://issues.apache.org/jira/browse/OFBIZ-6291
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: LocalizedConverters.patch, minilang_compare.patch, 
 minilang_compare_r1675655.patch


 framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java
 framework/base/src/org/ofbiz/base/util/ObjectType.java
 framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java
 all throw ClassCastExceptions and are ignored instead of checking types
 This caused issues in debugging when adding a ClassCastException breakpoint



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

[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException

2015-04-24 Thread Gareth Carter (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510829#comment-14510829
 ] 

Gareth Carter commented on OFBIZ-6291:
--

What about comparing 2.001 and 2.0001? Lets say both numbers are BigDecimal in 
both groovy and minilang. 
In groovy, == is false, compareTo() is 1 and equals() is false.
In minilang, if 'if-compare-field' type is set to BigDecimal, the result is 
true because compareBigDecimals sets the scale to the smallest scale and rounds 
up, in this instance 2.0001 will result in 2.001 and compareTo equals 0.

Why is this done in minilang and no where else?
Is this correct? Condidering the same value in another type float/double/string 
would be false?
What about com.ibm.icu.math.BigDecimal?

On further investigation, I doubt this will affect much in minilang considering 
the default conversion type on if-compare and if-compare-field is String so 
compareBigDecimals would only be called when type=BigDecimal

eg:
if-compare-field operator=equals field=d1 to-field=e1 type=BigDecimal
/if-compare-field

 Update code to check for types rather than throw ClassCastException
 ---

 Key: OFBIZ-6291
 URL: https://issues.apache.org/jira/browse/OFBIZ-6291
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: LocalizedConverters.patch, minilang_compare.patch, 
 minilang_compare_r1675655.patch


 framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java
 framework/base/src/org/ofbiz/base/util/ObjectType.java
 framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java
 all throw ClassCastExceptions and are ignored instead of checking types
 This caused issues in debugging when adding a ClassCastException breakpoint



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

[jira] [Commented] (OFBIZ-6298) Java collection use optimized

2015-04-24 Thread Ron Wheeler (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510954#comment-14510954
 ] 

Ron Wheeler commented on OFBIZ-6298:


Since Java 7 is coming to EOL, this might be a good time to consider how the 
Java 8 Stream processing will be used under the various scenarios being 
discussed around the choice of underlying collection structure.

This also affects some of the performance discussion since Streams take 
advantage of multi-core CPUs to process collections in parallel.


 Java collection use optimized
 -

 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor
  Labels: collection, performance

 With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
 realize a second pass to control what instantiation would be better.
 For List between LinkedList, ArrayList
 {quote}
 Using ArrayList, rather than LinkedList, as a default is a good approach 
 because ArrayList will work better in most situations (in terms of 
 algorithmic runtimes and memory footprints).
 However I think it is important to wisely choose ArrayList or LinkedList 
 based on the context, because sometimes a linked list may be a better choice: 
 I am not saying we should do it now and we can tackle this at a later moment, 
 possibly focusing only on list that can be very big and analyzing their usage 
 to see if array or linked list is better; it would be also nice, when we use 
 ArrayList, to see if we can predict the capacity of the list and allocate it 
 at creation: if we can do this we will have a more predictable memory usage 
 and less unpredictable peaks under heavy load (when the array capacity is 
 reached and the array is copied to a new one with double capacity).
 {quote}
 more documentation on :
  * 
 https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
  * 
 http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist
 For Map between HashMap and LinkedHashMap :
 {quote}
 Javolution Map Iterators return items in insertion sequence (HashMap does 
 not), so any code relying on the original insertion order must use a 
 LinkedHashMap.
 {quote}
  * 
 http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap
 If you detect an optimization, please comments this issues



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

[jira] [Commented] (OFBIZ-6298) Java collection use optimized


[ 
https://issues.apache.org/jira/browse/OFBIZ-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511096#comment-14511096
 ] 

Nicolas Malin commented on OFBIZ-6298:
--

Interesting, Ron can you give a link for doc and example ?
Do you have a concrete example to use in OFBiz ?


 Java collection use optimized
 -

 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor
  Labels: collection, performance

 With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
 realize a second pass to control what instantiation would be better.
 For List between LinkedList, ArrayList
 {quote}
 Using ArrayList, rather than LinkedList, as a default is a good approach 
 because ArrayList will work better in most situations (in terms of 
 algorithmic runtimes and memory footprints).
 However I think it is important to wisely choose ArrayList or LinkedList 
 based on the context, because sometimes a linked list may be a better choice: 
 I am not saying we should do it now and we can tackle this at a later moment, 
 possibly focusing only on list that can be very big and analyzing their usage 
 to see if array or linked list is better; it would be also nice, when we use 
 ArrayList, to see if we can predict the capacity of the list and allocate it 
 at creation: if we can do this we will have a more predictable memory usage 
 and less unpredictable peaks under heavy load (when the array capacity is 
 reached and the array is copied to a new one with double capacity).
 {quote}
 more documentation on :
  * 
 https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
  * 
 http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist
 For Map between HashMap and LinkedHashMap :
 {quote}
 Javolution Map Iterators return items in insertion sequence (HashMap does 
 not), so any code relying on the original insertion order must use a 
 LinkedHashMap.
 {quote}
  * 
 http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap
 If you detect an optimization, please comments this issues



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

Maven and Git providing build into at run-time

An interesting article about how git and Maven can be used to 
automatically make the build revision and other info available at 
run-time for logging or display in an About display.


http://www.petrikainulainen.net/programming/spring-framework/spring-from-the-trenches-returning-git-commit-information-as-json/

Not a compelling reason to move to Maven or git but a nice addition to 
OFBiz to make support and bug reporting a bit easier.


Also just a nice bit of reading if you enjoy reading about clever 
programming.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Maven short intro


For anyone who has never used Maven, here is a short introduction.

Maven essentials for the impatient developer
https://vaadin.com/blog/-/blogs/the-maven-essentials-for-the-impatient-developer

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

[jira] [Commented] (OFBIZ-5169) Removing Javolution from framework components


[ 
https://issues.apache.org/jira/browse/OFBIZ-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511170#comment-14511170
 ] 

Martin Becker commented on OFBIZ-5169:
--

Well, my intention is to overall switch the now used LinkedList to ArrayList, 
as it is the more proper default with a light performance drawback in rare 
cases, if at all, and to be in line with the types used in groovy scripts. No 
functional drawback compared to FastList is to be expected (in contrast to 
HashMap/HashSet, if preserving the insert-order for iteration is a requirement).

That would be a good starting point for detailed analysis and changes in the 
scope of [OFBIZ-6298], to optimize the use of collection types, also this will 
be a very exhausting activity over thousands of code places with very small 
expectable benefits in real world performance.


 Removing Javolution from framework components
 -

 Key: OFBIZ-5169
 URL: https://issues.apache.org/jira/browse/OFBIZ-5169
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Varun Bhansaly
Priority: Minor
 Attachments: framework-FastList-removed.patch


 a. Remove static instances of Javolution objects.
 b. Remove other uses of Javolution objects.



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

Re: Maven and Git providing build into at run-time

The key thing to me is that if a person reports a bug with the product 
identification on the screen or sends a log, can you find the version of 
the code that was used to build their application.


Ron

On 24/04/2015 10:39 AM, Adam Heath wrote:


On 04/24/2015 07:45 AM, Ron Wheeler wrote:
An interesting article about how git and Maven can be used to 
automatically make the build revision and other info available at 
run-time for logging or display in an About display.




The top-level build.xml has a rule to update the svn build revision; 
this number is monotomically increasing.  A git based $revhash isn't, 
so there's a little bit of information lost there.  But I think that's 
minor.


http://www.petrikainulainen.net/programming/spring-framework/spring-from-the-trenches-returning-git-commit-information-as-json/ 



Not a compelling reason to move to Maven or git but a nice addition 
to OFBiz to make support and bug reporting a bit easier.


Also just a nice bit of reading if you enjoy reading about clever 
programming.


Ron







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: move to git.



On 04/23/2015 06:00 PM, David E. Jones wrote:

An FYI for all committers: create an account on GitHub (if you don't already 
have one) and add your @apache.org email address to it, and within a few hours 
you'll show up in the contributor graphs. I tried this and am now showing up 
there:

https://github.com/apache/ofbiz/graphs/contributors

If nothing else it's entertaining, I had no idea that I had this volume of 
commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note 
that changes to lines show up in both counts).


Come on, everyone.  It's a competition!  See if you can beat Jacopo!

Useless metrics are fun sometimes.  Number of commits, number of lines 
added/removed, don't really mean anything.  I've seen stupid code that 
had the same 30 lines cut and pasted 20 times, instead of making a 
helper method, and of course a single line per commit can also inflate 
numbers.


But, it's fun to play with gui graph libraries.

[jira] [Assigned] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8

2015-04-24 Thread Adam Heath (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Heath reassigned OFBIZ-6300:
-

Assignee: Adam Heath

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath

 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

Re: Proposal: redefining the components' directory layout for source files

+0.5 (see below, comment inline)

Yes, I agree. I even have a way forward, if you've been paying
attention to the maven branch(OFBIZ-6271).

I have maven working with the *existing* layout in ofbiz. My plan for
migration has been this:

* Get maven working with existing structure. Ie, maven can compile all
the code, can create all the jars, basically, it can do everything that
the build.xml files do. This is a little tricky, as the top-level
build.xml contains several custom targets; I'll probably just use the
antrun plugin for these.

* Add top-level properties in ofbiz-parent.pom, that define all the
folders we might need to move; update ofbiz-component-pom.xml to use
these variables.

* Switch each component one at a time, setting variables in the local
pom.xml(s) with the new location. Each one of these should be a
separate commit.

* Announce(!)

* ??? Profit?

ps: The standard maven test hooks do *not* run coverage against code
compiled by the test phase. Aka, there is no way to know if src/test/*
is getting correct coverage. I think I can fix this, as we really
should verify not only the baseline code, but the testing code, for
correctness.

On 04/23/2015 10:42 PM, Scott Gray wrote:

Regards
Scott

On 21 January 2015 at 00:41, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com wrote:

In my opinion it would be nice to review how we organize the code in our
components and switch to a directory layout that is more inline with what
other projects are doing, for example:

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

More specifically I would like to switch from, for example:

script/org/ofbiz/product/
src/org/ofbiz/product/
src/org/ofbiz/product/test/

to:

src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/

Altho, actually, I think this layout is because maven is stupid, and the
plugins and fileset api does not allow for different type files in
different folders. Aka, the groovyc and javac hooks have a hard time
compiling .groovy and .java when they exist together in src/, so maven
authors decided to split them into src/*/groovy and src/*/java.

I haven't yet gotten to integrating a groovy compiler plugin, I see only
one .groovy in framework/service/src, for the entire project.

java 1.8 features: Re: [jira] [Commented] (OFBIZ-6298) Java collection use optimized

Not putting this into the jira issue, as it's not related, but with java 
1.8, construction of generic objects is nicer.


==
MapString, ListMapString, Object myVar = new HashMap();
==

Re: Proposal: redefining the components' directory layout for source files

2015-04-24 Thread Jacopo Cappellato

On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote:

 src/main/java/org/ofbiz/product/
 src/main/minilang/org/ofbiz/product/
 src/main/groovy/...
 src/test/java/org/ofbiz/product/
 
 I haven't yet gotten to integrating a groovy compiler plugin, I see only one 
 .groovy in framework/service/src, for the entire project.

When I proposed this I was also thinking about to move the groovy (data 
preparation) scripts that are currently under WEB-INF/actions folders; most of 
them could be used in non web applications.

Jacopo

[jira] [Commented] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8


[ 
https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511232#comment-14511232
 ] 

Martin Becker commented on OFBIZ-6300:
--

1.8 compile target top-level issue sounds good, currently (after applying my 
patch) there should only be warnings. The patched issue in EntityFieldMap was 
the only error I got.

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath
 Attachments: OFBIZ-6300-EntityFieldMap.patch


 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

Re: Maven and Git providing build into at run-time



On 04/24/2015 07:45 AM, Ron Wheeler wrote:
An interesting article about how git and Maven can be used to 
automatically make the build revision and other info available at 
run-time for logging or display in an About display.




The top-level build.xml has a rule to update the svn build revision; 
this number is monotomically increasing.  A git based $revhash isn't, so 
there's a little bit of information lost there.  But I think that's minor.


http://www.petrikainulainen.net/programming/spring-framework/spring-from-the-trenches-returning-git-commit-information-as-json/ 



Not a compelling reason to move to Maven or git but a nice addition to 
OFBiz to make support and bug reporting a bit easier.


Also just a nice bit of reading if you enjoy reading about clever 
programming.


Ron

[jira] [Commented] (OFBIZ-6298) Java collection use optimized

2015-04-24 Thread Ron Wheeler (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511179#comment-14511179
 ] 

Ron Wheeler commented on OFBIZ-6298:


http://winterbe.com/posts/2014/07/31/java8-stream-tutorial-examples/ is one 
tutorial.
If you google java stream tutorial you will find lots of entries.

I am not sure how collections are used in OFBiz but there was some talk of 
using a factory to encapsulate creation of collections. 
There may be a case for providing high level functions that encapsulate some 
operations on collections using streams as part of the classes delivered by the 
factory.
If you combine this with the new Java 8 ability to add code to interfaces, 
there may be some interesting possibilities to reduce the amount of code 
required in OFBIz and to hide some of the complexity of dealing with the myriad 
of OFBiz entities. The classes produced by the factory would share the same 
interface but have some methods overridden in the classes to provide the class 
specific behaviour.

I have started to use Streams in other applications that I have written and 
they do reduce the amount of code required. 
They do lock you into Java 8 but so does Oracle's short term view of Java 7- 
OES this year. 
I have only started to look at rewriting some of the interfaces in my 
applications to add default methods to the interfaces. This has a lot of 
potential for my application since it has a lot of classes that share 
processing patterns to implement plug-ins that are configured at runtime using 
Spring. It seems to have the potential to make creation of custom plug-ins a 
lot easier since a new plug-in might only have to override one or two methods 
to implement new functionality.
I would be surprised if this did not apply to OFBiz as well since many business 
processes have similar flows but require some special processing for different 
entities within the same family. 
The ability to pass methods as arguments also should help in these cases as 
well.  

If there is an effort to look at collections, it seems that it would be a good 
time to look at Java 8 since the whole nature of collections is changed and 
Java 8 does optimization that is not possible in Java 7 without adding a lot of 
complexity (parallel processing with multi-core optimization).

 Java collection use optimized
 -

 Key: OFBIZ-6298
 URL: https://issues.apache.org/jira/browse/OFBIZ-6298
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor
  Labels: collection, performance

 With the javolution collection cleaning (OFBIZ-5169,OFBIZ-5781) , we need to 
 realize a second pass to control what instantiation would be better.
 For List between LinkedList, ArrayList
 {quote}
 Using ArrayList, rather than LinkedList, as a default is a good approach 
 because ArrayList will work better in most situations (in terms of 
 algorithmic runtimes and memory footprints).
 However I think it is important to wisely choose ArrayList or LinkedList 
 based on the context, because sometimes a linked list may be a better choice: 
 I am not saying we should do it now and we can tackle this at a later moment, 
 possibly focusing only on list that can be very big and analyzing their usage 
 to see if array or linked list is better; it would be also nice, when we use 
 ArrayList, to see if we can predict the capacity of the list and allocate it 
 at creation: if we can do this we will have a more predictable memory usage 
 and less unpredictable peaks under heavy load (when the array capacity is 
 reached and the array is copied to a new one with double capacity).
 {quote}
 more documentation on :
  * 
 https://docs.oracle.com/javase/tutorial/collections/implementations/list.html
  * 
 http://stackoverflow.com/questions/322715/when-to-use-linkedlist-over-arraylist
 For Map between HashMap and LinkedHashMap :
 {quote}
 Javolution Map Iterators return items in insertion sequence (HashMap does 
 not), so any code relying on the original insertion order must use a 
 LinkedHashMap.
 {quote}
  * 
 http://stackoverflow.com/questions/2889777/difference-between-hashmap-linkedhashmap-and-treemap
 If you detect an optimization, please comments this issues



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

Re: Proposal: redefining the components' directory layout for source files

+1
Looks like Adam has the right approach.

Ron
On 24/04/2015 10:36 AM, Adam Heath wrote:

+0.5 (see below, comment inline)

Yes, I agree. I even have a way forward, if you've been paying
attention to the maven branch(OFBIZ-6271).

I have maven working with the *existing* layout in ofbiz. My plan for
migration has been this:

* Get maven working with existing structure. Ie, maven can compile
all the code, can create all the jars, basically, it can do everything
that the build.xml files do. This is a little tricky, as the
top-level build.xml contains several custom targets; I'll probably
just use the antrun plugin for these.

* Add top-level properties in ofbiz-parent.pom, that define all the
folders we might need to move; update ofbiz-component-pom.xml to use
these variables.

* Switch each component one at a time, setting variables in the local
pom.xml(s) with the new location. Each one of these should be a
separate commit.

* Announce(!)

* ??? Profit?

ps: The standard maven test hooks do *not* run coverage against code
compiled by the test phase. Aka, there is no way to know if
src/test/* is getting correct coverage. I think I can fix this, as we
really should verify not only the baseline code, but the testing code,
for correctness.

On 04/23/2015 10:42 PM, Scott Gray wrote:

Regards
Scott

On 21 January 2015 at 00:41, Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com wrote:

In my opinion it would be nice to review how we organize the code in
our
components and switch to a directory layout that is more inline with
what

other projects are doing, for example:

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

More specifically I would like to switch from, for example:

script/org/ofbiz/product/
src/org/ofbiz/product/
src/org/ofbiz/product/test/

to:

src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/

Altho, actually, I think this layout is because maven is stupid, and
the plugins and fileset api does not allow for different type files in
different folders. Aka, the groovyc and javac hooks have a hard time
compiling .groovy and .java when they exist together in src/, so maven
authors decided to split them into src/*/groovy and src/*/java.

I haven't yet gotten to integrating a groovy compiler plugin, I see
only one .groovy in framework/service/src, for the entire project.

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files


Still +1 !
Ron
On 24/04/2015 11:12 AM, Adam Heath wrote:


On 04/24/2015 10:05 AM, Ron Wheeler wrote:

+1
Looks like Adam has the right approach.



Thanks.

However, I'm thinking of adding a few steps.  See below.


Ron
On 24/04/2015 10:36 AM, Adam Heath wrote:

+0.5 (see below, comment inline)

Yes, I agree.  I even have a way forward, if you've been paying 
attention to the maven branch(OFBIZ-6271).


I have maven working with the *existing* layout in ofbiz. My plan 
for migration has been this:


* Get maven working with existing structure.  Ie, maven can compile 
all the code, can create all the jars, basically, it can do 
everything that the build.xml files do.  This is a little tricky, as 
the top-level build.xml contains several custom targets; I'll 
probably just use the antrun plugin for these.


* Add top-level properties in ofbiz-parent.pom, that define all the 
folders we might need to move; update ofbiz-component-pom.xml to use 
these variables.




* Add top-level properties in common.xml(and/or macros.xml), same as 
maven/pom.


* Switch each component one at a time, setting variables in the 
local pom.xml(s) with the new location.  Each one of these should be 
a separate commit.




* Do this to each component's build.xml as well.  This change should 
be part of the commit above.



* Announce(!)

* ??? Profit?

ps: The standard maven test hooks do *not* run coverage against code 
compiled by the test phase.  Aka, there is no way to know if 
src/test/* is getting correct coverage.  I think I can fix this, as 
we really should verify not only the baseline code, but the testing 
code, for correctness.








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal: redefining the components' directory layout for source files



On 04/24/2015 10:05 AM, Ron Wheeler wrote:

+1
Looks like Adam has the right approach.



Thanks.

However, I'm thinking of adding a few steps.  See below.


Ron
On 24/04/2015 10:36 AM, Adam Heath wrote:

+0.5 (see below, comment inline)

Yes, I agree.  I even have a way forward, if you've been paying 
attention to the maven branch(OFBIZ-6271).


I have maven working with the *existing* layout in ofbiz. My plan for 
migration has been this:


* Get maven working with existing structure.  Ie, maven can compile 
all the code, can create all the jars, basically, it can do 
everything that the build.xml files do.  This is a little tricky, as 
the top-level build.xml contains several custom targets; I'll 
probably just use the antrun plugin for these.


* Add top-level properties in ofbiz-parent.pom, that define all the 
folders we might need to move; update ofbiz-component-pom.xml to use 
these variables.




* Add top-level properties in common.xml(and/or macros.xml), same as 
maven/pom.


* Switch each component one at a time, setting variables in the local 
pom.xml(s) with the new location.  Each one of these should be a 
separate commit.




* Do this to each component's build.xml as well.  This change should be 
part of the commit above.



* Announce(!)

* ??? Profit?

ps: The standard maven test hooks do *not* run coverage against code 
compiled by the test phase.  Aka, there is no way to know if 
src/test/* is getting correct coverage.  I think I can fix this, as 
we really should verify not only the baseline code, but the testing 
code, for correctness.

[jira] [Commented] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8

2015-04-24 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511204#comment-14511204
 ] 

Adam Heath commented on OFBIZ-6300:
---

I have been getting additional generics warnings when using 1.8 to compile in 
1.7 mode; I'm not surprised if there are actual errors in 1.8 mode as well.

I had been meaning to create a 1.8 compile target top-level issue, but hadn't 
yet gotten to it.  So, before the patch promised is accepted, I'd like to 
create a top-level catch-all, and link this into it, maybe.

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath

 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

[jira] [Updated] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8


 [ 
https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Becker updated OFBIZ-6300:
-
Attachment: OFBIZ-6300-EntityFieldMap.patch

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath
 Attachments: OFBIZ-6300-EntityFieldMap.patch


 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

Re: Proposal: redefining the components' directory layout for source files

2015-04-24 Thread Adrian Crum


+1

OFBiz stopped following J2EE patterns years ago, so we might as well 
make it official.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/24/2015 3:57 PM, Jacopo Cappellato wrote:

On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote:


src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/


I haven't yet gotten to integrating a groovy compiler plugin, I see only one 
.groovy in framework/service/src, for the entire project.


When I proposed this I was also thinking about to move the groovy (data 
preparation) scripts that are currently under WEB-INF/actions folders; most of 
them could be used in non web applications.

Jacopo

Re: Proposal: redefining the components' directory layout for source files



On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:

On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote:


src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/

I haven't yet gotten to integrating a groovy compiler plugin, I see only one 
.groovy in framework/service/src, for the entire project.

When I proposed this I was also thinking about to move the groovy (data 
preparation) scripts that are currently under WEB-INF/actions folders; most of 
them could be used in non web applications.


Hmm, right.  Good idea.  We(Brainfood) would love it if all the action 
code was turned into services.  But, even in that case, src/main/scripts 
would be used, as I think src/main/groovy is for groovyc.  I'll find out 
today if that is the case.

[jira] [Created] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8

Martin Becker created OFBIZ-6300:


 Summary: Compiler-Error with JDK 1.8 and source compatibility 1.8
 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker


I just found another error compiling the code with JDK 1.8 with source code 
compatibility switched to 1.8 in my eclipse workspace. The external ant build 
is working because there is java version 1.7 defined as target in the 
macros.xml.

The error is an issue regarding generics in EntityFieldMap.java.

I will provide a patch her soon.

The code is the same in the release branches.



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

Re: Proposal: redefining the components' directory layout for source files

2015-04-24 Thread Divesh Dutta

Thanks for detailed advantages of going with this approach. My +1 for going
with this approach.

Thanks
--
Divesh Dutta

On Wed, Jan 21, 2015 at 2:36 PM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 On Jan 20, 2015, at 1:49 PM, Jacques Le Roux jacques.le.r...@les7arts.com
 wrote:

  Have you a clear idea of that this entails in term of migration, no only
 OOTB, but for custom projects which relies on trunk?

 I did some reasonings about it and it shouldn't be a big deal, especially
 on the programming side (it will require mostly search and replace
 sessions); of course I didn't do a thorough analysis, I just wanted to
 start the conversation here; the good news is that it can be done in
 chunks, hopefully with the help of the community (that could also support
 the migration of custom projects).

  I guess for Java it should not be so hard but for minilang and groovy
 could be harder, everybody does not use Idea (groovy part)...

 I am sorry but the above sentence doesn't make any sense to me...

 
  Also what does this bring to the project? Why do you want to do so
 (apart being in line with other projects)? And why should we be in line
 with them, do you envision something?

 The main advantages are the following:

 1) standardize our layout structure to make it consistent with other
 projects (may make it easier for a new developer to understand OFBiz and
 appreciate it since the beginning)
 2) review of past decision in light of the experience, lessons learned and
 established conventions: most of the decision we took for the project were
 optimal at that time but may be suboptimal in light of new technologies,
 standards, trends etc... in order for our (more than 10 years old) project
 to stay fresh and healthy we have to always revisit our decisions and keep
 it young; when the first objection to proposals is that this could impact
 custom projects or existing contributors, then in my opinion it is a sign
 of defensive mentality that could bring to staleness; these concerns and
 considerations are still important, but should be discussed (trying to
 propose a good migration plan) at a later point and not used to slow down
 or stop the change
 3) simplify the pre compilation of Groovy (and possibly other) scripts:
 this could be done to spot coding errors in advance, to improve performance
 at runtime, or just to simplify the deployment
 4) simplify our build scripts: right now the ant scripts do some
 funny/complex stuff in order to separate test classes from main ones
 5) moving a step forward in the direction of allowing the adoption of
 Maven like tools (Maven, Gradle etc..) that could make it easier to share
 external components (grow the ecosystem)
 6) right now there is not a standard place for non-Java services or
 events: the script folder is traditionally used for Minilang, where should
 Groovy (or other languages) service implementation live?
 7) I have some, longer term, plans to make the OFBiz framework codebase
 more modular: several smaller jars with clear dependencies that could be
 deployed in different ways (vs the monolithic approach we have to follow
 now); a standardization of the source folders may help the adoption of
 tools and strategies for achieving this

 Regards,

 Jacopo

 
  Jacques
 
  Le 20/01/2015 12:41, Jacopo Cappellato a écrit :
  In my opinion it would be nice to review how we organize the code in
 our components and switch to a directory layout that is more inline with
 what other projects are doing, for example:
 
 
 http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
 
  More specifically I would like to switch from, for example:
 
  script/org/ofbiz/product/
  src/org/ofbiz/product/
  src/org/ofbiz/product/test/
 
  to:
 
  src/main/java/org/ofbiz/product/
  src/main/minilang/org/ofbiz/product/
  src/main/groovy/...
  src/test/java/org/ofbiz/product/
 
  What do you think?
 
  Jacopo

[jira] [Updated] (OFBIZ-5400) Improve order application to better handle complex ship groups

[
https://issues.apache.org/jira/browse/OFBIZ-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christian Carlow updated OFBIZ-5400:

Attachment: OFBIZ-5400.patch

The new patch obsoletes the old ones. I realize there are a lot of changes but
its starting point from which smaller patches may be extracted later.

The shopping cart app was extended with a new tab that allows ship groups to be
managed more easily and allows for them to be setup before any items are added.

The item adding form was also extended to list quantity fields for each ship
group that exists and passes them along with their corresponding lineName
fields (OFBIZ-6056) to ShoppingCartItem.setQuantity() which was modified to
accept a map associating item quantities to ship groups.

OFBIZ-6295 is also resolved by the patch with newly added
ShoppingCart.checkShippingRules() since it is more likely to occur with the new
functionality.

Improve order application to better handle complex ship groups
--

Key: OFBIZ-5400
URL: https://issues.apache.org/jira/browse/OFBIZ-5400
Project: OFBiz
Issue Type: Improvement
Components: order
Affects Versions: Trunk
Reporter: Christian Carlow
Assignee: Jacques Le Roux
Attachments: OFBIZ-5400.patch, OFBIZ-5400.patch, OFBIZ-5400_0.patch

The order entry form should be improved to better handle orders with complex
shipments. Its difficult to use the current order entry forms for entering
ship group information when dealing with 10 or more ship groups with
different destinations, carriers, shipment methods, and dates.
Improvements should include:
1. Allow ship groups to be edited even if the cart is empty
2. Allow the address, carrier shipment method, and shipping dates to be
specified on a single page instead of relying on three separate pages
3. Allow items to be assigned to ship groups when creating or updating. The
order items page of existing orders already provides this functionality by
allowing quantities to be specified for each ship group for each order item.
Similarly, ship groups should be listed with quantity fields for each item
when more than one ship group exists so that items can be assigned to ship
groups directly when added or updated.
4. Allow ability to assign items directly to ship groups to the form on the
order edit page that allows appending of items to existing orders. Existing
items already have this ability so it should be expanded to this form as well.
5. Allow ability to reorder the ship group sequence. Having the ability to
control the sequence of the list of ship group quantity fields would be very
useful if the other functionality is implemented. This would allow for
example, a ship group with a date that falls between existing ship group
dates to be resequenced to fall between those respective ship group dates
when listed for order items.
6. Allow ship groups to be deleted/removed. Adding a fromDate and thruDate
to the OrderItemShipGroup entity could provide this functionality. Logic
would have to check to ensure that no order items have been assigned before
removing the ship group.

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

[jira] [Commented] (OFBIZ-5400) Improve order application to better handle complex ship groups

[
https://issues.apache.org/jira/browse/OFBIZ-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511741#comment-14511741
]

Christian Carlow commented on OFBIZ-5400:
-

To summarize the reason for the issue:

As ship groups increase, managing them and associated quantities becomes very
cumbersome for backend users. Given a large enough order with many items and
schedules, the current UI becomes impractical to use. This issue was created
to provide an alternative screens for managing such complex data.

Improve order application to better handle complex ship groups
--

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

[jira] [Updated] (OFBIZ-5400) Improve shopping cart to better handle a large number of ship groups and item associations

[
https://issues.apache.org/jira/browse/OFBIZ-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christian Carlow updated OFBIZ-5400:

Summary: Improve shopping cart to better handle a large number of ship
groups and item associations (was: Improve order application to better handle
complex ship groups)

Improve shopping cart to better handle a large number of ship groups and item
associations
--

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

[jira] [Commented] (OFBIZ-5400) Improve shopping cart to better handle a large number of ship groups and item associations

[
https://issues.apache.org/jira/browse/OFBIZ-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511752#comment-14511752
]

Christian Carlow commented on OFBIZ-5400:
-

The issue description was changed to narrow the scope to only the shopping
cart. Issues mentioned in previous comments invovling existing orders will be
handled by separate issues.

Improve shopping cart to better handle a large number of ship groups and item
associations
--

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

[jira] [Updated] (OFBIZ-5400) Improve order application to better handle complex ship groups

[
https://issues.apache.org/jira/browse/OFBIZ-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christian Carlow updated OFBIZ-5400:

Attachment: OFBIZ-5400.patch

Improve order application to better handle complex ship groups
--

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

[jira] [Updated] (OFBIZ-5400) Improve order application to better handle complex ship groups