date:20150418

Re: Start.java Issue

2015-04-18 Thread Adrian Crum


I will create a Jira issue and supply a patch for review.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/19/2015 7:13 AM, Jacopo Cappellato wrote:


On Apr 18, 2015, at 7:38 PM, Adrian Crum  
wrote:


I checked the commit logs - the double parsing was introduced in rev 1633182.



yes, and no. I did that commit and it was a good enhancement: before that, the 
start component, was parsing the filesystem and was adding to the classpath all 
the jars (including the ones from disabled components).
I introduced the additional parsing to avoid this (and with that commit I could 
remove a useless, if not problematic, Classloader) but I agree that with a 
refactoring we could optimize the code more.
I would appreciate if you could share some notes about how you would like to 
proceed (as there are different ways and some may be better that others).

Jacopo

PS: I am not asking the patch for RTC, I am just asking some details about the 
refactoring you have in mind


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 6:12 PM, Adrian Crum wrote:

I spent the day looking through the OFBiz startup code to see if there
is any way we can shorten the startup time.

Something I noticed that seems odd...

Start.java searches the OFBiz folders for all instances of
ofbiz-component.xml files, parses them, and builds a class path based on
their contents. Then Start.java loads the components using
ComponentContainer.java, and that class also parses ofbiz-component.xml
files. So the ofbiz-component.xml files are parsed twice.

I would like to redesign the component loading a bit to eliminate the
double parsing.

What do you think?

Re: Start.java Issue

2015-04-18 Thread Jacopo Cappellato

On Apr 18, 2015, at 7:38 PM, Adrian Crum  
wrote:

> I checked the commit logs - the double parsing was introduced in rev 1633182.
> 

yes, and no. I did that commit and it was a good enhancement: before that, the 
start component, was parsing the filesystem and was adding to the classpath all 
the jars (including the ones from disabled components).
I introduced the additional parsing to avoid this (and with that commit I could 
remove a useless, if not problematic, Classloader) but I agree that with a 
refactoring we could optimize the code more.
I would appreciate if you could share some notes about how you would like to 
proceed (as there are different ways and some may be better that others).

Jacopo

PS: I am not asking the patch for RTC, I am just asking some details about the 
refactoring you have in mind

> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> 
> On 4/18/2015 6:12 PM, Adrian Crum wrote:
>> I spent the day looking through the OFBiz startup code to see if there
>> is any way we can shorten the startup time.
>> 
>> Something I noticed that seems odd...
>> 
>> Start.java searches the OFBiz folders for all instances of
>> ofbiz-component.xml files, parses them, and builds a class path based on
>> their contents. Then Start.java loads the components using
>> ComponentContainer.java, and that class also parses ofbiz-component.xml
>> files. So the ofbiz-component.xml files are parsed twice.
>> 
>> I would like to redesign the component loading a bit to eliminate the
>> double parsing.
>> 
>> What do you think?
>> 
>>

[jira] [Commented] (OFBIZ-1607) let the ofbiz work with db2

2015-04-18 Thread Pierre Smits (JIRA)


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

Pierre Smits commented on OFBIZ-1607:
-

The mail thread below is relevant. It seems that it has been achieved in a PoC 
(Proof of Concept).

http://ofbiz.markmail.org/message/dgdiybxpwkpo2gln

> let the ofbiz work with db2
> ---
>
> Key: OFBIZ-1607
> URL: https://issues.apache.org/jira/browse/OFBIZ-1607
> Project: OFBiz
>  Issue Type: New Feature
>  Components: framework
>Affects Versions: Trunk
> Environment: db2 v9.1.0.356
>Reporter: WeizhanGuo
> Attachments: contentForm.diff, entityFordb2.diff
>
>   Original Estimate: 40m
>  Remaining Estimate: 40m
>
> create the db2filedtype file ; 
> change the seed/demo data to fixed the db2 requirement;
> change some relation define if needed;
> others



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

Re: svn commit: r1674587 - in /ofbiz/trunk/applications/accounting: webapp/accounting/WEB-INF/controller.xml widget/TaxAuthorityForms.xml widget/TaxAuthorityMenus.xml widget/TaxAuthorityScreens.xml

2015-04-18 Thread Adrian Crum


Don't forget that  is now a .

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 11:48 PM, jler...@apache.org wrote:

Author: jleroux
Date: Sat Apr 18 22:48:01 2015
New Revision: 1674587

URL: http://svn.apache.org/r1674587
Log:
A patch from Pierre Smits "Add a basic VAT report with frequency setting" 
https://issues.apache.org/jira/browse/OFBIZ-6225

This is a 1st stage, we will add more later, notably totals as a 1st step and 
then a more complete report but still basic

Modified:
 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
 ofbiz/trunk/applications/accounting/widget/TaxAuthorityForms.xml
 ofbiz/trunk/applications/accounting/widget/TaxAuthorityMenus.xml
 ofbiz/trunk/applications/accounting/widget/TaxAuthorityScreens.xml

Modified: 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml?rev=1674587&r1=1674586&r2=1674587&view=diff
==
--- 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml 
(original)
+++ 
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/controller.xml 
Sat Apr 18 22:48:01 2015
@@ -1566,6 +1566,12 @@ under the License.
  
  
  
+
+
+
+
+
+

  
  
