This completes "set different ports for testing in a CI environment (e.g. Jenkins)" https://issues.apache.org/jira/browse/OFBIZ-4794
This was waiting for a moment in my working copy after I found that there was an issue with testSOAPSimpleService when portoffset was used with run-tests target.
I have still no resolved this issue, but since I got a better way to run simultaneous Buildbot instances this is no longer an issue for run-tests target.
So I commit these small pending changes in order to allow to run Sonar on OFBiz https://issues.apache.org/jira/browse/INFRA-3590.
The cobertura target does not work yet but what's committed here is needed anyway to progress with INFRA-3590.



git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1553962 13f79535-47bb-0310-9956-ffa450edef68
I was too fast with the Cobertura changes in previous commit, I forgotI did not test those yet.
So I revert them for now, they are not needed yet for the INFRA-3590 progresses anyway, only the portoffset parameter is needed.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1553975 13f79535-47bb-0310-9956-ffa450edef68
Finally commits change in framework/base/build.xml, the Buildbot error was not related to this change (did not make sense, as long this target is not used at least)

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554016 13f79535-47bb-0310-9956-ffa450edef68
Oops my bad, I forgot that I had downloaded the cobertura-1.9.4.1.jar locally so I had no issues after an ant clean but Buildbot had
So finally removes last change in framework/base/build.xml related to Cobertura

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554018 13f79535-47bb-0310-9956-ffa450edef68
Fixed the FinAccountTests - which assumed the tests would be run in the order they appear in source code, which JUnit does not guarantee:

http://stackoverflow.com/questions/3693626/how-to-run-test-methods-in-specific-order-in-junit4


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554064 13f79535-47bb-0310-9956-ffa450edef68
Upgrade to the latest official major version of Groovy: 2.2.1


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554242 13f79535-47bb-0310-9956-ffa450edef68
This is a refactoring of the product promotion engine in order to overcome some limitations that prevented it to select and apply the best set of promotions under special conditions.

Example: Consider two promotions:
* consider two products: Product A, with price $20, and Product B, with price $40
* Promotion 1: 20% discount on all the products in a category containing Product A and Product B
* Promotion 2: 40% discount on Product A

When Product A and Product B are both in the cart:
* Expected behavior: on Product A the Promotion 2 should be applied i.e. 40% discount, and on Product B Promotion 1 should be applied i.e. 20% discount.
** Summary
Product		Price	Discount		Subtotal
A		$20	$8 (40% discount)	$12
B		$40	$8 (20% discount)	$32
Total Adjustment: $16

* OFBiz behavior (before this fix): Promotion 1 is applied to Product A and Product B; this happens because the total discount of Promotion 1 is greater than the total discount of Promotion 2 and OFBiz applies promotions sorted by discount (desc)
** Summary
Product		Price	Discount		Subtotal
A		$20	$4 (20% discount)	$16
B		$40	$8 (20% discount)	$32
Total Adjustment: $12

The new solution fixes this issue and similar ones.

Here are some details about the new algorithm.

Overview of the flow:
1) run the promotions one by one in a test run
2) collect the ProductPromoUse information
3) sort them by weight (i.e. the ratio between the discount and the value of the products discounted)
4) execute the ProductPromoUse in the given order

In order to understand this solution, and specifically the changes to ProductPromoWorker.java, there is an important concept to consider:
one Promotion can generate more than one ProductPromoUseInfo objects.
For example if I have 2 units of WG-1111 in the cart (in one cart item) and I have the promotion “20% discount on WG-1111 and GZ-1000” then the system will create TWO ProductPromoUseInfo objects both associated to the same promotion one for each of the 2 units discounted.
Similarly if I had two lines: 2 units of WG-1111 and 1 unit of GZ-1000 I would get 3 ProductPromoUseInfo objects 2 objects for WG-1111 and 1 object for GZ-1000

We can sort these ProductPromoUseInfo objects based on their weight (i.e. the ratio between the discount and the value of the products discounted) in desc order
and now we have a sorted list of ProductPromoUseInfo objects ready to be executed
However we only want to execute each of them once and for this reason we set (in memory, not in the DB) the useLimitPerOrder to 1 in the first ProductPromoUseInfo of a given promotion and then to 2 if the same ProductPromoUseInfo is associated to the same promotion etc...
in this way the end result is that the system will generate, as we desire, ONE ProductPromoUseInfo only for each of the ProductPromoUseInfo in the list.

