[jira] [Commented] (OFBIZ-7427) OrderId, PartId showing multiple times in ReceiveInventoryAgainstPurchaseOrder screen.

2016-07-11 Thread Renuka Srishti (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15372132#comment-15372132
 ] 

Renuka Srishti commented on OFBIZ-7427:
---

ReceiveInventoryAgainstPurchaseOrder screen is not looking good.As label and 
its corresponding values are not in a proper place.Fix the UI issue also in 
this patch.

> OrderId, PartId showing multiple times in 
> ReceiveInventoryAgainstPurchaseOrder screen.
> --
>
> Key: OFBIZ-7427
> URL: https://issues.apache.org/jira/browse/OFBIZ-7427
> Project: OFBiz
>  Issue Type: Task
>  Components: product
>Affects Versions: Trunk
>Reporter: Renuka Srishti
>Assignee: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-7427.patch
>
>
> In ReceiveInventoryAgainstPurchaseOrder screen there are three issue :
> 1. OrderId label is not in a right place with its corresponding inbox.
> 2. On selecting OrderId from lookup it showing  orderId , partyName multiple 
> times.
> 3. If we use autocomplete to fill orderId in place of choosing from lookup, 
> it showing orderId partId multipletimes.



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


[jira] [Closed] (OFBIZ-7618) Add "changeByUserLoginId" field for ShipmentStatus

2016-07-11 Thread Nicolas Malin (JIRA)

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

Nicolas Malin closed OFBIZ-7618.

   Resolution: Implemented
Fix Version/s: Upcoming Branch

Ok it's commited on trunk at revision 1752233 thanks [~nj] and [~charles 
steltzlen] for the resolution

> Add "changeByUserLoginId" field for ShipmentStatus
> --
>
> Key: OFBIZ-7618
> URL: https://issues.apache.org/jira/browse/OFBIZ-7618
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7618.patch, ofbiz-7618-ShipmentStatus.patch
>
>




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


[jira] [Closed] (OFBIZ-7763) Replace bshInterpreter with groovyShell

2016-07-11 Thread Gil Portenseigne (JIRA)

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

Gil Portenseigne closed OFBIZ-7763.
---

> Replace bshInterpreter with groovyShell
> ---
>
> Key: OFBIZ-7763
> URL: https://issues.apache.org/jira/browse/OFBIZ-7763
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7763.patch, beanshell-removal-part1.patch
>
>
> To support the migration to gradle, removing bsh.jar dependency from the 
> project, and improve readability and fonctionnalities following 
> [~deepak.dixit] idea expressed here 
> https://issues.apache.org/jira/browse/OFBIZ-7576?focusedCommentId=15347972



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


[jira] [Resolved] (OFBIZ-7763) Replace bshInterpreter with groovyShell

2016-07-11 Thread Gil Portenseigne (JIRA)

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

Gil Portenseigne resolved OFBIZ-7763.
-
   Resolution: Fixed
Fix Version/s: Upcoming Branch

Commited in trunk r1752231

Thanks Jacopo for your patch, Deepak and Rishi for the subtasks and Nicolas for 
the review.

> Replace bshInterpreter with groovyShell
> ---
>
> Key: OFBIZ-7763
> URL: https://issues.apache.org/jira/browse/OFBIZ-7763
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7763.patch, beanshell-removal-part1.patch
>
>
> To support the migration to gradle, removing bsh.jar dependency from the 
> project, and improve readability and fonctionnalities following 
> [~deepak.dixit] idea expressed here 
> https://issues.apache.org/jira/browse/OFBIZ-7576?focusedCommentId=15347972



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


[jira] [Closed] (OFBIZ-7623) Add "changeByUserLoginId" field for FinAccountStatus

2016-07-11 Thread Nicolas Malin (JIRA)

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

Nicolas Malin closed OFBIZ-7623.

   Resolution: Implemented
Fix Version/s: Upcoming Branch

Ok commited on trunk at revision 1752232, thks Nameet.

> Add "changeByUserLoginId" field for FinAccountStatus
> 
>
> Key: OFBIZ-7623
> URL: https://issues.apache.org/jira/browse/OFBIZ-7623
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7623.patch, OFBIZ-7623.patch
>
>




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


[jira] [Updated] (OFBIZ-7623) Add "changeByUserLoginId" field for FinAccountStatus

2016-07-11 Thread Nicolas Malin (JIRA)

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

Nicolas Malin updated OFBIZ-7623:
-
Attachment: OFBIZ-7623.patch

> Add "changeByUserLoginId" field for FinAccountStatus
> 
>
> Key: OFBIZ-7623
> URL: https://issues.apache.org/jira/browse/OFBIZ-7623
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7623.patch, OFBIZ-7623.patch
>
>




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


[jira] [Commented] (OFBIZ-7623) Add "changeByUserLoginId" field for FinAccountStatus

2016-07-11 Thread Nicolas Malin (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371836#comment-15371836
 ] 

Nicolas Malin commented on OFBIZ-7623:
--

I found on this entity an other date time field *statusEndDate* that store on 
the previous entity status change the date end for this cover. 

I manage it directly on the entity-auto but I'm not sure if this field is 
useful because the value can be found with analyse the next EntityStatus value 
stored.
  

> Add "changeByUserLoginId" field for FinAccountStatus
> 
>
> Key: OFBIZ-7623
> URL: https://issues.apache.org/jira/browse/OFBIZ-7623
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7623.patch
>
>




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


[jira] [Updated] (OFBIZ-7778) Please find attached the patch file for including Province data for South Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml

2016-07-11 Thread charl Bouwer (JIRA)

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

charl Bouwer updated OFBIZ-7778:

Summary: Please find attached the patch file for including Province data 
for South Africa via GeoData_ZA.xml and address format for South Africa in 
GeoData.xml  (was: Please find attached the patch file for including Province 
data for Southh Africa via GeoData_ZA.xml and address format for South Africa 
in GeoData.xml)

> Please find attached the patch file for including Province data for South 
> Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml
> --
>
> Key: OFBIZ-7778
> URL: https://issues.apache.org/jira/browse/OFBIZ-7778
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: charl Bouwer
>Priority: Minor
>  Labels: Geodate, SouthAfrica, province, regions
> Fix For: Trunk
>
> Attachments: GeoDataZAF01.patch
>
>
> Please find attached the patch file for including Province data for Southh 
> Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml



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


[jira] [Updated] (OFBIZ-7778) Please find attached the patch file for including Province data for Southh Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml

2016-07-11 Thread charl Bouwer (JIRA)

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

charl Bouwer updated OFBIZ-7778:

Attachment: GeoDataZAF01.patch

I believe I have done t correctly

> Please find attached the patch file for including Province data for Southh 
> Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml
> ---
>
> Key: OFBIZ-7778
> URL: https://issues.apache.org/jira/browse/OFBIZ-7778
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: charl Bouwer
>Priority: Minor
>  Labels: Geodate, SouthAfrica, province, regions
> Fix For: Trunk
>
> Attachments: GeoDataZAF01.patch
>
>
> Please find attached the patch file for including Province data for Southh 
> Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml



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


[jira] [Created] (OFBIZ-7778) Please find attached the patch file for including Province data for Southh Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml

2016-07-11 Thread charl Bouwer (JIRA)
charl Bouwer created OFBIZ-7778:
---

 Summary: Please find attached the patch file for including 
Province data for Southh Africa via GeoData_ZA.xml and address format for South 
Africa in GeoData.xml
 Key: OFBIZ-7778
 URL: https://issues.apache.org/jira/browse/OFBIZ-7778
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Upcoming Branch
Reporter: charl Bouwer
Priority: Minor
 Fix For: Trunk


Please find attached the patch file for including Province data for Southh 
Africa via GeoData_ZA.xml and address format for South Africa in GeoData.xml



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


[jira] [Closed] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

2016-07-11 Thread Julien NICOLAS (JIRA)

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

Julien NICOLAS closed OFBIZ-7622.
-
Resolution: Fixed

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




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


[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

2016-07-11 Thread Julien NICOLAS (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371705#comment-15371705
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

I use the entity-auto and don't use the minilang anymore.

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




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


[jira] [Updated] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

2016-07-11 Thread Julien NICOLAS (JIRA)

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

Julien NICOLAS updated OFBIZ-7622:
--
Attachment: OFBIZ-7622.patch

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch, OFBIZ-7622.patch
>
>




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


[jira] [Commented] (OFBIZ-7618) Add "changeByUserLoginId" field for ShipmentStatus

2016-07-11 Thread Charles STELTZLEN (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371696#comment-15371696
 ] 

Charles STELTZLEN commented on OFBIZ-7618:
--

Done.

> Add "changeByUserLoginId" field for ShipmentStatus
> --
>
> Key: OFBIZ-7618
> URL: https://issues.apache.org/jira/browse/OFBIZ-7618
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7618.patch, ofbiz-7618-ShipmentStatus.patch
>
>




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


[jira] [Comment Edited] (OFBIZ-7771) Rename loadDefault to something less ambiguous

2016-07-11 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371694#comment-15371694
 ] 

Jacques Le Roux edited comment on OFBIZ-7771 at 7/11/16 9:41 PM:
-

The problem here is demo is confusing, because there is also a demo data set... 
Which does not contain seed and seed-initial...


was (Author: jacques.le.roux):
The problem here is demo is confusing, because there is also a demo data set...

> Rename loadDefault to something less ambiguous
> --
>
> Key: OFBIZ-7771
> URL: https://issues.apache.org/jira/browse/OFBIZ-7771
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Trivial
>
> The gradle task loadDefault is ambiguous, as it means different things to 
> different uses. This could lead to a situations where it is used in a wrong 
> manner, resulting in data being overwritten.
> Having a more meaningful name lessens the risk of such situations.



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


[jira] [Updated] (OFBIZ-7618) Add "changeByUserLoginId" field for ShipmentStatus

2016-07-11 Thread Charles STELTZLEN (JIRA)

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

Charles STELTZLEN updated OFBIZ-7618:
-
Attachment: (was: ofbiz-7618-ShipmentStatus.patch)

> Add "changeByUserLoginId" field for ShipmentStatus
> --
>
> Key: OFBIZ-7618
> URL: https://issues.apache.org/jira/browse/OFBIZ-7618
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7618.patch, ofbiz-7618-ShipmentStatus.patch
>
>




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


[jira] [Updated] (OFBIZ-7618) Add "changeByUserLoginId" field for ShipmentStatus

2016-07-11 Thread Charles STELTZLEN (JIRA)

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

Charles STELTZLEN updated OFBIZ-7618:
-
Attachment: ofbiz-7618-ShipmentStatus.patch

> Add "changeByUserLoginId" field for ShipmentStatus
> --
>
> Key: OFBIZ-7618
> URL: https://issues.apache.org/jira/browse/OFBIZ-7618
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7618.patch, ofbiz-7618-ShipmentStatus.patch
>
>




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


[jira] [Commented] (OFBIZ-7771) Rename loadDefault to something less ambiguous

2016-07-11 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371694#comment-15371694
 ] 

Jacques Le Roux commented on OFBIZ-7771:


The problem here is demo is confusing, because there is also a demo data set...

> Rename loadDefault to something less ambiguous
> --
>
> Key: OFBIZ-7771
> URL: https://issues.apache.org/jira/browse/OFBIZ-7771
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Trivial
>
> The gradle task loadDefault is ambiguous, as it means different things to 
> different uses. This could lead to a situations where it is used in a wrong 
> manner, resulting in data being overwritten.
> Having a more meaningful name lessens the risk of such situations.



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


[jira] [Updated] (OFBIZ-7618) Add "changeByUserLoginId" field for ShipmentStatus

2016-07-11 Thread Charles STELTZLEN (JIRA)

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

Charles STELTZLEN updated OFBIZ-7618:
-
Attachment: ofbiz-7618-ShipmentStatus.patch

> Add "changeByUserLoginId" field for ShipmentStatus
> --
>
> Key: OFBIZ-7618
> URL: https://issues.apache.org/jira/browse/OFBIZ-7618
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7618.patch, ofbiz-7618-ShipmentStatus.patch
>
>




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


[jira] [Commented] (OFBIZ-7625) Add "changeByUserLoginId" field for ExampleStatus

2016-07-11 Thread Antoine Ouvrard (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371547#comment-15371547
 ] 

Antoine Ouvrard commented on OFBIZ-7625:


I'm working on it 

> Add "changeByUserLoginId" field for ExampleStatus
> -
>
> Key: OFBIZ-7625
> URL: https://issues.apache.org/jira/browse/OFBIZ-7625
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Renuka Srishti
> Attachments: OFBIZ-7625.patch
>
>




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


[jira] [Updated] (OFBIZ-7777) QuoteId field displayed with no value

2016-07-11 Thread Montalbano Florian (JIRA)

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

Montalbano Florian updated OFBIZ-:
--
Attachment: OFBIZ-.patch

Here is the patch for this issue.
I added a use-when condition to display the field when the quote already exist 
(edition) and to hide the field when the quote is being created.