@@ -2844,7 +2850,8 @@ under the License.
  
  
  
-
+
+
  
  
  

Modified: ofbiz/trunk/applications/accounting/widget/TaxAuthorityForms.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/TaxAuthorityForms.xml?rev=1674587&r1=1674586&r2=1674587&view=diff
==
--- ofbiz/trunk/applications/accounting/widget/TaxAuthorityForms.xml (original)
+++ ofbiz/trunk/applications/accounting/widget/TaxAuthorityForms.xml Sat Apr 18 
22:48:01 2015
@@ -405,4 +405,33 @@ under the License.
  
  
  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
  

Modified: ofbiz/trunk/applications/accounting/widget/TaxAuthorityMenus.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/TaxAuthorityMenus.xml?rev=1674587&r1=1674586&r2=1674587&view=diff
==
--- ofbiz/trunk/applications/accounting/widget/TaxAuthorityMenus.xml (original)
+++ ofbiz/trunk/applications/accounting/widget/TaxAuthorityMenus.xml Sat Apr 18 
22:48:01 2015
@@ -59,5 +59,11 @@ under the License.
  
  
  
+
+
+
+
+
+
  
  

Modified: ofbiz/trunk/applications/accounting/widget/TaxAuthorityScreens.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/TaxAuthorityScreens.xml?rev=1674587&r1=1674586&r2=1674587&view=diff
==
--- ofbiz/trunk/applications/accounting/widget/TaxAuthorityScreens.xml 
(original)
+++ ofbiz/trunk/applications/accounting/widget/TaxAuthorityScreens.xml Sat Apr 
18 22:48:01 2015
@@ -264,4 +264,28 @@ under the License.
  
  
  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

[jira] [Commented] (OFBIZ-5441) URLs in PDF files are not handled correctly

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-5441:


I checked, this is no longer a problem using NoTo fonts, see r1674586

> URLs in PDF files are not handled correctly
> ---
>
> Key: OFBIZ-5441
> URL: https://issues.apache.org/jira/browse/OFBIZ-5441
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>
> When a PDF file contains a reference to a promotion like when you buy a 
> WG-5569 (Tiny Chrome Widget) and get a free WG- (Micro Chrome Widget). 
> You end with a corresponding invoice containing < your favorite widgets and gizmos and get a free  href="/ecommerce/control/product?category_id=20111&product_id=WG-">Micro
>  Chrome Widget!>> instead of a real link. 
> It's possible to generare a link in a PDF with FOP, we need to
> # dynamically define a fop.base using a ftl transform refs: 
> http://xmlgraphics.apache.org/fop/0.95/configuration.html#general-elements 
> http://xmlgraphics.apache.org/fop/faq.html#MalformedURL
> # here is an example from ProductionRun.fo.ftl
> {code}
> 
>  external-destination="<@ofbizContentUrl>/content/control/ViewBinaryDataResource?dataResourceId=${productionRunContent.drDataResourceId}">${uiLabelMap.CommonView}
> 
> {code}



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

[jira] [Commented] (OFBIZ-6225) Add a basic VAT report with frequency setting

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-6225:


Pierre,

Finally I committed your patch at revision: 1674587. We will complete later 
with baby steps, no needs to hurry here...

I just removed the dummy field :)


> Add a basic VAT report with frequency setting
> -
>
> Key: OFBIZ-6225
> URL: https://issues.apache.org/jira/browse/OFBIZ-6225
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: reporting, vat
> Attachments: OFBIZ-6225 - Vat control reports.patch, 
> OFBIZ-6225-TaxReport.patch
>
>
> Few years ago I began to work on that. I just stumbled upon it so I note it 
> here to continue when I will get a chance. It would be something basic with a 
> find and single input form, rendered with FOP



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

[jira] [Commented] (OFBIZ-6225) Add a basic VAT report with frequency setting

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-6225:


Pierre,

I was ready to apply you VAT patch, but I just hastily reviewed mine (I did not 
when I attached) and I decided I will review all that again, rather than 
committed your patch as is...

Thanks!

> Add a basic VAT report with frequency setting
> -
>
> Key: OFBIZ-6225
> URL: https://issues.apache.org/jira/browse/OFBIZ-6225
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: reporting, vat
> Attachments: OFBIZ-6225 - Vat control reports.patch, 
> OFBIZ-6225-TaxReport.patch
>
>
> Few years ago I began to work on that. I just stumbled upon it so I note it 
> here to continue when I will get a chance. It would be something basic with a 
> find and single input form, rendered with FOP



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

[jira] [Comment Edited] (OFBIZ-6225) Add a basic VAT report with frequency setting

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux edited comment on OFBIZ-6225 at 4/18/15 10:14 PM:
--

Yes I think we should, I see no reason your patch would introduce this


was (Author: jacques.le.roux):
Yes I think we should

> Add a basic VAT report with frequency setting
> -
>
> Key: OFBIZ-6225
> URL: https://issues.apache.org/jira/browse/OFBIZ-6225
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: reporting, vat
> Attachments: OFBIZ-6225 - Vat control reports.patch, 
> OFBIZ-6225-TaxReport.patch
>
>
> Few years ago I began to work on that. I just stumbled upon it so I note it 
> here to continue when I will get a chance. It would be something basic with a 
> find and single input form, rendered with FOP



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