Here is an example:
we have 2 promotions:
PROMO A
PROMO B

After test run:

ProductPromoUseInfo - PROMO A - #1 - weight 0.3
ProductPromoUseInfo - PROMO A - #2 - weight 0.3
ProductPromoUseInfo - PROMO B - #1 - weight 0.4

After sorting:

ProductPromoUseInfo - PROMO B - #1 - weight 0.4
ProductPromoUseInfo - PROMO A - #1 - weight 0.3
ProductPromoUseInfo - PROMO A - #2 - weight 0.3

Based on this we create a list (sortedExplodedProductPromoList) of ProductPromo:

PROMO B - with useLimitPerOrder=1
PROMO A - with useLimitPerOrder=1
PROMO A - with useLimitPerOrder=2

When we apply these to the cart we get the following results:

PROMO B - with useLimitPerOrder=1 APPLIED
PROMO A - with useLimitPerOrder=1 APPLIED
PROMO A - with useLimitPerOrder=2 NOT APPLIED (because PROMO B used the item)



git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554265 13f79535-47bb-0310-9956-ffa450edef68
Fixed a bug in Party Manager where FreeMarker threw an exception when a PostalAddress did not contain a country GEO ID.


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554290 13f79535-47bb-0310-9956-ffa450edef68
Removed incomplete JUnit test that was created by Hans Bakker in commit 1449615 in order to test the feature associated to a new field calcTaxAfterPromotion; after this, Paul Foxworthy reverted the commit in rev. 1468865 but he forgot to remove the whole test and instead he updated it, leaving it in a useless state.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554373 13f79535-47bb-0310-9956-ffa450edef68
Upgrade to the latest Lucene release 4.6.0


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554384 13f79535-47bb-0310-9956-ffa450edef68
This fixes the geolocation in OFBiz, for both Google Maps and OpenLayers. It seems few changes, it took me more time than I thought. I hope this will last few years again, and it should be easier to maintain now.

What I did:
Upgraded from Google Maps API 2 to 3, which also means removing the keys in general.properties. They are no longer needed in API-3 (at least for our demo and local test uses), one worry less!
Refactored Google Maps code in geolocation.ftl: put more things in common,  simplified code (the API-3 is better from this POV).

For OpenLayers, due to most browsers now rejecting mixed content (HTTP vs HTTPS), I had to follow their advice and put OpenLayers-2.13.1.js + images and theme(finally not used) in the framework. Not a big deal in term of size but again one more lib to worry about. Anyway geolocation is not vital for OFBiz. I have also added a zoom and navigation widget in maps. Note that IE warns about mixed content, but you can bypass it.

While working on editGeoLocation (in Party) I noticed it does not update the elevation. I found it was possible http://www.daftlogic.com/sandbox-google-maps-find-altitude.htm but I did not implement it, lack of time...
Also I got once a NPE in CallSimpleMapProcessor (when using editGeoLocation) but was unable to reproduce (w/o changes before and after)

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554536 13f79535-47bb-0310-9956-ffa450edef68
This closes "Set field in (at least) widget screen does not take into account a locale for (at least) the Float type" https://issues.apache.org/jira/browse/OFBIZ-5453
And definitively fixes issues with i18n of geolocation 

It introduces a "locale" attribute to the "set" operation in widget (I only tested screen, form is quite similar, should be ok) and minilang.


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554681 13f79535-47bb-0310-9956-ffa450edef68
Completes "Set field in (at least) widget screen does not take into account a locale for (at least) the Float type" https://issues.apache.org/jira/browse/OFBIZ-5453 for minilang.
Removes dead code.
Locale applies only when the type is also passed, like in widgets.



git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554685 13f79535-47bb-0310-9956-ffa450edef68
This is a temporary hack waiting for a better geolocation data model, related with OFBIZ-5453

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554706 13f79535-47bb-0310-9956-ffa450edef68
Keeps the hack clean, sync is not needed here

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554764 13f79535-47bb-0310-9956-ffa450edef68
I did not get a chance to test my last editGeoLocation related change, here is the definitive version

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1554787 13f79535-47bb-0310-9956-ffa450edef68
Merges trunk HEAD

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/OFBIZ-5312-ofbiz-ecommerce-seo-2013-10-23@1554827 13f79535-47bb-0310-9956-ffa450edef68