> QuoteId field displayed with no value
> -
>
> Key: OFBIZ-
> URL: https://issues.apache.org/jira/browse/OFBIZ-
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Priority: Trivial
>  Labels: form, null, quote, quoteid
> Attachments: OFBIZ-.patch
>
>
> When creating a new quote, the field quoteId is displayed even though its 
> value is "null".
> Step to reproduce :
> - Go to the "Order" component
> - Go on the "Quotes" tab
> - Click on create a new quote
> - See the "quoteId" field displaying no value
> (quick link : https://localhost:8443/ordermgr/control/EditQuote)
> Expected behaviour :
> The field "quoteId" should not appear when creating a new Quote



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


[jira] [Created] (OFBIZ-7777) QuoteId field displayed with no value

2016-07-11 Thread Montalbano Florian (JIRA)
Montalbano Florian created OFBIZ-:
-

 Summary: QuoteId field displayed with no value
 Key: OFBIZ-
 URL: https://issues.apache.org/jira/browse/OFBIZ-
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Trunk
Reporter: Montalbano Florian
Priority: Trivial


When creating a new quote, the field quoteId is displayed even though its value 
is "null".

Step to reproduce :
- Go to the "Order" component
- Go on the "Quotes" tab
- Click on create a new quote
- See the "quoteId" field displaying no value
(quick link : https://localhost:8443/ordermgr/control/EditQuote)


Expected behaviour :
The field "quoteId" should not appear when creating a new Quote



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


[jira] [Assigned] (OFBIZ-7623) Add "changeByUserLoginId" field for FinAccountStatus

2016-07-11 Thread Nicolas Malin (JIRA)

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

Nicolas Malin reassigned OFBIZ-7623:


Assignee: Nicolas Malin  (was: Renuka Srishti)

> Add "changeByUserLoginId" field for FinAccountStatus
> 
>
> Key: OFBIZ-7623
> URL: https://issues.apache.org/jira/browse/OFBIZ-7623
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7623.patch
>
>




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


[jira] [Commented] (OFBIZ-7618) Add "changeByUserLoginId" field for ShipmentStatus

2016-07-11 Thread Charles STELTZLEN (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371500#comment-15371500
 ] 

Charles STELTZLEN commented on OFBIZ-7618:
--

I took it. Charles

> Add "changeByUserLoginId" field for ShipmentStatus
> --
>
> Key: OFBIZ-7618
> URL: https://issues.apache.org/jira/browse/OFBIZ-7618
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Nicolas Malin
> Attachments: OFBIZ-7618.patch
>
>




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


[jira] [Assigned] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

2016-07-11 Thread Julien NICOLAS (JIRA)

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

Julien NICOLAS reassigned OFBIZ-7622:
-

Assignee: Julien NICOLAS

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch
>
>




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


[jira] [Commented] (OFBIZ-7622) Add "changeByUserLoginId" field for CustRequestStatus

2016-07-11 Thread Julien NICOLAS (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371498#comment-15371498
 ] 

Julien NICOLAS commented on OFBIZ-7622:
---

I start working on this one

> Add "changeByUserLoginId" field for CustRequestStatus
> -
>
> Key: OFBIZ-7622
> URL: https://issues.apache.org/jira/browse/OFBIZ-7622
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Nameet Jain
>Assignee: Julien NICOLAS
> Attachments: OFBIZ-7622.patch
>
>




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


[jira] [Commented] (OFBIZ-7534) Migrate OFBiz from Apache Ant to Gradle build system

2016-07-11 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371486#comment-15371486
 ] 

Pierre Smits commented on OFBIZ-7534:
-

This seems like a sub-task to resolve.

> Migrate OFBiz from Apache Ant to Gradle build system
> 
>
> Key: OFBIZ-7534
> URL: https://issues.apache.org/jira/browse/OFBIZ-7534
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: ant, build-tools, gradle
> Attachments: ANT_GRADLE_COMPARISON.txt, OFBIZ-7534.patch, 
> OFBIZ-7534.patch, OFBIZ-7534.patch, OFBIZ-7534.patch, OFBizRemoteJarList.csv, 
> OFBizRemoteJarList.csv, OFBizRemoteJarList.csv, OFBizRemoteJarList.csv, 
> gradle-wrapper.jar
>
>
> This is a major refactoring task referring to the [email 
> thread|http://ofbiz.markmail.org/message/vstt3wxuubmjgmqj?q=Important+Changes+to+Trunk+and+Use+of+Ant+%26+Gradle]
>  in which the community voted for the switch after a proposal from the PMC
> The purpose of this JIRA is to achieve the following objectives
> - Fully implement a working compiling system in Gradle that passes all tests
> - Remove all ant and maven build scripts from the system
> - update the documentation of the system to reflect these changes



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


[jira] [Comment Edited] (OFBIZ-7771) Rename loadDefault to something less ambiguous

2016-07-11 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371474#comment-15371474
 ] 

Pierre Smits edited comment on OFBIZ-7771 at 7/11/16 7:37 PM:
--

My apologies to all who feel that they get vexed by the issues I am 
experiencing with this switch.

If the 'loadDefault' is not intended to load all data, but is just intended to 
load the data sets that were previously designated as the load-demo task with 
the ant solution, and thus for demo-purposes (which I agree can also be used by 
developers and testers for their specific purposes and processes), then an 
equally good suggestion would be rename it to:

*loadDemoData* or *loadDemoDataSets*

[~jacques.le.roux]: thank you for taking upon you the task to also provide 
better suggestions. Thank you.


was (Author: pfm.smits):
My apologies to all who feel that they get vexed by the issues I am 
experiencing with this switch.

If the 'loadDefault' is not intended to load all data, but is just intended to 
load the data sets that were previously designated as the load-demo task with 
the ant solution, and thus for demo-purposes (which I agree can also be used by 
developers and tested for their specific purposes and process), then an equally 
good suggestion would be rename it to:

*loadDemoData* or *loadDemoDataSets*

[~jacques.le.roux]: thank you for taking upon you the task to also provide 
better suggestions. Thank you.

> Rename loadDefault to something less ambiguous
> --
>
> Key: OFBIZ-7771
> URL: https://issues.apache.org/jira/browse/OFBIZ-7771
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Trivial
>
> The gradle task loadDefault is ambiguous, as it means different things to 
> different uses. This could lead to a situations where it is used in a wrong 
> manner, resulting in data being overwritten.
> Having a more meaningful name lessens the risk of such situations.



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


[jira] [Commented] (OFBIZ-7771) Rename loadDefault to something less ambiguous

2016-07-11 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371474#comment-15371474
 ] 

Pierre Smits commented on OFBIZ-7771:
-

My apologies to all who feel that they get vexed by the issues I am 
experiencing with this switch.

If the 'loadDefault' is not intended to load all data, but is just intended to 
load the data sets that were previously designated as the load-demo task with 
the ant solution, and thus for demo-purposes (which I agree can also be used by 
developers and tested for their specific purposes and process), then an equally 
good suggestion would be rename it to:

*loadDemoData* or *loadDemoDataSets*

[~jacques.le.roux]: thank you for taking upon you the task to also provide 
better suggestions. Thank you.

> Rename loadDefault to something less ambiguous
> --
>
> Key: OFBIZ-7771
> URL: https://issues.apache.org/jira/browse/OFBIZ-7771
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Trivial
>
> The gradle task loadDefault is ambiguous, as it means different things to 
> different uses. This could lead to a situations where it is used in a wrong 
> manner, resulting in data being overwritten.
> Having a more meaningful name lessens the risk of such situations.



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


[jira] [Commented] (OFBIZ-7534) Migrate OFBiz from Apache Ant to Gradle build system

2016-07-11 Thread charl Bouwer (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371471#comment-15371471
 ] 

charl Bouwer commented on OFBIZ-7534:
-

Caused by: java.lang.ClassNotFoundException: com.mysql.jdbc.Driver

With the gradle build system the lib library isn't in the  
/framework/entity/lib/jdbc folder any more. What is the correct way 
for me to add it as not everybody is going to use the Mysql driver. 
I should have asked for all database drivers though because I assume they could 
be problematic though

> Migrate OFBiz from Apache Ant to Gradle build system
> 
>
> Key: OFBIZ-7534
> URL: https://issues.apache.org/jira/browse/OFBIZ-7534
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: ant, build-tools, gradle
> Attachments: ANT_GRADLE_COMPARISON.txt, OFBIZ-7534.patch, 
> OFBIZ-7534.patch, OFBIZ-7534.patch, OFBIZ-7534.patch, OFBizRemoteJarList.csv, 
> OFBizRemoteJarList.csv, OFBizRemoteJarList.csv, OFBizRemoteJarList.csv, 
> gradle-wrapper.jar
>
>
> This is a major refactoring task referring to the [email 
> thread|http://ofbiz.markmail.org/message/vstt3wxuubmjgmqj?q=Important+Changes+to+Trunk+and+Use+of+Ant+%26+Gradle]
>  in which the community voted for the switch after a proposal from the PMC
> The purpose of this JIRA is to achieve the following objectives
> - Fully implement a working compiling system in Gradle that passes all tests
> - Remove all ant and maven build scripts from the system
> - update the documentation of the system to reflect these changes



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


[jira] [Issue Comment Deleted] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux updated OFBIZ-5522:
---
Comment: was deleted

(was: lån penge online i dag http://www.laanogsparpenge.dk


danske bank renter på lån  http://www.bank-i-danmark.dk/

nordea bank 
http://www.bank-i-danmark.dk/nordea-bank-koebenhavn-k-strandgade-3.html 


skat skattecenter københavn http://finansielle-raadgivere.dk


lån penge trods rki  http://www.laanesider.dk
)

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Commented] (OFBIZ-7605) Extend use of Apache IVY re external library management for r13x

2016-07-11 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371367#comment-15371367
 ] 

Jacques Le Roux commented on OFBIZ-7605:


Pierre,
Since you seem to have agreed about the plan, can we now?
bq. It seems all Ivy related tasks will be abandonned, we should close them as 
"Won't fix" or alike
Can you take care of it?

> Extend use of Apache IVY re external library management for r13x
> 
>
> Key: OFBIZ-7605
> URL: https://issues.apache.org/jira/browse/OFBIZ-7605
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS, framework
>Affects Versions: Release Branch 13.07
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Blocker
> Attachments: OFBIZ-7605-r13-ivy-v2.patch, OFBIZ-7605-status-v2.txt, 
> OFBIZ-7605-svn-status.txt, ofbiz-7605-r13-ivy.patch
>
>
> This subtask addresses the issues regarding the r13.07 branch.



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


[jira] [Issue Comment Deleted] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

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

morten vermund updated OFBIZ-5522:
--
Comment: was deleted

(was: Protein pandekager http://proteinpulver.guide/proteinpandekager/

billlig protein pulver http://proteinpulver.guide/smoothie-med-protein)

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Issue Comment Deleted] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

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

morten vermund updated OFBIZ-5522:
--
Comment: was deleted

(was: When the town is so promising and potential then it has a constant 
floating population which often shifts from one spot to another. The shifting 
procedure is created simple now by the expert shifting organizations.

Packers and Movers Hyderabad

Packers and Movers Pune

Packers and Movers Bangalore

Packers and Movers Gurgaon

Packers and Movers Mumbai

Packers and Movers Delhi)

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Issue Comment Deleted] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

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

morten vermund updated OFBIZ-5522:
--
Comment: was deleted

(was: greenskosttilskud http://www.greenskosttilskud.dk

http://finansielle-raadgivere.dk/skat-skattecenter-kobenhavn-kobenhavn-sv-sluseholmen-8-b.html;>finansielle
 rådgivere)

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Issue Comment Deleted] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

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

morten vermund updated OFBIZ-5522:
--
Comment: was deleted

(was: kreditkort i danmark http://www.kreditkort365.dk


Billigaste lån http://www.billigalaan.se/billigaste-lan


Låna pengar nu  http://www.billigalaan.se/lana-pengar-nu


lån penge i sverige http://www.laan-365.dk 

[url=http://www.greenskosttilskud.dk/]hvad er kosttilskud[/url])

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Commented] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371337#comment-15371337
 ] 

morten vermund commented on OFBIZ-5522:
---

When the town is so promising and potential then it has a constant floating 
population which often shifts from one spot to another. The shifting procedure 
is created simple now by the expert shifting organizations.

Packers and Movers Hyderabad

Packers and Movers Pune

Packers and Movers Bangalore

Packers and Movers Gurgaon

Packers and Movers Mumbai

Packers and Movers Delhi

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Issue Comment Deleted] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

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

morten vermund updated OFBIZ-5522:
--
Comment: was deleted

(was:   [ 

Packers and Movers in Pune at 
http://www.moveby5th.in/packers-and-movers-pune.html 
Packers and Movers in Bangalore at 
http://www.moveby5th.in/packers-and-movers-bangalore.html 
Packers and Movers in Gurgaon at 
http://www.expert5th.in/packers-and-movers-gurgaon/ 
Packers and Movers in Mumbai at 
http://www.moveby5th.in/packers-and-movers-mumbai.html 
])

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Commented] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371314#comment-15371314
 ] 

morten vermund commented on OFBIZ-5522:
---

[ 

Packers and Movers in Pune at 
http://www.moveby5th.in/packers-and-movers-pune.html 
Packers and Movers in Bangalore at 
http://www.moveby5th.in/packers-and-movers-bangalore.html 
Packers and Movers in Gurgaon at 
http://www.expert5th.in/packers-and-movers-gurgaon/ 
Packers and Movers in Mumbai at 
http://www.moveby5th.in/packers-and-movers-mumbai.html 
]

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Comment Edited] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371231#comment-15371231
 ] 

morten vermund edited comment on OFBIZ-5522 at 7/11/16 6:08 PM:


kreditkort i danmark http://www.kreditkort365.dk


Billigaste lån http://www.billigalaan.se/billigaste-lan


Låna pengar nu  http://www.billigalaan.se/lana-pengar-nu


lån penge i sverige http://www.laan-365.dk 

[url=http://www.greenskosttilskud.dk/]hvad er kosttilskud[/url]


was (Author: mortenverm...@gmail.com):
kreditkort i danmark http://www.kreditkort365.dk


Billigaste lån http://www.billigalaan.se/billigaste-lan


Låna pengar nu  http://www.billigalaan.se/lana-pengar-nu


lån penge i sverige http://www.laan-365.dk 

[url=http://www.greenskosttilskud.dk/]hvad er kosttilskud[/url]

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Comment Edited] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371265#comment-15371265
 ] 