[jira] [Commented] (OFBIZ-6225) Add a basic VAT report with frequency setting

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-6225:


Yes I think we should

> Add a basic VAT report with frequency setting
> -
>
> Key: OFBIZ-6225
> URL: https://issues.apache.org/jira/browse/OFBIZ-6225
> Project: OFBiz
>  Issue Type: Improvement
>  Components: accounting
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>  Labels: reporting, vat
> Attachments: OFBIZ-6225 - Vat control reports.patch, 
> OFBIZ-6225-TaxReport.patch
>
>
> Few years ago I began to work on that. I just stumbled upon it so I note it 
> here to continue when I will get a chance. It would be something basic with a 
> find and single input form, rendered with FOP



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

Le 18/04/2015 22:20, Adrian Crum a écrit :
RTC will bring the project to a screeching halt - because no one reviews anything. I'm still waiting for feedback on the entity cache fix I
committed a while ago.

"no one reviews anything. "
That's *almost* right Adrian, we review some I believe ;) and I think Pierre
has a point here, as your previous email about r1633182 shows.

I think it's something we should really care more about. For important commits in the core, we can't rely only on one person, even among our most
experienced core developers.
Obviously the "deeper" a commit is, the more chances are it has a negative impact, contrary to a change, for instance, at the UI level. We have proofs
everyday, having something working is not enough.
We (all committers) should even, as a priority, focus on such changes. Of course it's not the easiest job so we often prefer to close our eyes and
rely on others, I know, I do that.

Now, I don't believe asking for review on such important patch attached to a Jira would throw OFBiz in "a screeching halt", at least when it's not
about a bug fix. Refactoring and improving is nice, but we all know it also introduce some risks. I have the feeling we crossed some regressions we
could have avoided with a more community minded spirit. I know you often ask for reviews when doing such changes and we sometimes lack to provide
them. But that should not prevent us to ask for RTC when we have the feeling it should be done. I did in the recent past by attaching patches to Jira,
not sure I got more attention, but at least I tried.

We knowcoercion is impossible due to the nature of the project. So maybe putting more pressure (reiterated, if no feedbacks) on RTC requests would
help, before committing something w/o enough eyes balls reviews. And a patch in a Jira is the best way to keep things focused.

BTW I will begin by doing the reviews I promised I would do...

Thanks!

Jacques

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 8:08 PM, Pierre Smits wrote:

We should learn from the past, not repeat it. RTC would have brought this
aspect of the improvement in r1633182 earlier to our attention than CTR.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Apr 18, 2015 at 7:39 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

There have been many Start.java refactorings in the past that did not
require review. Why is this one different?

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 6:24 PM, Jacques Le Roux wrote:

Le 18/04/2015 19:12, Adrian Crum a écrit :

I spent the day looking through the OFBiz startup code to see if there
is any way we can shorten the startup time.

Something I noticed that seems odd...

Start.java searches the OFBiz folders for all instances of
ofbiz-component.xml files, parses them, and builds a class path based
on their contents. Then Start.java loads the components using
ComponentContainer.java, and that class also parses
ofbiz-component.xml files. So the ofbiz-component.xml files are parsed
twice.

I would like to redesign the component loading a bit to eliminate the
double parsing.

What do you think?

This would need a review to confirm, but if the double parsing is

useless then indeed a refactoring seems the way.
This is the kind of change we could wait to be reviewed before
committing, but not necessarily since we can always revert

Jacques

Re: Start.java Issue

2015-04-18 Thread Pierre Smits

'no one reviews anything' is misleading because not true. We do what we
can.

Seeking collaboration and consensus is a far better attitude than putting
Code over Community. CTR regarding improvements is putting Code over
Community.

Is creating an improvement issue, attaching patches and seeking
collaboration for review before applying the patch after 72 hours to much
work?

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Apr 18, 2015 at 10:20 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

> RTC will bring the project to a screeching halt - because no one reviews
> anything. I'm still waiting for feedback on the entity cache fix I
> committed a while ago.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/18/2015 8:08 PM, Pierre Smits wrote:
>
>> We should learn from the past, not repeat it. RTC would have brought this
>> aspect of the improvement in r1633182 earlier to our attention than CTR.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM *
>>
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Sat, Apr 18, 2015 at 7:39 PM, Adrian Crum <
>> adrian.c...@sandglass-software.com> wrote:
>>
>>  There have been many Start.java refactorings in the past that did not
>>> require review. Why is this one different?
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 4/18/2015 6:24 PM, Jacques Le Roux wrote:
>>>
>>>  Le 18/04/2015 19:12, Adrian Crum a écrit :

  I spent the day looking through the OFBiz startup code to see if there
> is any way we can shorten the startup time.
>
> Something I noticed that seems odd...
>
> Start.java searches the OFBiz folders for all instances of
> ofbiz-component.xml files, parses them, and builds a class path based
> on their contents. Then Start.java loads the components using
> ComponentContainer.java, and that class also parses
> ofbiz-component.xml files. So the ofbiz-component.xml files are parsed
> twice.
>
> I would like to redesign the component loading a bit to eliminate the
> double parsing.
>
> What do you think?
>
>
>   This would need a review to confirm, but if the double parsing is
>
 useless then indeed a refactoring seems the way.
 This is the kind of change we could wait to be reviewed before
 committing, but not necessarily since we can always revert

 Jacques