morten vermund edited comment on OFBIZ-5522 at 7/11/16 6:04 PM:


greenskosttilskud http://www.greenskosttilskud.dk

http://finansielle-raadgivere.dk/skat-skattecenter-kobenhavn-kobenhavn-sv-sluseholmen-8-b.html;>finansielle
 rådgivere


was (Author: mortenverm...@gmail.com):
greenskosttilskud http://www.greenskosttilskud.dk

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Commented] (OFBIZ-7768) remove gradle-wrapper external library

2016-07-11 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371298#comment-15371298
 ] 

Jacques Le Roux commented on OFBIZ-7768:


To be clear here. We can use gradlew (aka the wrapper) on BuilBot, but since we 
start anew for each build this means to uselessly download 45 MB each time, so 
we use a gradle version (currently 2.13) rather. The idea is we will only 
upgrade it (what the wrapper does automatically) when we will cross issues. 
Done with INFRA-12235.

On the other hand the deamon should not be used on CI servers like BuildBot.

See the documentation for details about these 2 important parts of Gradle.

> remove gradle-wrapper external library
> --
>
> Key: OFBIZ-7768
> URL: https://issues.apache.org/jira/browse/OFBIZ-7768
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>




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


Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-11 Thread Taher Alkhateeb
Hi Sharan and everyone.

I propose in complement and summarizing your points the following:

1- deactivate by default all specialpurpose components. Possibly with a
convenience task called activateAllPlugins
2- redesign the directory structure to separate main classes from test
classes
3- rename the specialpurpose folder to plugins

The migration of remote libs is already on its way.

Taher Alkhateeb
On Jul 11, 2016 7:38 PM, "Sharan-F"  wrote:

Hi Everyone

Another update on the task list for moving forward with Gradle and the
Trunk. We would also like to get community feedback and comments on each of
the following 3 proposals:

Task 1 “Replace all the current jars in OFBiz with appropriate remote
libraries from a download repository
--
The work to replace the jars is ongoing and we have already removed 169 of
them. These libraries will now be automatically downloaded by Gradle. Work
will continue to remove the remaining files. As we are working through, we
are finding library migration issues with some of the specialpurpose
components so would like *to propose to deactivate all specialpurpose
components by default.*


Task 4. “ Move all java source files to\u2002$component/src/main/java and
introduce all unit tests in\u2002\u2002$component/src/test/java”
-
Another area we need to progress is the re-design and changing of the
directory structure so that we can separate the Java files between main and
test. This will help us simplify the implementation of a testing framework.
*The proposal for the directory structure is as follows:

   componentname/src/main/java
   componentname/src/test/java*


Task 10. “Propose the renaming specialpurpose to plugins or such an
appropriate name for clarity”
-
We would like * to propose changing the name of the specialpurpose folder to
'plugins'*

These are the 3 areas we would like to progress so please feel free to
respond with your feedback and comments.

Thanks
Sharan




--
View this message in context:
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.


Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Jacques Le Roux

Le 11/07/2016 à 19:46, Jacques Le Roux a écrit :

Pierre, All,

There are 3 aspects here:

1. Repositories, you can do almost what you want, the ASF does not care if you 
put jar, exe, dll, youNameIt... there (kidding with dll ;))
2. Source releases (required by ASF and must not contain external jar)
3. Binaries releases (required by ASF and can contain external jar, this is what you call 
"convenience downloads projects make available" There are

Argh, typo :/
3. Binaries releases (*NOT* required by ASF and can contain external jar, this is what you call "convenience downloads projects make available" 
There are

jacques


   usually provided by a 3rd party and can be hosted on ASF servers. But are 
not, in any ways, official ASF releases.

At least we should all use the same vocabulary (I used the one ASF uses), if we 
want to understand each other. What is the problem?

Thanks

Jacques


Le 11/07/2016 à 10:55, Pierre Smits a écrit :

Hi Taher,

It seems you did not read the entire posting.

The ASF doesn't object from having external libraries (3rd party jar files)
in the convenience downloads projects make available. This is what OFBiz
does also.

If there is a problem within the release process, regarding the external
libraries, then there are more ways around that than to fix something that
is not broken.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:


Hi Pierre,

It seems you did not read the entire sentence, so I will write here again
from the JIRA you mentioned.

 From Jacques: "There is no problems having an external jar (and even more)
in the repo. The pb is only when we release"

This is exactly what Sharan is saying above. You can keep Jars in branches,
"Releases" are where you are not supposed to keep binaries.

HTH

Taher Alkhateeb

On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits 
wrote:


Jacques posted this recently in a JIRA issue:


https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886 


Stating that there is no issue with having 3rd party libraries (jar

files)

in the repo.
Also the ASF does not object to have 3rd party libraries in the

convenience

downloads that the project makes available.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga 
wrote:


Hi Pierre

Thanks for starting the discussion. I had expected to start it this

week,

giving us time to continue stabilising and consolidating the gradle

work

in

the trunk from last week. (Also a minor correction – I 'suggested' not
'promised').

Anyway my suggestion was to take the discussion to this list to talk

about

the next steps. So just as a recap from the user mailing list, my

summary

of the discussion there included the following points that are relevant

to

the 14.12 and 15.12 unreleased branches.

1) - We would not backport any of the gradle changes into the 14.12. or
15.12
branches because it would cause instability
2) - We would leave 14.12 and 15.12 as unreleased branches as they are

now

(and not
make them into releases as to do that we would need to remove all the

jar

files
and this would create instability).
3) - The benefits for our community are that developers and service
providers will
still have access to the complete codebase for 14.12 and 15.12

including

the
special purpose components to be able to support their client base.

My understanding was that the community did reach a consensus on these
points. No-one responded to correct, update nor oppose any of these

points.

Both of your questions are answered by the second point. So based on

this

the responses to your questions are:

- No, we are not going to delete the external libraries from the
unreleased branches 14.12 and 15.12  (if they remain as unreleased

branches

the there is no need to remove the external jars)

- No, we are not going to delete the entire unreleased branches 14.12

and

15.12 (we are leaving these available so that our community will still

have

access to the complete codebase including the special purpose

components)

In fact the main discussion that I wanted to start here was more

related

to support for 14.12 and 15.12.  As we are in transition to gradle, we

need

to define a time period for backporting bug fixes into these unreleased
branches.

As an initial suggestion – would 12 months be a good timeframe to work
with. What do other people think?

Thanks
Sharan

On 2016-07-10 10:48 (+0200), Pierre Smits 

wrote:

Hi all,

Sharan promised the greater community in the '[*[DISCUSSION]*

*Anticipate*

  

Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Jacques Le Roux

+1 (from today)

I agree with Deepak, best place for this information

Jacques

Le 11/07/2016 à 11:32, Deepak Dixit a écrit :

+1

assuming 12 months from today, We can add these support date on release
page as well
https://ofbiz.apache.org/download.html

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Mon, Jul 11, 2016 at 2:49 PM, Taher Alkhateeb  wrote:


12 months seems a reasonable timeframe to me.

Jacopo

On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga 
wrote:


Hi Everyone

Following on from the discussion on the user mailing list and the
consensus to leave 14.12 and 15.12 as unreleased branches.

I'd like to start thinking about the support timeframe for backporting

bug

fixes into these branches. My initial suggestion is 12 months. What do
other people think?

Thanks
Sharan






Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Jacques Le Roux

Pierre, All,

There are 3 aspects here:

1. Repositories, you can do almost what you want, the ASF does not care if you 
put jar, exe, dll, youNameIt... there (kidding with dll ;))
2. Source releases (required by ASF and must not contain external jar)
3. Binaries releases (required by ASF and can contain external jar, this is what you call 
"convenience downloads projects make available" There are
   usually provided by a 3rd party and can be hosted on ASF servers. But are 
not, in any ways, official ASF releases.

At least we should all use the same vocabulary (I used the one ASF uses), if we 
want to understand each other. What is the problem?

Thanks

Jacques


Le 11/07/2016 à 10:55, Pierre Smits a écrit :

Hi Taher,

It seems you did not read the entire posting.

The ASF doesn't object from having external libraries (3rd party jar files)
in the convenience downloads projects make available. This is what OFBiz
does also.

If there is a problem within the release process, regarding the external
libraries, then there are more ways around that than to fix something that
is not broken.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:


Hi Pierre,

It seems you did not read the entire sentence, so I will write here again
from the JIRA you mentioned.

 From Jacques: "There is no problems having an external jar (and even more)
in the repo. The pb is only when we release"

This is exactly what Sharan is saying above. You can keep Jars in branches,
"Releases" are where you are not supposed to keep binaries.

HTH

Taher Alkhateeb

On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits 
wrote:


Jacques posted this recently in a JIRA issue:



https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886

Stating that there is no issue with having 3rd party libraries (jar

files)

in the repo.
Also the ASF does not object to have 3rd party libraries in the

convenience

downloads that the project makes available.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga 
wrote:


Hi Pierre

Thanks for starting the discussion. I had expected to start it this

week,

giving us time to continue stabilising and consolidating the gradle

work

in

the trunk from last week. (Also a minor correction – I 'suggested' not
'promised').

Anyway my suggestion was to take the discussion to this list to talk

about

the next steps. So just as a recap from the user mailing list, my

summary

of the discussion there included the following points that are relevant

to

the 14.12 and 15.12 unreleased branches.

1) - We would not backport any of the gradle changes into the 14.12. or
15.12
branches because it would cause instability
2) - We would leave 14.12 and 15.12 as unreleased branches as they are

now

(and not
make them into releases as to do that we would need to remove all the

jar

files
and this would create instability).
3) - The benefits for our community are that developers and service
providers will
still have access to the complete codebase for 14.12 and 15.12

including

the
special purpose components to be able to support their client base.

My understanding was that the community did reach a consensus on these
points. No-one responded to correct, update nor oppose any of these

points.

Both of your questions are answered by the second point. So based on

this

the responses to your questions are:

- No, we are not going to delete the external libraries from the
unreleased branches 14.12 and 15.12  (if they remain as unreleased

branches

the there is no need to remove the external jars)

- No, we are not going to delete the entire unreleased branches 14.12

and

15.12 (we are leaving these available so that our community will still

have

access to the complete codebase including the special purpose

components)

In fact the main discussion that I wanted to start here was more

related

to support for 14.12 and 15.12.  As we are in transition to gradle, we

need

to define a time period for backporting bug fixes into these unreleased
branches.

As an initial suggestion – would 12 months be a good timeframe to work
with. What do other people think?

Thanks
Sharan

On 2016-07-10 10:48 (+0200), Pierre Smits 

wrote:

Hi all,

Sharan promised the greater community in the '[*[DISCUSSION]*

*Anticipate*

  the *end* of *life* of the *13.07* branch and backport some non-bug
related changes to the 14.12 and 15.12 branches
' starting via
http://ofbiz.markmail.org/message/nqo5xacngpspytvf ) that 

[jira] [Commented] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371271#comment-15371271
 ] 

morten vermund commented on OFBIZ-5522:
---

Protein pandekager http://proteinpulver.guide/proteinpandekager/

billlig protein pulver http://proteinpulver.guide/smoothie-med-protein

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Commented] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371265#comment-15371265
 ] 

morten vermund commented on OFBIZ-5522:
---

greenskosttilskud http://www.greenskosttilskud.dk

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Comment Edited] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371231#comment-15371231
 ] 

morten vermund edited comment on OFBIZ-5522 at 7/11/16 5:40 PM:


kreditkort i danmark http://www.kreditkort365.dk


Billigaste lån http://www.billigalaan.se/billigaste-lan


Låna pengar nu  http://www.billigalaan.se/lana-pengar-nu


lån penge i sverige http://www.laan-365.dk 

[url=http://www.greenskosttilskud.dk/]hvad er kosttilskud[/url]


was (Author: mortenverm...@gmail.com):
kreditkort i danmark http://www.kreditkort365.dk


Billigaste lån http://www.billigalaan.se/billigaste-lan


Låna pengar nu  http://www.billigalaan.se/lana-pengar-nu


lån penge i sverige http://www.laan-365.dk 

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Commented] (OFBIZ-7776) Remove warnings regarding missing component lib folders

2016-07-11 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371248#comment-15371248
 ] 

Jacques Le Roux commented on OFBIZ-7776:


To fix this issue I'll wait that all external jars are removed (except gradle 
ones of course)

> Remove warnings regarding missing component lib folders
> ---
>
> Key: OFBIZ-7776
> URL: https://issues.apache.org/jira/browse/OFBIZ-7776
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>
> With the move to gradle/gradlew the lib folder - that previously held the 
> external libraries - doesn't exist anymore in various components. This 
> results in unnecessary warnings in the log files, e.g.:
> {code}
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/build/lib' 
> does not exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/ant' 
> does not exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/commons' does not 
> exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/j2eespecs' does not 
> exist
> 2016-07-11 13:15:00,009 |main |ComponentContainer
> |I| Loaded component : [base]
> 2016-07-11 13:15:00,041 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/lib' 
> does not exist
> 2016-07-11 13:15:00,041 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/build/lib' does not 
> exist
> 2016-07-11 13:15:00,042 |main |ComponentContainer
> |I| Loaded component : [geronimo]
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib' does 
> not exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib/jdbc' 
> does not exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/build/lib' does not 
> exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |I| Loaded component : [entity]
> 2016-07-11 13:15:00,098 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/security/build/lib' does not 
> exist
> 2016-07-11 13:15:00,098 |main |ComponentContainer
> |I| Loaded component : [security]
> 2016-07-11 13:15:00,122 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/datafile/build/lib' does not 
> exist
> 2016-07-11 13:15:00,123 |main |ComponentContainer
> |I| Loaded component : [datafile]
> 2016-07-11 13:15:00,142 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/minilang/build/lib' does not 
> exist
> 2016-07-11 13:15:00,142 |main |ComponentContainer
> |I| Loaded component : [minilang]
> 2016-07-11 13:15:00,178 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/common/build/lib' does not 
> exist
> 2016-07-11 13:15:00,178 |main |ComponentContainer
> |I| Loaded component : [common]
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/lib' 
> does not exist
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/build/lib' does not 
> exist
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |I| Loaded component : [service]
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/lib' 
> does not exist
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/build/lib' does not 
> exist
> 2016-07-11 13:15:00,237 |main  