>>>
>>

Re: Start.java Issue

2015-04-18 Thread Adrian Crum

RTC will bring the project to a screeching halt - because no one reviews 
anything. I'm still waiting for feedback on the entity cache fix I 
committed a while ago.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 8:08 PM, Pierre Smits wrote:

We should learn from the past, not repeat it. RTC would have brought this
aspect of the improvement in r1633182 earlier to our attention than CTR.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Apr 18, 2015 at 7:39 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:


There have been many Start.java refactorings in the past that did not
require review. Why is this one different?

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 6:24 PM, Jacques Le Roux wrote:


Le 18/04/2015 19:12, Adrian Crum a écrit :


I spent the day looking through the OFBiz startup code to see if there
is any way we can shorten the startup time.

Something I noticed that seems odd...

Start.java searches the OFBiz folders for all instances of
ofbiz-component.xml files, parses them, and builds a class path based
on their contents. Then Start.java loads the components using
ComponentContainer.java, and that class also parses
ofbiz-component.xml files. So the ofbiz-component.xml files are parsed
twice.

I would like to redesign the component loading a bit to eliminate the
double parsing.

What do you think?


  This would need a review to confirm, but if the double parsing is

useless then indeed a refactoring seems the way.
This is the kind of change we could wait to be reviewed before
committing, but not necessarily since we can always revert

Jacques

Re: Start.java Issue

2015-04-18 Thread Pierre Smits

We should learn from the past, not repeat it. RTC would have brought this
aspect of the improvement in r1633182 earlier to our attention than CTR.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Apr 18, 2015 at 7:39 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

> There have been many Start.java refactorings in the past that did not
> require review. Why is this one different?
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/18/2015 6:24 PM, Jacques Le Roux wrote:
>
>> Le 18/04/2015 19:12, Adrian Crum a écrit :
>>
>>> I spent the day looking through the OFBiz startup code to see if there
>>> is any way we can shorten the startup time.
>>>
>>> Something I noticed that seems odd...
>>>
>>> Start.java searches the OFBiz folders for all instances of
>>> ofbiz-component.xml files, parses them, and builds a class path based
>>> on their contents. Then Start.java loads the components using
>>> ComponentContainer.java, and that class also parses
>>> ofbiz-component.xml files. So the ofbiz-component.xml files are parsed
>>> twice.
>>>
>>> I would like to redesign the component loading a bit to eliminate the
>>> double parsing.
>>>
>>> What do you think?
>>>
>>>
>>>  This would need a review to confirm, but if the double parsing is
>> useless then indeed a refactoring seems the way.
>> This is the kind of change we could wait to be reviewed before
>> committing, but not necessarily since we can always revert
>>
>> Jacques
>>
>

Re: Start.java Issue

2015-04-18 Thread Adrian Crum

There have been many Start.java refactorings in the past that did not 
require review. Why is this one different?


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 6:24 PM, Jacques Le Roux wrote:

Le 18/04/2015 19:12, Adrian Crum a écrit :

I spent the day looking through the OFBiz startup code to see if there
is any way we can shorten the startup time.

Something I noticed that seems odd...

Start.java searches the OFBiz folders for all instances of
ofbiz-component.xml files, parses them, and builds a class path based
on their contents. Then Start.java loads the components using
ComponentContainer.java, and that class also parses
ofbiz-component.xml files. So the ofbiz-component.xml files are parsed
twice.

I would like to redesign the component loading a bit to eliminate the
double parsing.

What do you think?



This would need a review to confirm, but if the double parsing is
useless then indeed a refactoring seems the way.
This is the kind of change we could wait to be reviewed before
committing, but not necessarily since we can always revert

Jacques

Re: Start.java Issue

2015-04-18 Thread Adrian Crum

I checked the commit logs - the double parsing was introduced in rev 
1633182.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 6:12 PM, Adrian Crum wrote:

I spent the day looking through the OFBiz startup code to see if there
is any way we can shorten the startup time.

Something I noticed that seems odd...

Start.java searches the OFBiz folders for all instances of
ofbiz-component.xml files, parses them, and builds a class path based on
their contents. Then Start.java loads the components using
ComponentContainer.java, and that class also parses ofbiz-component.xml
files. So the ofbiz-component.xml files are parsed twice.

I would like to redesign the component loading a bit to eliminate the
double parsing.

What do you think?

[jira] [Comment Edited] (OFBIZ-5917) Improve the way FOP handles fonts notably for currency symbols

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux edited comment on OFBIZ-5917 at 4/18/15 5:36 PM:
-

http://svn.apache.org/viewvc?view=revision&revision=1646781 is related


was (Author: jacques.le.roux):
http://svn.apache.org/viewvc?view=revision&revision=r1646781 is related