[jira] [Assigned] (OFBIZ-7776) Remove warnings regarding missing component lib folders

2016-07-11 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux reassigned OFBIZ-7776:
--

Assignee: (was: Jacques Le Roux)

> Remove warnings regarding missing component lib folders
> ---
>
> Key: OFBIZ-7776
> URL: https://issues.apache.org/jira/browse/OFBIZ-7776
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>
> With the move to gradle/gradlew the lib folder - that previously held the 
> external libraries - doesn't exist anymore in various components. This 
> results in unnecessary warnings in the log files, e.g.:
> {code}
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/build/lib' 
> does not exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/ant' 
> does not exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/commons' does not 
> exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/j2eespecs' does not 
> exist
> 2016-07-11 13:15:00,009 |main |ComponentContainer
> |I| Loaded component : [base]
> 2016-07-11 13:15:00,041 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/lib' 
> does not exist
> 2016-07-11 13:15:00,041 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/build/lib' does not 
> exist
> 2016-07-11 13:15:00,042 |main |ComponentContainer
> |I| Loaded component : [geronimo]
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib' does 
> not exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib/jdbc' 
> does not exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/build/lib' does not 
> exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |I| Loaded component : [entity]
> 2016-07-11 13:15:00,098 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/security/build/lib' does not 
> exist
> 2016-07-11 13:15:00,098 |main |ComponentContainer
> |I| Loaded component : [security]
> 2016-07-11 13:15:00,122 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/datafile/build/lib' does not 
> exist
> 2016-07-11 13:15:00,123 |main |ComponentContainer
> |I| Loaded component : [datafile]
> 2016-07-11 13:15:00,142 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/minilang/build/lib' does not 
> exist
> 2016-07-11 13:15:00,142 |main |ComponentContainer
> |I| Loaded component : [minilang]
> 2016-07-11 13:15:00,178 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/common/build/lib' does not 
> exist
> 2016-07-11 13:15:00,178 |main |ComponentContainer
> |I| Loaded component : [common]
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/lib' 
> does not exist
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/build/lib' does not 
> exist
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |I| Loaded component : [service]
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/lib' 
> does not exist
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/build/lib' does not 
> exist
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |I| Loaded component : [catalina]
> 2016-07-11 13:15:00,262 |main 

[jira] [Commented] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371244#comment-15371244
 ] 

morten vermund commented on OFBIZ-5522:
---

lån penge online i dag http://www.laanogsparpenge.dk


danske bank renter på lån  http://www.bank-i-danmark.dk/

nordea bank 
http://www.bank-i-danmark.dk/nordea-bank-koebenhavn-k-strandgade-3.html 


skat skattecenter københavn http://finansielle-raadgivere.dk


lån penge trods rki  http://www.laanesider.dk


> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


[jira] [Commented] (OFBIZ-5522) Introduce websocket usage

2016-07-11 Thread morten vermund (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371231#comment-15371231
 ] 

morten vermund commented on OFBIZ-5522:
---

kreditkort i danmark http://www.kreditkort365.dk


Billigaste lån http://www.billigalaan.se/billigaste-lan


Låna pengar nu  http://www.billigalaan.se/lana-pengar-nu


lån penge i sverige http://www.laan-365.dk 

> Introduce websocket usage
> -
>
> Key: OFBIZ-5522
> URL: https://issues.apache.org/jira/browse/OFBIZ-5522
> Project: OFBiz
>  Issue Type: Task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> After a discussion with Ean, was suggested (draft here):
> You need a service that lets you "subscribe" a widget to an entity and
> then propagate change events to the widget as the entity is modified.
> A generic mechanism like that could eventually expand to be a general
> purpose "data bound widgets" system that mostly looks like the existing
> system but magically reflects updates.
> Could be used with/for
> * The entity cache and webforms to automatically update views when data 
> changes. 
> * Replaces the current system notes
> * Create a dashboard type pages  (to be discussed futher)



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


Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-11 Thread Sharan-F
Hi Everyone

Another update on the task list for moving forward with Gradle and the
Trunk. We would also like to get community feedback and comments on each of
the following 3 proposals:

Task 1 “Replace all the current jars in OFBiz with appropriate remote
libraries from a download repository
--
The work to replace the jars is ongoing and we have already removed 169 of
them. These libraries will now be automatically downloaded by Gradle. Work
will continue to remove the remaining files. As we are working through, we
are finding library migration issues with some of the specialpurpose
components so would like *to propose to deactivate all specialpurpose
components by default.*


Task 4. “ Move all java source files to\u2002$component/src/main/java and
introduce all unit tests in\u2002\u2002$component/src/test/java”
-
Another area we need to progress is the re-design and changing of the
directory structure so that we can separate the Java files between main and
test. This will help us simplify the implementation of a testing framework.
*The proposal for the directory structure is as follows:

   componentname/src/main/java
   componentname/src/test/java*


Task 10. “Propose the renaming specialpurpose to plugins or such an
appropriate name for clarity”
-
We would like * to propose changing the name of the specialpurpose folder to
'plugins'*

These are the 3 areas we would like to progress so please feel free to
respond with your feedback and comments.

Thanks
Sharan




--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.


[jira] [Updated] (OFBIZ-6670) Have configuration options for Content.

2016-07-11 Thread Pierre Smits (JIRA)

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

Pierre Smits updated OFBIZ-6670:

Assignee: (was: Pierre Smits)

> Have configuration options for Content.
> ---
>
> Key: OFBIZ-6670
> URL: https://issues.apache.org/jira/browse/OFBIZ-6670
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: content
>Affects Versions: Trunk
>Reporter: Pierre Smits
>




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


[jira] [Updated] (OFBIZ-6711) Have configuration options regarding widgets

2016-07-11 Thread Pierre Smits (JIRA)

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

Pierre Smits updated OFBIZ-6711:

Assignee: (was: Pierre Smits)

> Have configuration options regarding widgets
> 
>
> Key: OFBIZ-6711
> URL: https://issues.apache.org/jira/browse/OFBIZ-6711
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL APPLICATIONS, ALL COMPONENTS
>Reporter: Pierre Smits
> Attachments: OFBIZ-6711-widget.patch
>
>




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


[jira] [Updated] (OFBIZ-6211) Split configuration options in /framework/common .properties files

2016-07-11 Thread Pierre Smits (JIRA)

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

Pierre Smits updated OFBIZ-6211:

Assignee: (was: Pierre Smits)

> Split configuration options in /framework/common .properties files
> --
>
> Key: OFBIZ-6211
> URL: https://issues.apache.org/jira/browse/OFBIZ-6211
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Pierre Smits
>  Labels: common, configuration, multi-tenant
>
> The configuration file general.properties contains has configuration options 
> that are multi-tenant configurable (e.g. mail settings) and options that are 
> implementation specific (e.g. multitenant) and require a restart.
> The multi-tenant configurable options should move out of general.properties 
> into a separate .properties file.



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


[jira] [Comment Edited] (OFBIZ-7532) Form Display Field improvement to manage multiple number format

2016-07-11 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371096#comment-15371096
 ] 

Pierre Smits edited comment on OFBIZ-7532 at 7/11/16 4:25 PM:
--

I see nothing wrong with this issue. It is a sound improvement.

And the patch looks equally fine.

We don't need to discuss a trivial aspect like the validation of choices. There 
are lots of best practices that can be found. It only needs one to start with. 
The rest can be covered through follow-up JIRA issues.

I don't believe we need contributors second-guessing their judgement after they 
have created their issues with the best of intentions, by doing a do-over of 
the issue in a mail thread in the dev mailing list.

The only thing I find missing in the patch is addressing the properties for 
multi-tenant usage, meaning an enhancement of the seed data set with respect to 
the SystemProperty value(s) desired. See OFBIZ-6164


was (Author: pfm.smits):
I see nothing wrong with this issue. It is a sound improvement.

And the patch looks equally fine.

We don't need discuss a trivial aspect like the validation of choices. There 
are lots of best practices that can be found. It only needs one to start with. 
The rest can be covered through follow-up JIRA issues.

I don't believe we need contributors second-guessing their judgement after they 
have created their issues with the best of intentions, by doing a do-over of 
the issue in a mail thread in the dev mailing list.

The only thing I find missing in the patch is addressing the properties for 
multi-tenant usage, meaning an enhancement of the seed data set with respect to 
the SystemProperty value(s) desired. See OFBIZ-6164

> Form Display Field improvement to manage multiple number format
> ---
>
> Key: OFBIZ-7532
> URL: https://issues.apache.org/jira/browse/OFBIZ-7532
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Charles STELTZLEN
>Priority: Minor
> Attachments: OFBIZ-7532.patch
>
>
> On display field used in forms, there is a "type" "accounting-number" which 
> is used to format number like property configuration :  
> #,##0.;(#,##0.).
> This JIRA propose to extend this idea by using a "type" "number" and an 
> additional attribute called "format-pattern". This field will be used by form 
> renderer to get the good property. It use FlexibleString to manage variable 
> in this field and so allow to have different format for the same column 
> according to some conditions.
> example:  format-pattern="accounting"/>
> The "format-pattern" will be stored in arithmetic.properties.
> example:
> # the default number format 
> default.number.format = ##0.00
> accounting.number.format = #,##0.;(#,##0.)
> quantity.number.format = ##0.00
> integer-quantity.number.format = #0
> percentage.number.format = ##.##%
> export.number.format = #.00
> In ModelFormField.java, the system gets property using 
> EntityUtilProperties.getPropertyValue to ba able to quickly add a new format.
> I think that it will require a discussion on Dev mailing-list to validate the 
> choices.



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


Re: Form Display Field improvement to manage multiple number format

2016-07-11 Thread Pierre Smits
Hi Charles,

See my comment in https://issues.apache.org/jira/browse/OFBIZ-7532.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 3:43 PM, Charles STELTZLEN <
charles.steltz...@nereide.biz> wrote:

> Hi,
>
> On display field used in Forms, there is a "type" "accounting-number"
> which is used to format number like 'accounting-number.format' property
> configuration (arithmetic.properties) :  #,##0.;(#,##0.).
>
> The proposal is to extend this idea by using a "type" "number" and an
> additional attribute called "format-pattern". This field will be used by
> form renderer to get the good property. It use FlexibleString to manage
> variable in this field and so allow to have different format for the same
> column according to some conditions.
>
> example:
>
>format-pattern="accounting"/>
>
> The "format-pattern" will be stored in the arithmetic.properties.
>
> example:
>
>   # the default number format
>   default.number.format = ##0.00
>   accounting.number.format = #,##0.;(#,##0.)
>   quantity.number.format = ##0.00
>   integer-quantity.number.format = #0
>   percentage.number.format = ##.##%
>   export.number.format = #.00
>
> In ModelFormField.java, the system gets property using
> EntityUtilProperties.getPropertyValue to be able to quickly add a new
> format.
>
> A JIRA exists on this proposition (opened to soon as Jacques mentionned ) :
> https://issues.apache.org/jira/browse/OFBIZ-7532
> Do think that this proposal is a good one ?
>
> Best regards,
> Charles
>
>
>


[jira] [Commented] (OFBIZ-7532) Form Display Field improvement to manage multiple number format

2016-07-11 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371096#comment-15371096
 ] 

Pierre Smits commented on OFBIZ-7532:
-

I see nothing wrong with this issue. It is a sound improvement.

And the patch looks equally fine.

We don't need discuss a trivial aspect like the validation of choices. There 
are lots of best practices that can be found. It only needs one to start with. 
The rest can be covered through follow-up JIRA issues.

I don't believe we need contributors second-guessing their judgement after they 
have created their issues with the best of intentions, by doing a do-over of 
the issue in a mail thread in the dev mailing list.

The only thing I find missing in the patch is addressing the properties for 
multi-tenant usage, meaning an enhancement of the seed data set with respect to 
the SystemProperty value(s) desired. See OFBIZ-6164

> Form Display Field improvement to manage multiple number format
> ---
>
> Key: OFBIZ-7532
> URL: https://issues.apache.org/jira/browse/OFBIZ-7532
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Charles STELTZLEN
>Priority: Minor
> Attachments: OFBIZ-7532.patch
>
>
> On display field used in forms, there is a "type" "accounting-number" which 
> is used to format number like property configuration :  
> #,##0.;(#,##0.).
> This JIRA propose to extend this idea by using a "type" "number" and an 
> additional attribute called "format-pattern". This field will be used by form 
> renderer to get the good property. It use FlexibleString to manage variable 
> in this field and so allow to have different format for the same column 
> according to some conditions.
> example:  format-pattern="accounting"/>
> The "format-pattern" will be stored in arithmetic.properties.
> example:
> # the default number format 
> default.number.format = ##0.00
> accounting.number.format = #,##0.;(#,##0.)
> quantity.number.format = ##0.00
> integer-quantity.number.format = #0
> percentage.number.format = ##.##%
> export.number.format = #.00
> In ModelFormField.java, the system gets property using 
> EntityUtilProperties.getPropertyValue to ba able to quickly add a new format.
> I think that it will require a discussion on Dev mailing-list to validate the 
> choices.



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


[jira] [Updated] (OFBIZ-6189) Have configuration options for accounting

2016-07-11 Thread Pierre Smits (JIRA)

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

Pierre Smits updated OFBIZ-6189:

Assignee: (was: Pierre Smits)

> Have configuration options for accounting
> -
>
> Key: OFBIZ-6189
> URL: https://issues.apache.org/jira/browse/OFBIZ-6189
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: configuration, multi-tenant
>




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


Form Display Field improvement to manage multiple number format

2016-07-11 Thread Charles STELTZLEN

Hi,

On display field used in Forms, there is a "type" "accounting-number" 
which is used to format number like 'accounting-number.format' property 
configuration (arithmetic.properties) :  #,##0.;(#,##0.).


The proposal is to extend this idea by using a "type" "number" and an 
additional attribute called "format-pattern". This field will be used by 
form renderer to get the good property. It use FlexibleString to manage 
variable in this field and so allow to have different format for the 
same column according to some conditions.


example:

  format-pattern="accounting"/>


The "format-pattern" will be stored in the arithmetic.properties.

example:

  # the default number format
  default.number.format = ##0.00
  accounting.number.format = #,##0.;(#,##0.)
  quantity.number.format = ##0.00
  integer-quantity.number.format = #0
  percentage.number.format = ##.##%
  export.number.format = #.00

In ModelFormField.java, the system gets property using 
EntityUtilProperties.getPropertyValue to be able to quickly add a new 
format.


A JIRA exists on this proposition (opened to soon as Jacques mentionned 
) :https://issues.apache.org/jira/browse/OFBIZ-7532

Do think that this proposal is a good one ?

Best regards,
Charles




[jira] [Assigned] (OFBIZ-7776) Remove warnings regarding missing component lib folders

2016-07-11 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux reassigned OFBIZ-7776:
--

Assignee: Jacques Le Roux

> Remove warnings regarding missing component lib folders
> ---
>
> Key: OFBIZ-7776
> URL: https://issues.apache.org/jira/browse/OFBIZ-7776
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>
> With the move to gradle/gradlew the lib folder - that previously held the 
> external libraries - doesn't exist anymore in various components. This 
> results in unnecessary warnings in the log files, e.g.:
> {code}
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/build/lib' 
> does not exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/ant' 
> does not exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/commons' does not 
> exist
> 2016-07-11 13:15:00,008 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/j2eespecs' does not 
> exist
> 2016-07-11 13:15:00,009 |main |ComponentContainer
> |I| Loaded component : [base]
> 2016-07-11 13:15:00,041 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/lib' 
> does not exist
> 2016-07-11 13:15:00,041 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/build/lib' does not 
> exist
> 2016-07-11 13:15:00,042 |main |ComponentContainer
> |I| Loaded component : [geronimo]
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib' does 
> not exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib/jdbc' 
> does not exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/build/lib' does not 
> exist
> 2016-07-11 13:15:00,073 |main |ComponentContainer
> |I| Loaded component : [entity]
> 2016-07-11 13:15:00,098 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/security/build/lib' does not 
> exist
> 2016-07-11 13:15:00,098 |main |ComponentContainer
> |I| Loaded component : [security]
> 2016-07-11 13:15:00,122 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/datafile/build/lib' does not 
> exist
> 2016-07-11 13:15:00,123 |main |ComponentContainer
> |I| Loaded component : [datafile]
> 2016-07-11 13:15:00,142 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/minilang/build/lib' does not 
> exist
> 2016-07-11 13:15:00,142 |main |ComponentContainer
> |I| Loaded component : [minilang]
> 2016-07-11 13:15:00,178 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/common/build/lib' does not 
> exist
> 2016-07-11 13:15:00,178 |main |ComponentContainer
> |I| Loaded component : [common]
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/lib' 
> does not exist
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/build/lib' does not 
> exist
> 2016-07-11 13:15:00,207 |main |ComponentContainer
> |I| Loaded component : [service]
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/lib' 
> does not exist
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |W| Location 
> '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/build/lib' does not 
> exist
> 2016-07-11 13:15:00,237 |main |ComponentContainer
> |I| Loaded component : [catalina]
> 2016-07-11 

[jira] [Commented] (OFBIZ-7765) Replace call with

2016-07-11 Thread Rishi Solanki (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370599#comment-15370599
 ] 

Rishi Solanki commented on OFBIZ-7765:
--

Thanks Deepak!

> Replace  call with 

Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Ashish Vijaywargiya
12 months time frame looks good to me!

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
Connect with me on LinkedIn -
https://www.linkedin.com/in/ashishvijaywargiya1

On Mon, Jul 11, 2016 at 2:44 PM, Sharan Foga  wrote:

> Hi Everyone
>
> Following on from the discussion on the user mailing list and the
> consensus to leave 14.12 and 15.12 as unreleased branches.
>
> I'd like to start thinking about the support timeframe for backporting bug
> fixes into these branches. My initial suggestion is 12 months. What do
> other people think?
>
> Thanks
> Sharan
>
>


Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Pierre Smits
Sharan,

I know the difference between a vote and a discussion.

My +1 expresses nothing more than that I can find myself in the proposal.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 1:29 PM, Sharan Foga  wrote:

> Hi Pierre
>
> Thank very much for your support, although this is not a vote, just a
> simple show of support (or not) from any community member that wishes to do
> so.
>
> Thanks
> Sharan
>
> On 2016-07-11 13:17 (+0200), Pierre Smits  wrote:
> > +1 (non-binding).
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga 
> wrote:
> >
> > > Hi Everyone
> > >
> > > Following on from the discussion on the user mailing list and the
> > > consensus to leave 14.12 and 15.12 as unreleased branches.
> > >
> > > I'd like to start thinking about the support timeframe for backporting
> bug
> > > fixes into these branches. My initial suggestion is 12 months. What do
> > > other people think?
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> >
>


Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Sharan Foga
Hi Pierre

Thank very much for your support, although this is not a vote, just a simple 
show of support (or not) from any community member that wishes to do so. 

Thanks
Sharan

On 2016-07-11 13:17 (+0200), Pierre Smits  wrote: 
> +1 (non-binding).
> 
> Best regards,
> 
> Pierre Smits
> 
> ORRTIZ.COM 
> OFBiz based solutions & services
> 
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
> 
> On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga  wrote:
> 
> > Hi Everyone
> >
> > Following on from the discussion on the user mailing list and the
> > consensus to leave 14.12 and 15.12 as unreleased branches.
> >
> > I'd like to start thinking about the support timeframe for backporting bug
> > fixes into these branches. My initial suggestion is 12 months. What do
> > other people think?
> >
> > Thanks
> > Sharan
> >
> >
> 


[jira] [Created] (OFBIZ-7776) Remove warnings regarding missing component lib folders

2016-07-11 Thread Pierre Smits (JIRA)
Pierre Smits created OFBIZ-7776:
---

 Summary: Remove warnings regarding missing component lib folders
 Key: OFBIZ-7776
 URL: https://issues.apache.org/jira/browse/OFBIZ-7776
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Trunk
Reporter: Pierre Smits


With the move to gradle/gradlew the lib folder - that previously held the 
external libraries - doesn't exist anymore in various components. This results 
in unnecessary warnings in the log files, e.g.:
{code}

2016-07-11 13:15:00,008 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/build/lib' 
does not exist
2016-07-11 13:15:00,008 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/ant' does 
not exist
2016-07-11 13:15:00,008 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/commons' 
does not exist
2016-07-11 13:15:00,008 |main |ComponentContainer
|W| Location 
'/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/base/lib/j2eespecs' does not 
exist
2016-07-11 13:15:00,009 |main |ComponentContainer
|I| Loaded component : [base]
2016-07-11 13:15:00,041 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/lib' does 
not exist
2016-07-11 13:15:00,041 |main |ComponentContainer
|W| Location 
'/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/geronimo/build/lib' does not 
exist
2016-07-11 13:15:00,042 |main |ComponentContainer
|I| Loaded component : [geronimo]
2016-07-11 13:15:00,073 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib' does 
not exist
2016-07-11 13:15:00,073 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/lib/jdbc' 
does not exist
2016-07-11 13:15:00,073 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entity/build/lib' 
does not exist
2016-07-11 13:15:00,073 |main |ComponentContainer
|I| Loaded component : [entity]
2016-07-11 13:15:00,098 |main |ComponentContainer
|W| Location 
'/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/security/build/lib' does not 
exist
2016-07-11 13:15:00,098 |main |ComponentContainer
|I| Loaded component : [security]
2016-07-11 13:15:00,122 |main |ComponentContainer
|W| Location 
'/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/datafile/build/lib' does not 
exist
2016-07-11 13:15:00,123 |main |ComponentContainer
|I| Loaded component : [datafile]
2016-07-11 13:15:00,142 |main |ComponentContainer
|W| Location 
'/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/minilang/build/lib' does not 
exist
2016-07-11 13:15:00,142 |main |ComponentContainer
|I| Loaded component : [minilang]
2016-07-11 13:15:00,178 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/common/build/lib' 
does not exist
2016-07-11 13:15:00,178 |main |ComponentContainer
|I| Loaded component : [common]
2016-07-11 13:15:00,207 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/lib' does 
not exist
2016-07-11 13:15:00,207 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/service/build/lib' 
does not exist
2016-07-11 13:15:00,207 |main |ComponentContainer
|I| Loaded component : [service]
2016-07-11 13:15:00,237 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/lib' does 
not exist
2016-07-11 13:15:00,237 |main |ComponentContainer
|W| Location 
'/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/catalina/build/lib' does not 
exist
2016-07-11 13:15:00,237 |main |ComponentContainer
|I| Loaded component : [catalina]
2016-07-11 13:15:00,262 |main |ComponentContainer
|W| Location 
'/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/entityext/build/lib' does not 
exist
2016-07-11 13:15:00,263 |main |ComponentContainer
|I| Loaded component : [entityext]
2016-07-11 13:15:00,286 |main |ComponentContainer
|W| Location '/Users/pierre/dev/ofbiz/ofbiz-gradle/framework/webapp/lib' does 

[jira] [Commented] (OFBIZ-7729) Eclipse IDE gets messed up

2016-07-11 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370573#comment-15370573
 ] 

Pierre Smits commented on OFBIZ-7729:
-

Thanks [~jacques.le.roux]

It seems the recent commits work have a different (positive) effect on my 
Eclipse IDE than the patches had. Can't reproduce either since then.

> Eclipse IDE gets messed up
> --
>
> Key: OFBIZ-7729
> URL: https://issues.apache.org/jira/browse/OFBIZ-7729
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>Priority: Blocker
>  Labels: gradle
> Attachments: Screen Shot 2016-07-04 at 09.26.09.png, Screen Shot 
> 2016-07-04 at 09.26.39.png
>
>
> When applying the patches from OFBIZ-7534 and executing the eclipse 
> configuration task, my IDE gets messed up.



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


Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Pierre Smits
+1 (non-binding).

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga  wrote:

> Hi Everyone
>
> Following on from the discussion on the user mailing list and the
> consensus to leave 14.12 and 15.12 as unreleased branches.
>
> I'd like to start thinking about the support timeframe for backporting bug
> fixes into these branches. My initial suggestion is 12 months. What do
> other people think?
>
> Thanks
> Sharan
>
>


Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Sharan Foga
Good catch everyone - yes I mean 12 months from today, (so we'd be looking at 
July 2017 to stop the back porting.)

Also once we get consensus on the timeframe we can update the website.

Thanks
Sharan

On 2016-07-11 11:32 (+0200), Deepak Dixit  
wrote: 
> +1
> 
> assuming 12 months from today, We can add these support date on release
> page as well
> https://ofbiz.apache.org/download.html
> 
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> 
> On Mon, Jul 11, 2016 at 2:49 PM, Taher Alkhateeb  > wrote:
> 
> > +1
> >
> > 12 months seems a reasonable time frame for people to adjust to the
> > changes. I am assuming 12 months from today, not from the branch creation
> > date right?
> >
> > On Mon, Jul 11, 2016 at 12:16 PM, Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> >
> > > 12 months seems a reasonable timeframe to me.
> > >
> > > Jacopo
> > >
> > > On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga 
> > > wrote:
> > >
> > > > Hi Everyone
> > > >
> > > > Following on from the discussion on the user mailing list and the
> > > > consensus to leave 14.12 and 15.12 as unreleased branches.
> > > >
> > > > I'd like to start thinking about the support timeframe for backporting
> > > bug
> > > > fixes into these branches. My initial suggestion is 12 months. What do
> > > > other people think?
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > >
> > >
> >
> 


buildbot success in on ofbiz-trunk

2016-07-11 Thread 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/1069

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

Buildslave for this Build: silvanus_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot





[jira] [Updated] (OFBIZ-7763) Replace bshInterpreter with groovyShell

2016-07-11 Thread Gil Portenseigne (JIRA)

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

Gil Portenseigne updated OFBIZ-7763:

Attachment: (was: OFBIZ-7763.patch)

> Replace bshInterpreter with groovyShell
> ---
>
> Key: OFBIZ-7763
> URL: https://issues.apache.org/jira/browse/OFBIZ-7763
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Attachments: OFBIZ-7763.patch, beanshell-removal-part1.patch
>
>
> To support the migration to gradle, removing bsh.jar dependency from the 
> project, and improve readability and fonctionnalities following 
> [~deepak.dixit] idea expressed here 
> https://issues.apache.org/jira/browse/OFBIZ-7576?focusedCommentId=15347972



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


[jira] [Updated] (OFBIZ-7763) Replace bshInterpreter with groovyShell

2016-07-11 Thread Gil Portenseigne (JIRA)

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

Gil Portenseigne updated OFBIZ-7763:

Attachment: OFBIZ-7763.patch