> Improve the way FOP handles fonts notably for currency symbols
> --
>
> Key: OFBIZ-5917
> URL: https://issues.apache.org/jira/browse/OFBIZ-5917
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: rupee, symbol
> Fix For: 14.12.01
>
>
> In the dev ML I suggested we could add
> 
> in the fonts section of our fop.xconf
> We can do more than that. For instance currently there are no easy ways to 
> render the "new" (since 2010) rupee symbol: ₹.
> One is to use the Google NotoSans font which is Apache licensed
> * http://www.google.com/fonts/specimen/Noto+Sans
> * https://www.google.com/get/noto/#/
> We need also to
> * Add the rupee symbol (₹) to antisamy-esapi.xml file like we have the euro 
> symbol (€)
> * Use NotoSans as the default FOP font. For that we can put the NotoSans font 
> 4 files in framework/resources/fonts and add 
> framework/resources/fonts/NotoSansFonts in our 
> fop.xconf
> * Render ₹ in content/control/fonts.pdf as we do for €. Other symbols could 
> be added later when needed, backed by Google NotoSans font...



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

Re: Start.java Issue

2015-04-18 Thread Jacques Le Roux


Le 18/04/2015 19:12, Adrian Crum a écrit :

I spent the day looking through the OFBiz startup code to see if there is any 
way we can shorten the startup time.

Something I noticed that seems odd...

Start.java searches the OFBiz folders for all instances of ofbiz-component.xml files, parses them, and builds a class path based on their contents. 
Then Start.java loads the components using ComponentContainer.java, and that class also parses ofbiz-component.xml files. So the ofbiz-component.xml 
files are parsed twice.


I would like to redesign the component loading a bit to eliminate the double 
parsing.

What do you think?



This would need a review to confirm, but if the double parsing is useless then 
indeed a refactoring seems the way.
This is the kind of change we could wait to be reviewed before committing, but 
not necessarily since we can always revert

Jacques

Start.java Issue

2015-04-18 Thread Adrian Crum

I spent the day looking through the OFBiz startup code to see if there 
is any way we can shorten the startup time.


Something I noticed that seems odd...

Start.java searches the OFBiz folders for all instances of 
ofbiz-component.xml files, parses them, and builds a class path based on 
their contents. Then Start.java loads the components using 
ComponentContainer.java, and that class also parses ofbiz-component.xml 
files. So the ofbiz-component.xml files are parsed twice.


I would like to redesign the component loading a bit to eliminate the 
double parsing.


What do you think?


--
Adrian Crum
Sandglass Software
www.sandglass-software.com

Re: [VOTE] [RELEASE] Apache OFBiz 13.07.02 - second attempt

2015-04-18 Thread Adrian Crum

Jacques started to fix something that he thought was broken, then he 
realized it wasn't broken and he reverted his changes.


There have been numerous bug fixes since then, so a new vote would be 
appropriate.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/18/2015 5:17 PM, Jacopo Cappellato wrote:

In light of the recent fixes (committed by Jacques) I am proposing to cancel 
this second vote and start a new one.
I didn't review them closely because I am travelling but it seems like the best 
way to go.

What do you think guys?

Jacopo


On Apr 12, 2015, at 1:54 PM, Jacques Le Roux  
wrote:


0

Jacques

Le 12/04/2015 11:08, Deepak Dixit a écrit :

+1

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

On Sat, Apr 11, 2015 at 10:14 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


This is the second vote thread vote thread (after the first was cancelled
to prepare a new release file with some latest bug fixes) to release a new
bug fix release for the release13.07 branch. This new release, "Apache
OFBiz 13.07.02" will supersede the previous release from the same branch.
The release files can be downloaded from here:

https://dist.apache.org/repos/dist/dev/ofbiz/

and are:

* apache-ofbiz-13.07.02.zip
* KEYS: text file with keys
* apache-ofbiz-13.07.02.zip.asc: the detached signature file
* apache-ofbiz-13.07.02.zip.md5, apache-ofbiz-13.07.02.zip.sha: hashes

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html
).

Vote:

[ +1] release as Apache OFBiz 13.07.02
[ -1] do not release

This vote will be open for at least 3 days.
For more details about this process please read
http://www.apache.org/foundation/voting.html

Kind Regards,

Jacopo

Re: [VOTE] [RELEASE] Apache OFBiz 13.07.02 - second attempt

2015-04-18 Thread Jacopo Cappellato

In light of the recent fixes (committed by Jacques) I am proposing to cancel 
this second vote and start a new one.
I didn't review them closely because I am travelling but it seems like the best 
way to go.

What do you think guys?

Jacopo


On Apr 12, 2015, at 1:54 PM, Jacques Le Roux  
wrote:

> 0
> 
> Jacques
> 
> Le 12/04/2015 11:08, Deepak Dixit a écrit :
>> +1
>> 
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> 
>> On Sat, Apr 11, 2015 at 10:14 PM, Jacopo Cappellato <
>> jacopo.cappell...@hotwaxsystems.com> wrote:
>> 
>>> This is the second vote thread vote thread (after the first was cancelled
>>> to prepare a new release file with some latest bug fixes) to release a new
>>> bug fix release for the release13.07 branch. This new release, "Apache
>>> OFBiz 13.07.02" will supersede the previous release from the same branch.
>>> The release files can be downloaded from here:
>>> 
>>> https://dist.apache.org/repos/dist/dev/ofbiz/
>>> 
>>> and are:
>>> 
>>> * apache-ofbiz-13.07.02.zip
>>> * KEYS: text file with keys
>>> * apache-ofbiz-13.07.02.zip.asc: the detached signature file
>>> * apache-ofbiz-13.07.02.zip.md5, apache-ofbiz-13.07.02.zip.sha: hashes
>>> 
>>> Please download and test the zip file and its signatures (for instructions
>>> on testing the signatures see http://www.apache.org/info/verification.html
>>> ).
>>> 
>>> Vote:
>>> 
>>> [ +1] release as Apache OFBiz 13.07.02
>>> [ -1] do not release
>>> 
>>> This vote will be open for at least 3 days.
>>> For more details about this process please read
>>> http://www.apache.org/foundation/voting.html
>>> 
>>> Kind Regards,
>>> 
>>> Jacopo