Last rev of my patch, i will commit it soon

> Replace bshInterpreter with groovyShell
> ---
>
> Key: OFBIZ-7763
> URL: https://issues.apache.org/jira/browse/OFBIZ-7763
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Attachments: OFBIZ-7763.patch, OFBIZ-7763.patch, 
> beanshell-removal-part1.patch
>
>
> To support the migration to gradle, removing bsh.jar dependency from the 
> project, and improve readability and fonctionnalities following 
> [~deepak.dixit] idea expressed here 
> https://issues.apache.org/jira/browse/OFBIZ-7576?focusedCommentId=15347972



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


[jira] [Updated] (OFBIZ-7763) Replace bshInterpreter with groovyShell

2016-07-11 Thread Gil Portenseigne (JIRA)

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

Gil Portenseigne updated OFBIZ-7763:

Attachment: (was: OFBIZ-7763.patch)

> Replace bshInterpreter with groovyShell
> ---
>
> Key: OFBIZ-7763
> URL: https://issues.apache.org/jira/browse/OFBIZ-7763
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Attachments: OFBIZ-7763.patch, OFBIZ-7763.patch, 
> beanshell-removal-part1.patch
>
>
> To support the migration to gradle, removing bsh.jar dependency from the 
> project, and improve readability and fonctionnalities following 
> [~deepak.dixit] idea expressed here 
> https://issues.apache.org/jira/browse/OFBIZ-7576?focusedCommentId=15347972



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


Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Michael Brohl

+1

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 11.07.16 um 11:14 schrieb Sharan Foga:

Hi Everyone

Following on from the discussion on the user mailing list and the consensus to 
leave 14.12 and 15.12 as unreleased branches.

I'd like to start thinking about the support timeframe for backporting bug 
fixes into these branches. My initial suggestion is 12 months. What do other 
people think?

Thanks
Sharan






smime.p7s
Description: S/MIME Cryptographic Signature


buildbot failure in on ofbiz-trunk

2016-07-11 Thread 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/1068

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

Buildslave for this Build: silvanus_ubuntu

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

BUILD FAILED: failed shell_1

Sincerely,
 -The Buildbot





[jira] [Commented] (OFBIZ-7765) Replace call with

2016-07-11 Thread Deepak Dixit (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370525#comment-15370525
 ] 

Deepak Dixit commented on OFBIZ-7765:
-

Thanks Rishi, this has been fixed at r#1752140

> Replace  call with 

[jira] [Commented] (OFBIZ-7763) Replace bshInterpreter with groovyShell

2016-07-11 Thread Rishi Solanki (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370508#comment-15370508
 ] 

Rishi Solanki commented on OFBIZ-7763:
--

Reported issue with probable solution on sub-ticket: 
https://issues.apache.org/jira/browse/OFBIZ-7765

> Replace bshInterpreter with groovyShell
> ---
>
> Key: OFBIZ-7763
> URL: https://issues.apache.org/jira/browse/OFBIZ-7763
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Attachments: OFBIZ-7763.patch, OFBIZ-7763.patch, 
> beanshell-removal-part1.patch
>
>
> To support the migration to gradle, removing bsh.jar dependency from the 
> project, and improve readability and fonctionnalities following 
> [~deepak.dixit] idea expressed here 
> https://issues.apache.org/jira/browse/OFBIZ-7576?focusedCommentId=15347972



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


[jira] [Commented] (OFBIZ-7765) Replace call with

2016-07-11 Thread Rishi Solanki (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370505#comment-15370505
 ] 

Rishi Solanki commented on OFBIZ-7765:
--

Not sure if this is right ticket to report this issue;

When user tries to browse - https://localhost:8443/webtools/control/ServiceList
receives following exception:
{code}
org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
[component://webtools/widget/ServiceScreens.xml#ServiceList]: 
java.lang.IllegalArgumentException: Error running script at location 
[component://webtools/groovyScripts/service/AvailableServices.groovy]: 
org.ofbiz.service.GenericServiceException: Cannot locate service by name 
(testBsh) (Error running script at location 
[component://webtools/groovyScripts/service/AvailableServices.groovy]: 
org.ofbiz.service.GenericServiceException: Cannot locate service by name 
(testBsh))
{code}

On further look into the issue found that testBsh service definition commented 
in the services_test.xml and removed from other places. But this is in use 
groups_test.xml and secas_test.xml of framework/common/./. After commenting 
both entries I'm able to browse the shared screen of service list.

Thanks!

> Replace  call with 

[jira] [Updated] (OFBIZ-3739) PrepareFind Service Ignores timeZone Parameter When Performing Date/Time Calculations

2016-07-11 Thread Supatthra Nawicha (JIRA)

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

Supatthra Nawicha updated OFBIZ-3739:
-
Attachment: OFBIZ-3739.patch

> PrepareFind Service Ignores timeZone Parameter When Performing Date/Time 
> Calculations
> -
>
> Key: OFBIZ-3739
> URL: https://issues.apache.org/jira/browse/OFBIZ-3739
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04, Trunk
>Reporter: Adrian Crum
> Attachments: OFBIZ-3739.patch
>
>
> In FindServices.java, the prepareFind service calls the createCondition 
> method, which in turn calls the dayStart method - a method that calculates 
> the start of the day based on a Timestamp value. That calculation ignores the 
> timeZone parameter passed to the prepareFind service, so the results are 
> inaccurate.



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


Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Pierre Smits
Thanks Jacopo.

Now that we have the initial intent of this thread resolved, shall we
continue the suggestion by Sharan regarding backporting bug fixes from
trunk to the r14.12 and 15.12 branched in a new thread?

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 11:30 AM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Thanks for your suggestion, we will definitely make sure that our website
> will provide the correct information in a clear way.
>
> Jacopo
>
> On Mon, Jul 11, 2016 at 11:27 AM, Pierre Smits 
> wrote:
>
> > I just want unambiguous communications from the project to its community
> > (contributors and adopters).
> >
> > Messages as 'what I understand' are personal viewpoints, and  - like
> other
> > posting that starts in similar ways - dilute perceptions of the project's
> > direction with respect to its products.
> >
> > If all are on the same page, then there is some shared agreement on the
> > conclusion derived from the thread. This means that an explicit statement
> > can be made by the PMC regarding the short term action and sent to the
> > entire community (the user ml), so that every contributor and adopters
> can
> > determine what to expect from the project.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Mon, Jul 11, 2016 at 11:11 AM, Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> >
> > > I went thru all the comments in this thread and it seems to me that the
> > > summary that Sharan provided based on the discussion on the user list
> is
> > a
> > > good way to go to deal with Pierre's and other's concerns and with the
> > > concerns of the developers: it seems we are all on the same page.
> > >
> > > Jacopo
> > >
> > > On Mon, Jul 11, 2016 at 10:55 AM, Pierre Smits  >
> > > wrote:
> > >
> > > > Hi Taher,
> > > >
> > > > It seems you did not read the entire posting.
> > > >
> > > > The ASF doesn't object from having external libraries (3rd party jar
> > > files)
> > > > in the convenience downloads projects make available. This is what
> > OFBiz
> > > > does also.
> > > >
> > > > If there is a problem within the release process, regarding the
> > external
> > > > libraries, then there are more ways around that than to fix something
> > > that
> > > > is not broken.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM 
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
> > > > slidingfilame...@gmail.com> wrote:
> > > >
> > > > > Hi Pierre,
> > > > >
> > > > > It seems you did not read the entire sentence, so I will write here
> > > again
> > > > > from the JIRA you mentioned.
> > > > >
> > > > > From Jacques: "There is no problems having an external jar (and
> even
> > > > more)
> > > > > in the repo. The pb is only when we release"
> > > > >
> > > > > This is exactly what Sharan is saying above. You can keep Jars in
> > > > branches,
> > > > > "Releases" are where you are not supposed to keep binaries.
> > > > >
> > > > > HTH
> > > > >
> > > > > Taher Alkhateeb
> > > > >
> > > > > On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits <
> > pierre.sm...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Jacques posted this recently in a JIRA issue:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886
> > > > > >
> > > > > > Stating that there is no issue with having 3rd party libraries
> (jar
> > > > > files)
> > > > > > in the repo.
> > > > > > Also the ASF does not object to have 3rd party libraries in the
> > > > > convenience
> > > > > > downloads that the project makes available.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Pierre Smits
> > > > > >
> > > > > > ORRTIZ.COM 
> > > > > > OFBiz based solutions & services
> > > > > >
> > > > > > OFBiz Extensions Marketplace
> > > > > > http://oem.ofbizci.net/oci-2/
> > > > > >
> > > > > > On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga <
> > sharan.f...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Pierre
> > > > > > >
> > > > > > > Thanks for starting the discussion. I had expected to start it
> > this
> > > > > week,
> > > > > > > giving us time to continue stabilising and consolidating the
> > gradle
> > > > > work
> > > > > > in
> > > > > > > the trunk from last week. (Also a minor correction – I
> > 'suggested'
> > > > not
> > > > > > > 'promised').
> > > > > 

Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Deepak Dixit
+1

assuming 12 months from today, We can add these support date on release
page as well
https://ofbiz.apache.org/download.html

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Mon, Jul 11, 2016 at 2:49 PM, Taher Alkhateeb  wrote:

> +1
>
> 12 months seems a reasonable time frame for people to adjust to the
> changes. I am assuming 12 months from today, not from the branch creation
> date right?
>
> On Mon, Jul 11, 2016 at 12:16 PM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > 12 months seems a reasonable timeframe to me.
> >
> > Jacopo
> >
> > On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga 
> > wrote:
> >
> > > Hi Everyone
> > >
> > > Following on from the discussion on the user mailing list and the
> > > consensus to leave 14.12 and 15.12 as unreleased branches.
> > >
> > > I'd like to start thinking about the support timeframe for backporting
> > bug
> > > fixes into these branches. My initial suggestion is 12 months. What do
> > > other people think?
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> >
>


Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Jacopo Cappellato
Thanks for your suggestion, we will definitely make sure that our website
will provide the correct information in a clear way.

Jacopo

On Mon, Jul 11, 2016 at 11:27 AM, Pierre Smits 
wrote:

> I just want unambiguous communications from the project to its community
> (contributors and adopters).
>
> Messages as 'what I understand' are personal viewpoints, and  - like other
> posting that starts in similar ways - dilute perceptions of the project's
> direction with respect to its products.
>
> If all are on the same page, then there is some shared agreement on the
> conclusion derived from the thread. This means that an explicit statement
> can be made by the PMC regarding the short term action and sent to the
> entire community (the user ml), so that every contributor and adopters can
> determine what to expect from the project.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Mon, Jul 11, 2016 at 11:11 AM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > I went thru all the comments in this thread and it seems to me that the
> > summary that Sharan provided based on the discussion on the user list is
> a
> > good way to go to deal with Pierre's and other's concerns and with the
> > concerns of the developers: it seems we are all on the same page.
> >
> > Jacopo
> >
> > On Mon, Jul 11, 2016 at 10:55 AM, Pierre Smits 
> > wrote:
> >
> > > Hi Taher,
> > >
> > > It seems you did not read the entire posting.
> > >
> > > The ASF doesn't object from having external libraries (3rd party jar
> > files)
> > > in the convenience downloads projects make available. This is what
> OFBiz
> > > does also.
> > >
> > > If there is a problem within the release process, regarding the
> external
> > > libraries, then there are more ways around that than to fix something
> > that
> > > is not broken.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
> > > slidingfilame...@gmail.com> wrote:
> > >
> > > > Hi Pierre,
> > > >
> > > > It seems you did not read the entire sentence, so I will write here
> > again
> > > > from the JIRA you mentioned.
> > > >
> > > > From Jacques: "There is no problems having an external jar (and even
> > > more)
> > > > in the repo. The pb is only when we release"
> > > >
> > > > This is exactly what Sharan is saying above. You can keep Jars in
> > > branches,
> > > > "Releases" are where you are not supposed to keep binaries.
> > > >
> > > > HTH
> > > >
> > > > Taher Alkhateeb
> > > >
> > > > On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits <
> pierre.sm...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Jacques posted this recently in a JIRA issue:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886
> > > > >
> > > > > Stating that there is no issue with having 3rd party libraries (jar
> > > > files)
> > > > > in the repo.
> > > > > Also the ASF does not object to have 3rd party libraries in the
> > > > convenience
> > > > > downloads that the project makes available.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Pierre Smits
> > > > >
> > > > > ORRTIZ.COM 
> > > > > OFBiz based solutions & services
> > > > >
> > > > > OFBiz Extensions Marketplace
> > > > > http://oem.ofbizci.net/oci-2/
> > > > >
> > > > > On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga <
> sharan.f...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi Pierre
> > > > > >
> > > > > > Thanks for starting the discussion. I had expected to start it
> this
> > > > week,
> > > > > > giving us time to continue stabilising and consolidating the
> gradle
> > > > work
> > > > > in
> > > > > > the trunk from last week. (Also a minor correction – I
> 'suggested'
> > > not
> > > > > > 'promised').
> > > > > >
> > > > > > Anyway my suggestion was to take the discussion to this list to
> > talk
> > > > > about
> > > > > > the next steps. So just as a recap from the user mailing list, my
> > > > summary
> > > > > > of the discussion there included the following points that are
> > > relevant
> > > > > to
> > > > > > the 14.12 and 15.12 unreleased branches.
> > > > > >
> > > > > > 1) - We would not backport any of the gradle changes into the
> > 14.12.
> > > or
> > > > > > 15.12
> > > > > > branches because it would cause instability
> > > > > > 2) - We would leave 14.12 and 15.12 as unreleased branches as
> they
> > > are
> > > > > now
> > > > > > (and not
> > > > > > make them into releases as to do that we would need to remove all
> > the
> > > > jar
> > > 

Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Pierre Smits
I just want unambiguous communications from the project to its community
(contributors and adopters).

Messages as 'what I understand' are personal viewpoints, and  - like other
posting that starts in similar ways - dilute perceptions of the project's
direction with respect to its products.

If all are on the same page, then there is some shared agreement on the
conclusion derived from the thread. This means that an explicit statement
can be made by the PMC regarding the short term action and sent to the
entire community (the user ml), so that every contributor and adopters can
determine what to expect from the project.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 11:11 AM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> I went thru all the comments in this thread and it seems to me that the
> summary that Sharan provided based on the discussion on the user list is a
> good way to go to deal with Pierre's and other's concerns and with the
> concerns of the developers: it seems we are all on the same page.
>
> Jacopo
>
> On Mon, Jul 11, 2016 at 10:55 AM, Pierre Smits 
> wrote:
>
> > Hi Taher,
> >
> > It seems you did not read the entire posting.
> >
> > The ASF doesn't object from having external libraries (3rd party jar
> files)
> > in the convenience downloads projects make available. This is what OFBiz
> > does also.
> >
> > If there is a problem within the release process, regarding the external
> > libraries, then there are more ways around that than to fix something
> that
> > is not broken.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
> > slidingfilame...@gmail.com> wrote:
> >
> > > Hi Pierre,
> > >
> > > It seems you did not read the entire sentence, so I will write here
> again
> > > from the JIRA you mentioned.
> > >
> > > From Jacques: "There is no problems having an external jar (and even
> > more)
> > > in the repo. The pb is only when we release"
> > >
> > > This is exactly what Sharan is saying above. You can keep Jars in
> > branches,
> > > "Releases" are where you are not supposed to keep binaries.
> > >
> > > HTH
> > >
> > > Taher Alkhateeb
> > >
> > > On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits  >
> > > wrote:
> > >
> > > > Jacques posted this recently in a JIRA issue:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886
> > > >
> > > > Stating that there is no issue with having 3rd party libraries (jar
> > > files)
> > > > in the repo.
> > > > Also the ASF does not object to have 3rd party libraries in the
> > > convenience
> > > > downloads that the project makes available.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM 
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga  >
> > > > wrote:
> > > >
> > > > > Hi Pierre
> > > > >
> > > > > Thanks for starting the discussion. I had expected to start it this
> > > week,
> > > > > giving us time to continue stabilising and consolidating the gradle
> > > work
> > > > in
> > > > > the trunk from last week. (Also a minor correction – I 'suggested'
> > not
> > > > > 'promised').
> > > > >
> > > > > Anyway my suggestion was to take the discussion to this list to
> talk
> > > > about
> > > > > the next steps. So just as a recap from the user mailing list, my
> > > summary
> > > > > of the discussion there included the following points that are
> > relevant
> > > > to
> > > > > the 14.12 and 15.12 unreleased branches.
> > > > >
> > > > > 1) - We would not backport any of the gradle changes into the
> 14.12.
> > or
> > > > > 15.12
> > > > > branches because it would cause instability
> > > > > 2) - We would leave 14.12 and 15.12 as unreleased branches as they
> > are
> > > > now
> > > > > (and not
> > > > > make them into releases as to do that we would need to remove all
> the
> > > jar
> > > > > files
> > > > > and this would create instability).
> > > > > 3) - The benefits for our community are that developers and service
> > > > > providers will
> > > > > still have access to the complete codebase for 14.12 and 15.12
> > > including
> > > > > the
> > > > > special purpose components to be able to support their client base.
> > > > >
> > > > > My understanding was that the community did reach a consensus on
> > these
> > > > > points. No-one responded to correct, update nor oppose any of these
> > > > 

Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread gil portenseigne