[jira] [Assigned] (OFBIZ-4674) Human Resource Manager Tree

2015-04-18 Thread Ashish Vijaywargiya (JIRA)


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

Ashish Vijaywargiya reassigned OFBIZ-4674:
--

Assignee: Ashish Vijaywargiya

> Human Resource Manager Tree
> ---
>
> Key: OFBIZ-4674
> URL: https://issues.apache.org/jira/browse/OFBIZ-4674
> Project: OFBiz
>  Issue Type: Bug
>  Components: humanres
>Affects Versions: Trunk
> Environment: Latest Trunk
>Reporter: Jacopo Cappellato
>Assignee: Ashish Vijaywargiya
> Attachments: ASF.LICENSE.NOT.GRANTED--HR Tree Before Sample 
> Accounting Data Loaded.jpg, ASF.LICENSE.NOT.GRANTED--HR Tree With Sample 
> Accounting Data Loaded.jpg, HumanResAcctData.xml
>
>
> In the latest trunk the tree off the HR Main menu has some questionable 
> behavior: 
> 1. The developer and test persons created in the Accounting application 
> behave like organizations. 
> They display the organization icon and context menu. 
> For example: 
> Go to Human Resources Main 
> In the tree open the nodes Development Department > Development Team 1 
> Right Click on any of the children Developer1-3. 
> Developers 1-3 are persons but the context menu presents the functions for an 
> organization (Add Employee Position / Add Internal Organization). 
> The Testing entities have the same behavior. 
> See attached AcctHRBefore.jpg 
> Expected parties that are persons would not have context functions. 
> Expected Accounting entities to display icons and behavior in the manner of 
> the Programmer and Demo Employee created by HumanResDemoData.xml. 
> For example load the attached HumanResAcctData.xml using Webtools > Entity 
> Import > Absolute Filename or URL to see the expected result as shown in 
> attache AcctHRAfter.jpg 
> 2. The context menu Add Internal Organization allows duplicate organization 
> entities in the tree. 
> This by itself does not make business sense and it permits the creation of 
> recursive structures by selecting the name of the parent for the child. 
> For example:
> Go to Human Resources Main In the tree right click on "Development 
> department" 
> In the context menu select Add Internal Organization In the drop down list 
> select "DEV" Click Create After refresh open the "Development department". 
> It now contains a child "Development department" which has a child 
> "Development department" etc etc. 
> It is also possible to create recursion by adding an organizations parent as 
> a child. 
> Substitute party_id "Company" for "DEV" in the above exercise. 
> Expected unique nodes 
> 3. Selecting Add Employee Position or Add Person from the context menu opens 
> the corresponding edit forms with calendar lookup fields. 
> The calendar form does no open when the lookup icon is clicked. 
> Expected calendar to open on click.



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

[jira] [Closed] (OFBIZ-6260) foScreenMacroLibrary.ftl renderLabel doesn't apply style parameter

2015-04-18 Thread Ashish Vijaywargiya (JIRA)


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

Ashish Vijaywargiya closed OFBIZ-6260.
--
   Resolution: Fixed
Fix Version/s: Upcoming Branch
   13.07.02
   14.12.01

Thanks Christian for the contribution and Thanks Aditya for reviewing the 
patch. Changes are pushed to: r1674513(trunk), r1674514(R14.12), 
r1674515(R13.07).

> foScreenMacroLibrary.ftl renderLabel doesn't apply style parameter
> --
>
> Key: OFBIZ-6260
> URL: https://issues.apache.org/jira/browse/OFBIZ-6260
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Ashish Vijaywargiya
> Fix For: 14.12.01, 13.07.02, Upcoming Branch
>
> Attachments: OFBIZ-6260.patch
>
>
> foScreenMacroLibrary.ftl renderLabel accepts a style parameter but does not 
> apply it to the rendered element which should happen.



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

[jira] [Assigned] (OFBIZ-6260) foScreenMacroLibrary.ftl renderLabel doesn't apply style parameter

2015-04-18 Thread Ashish Vijaywargiya (JIRA)


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

Ashish Vijaywargiya reassigned OFBIZ-6260:
--

Assignee: Ashish Vijaywargiya

> foScreenMacroLibrary.ftl renderLabel doesn't apply style parameter
> --
>
> Key: OFBIZ-6260
> URL: https://issues.apache.org/jira/browse/OFBIZ-6260
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Ashish Vijaywargiya
> Attachments: OFBIZ-6260.patch
>
>
> foScreenMacroLibrary.ftl renderLabel accepts a style parameter but does not 
> apply it to the rendered element which should happen.



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

[jira] [Comment Edited] (OFBIZ-6058) Find Shipment generates an error

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux edited comment on OFBIZ-6058 at 4/18/15 1:57 PM:
-

Ho, I see it contains query builder stuff. 