I answered the wrong thread but +1 !

Assuming from today too :)

Gil

On 11/07/2016 11:19, Taher Alkhateeb wrote:

+1

12 months seems a reasonable time frame for people to adjust to the
changes. I am assuming 12 months from today, not from the branch creation
date right?

On Mon, Jul 11, 2016 at 12:16 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


12 months seems a reasonable timeframe to me.

Jacopo

On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga 
wrote:


Hi Everyone

Following on from the discussion on the user mailing list and the
consensus to leave 14.12 and 15.12 as unreleased branches.

I'd like to start thinking about the support timeframe for backporting

bug

fixes into these branches. My initial suggestion is 12 months. What do
other people think?

Thanks
Sharan






Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread gil portenseigne

Hi Sharan,

Thanks for the sum-up, that's quite i had got in mind.

I think that 12 month seems OK,

Gil

On 11/07/2016 10:33, Sharan Foga wrote:

As an initial suggestion – would 12 months be a good timeframe to work with. 
What do other people think?




Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Taher Alkhateeb
+1

12 months seems a reasonable time frame for people to adjust to the
changes. I am assuming 12 months from today, not from the branch creation
date right?

On Mon, Jul 11, 2016 at 12:16 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> 12 months seems a reasonable timeframe to me.
>
> Jacopo
>
> On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga 
> wrote:
>
> > Hi Everyone
> >
> > Following on from the discussion on the user mailing list and the
> > consensus to leave 14.12 and 15.12 as unreleased branches.
> >
> > I'd like to start thinking about the support timeframe for backporting
> bug
> > fixes into these branches. My initial suggestion is 12 months. What do
> > other people think?
> >
> > Thanks
> > Sharan
> >
> >
>


Re: Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Jacopo Cappellato
12 months seems a reasonable timeframe to me.

Jacopo

On Mon, Jul 11, 2016 at 11:14 AM, Sharan Foga  wrote:

> Hi Everyone
>
> Following on from the discussion on the user mailing list and the
> consensus to leave 14.12 and 15.12 as unreleased branches.
>
> I'd like to start thinking about the support timeframe for backporting bug
> fixes into these branches. My initial suggestion is 12 months. What do
> other people think?
>
> Thanks
> Sharan
>
>


Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Jacopo Cappellato
On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga  wrote:

> ...
> In fact the main discussion that I wanted to start here was more related
> to support for 14.12 and 15.12.  As we are in transition to gradle, we need
> to define a time period for backporting bug fixes into these unreleased
> branches.
>
> As an initial suggestion – would 12 months be a good timeframe to work
> with. What do other people think?
>

12 months seems a reasonable timeframe to me.

Jacopo


Support timeframe for 14.12 and 15.12 unreleased branches

2016-07-11 Thread Sharan Foga
Hi Everyone

Following on from the discussion on the user mailing list and the consensus to 
leave 14.12 and 15.12 as unreleased branches.

I'd like to start thinking about the support timeframe for backporting bug 
fixes into these branches. My initial suggestion is 12 months. What do other 
people think?

Thanks
Sharan



Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Sharan Foga
Hi Pierre

I've responded to your initial questions but it sounds like you want to discuss 
something other than the support of 14.12 and 15.12 so I'll start a separate 
thread for the support discussion.

Thanks
Sharan

On 2016-07-11 10:55 (+0200), Pierre Smits  wrote: 
> Hi Taher,
> 
> It seems you did not read the entire posting.
> 
> The ASF doesn't object from having external libraries (3rd party jar files)
> in the convenience downloads projects make available. This is what OFBiz
> does also.
> 
> If there is a problem within the release process, regarding the external
> libraries, then there are more ways around that than to fix something that
> is not broken.
> 
> Best regards,
> 
> Pierre Smits
> 
> ORRTIZ.COM 
> OFBiz based solutions & services
> 
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
> 
> On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
> 
> > Hi Pierre,
> >
> > It seems you did not read the entire sentence, so I will write here again
> > from the JIRA you mentioned.
> >
> > From Jacques: "There is no problems having an external jar (and even more)
> > in the repo. The pb is only when we release"
> >
> > This is exactly what Sharan is saying above. You can keep Jars in branches,
> > "Releases" are where you are not supposed to keep binaries.
> >
> > HTH
> >
> > Taher Alkhateeb
> >
> > On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits 
> > wrote:
> >
> > > Jacques posted this recently in a JIRA issue:
> > >
> > >
> > https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886
> > >
> > > Stating that there is no issue with having 3rd party libraries (jar
> > files)
> > > in the repo.
> > > Also the ASF does not object to have 3rd party libraries in the
> > convenience
> > > downloads that the project makes available.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga 
> > > wrote:
> > >
> > > > Hi Pierre
> > > >
> > > > Thanks for starting the discussion. I had expected to start it this
> > week,
> > > > giving us time to continue stabilising and consolidating the gradle
> > work
> > > in
> > > > the trunk from last week. (Also a minor correction – I 'suggested' not
> > > > 'promised').
> > > >
> > > > Anyway my suggestion was to take the discussion to this list to talk
> > > about
> > > > the next steps. So just as a recap from the user mailing list, my
> > summary
> > > > of the discussion there included the following points that are relevant
> > > to
> > > > the 14.12 and 15.12 unreleased branches.
> > > >
> > > > 1) - We would not backport any of the gradle changes into the 14.12. or
> > > > 15.12
> > > > branches because it would cause instability
> > > > 2) - We would leave 14.12 and 15.12 as unreleased branches as they are
> > > now
> > > > (and not
> > > > make them into releases as to do that we would need to remove all the
> > jar
> > > > files
> > > > and this would create instability).
> > > > 3) - The benefits for our community are that developers and service
> > > > providers will
> > > > still have access to the complete codebase for 14.12 and 15.12
> > including
> > > > the
> > > > special purpose components to be able to support their client base.
> > > >
> > > > My understanding was that the community did reach a consensus on these
> > > > points. No-one responded to correct, update nor oppose any of these
> > > points.
> > > >
> > > > Both of your questions are answered by the second point. So based on
> > this
> > > > the responses to your questions are:
> > > >
> > > > - No, we are not going to delete the external libraries from the
> > > > unreleased branches 14.12 and 15.12  (if they remain as unreleased
> > > branches
> > > > the there is no need to remove the external jars)
> > > >
> > > > - No, we are not going to delete the entire unreleased branches 14.12
> > and
> > > > 15.12 (we are leaving these available so that our community will still
> > > have
> > > > access to the complete codebase including the special purpose
> > components)
> > > >
> > > > In fact the main discussion that I wanted to start here was more
> > related
> > > > to support for 14.12 and 15.12.  As we are in transition to gradle, we
> > > need
> > > > to define a time period for backporting bug fixes into these unreleased
> > > > branches.
> > > >
> > > > As an initial suggestion – would 12 months be a good timeframe to work
> > > > with. What do other people think?
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > > On 2016-07-10 10:48 (+0200), Pierre Smits 
> > > wrote:
> > > > > Hi all,
> > > > >
> > > > > 

Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Jacopo Cappellato
I went thru all the comments in this thread and it seems to me that the
summary that Sharan provided based on the discussion on the user list is a
good way to go to deal with Pierre's and other's concerns and with the
concerns of the developers: it seems we are all on the same page.

Jacopo

On Mon, Jul 11, 2016 at 10:55 AM, Pierre Smits 
wrote:

> Hi Taher,
>
> It seems you did not read the entire posting.
>
> The ASF doesn't object from having external libraries (3rd party jar files)
> in the convenience downloads projects make available. This is what OFBiz
> does also.
>
> If there is a problem within the release process, regarding the external
> libraries, then there are more ways around that than to fix something that
> is not broken.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
> > Hi Pierre,
> >
> > It seems you did not read the entire sentence, so I will write here again
> > from the JIRA you mentioned.
> >
> > From Jacques: "There is no problems having an external jar (and even
> more)
> > in the repo. The pb is only when we release"
> >
> > This is exactly what Sharan is saying above. You can keep Jars in
> branches,
> > "Releases" are where you are not supposed to keep binaries.
> >
> > HTH
> >
> > Taher Alkhateeb
> >
> > On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits 
> > wrote:
> >
> > > Jacques posted this recently in a JIRA issue:
> > >
> > >
> >
> https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886
> > >
> > > Stating that there is no issue with having 3rd party libraries (jar
> > files)
> > > in the repo.
> > > Also the ASF does not object to have 3rd party libraries in the
> > convenience
> > > downloads that the project makes available.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga 
> > > wrote:
> > >
> > > > Hi Pierre
> > > >
> > > > Thanks for starting the discussion. I had expected to start it this
> > week,
> > > > giving us time to continue stabilising and consolidating the gradle
> > work
> > > in
> > > > the trunk from last week. (Also a minor correction – I 'suggested'
> not
> > > > 'promised').
> > > >
> > > > Anyway my suggestion was to take the discussion to this list to talk
> > > about
> > > > the next steps. So just as a recap from the user mailing list, my
> > summary
> > > > of the discussion there included the following points that are
> relevant
> > > to
> > > > the 14.12 and 15.12 unreleased branches.
> > > >
> > > > 1) - We would not backport any of the gradle changes into the 14.12.
> or
> > > > 15.12
> > > > branches because it would cause instability
> > > > 2) - We would leave 14.12 and 15.12 as unreleased branches as they
> are
> > > now
> > > > (and not
> > > > make them into releases as to do that we would need to remove all the
> > jar
> > > > files
> > > > and this would create instability).
> > > > 3) - The benefits for our community are that developers and service
> > > > providers will
> > > > still have access to the complete codebase for 14.12 and 15.12
> > including
> > > > the
> > > > special purpose components to be able to support their client base.
> > > >
> > > > My understanding was that the community did reach a consensus on
> these
> > > > points. No-one responded to correct, update nor oppose any of these
> > > points.
> > > >
> > > > Both of your questions are answered by the second point. So based on
> > this
> > > > the responses to your questions are:
> > > >
> > > > - No, we are not going to delete the external libraries from the
> > > > unreleased branches 14.12 and 15.12  (if they remain as unreleased
> > > branches
> > > > the there is no need to remove the external jars)
> > > >
> > > > - No, we are not going to delete the entire unreleased branches 14.12
> > and
> > > > 15.12 (we are leaving these available so that our community will
> still
> > > have
> > > > access to the complete codebase including the special purpose
> > components)
> > > >
> > > > In fact the main discussion that I wanted to start here was more
> > related
> > > > to support for 14.12 and 15.12.  As we are in transition to gradle,
> we
> > > need
> > > > to define a time period for backporting bug fixes into these
> unreleased
> > > > branches.
> > > >
> > > > As an initial suggestion – would 12 months be a good timeframe to
> work
> > > > with. What do other people think?
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > > On 2016-07-10 10:48 (+0200), 