I wondered if the issue also existed in older releases. Because I used only the 
Enter key, before spotting the "Find Shipment(s)" button :(.
So a *BIG +1* for OFBIZ-6144 and form-widgets by and large!




was (Author: jacques.le.roux):
Ho, I see it contains query builder stuff. 

I wondered if the issue also existed in older releases (remember our stable is 
not R14.12 but R13.07). Because I used only the Enter key, before spotting the 
"Find Shipment(s)" button :(.
So a *BIG +1* for OFBIZ-6144 and form-widgets by and large!



> Find Shipment generates an error
> 
>
> Key: OFBIZ-6058
> URL: https://issues.apache.org/jira/browse/OFBIZ-6058
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Ashish Vijaywargiya
>  Labels: facility, shipment
> Fix For: 14.12.01, Upcoming Branch
>
> Attachments: OFBIZ-6058.patch
>
>
> When trying to look up shipments, following error is shown:
> ERROR rendering error page [/error/error.jsp], but here is the error text: 
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
> [component://product/widget/facility/ShipmentScreens.xml#FindShipment]: 
> java.lang.IllegalArgumentException: Error running script at location 
> [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]:
>  groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method 
> org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to 
> invoke for [null] due to overlapping prototypes between: [interface 
> java.util.List] [interface java.util.Map] (Error running script at location 
> [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]:
>  groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method 
> org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to 
> invoke for [null] due to overlapping prototypes between: [interface 
> java.util.List] [interface java.util.Map])



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

[jira] [Commented] (OFBIZ-6058) Find Shipment generates an error

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-6058:


Ho, I see it contains query builder stuff. 

I wondered if the issue also existed in older releases (remember our stable is 
not R14.12 but R13.07). Because I used only the Enter key, before spotting the 
"Find Shipment(s)" button :(.
So a *BIG +1* for OFBIZ-6144 and form-widgets by and large!



> Find Shipment generates an error
> 
>
> Key: OFBIZ-6058
> URL: https://issues.apache.org/jira/browse/OFBIZ-6058
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Ashish Vijaywargiya
>  Labels: facility, shipment
> Fix For: 14.12.01, Upcoming Branch
>
> Attachments: OFBIZ-6058.patch
>
>
> When trying to look up shipments, following error is shown:
> ERROR rendering error page [/error/error.jsp], but here is the error text: 
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
> [component://product/widget/facility/ShipmentScreens.xml#FindShipment]: 
> java.lang.IllegalArgumentException: Error running script at location 
> [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]:
>  groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method 
> org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to 
> invoke for [null] due to overlapping prototypes between: [interface 
> java.util.List] [interface java.util.Map] (Error running script at location 
> [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]:
>  groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method 
> org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to 
> invoke for [null] due to overlapping prototypes between: [interface 
> java.util.List] [interface java.util.Map])



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

[jira] [Commented] (OFBIZ-6058) Find Shipment generates an error

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-6058:


Hi Ashish, is there a specific reason to no backport to older releases?

> Find Shipment generates an error
> 
>
> Key: OFBIZ-6058
> URL: https://issues.apache.org/jira/browse/OFBIZ-6058
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Ashish Vijaywargiya
>  Labels: facility, shipment
> Fix For: 14.12.01, Upcoming Branch
>
> Attachments: OFBIZ-6058.patch
>
>
> When trying to look up shipments, following error is shown:
> ERROR rendering error page [/error/error.jsp], but here is the error text: 
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
> [component://product/widget/facility/ShipmentScreens.xml#FindShipment]: 
> java.lang.IllegalArgumentException: Error running script at location 
> [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]:
>  groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method 
> org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to 
> invoke for [null] due to overlapping prototypes between: [interface 
> java.util.List] [interface java.util.Map] (Error running script at location 
> [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]:
>  groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method 
> org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to 
> invoke for [null] due to overlapping prototypes between: [interface 
> java.util.List] [interface java.util.Map])



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

[jira] [Comment Edited] (OFBIZ-5441) URLs in PDF files are not handled correctly

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux edited comment on OFBIZ-5441 at 4/18/15 1:43 PM:
-

The problem is more than that, we actually have to handle 
InvoiceItem.descriptions like

description="Spend more than $100 on your favorite widgets and gizmos and get a 
free Micro
 Chrome Widget!"

See for instane this one
 

So, to generate the url inside the generated PDF file, we need to parse the 
InvoiceItem.description inside invoiceReportItems.fo.ftl.

Also in ProductionRun.fo.ftl (the only place where we currently have a 
) the external-destinationattribute is 
wrongly completed. It misses the url('...') part in 
external-destination=url('...'). And, as you mentionned, the generated url is 
incomplete. I believe we will need a new transform for URLs in *fo.ftl files.


was (Author: jacques.le.roux):
The problem is more than we actually have to handle InvoiceItem.descriptions 
like

description="Spend more than $100 on your favorite widgets and gizmos and get a 
free Micro
 Chrome Widget!"

See for instane this one
  
 
So, to generate the url inside the generated PDF file, we need to parse the 
InvoiceItem.description inside invoiceReportItems.fo.ftl. 
 
Also in ProductionRun.fo.ftl (the only place where we currently have a 
) the external-destinationattribute is 
wrongly completed. It misses the url('...') part in 
external-destination=url('...'). And, as you mentionned, the generated url is 
incomplete. I believe we will need a new transform for URLs in *fo.ftl files.

> URLs in PDF files are not handled correctly
> ---
>
> Key: OFBIZ-5441
> URL: https://issues.apache.org/jira/browse/OFBIZ-5441
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>
> When a PDF file contains a reference to a promotion like when you buy a 
> WG-5569 (Tiny Chrome Widget) and get a free WG- (Micro Chrome Widget). 
> You end with a corresponding invoice containing < your favorite widgets and gizmos and get a free  href="/ecommerce/control/product?category_id=20111&product_id=WG-">Micro
>  Chrome Widget!>> instead of a real link. 
> It's possible to generare a link in a PDF with FOP, we need to
> # dynamically define a fop.base using a ftl transform refs: 
> http://xmlgraphics.apache.org/fop/0.95/configuration.html#general-elements 
> http://xmlgraphics.apache.org/fop/faq.html#MalformedURL
> # here is an example from ProductionRun.fo.ftl
> {code}
> 
>  external-destination="<@ofbizContentUrl>/content/control/ViewBinaryDataResource?dataResourceId=${productionRunContent.drDataResourceId}">${uiLabelMap.CommonView}
> 
> {code}



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

buildbot exception in ASF Buildbot on ofbiz-branch12

2015-04-18 Thread buildbot

The Buildbot has detected a build exception on builder ofbiz-branch12 while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/ofbiz-branch12/builds/200

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

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz12-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release12.04] 1674507
Blamelist: jleroux

BUILD FAILED: exception upload_1

Sincerely,
 -The Buildbot

buildbot success in ASF Buildbot on ofbiz-branch13

2015-04-18 Thread buildbot

The Buildbot has detected a restored build on builder ofbiz-branch13 while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/ofbiz-branch13/builds/293

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

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz13-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release13.07] 1674506
Blamelist: jleroux

Build succeeded!

Sincerely,
 -The Buildbot

[jira] [Updated] (OFBIZ-6188) Task Report error for Manufacturing Shipment Plan

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux updated OFBIZ-6188:
---
Fix Version/s: 13.07.02
   12.04.06

> Task Report error for Manufacturing Shipment Plan
> -
>
> Key: OFBIZ-6188
> URL: https://issues.apache.org/jira/browse/OFBIZ-6188
> Project: OFBiz
>  Issue Type: Bug
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Deepak Dixit
> Fix For: 14.12.01, 12.04.06, 13.07.02, Upcoming Branch
>
> Attachments: OFBIZ-6188.patch
>
>
> This error occurs when clicking the Task Report button for Manufacturing 
> Shipment Plans at manufacturing/control/WorkWithShipmentPlan:
> Problems with the response writer/output stream: 
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
> [component://manufacturing/widget/manufacturing/ReportScreens.xml#ShipmentWorkEffortTasks]:
>  java.lang.IllegalArgumentException: Error running script at location 
> [component://manufacturing/webapp/manufacturing/WEB-INF/actions/reports/ShipmentWorkEffortTasks.groovy]:
>  groovy.lang.MissingPropertyException: No such property: records for class: 
> ShipmentWorkEffortTasks (Error running script at location 
> [component://manufacturing/webapp/manufacturing/WEB-INF/actions/reports/ShipmentWorkEffortTasks.groovy]:
>  groovy.lang.MissingPropertyException: No such property: records for class: 
> ShipmentWorkEffortTasks)



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

[jira] [Commented] (OFBIZ-6188) Task Report error for Manufacturing Shipment Plan

2015-04-18 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-6188:


I checked, this could be backported to older branches, done in
R13.07 r1674506
R12.04 r1674507


> Task Report error for Manufacturing Shipment Plan
> -
>
> Key: OFBIZ-6188
> URL: https://issues.apache.org/jira/browse/OFBIZ-6188
> Project: OFBiz
>  Issue Type: Bug
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Deepak Dixit
> Fix For: 14.12.01, 12.04.06, 13.07.02, Upcoming Branch
>
> Attachments: OFBIZ-6188.patch
>
>
> This error occurs when clicking the Task Report button for Manufacturing 
> Shipment Plans at manufacturing/control/WorkWithShipmentPlan:
> Problems with the response writer/output stream: 
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen 
> [component://manufacturing/widget/manufacturing/ReportScreens.xml#ShipmentWorkEffortTasks]:
>  java.lang.IllegalArgumentException: Error running script at location 
> [component://manufacturing/webapp/manufacturing/WEB-INF/actions/reports/ShipmentWorkEffortTasks.groovy]:
>  groovy.lang.MissingPropertyException: No such property: records for class: 
> ShipmentWorkEffortTasks (Error running script at location 
> [component://manufacturing/webapp/manufacturing/WEB-INF/actions/reports/ShipmentWorkEffortTasks.groovy]:
>  groovy.lang.MissingPropertyException: No such property: records for class: 
> ShipmentWorkEffortTasks)



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

buildbot exception in ASF Buildbot on ofbiz-branch13

2015-04-18 Thread buildbot

The Buildbot has detected a build exception on builder ofbiz-branch13 while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/ofbiz-branch13/builds/292

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

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz13-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release13.07] 1674500
Blamelist: deepak

BUILD FAILED: exception upload_1

Sincerely,
 -The Buildbot

85 matches

Mail list logo