[jira] [Updated] (OFBIZ-7775) Cleanup JavaDocs to be standards compliant

2016-07-11 Thread Taher Alkhateeb (JIRA)

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

Taher Alkhateeb updated OFBIZ-7775:
---
Summary: Cleanup JavaDocs to be standards compliant  (was: Fixes Javadoc in 
sources)

> Cleanup JavaDocs to be standards compliant
> --
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> To check what to fix simply run gradlew javadoc



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


[jira] [Updated] (OFBIZ-7775) Fixes Javadoc in sources

2016-07-11 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux updated OFBIZ-7775:
---
Description: To check what to fix simply run gradlew javadoc  (was: To 
check what to fix simply run gradlew javadoc
But before change back )

> Fixes Javadoc in sources
> 
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> To check what to fix simply run gradlew javadoc



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


[jira] [Updated] (OFBIZ-7775) Fixes Javadoc in sources

2016-07-11 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux updated OFBIZ-7775:
---
Description: 
To check what to fix simply run gradlew javadoc
But before change back 

  was:To check what to fix simply run gradlew javadoc


> Fixes Javadoc in sources
> 
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> To check what to fix simply run gradlew javadoc
> But before change back 



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


Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Pierre Smits
Hi Taher,

It seems you did not read the entire posting.

The ASF doesn't object from having external libraries (3rd party jar files)
in the convenience downloads projects make available. This is what OFBiz
does also.

If there is a problem within the release process, regarding the external
libraries, then there are more ways around that than to fix something that
is not broken.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> Hi Pierre,
>
> It seems you did not read the entire sentence, so I will write here again
> from the JIRA you mentioned.
>
> From Jacques: "There is no problems having an external jar (and even more)
> in the repo. The pb is only when we release"
>
> This is exactly what Sharan is saying above. You can keep Jars in branches,
> "Releases" are where you are not supposed to keep binaries.
>
> HTH
>
> Taher Alkhateeb
>
> On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits 
> wrote:
>
> > Jacques posted this recently in a JIRA issue:
> >
> >
> https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886
> >
> > Stating that there is no issue with having 3rd party libraries (jar
> files)
> > in the repo.
> > Also the ASF does not object to have 3rd party libraries in the
> convenience
> > downloads that the project makes available.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga 
> > wrote:
> >
> > > Hi Pierre
> > >
> > > Thanks for starting the discussion. I had expected to start it this
> week,
> > > giving us time to continue stabilising and consolidating the gradle
> work
> > in
> > > the trunk from last week. (Also a minor correction – I 'suggested' not
> > > 'promised').
> > >
> > > Anyway my suggestion was to take the discussion to this list to talk
> > about
> > > the next steps. So just as a recap from the user mailing list, my
> summary
> > > of the discussion there included the following points that are relevant
> > to
> > > the 14.12 and 15.12 unreleased branches.
> > >
> > > 1) - We would not backport any of the gradle changes into the 14.12. or
> > > 15.12
> > > branches because it would cause instability
> > > 2) - We would leave 14.12 and 15.12 as unreleased branches as they are
> > now
> > > (and not
> > > make them into releases as to do that we would need to remove all the
> jar
> > > files
> > > and this would create instability).
> > > 3) - The benefits for our community are that developers and service
> > > providers will
> > > still have access to the complete codebase for 14.12 and 15.12
> including
> > > the
> > > special purpose components to be able to support their client base.
> > >
> > > My understanding was that the community did reach a consensus on these
> > > points. No-one responded to correct, update nor oppose any of these
> > points.
> > >
> > > Both of your questions are answered by the second point. So based on
> this
> > > the responses to your questions are:
> > >
> > > - No, we are not going to delete the external libraries from the
> > > unreleased branches 14.12 and 15.12  (if they remain as unreleased
> > branches
> > > the there is no need to remove the external jars)
> > >
> > > - No, we are not going to delete the entire unreleased branches 14.12
> and
> > > 15.12 (we are leaving these available so that our community will still
> > have
> > > access to the complete codebase including the special purpose
> components)
> > >
> > > In fact the main discussion that I wanted to start here was more
> related
> > > to support for 14.12 and 15.12.  As we are in transition to gradle, we
> > need
> > > to define a time period for backporting bug fixes into these unreleased
> > > branches.
> > >
> > > As an initial suggestion – would 12 months be a good timeframe to work
> > > with. What do other people think?
> > >
> > > Thanks
> > > Sharan
> > >
> > > On 2016-07-10 10:48 (+0200), Pierre Smits 
> > wrote:
> > > > Hi all,
> > > >
> > > > Sharan promised the greater community in the '[*[DISCUSSION]*
> > > *Anticipate*
> > > >  the *end* of *life* of the *13.07* branch and backport some non-bug
> > > > related changes to the 14.12 and 15.12 branches
> > > > ' starting via
> > > > http://ofbiz.markmail.org/message/nqo5xacngpspytvf ) that the
> > discussion
> > > > would continue in the dev ml.
> > > >
> > > > As I haven't seen her start that discussion, I will:
> > > >
> > > > Given that Sharan made clear that external libraries as per ASF
> > > guidelines
> > > > and 

Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Taher Alkhateeb
Hi Pierre,

It seems you did not read the entire sentence, so I will write here again
from the JIRA you mentioned.

>From Jacques: "There is no problems having an external jar (and even more)
in the repo. The pb is only when we release"

This is exactly what Sharan is saying above. You can keep Jars in branches,
"Releases" are where you are not supposed to keep binaries.

HTH

Taher Alkhateeb

On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits 
wrote:

> Jacques posted this recently in a JIRA issue:
>
> https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886
>
> Stating that there is no issue with having 3rd party libraries (jar files)
> in the repo.
> Also the ASF does not object to have 3rd party libraries in the convenience
> downloads that the project makes available.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga 
> wrote:
>
> > Hi Pierre
> >
> > Thanks for starting the discussion. I had expected to start it this week,
> > giving us time to continue stabilising and consolidating the gradle work
> in
> > the trunk from last week. (Also a minor correction – I 'suggested' not
> > 'promised').
> >
> > Anyway my suggestion was to take the discussion to this list to talk
> about
> > the next steps. So just as a recap from the user mailing list, my summary
> > of the discussion there included the following points that are relevant
> to
> > the 14.12 and 15.12 unreleased branches.
> >
> > 1) - We would not backport any of the gradle changes into the 14.12. or
> > 15.12
> > branches because it would cause instability
> > 2) - We would leave 14.12 and 15.12 as unreleased branches as they are
> now
> > (and not
> > make them into releases as to do that we would need to remove all the jar
> > files
> > and this would create instability).
> > 3) - The benefits for our community are that developers and service
> > providers will
> > still have access to the complete codebase for 14.12 and 15.12 including
> > the
> > special purpose components to be able to support their client base.
> >
> > My understanding was that the community did reach a consensus on these
> > points. No-one responded to correct, update nor oppose any of these
> points.
> >
> > Both of your questions are answered by the second point. So based on this
> > the responses to your questions are:
> >
> > - No, we are not going to delete the external libraries from the
> > unreleased branches 14.12 and 15.12  (if they remain as unreleased
> branches
> > the there is no need to remove the external jars)
> >
> > - No, we are not going to delete the entire unreleased branches 14.12 and
> > 15.12 (we are leaving these available so that our community will still
> have
> > access to the complete codebase including the special purpose components)
> >
> > In fact the main discussion that I wanted to start here was more related
> > to support for 14.12 and 15.12.  As we are in transition to gradle, we
> need
> > to define a time period for backporting bug fixes into these unreleased
> > branches.
> >
> > As an initial suggestion – would 12 months be a good timeframe to work
> > with. What do other people think?
> >
> > Thanks
> > Sharan
> >
> > On 2016-07-10 10:48 (+0200), Pierre Smits 
> wrote:
> > > Hi all,
> > >
> > > Sharan promised the greater community in the '[*[DISCUSSION]*
> > *Anticipate*
> > >  the *end* of *life* of the *13.07* branch and backport some non-bug
> > > related changes to the 14.12 and 15.12 branches
> > > ' starting via
> > > http://ofbiz.markmail.org/message/nqo5xacngpspytvf ) that the
> discussion
> > > would continue in the dev ml.
> > >
> > > As I haven't seen her start that discussion, I will:
> > >
> > > Given that Sharan made clear that external libraries as per ASF
> > guidelines
> > > and rulings, we need to decide what to do with the r14.x and the r15.x
> > > branches, as these hold all the external libraries required to build,
> > test
> > > and/or run a copy from that branch in a separate environment.
> > >
> > >
> > > So the questions are:
> > >
> > >
> > >- are we going to delete the external libraries from the branches,
> or
> > >- are we going to delete the entire branches?
> > >
> > >
> > > I believe we should have this addressed in order to provide the greater
> > > community with a clear answer as what to expect regarding future
> > adoptions
> > > and/or upgrades.
> > >
> > > Best regards,
> > >
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> >
>


Re: [DISCUSSION] What are we going to do with the R14.x and r15.x?

2016-07-11 Thread Pierre Smits
Jacques posted this recently in a JIRA issue:
https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15369886#comment-15369886

Stating that there is no issue with having 3rd party libraries (jar files)
in the repo.
Also the ASF does not object to have 3rd party libraries in the convenience
downloads that the project makes available.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga  wrote:

> Hi Pierre
>
> Thanks for starting the discussion. I had expected to start it this week,
> giving us time to continue stabilising and consolidating the gradle work in
> the trunk from last week. (Also a minor correction – I 'suggested' not
> 'promised').
>
> Anyway my suggestion was to take the discussion to this list to talk about
> the next steps. So just as a recap from the user mailing list, my summary
> of the discussion there included the following points that are relevant to
> the 14.12 and 15.12 unreleased branches.
>
> 1) - We would not backport any of the gradle changes into the 14.12. or
> 15.12
> branches because it would cause instability
> 2) - We would leave 14.12 and 15.12 as unreleased branches as they are now
> (and not
> make them into releases as to do that we would need to remove all the jar
> files
> and this would create instability).
> 3) - The benefits for our community are that developers and service
> providers will
> still have access to the complete codebase for 14.12 and 15.12 including
> the
> special purpose components to be able to support their client base.
>
> My understanding was that the community did reach a consensus on these
> points. No-one responded to correct, update nor oppose any of these points.
>
> Both of your questions are answered by the second point. So based on this
> the responses to your questions are:
>
> - No, we are not going to delete the external libraries from the
> unreleased branches 14.12 and 15.12  (if they remain as unreleased branches
> the there is no need to remove the external jars)
>
> - No, we are not going to delete the entire unreleased branches 14.12 and
> 15.12 (we are leaving these available so that our community will still have
> access to the complete codebase including the special purpose components)
>
> In fact the main discussion that I wanted to start here was more related
> to support for 14.12 and 15.12.  As we are in transition to gradle, we need
> to define a time period for backporting bug fixes into these unreleased
> branches.
>
> As an initial suggestion – would 12 months be a good timeframe to work
> with. What do other people think?
>
> Thanks
> Sharan
>
> On 2016-07-10 10:48 (+0200), Pierre Smits  wrote:
> > Hi all,
> >
> > Sharan promised the greater community in the '[*[DISCUSSION]*
> *Anticipate*
> >  the *end* of *life* of the *13.07* branch and backport some non-bug
> > related changes to the 14.12 and 15.12 branches
> > ' starting via
> > http://ofbiz.markmail.org/message/nqo5xacngpspytvf ) that the discussion
> > would continue in the dev ml.
> >
> > As I haven't seen her start that discussion, I will:
> >
> > Given that Sharan made clear that external libraries as per ASF
> guidelines
> > and rulings, we need to decide what to do with the r14.x and the r15.x
> > branches, as these hold all the external libraries required to build,
> test
> > and/or run a copy from that branch in a separate environment.
> >
> >
> > So the questions are:
> >
> >
> >- are we going to delete the external libraries from the branches, or
> >- are we going to delete the entire branches?
> >
> >
> > I believe we should have this addressed in order to provide the greater
> > community with a clear answer as what to expect regarding future
> adoptions
> > and/or upgrades.
> >
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
>


[jira] [Commented] (OFBIZ-7775) Fixes Javadoc in sources

2016-07-11 Thread Taher Alkhateeb (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-7775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370389#comment-15370389
 ] 

Taher Alkhateeb commented on OFBIZ-7775:


Committed a fix in r1752131

This fix is a temporary solution. Gradle does not allow generating JavaDocs if 
they have javadocs that are not properly formatted. This commit will override 
this behavior by adding the following code snippet:
 
{code:groovy}
 javadoc.failOnError = false
{code}
 
However, the long term proper solution is to actually fix all the JavaDoc 
errors in our current OFBiz API. This JIRA will remain open to complete 
cleaning up the JavaDocs in our code base.

> Fixes Javadoc in sources
> 
>
> Key: OFBIZ-7775
> URL: https://issues.apache.org/jira/browse/OFBIZ-7775
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
> Fix For: Upcoming Branch
>
>
> To check what to fix simply run gradlew javadoc



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


  1   2   >