date:20170315

James,

I asked because the problem with this feature is it seems deeply entrenched in
Gradle. Look, you need to set an ENV variable to make it dumb!

Fortunately it's only a trivial issue, but an annoying one. Let's see if we can
do better than dumbing it...

Jacques

Le 16/03/2017 à 07:27, james yong a écrit :

Hi Jacques,

Haven't looked into yet. Was side-tracked by too many things :(

Regards,
James Yong

Jacques Le Roux wrote

That's quite a good idea James,

Did you try it's possible?

Thanks

Jacques

Le 16/03/2017 à 04:53, james yong a écrit :

Hi,

I think it is better to explicitly inform the user in the log message
that
OFBiz has started after all the components are loaded.
Something like this, but can be improved with some ANSI/ASCII artwork.

##
## OFBiz has started and ready for use
##

So there is less focus on the 91% message from gradle.

Regards,
James

Jacques Le Roux wrote

Hi,

Do you agree about https://issues.apache.org/jira/browse/OFBIZ-9263 ?

Thanks

Jacques

--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Remove-the-91-message-from-gradle-when-running-tasks-ofbiz-ofbizDebug-etc-or-altogether-tp4703413p4703423.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Remove-the-91-message-from-gradle-when-running-tasks-ofbiz-ofbizDebug-etc-or-altogether-tp4703413p4703440.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Remove the 91% message from gradle when running tasks (ofbiz, ofbizDebug, etc) or altogether

Hi Jacques,

Haven't looked into yet. Was side-tracked by too many things :(

Regards,
James Yong


Jacques Le Roux wrote
> That's quite a good idea James,
> 
> Did you try it's possible?
> 
> Thanks
> 
> Jacques
> 
> 
> Le 16/03/2017 à 04:53, james yong a écrit :
>> Hi,
>>
>> I think it is better to explicitly inform the user in the log message
>> that
>> OFBiz has started after all the components are loaded.
>> Something like this, but can be improved with some ANSI/ASCII artwork.
>>
>> ##
>> ## OFBiz has started and ready for use
>> ##
>>
>> So there is less focus on the 91% message from gradle.
>>
>> Regards,
>> James
>>
>>
>> Jacques Le Roux wrote
>>> Hi,
>>>
>>> Do you agree about https://issues.apache.org/jira/browse/OFBIZ-9263 ?
>>>
>>> Thanks
>>>
>>> Jacques
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Remove-the-91-message-from-gradle-when-running-tasks-ofbiz-ofbizDebug-etc-or-altogether-tp4703413p4703423.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Remove-the-91-message-from-gradle-when-running-tasks-ofbiz-ofbizDebug-etc-or-altogether-tp4703413p4703440.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Documentation by Release / Version

Hi Rishi,

Sorry for the late reply. The Tour section contains links to other topics
for guiding the beginners. I think "Business Process Stories and Use Cases
Library" is good and important to be included in Tour as it helps beginners
to evaluate their business needs. 

Cheers,
James Yong


Rishi Solanki wrote
> See if this effort can be part of -
> https://cwiki.apache.org/confluence/display/OFBIZ/Business+Process+Stories+and+Use+Cases+Library
> For more details please refer the email thread -
> ofbiz.markmail.org/search/?q=User+Acceptance+Test+Cases+For+Ecommerce+14.12
> 
> Or you would like to do it as completely separate effort and document will
> target completely different audiance/purpose?
> 
> Thanks!
> 
> Regards,
> --
> Rishi Solanki
> Sr. Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
> 
> On Fri, Mar 10, 2017 at 4:05 PM, Jacques Le Roux <

> jacques.le.roux@

>> wrote:
> 
>> +1
>>
>> Jacques
>>
>>
>> Le 10/03/2017 à 02:45, james yong a écrit :
>>
>>> Hi Jacques,
>>>
>>> I like your approach too.  I propose creating a Tour page in Confluence.
>>> This tour page will have a direct child page for the recent OFBiz
>>> releases,
>>> like the following menu structure:
>>>
>>> Tour
>>> -> Release 13.7
>>> -> Release 16.11
>>>
>>> Each of the Release xx.x page is a Table of Content that links to other
>>> existing pages.
>>> The tour is meant for beginner and they are expected to go through the
>>> topics from top to bottom.
>>>   With this approach, there will not be direct child page under each
>>> Release
>>> xx.x page. Existing documentation isn’t affected.
>>>
>>> Regards,
>>> James
>>>
>>>
>>>
>>> Jacques Le Roux wrote
>>>
>>> Hi James,

 I'm all for it.

 Note that I already used another strategy by referring to the history
 of
 few major pages[1] while documenting the Gradle from Ant. It though was
 a
 more an expedient than a structured way as you are proposing. But it
 could
 still be used when referring to old pages...

 [1] These pages contain the sentence "the pre-Gradle documentation is
 here", eg
 https://cwiki.apache.org/confluence/display/OFBIZ/Demo+and+
 Test+Setup+Guide

 Jacques


 Le 08/03/2017 à 18:05, james yong a écrit :

> Hi all,
>
> I am planning to add some new documentation in Confluence but will
> have
> them
> placed/linked under the affected OFBiz release / version.  For a user
> navigating the documentation, the user can click on a particular OFBiz
> release on the menu tree to display the list of topic for that OFBiz
> version.
>
> What do you think of this approach? Are there better ways to structure
> the
> menu items?
>
> Cheers,
> James Yong
>
>
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/Documentation-by-Release-V
> ersion-tp4703069.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>> com/Documentation-by-Release-Version-tp4703069p4703111.html
>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>
>>>
>>>
>>





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Documentation-by-Release-Version-tp4703069p4703439.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: svn commit: r1787047 - /ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/java/org/apache/of biz/webtools/labelmanager/LabelManagerFactory.java


If you really want to help, here you go 
https://issues.apache.org/jira/browse/OFBIZ-8154

Jacques

Le 16/03/2017 à 07:10, Jacques Le Roux a écrit :

BTW before asking you can check by yourself, it's not a big deal ;)

Jacques


Le 16/03/2017 à 07:06, Jacques Le Roux a écrit :

Hi Taher

Inline

Le 15/03/2017 à 22:46, Taher Alkhateeb a écrit :

How do you know that this does not crash existing code?

Because I tested it

You are switching from an ignore behavior to throwing an exception! Did you 
check all
reference and calls to it?

Of course I did

Jacques


On Wed, Mar 15, 2017 at 4:56 PM,  wrote:


Author: jleroux
Date: Wed Mar 15 13:56:38 2017
New Revision: 1787047

URL: http://svn.apache.org/viewvc?rev=1787047&view=rev
Log:
Improved: Handle only labels with the "_" separator between languages and
countries
(OFBIZ-9261)

This is handled in LabelManagerFactory.java

 Element valueElem = (Element) valueNode;
 // Support old way of specifying xml:lang value.
 // Old way: en_AU, new way: en-AU
 String localeName = valueElem.getAttribute("xml:lang");
 if( localeName.contains("_")) {
 localeName = localeName.replace('_', '-');
 }

I replaces this snippet by throwing an exception in order to now to
automatically detect issues

Moreover I notices that there are no longer reasons to bypass the
ExampleEntityLabels and ProductPromoUiLabels files

Modified:
ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java

Modified: ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager/
LabelManagerFactory.java?rev=1787047&r1=1787046&r2=1787047&view=diff

==
--- ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
(original)
+++ ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java Wed
Mar 15 13:56:38 2017
@@ -114,11 +114,6 @@ public class LabelManagerFactory {
  if (UtilValidate.isNotEmpty(fileName) &&
!fileName.equals(fileInfo.getFileName())) {
  continue;
  }
-if ("ExampleEntityLabels.xml".equals(fileInfo.getFileName())
-|| "ProductPromoUiLabels.xml".
equals(fileInfo.getFileName())
-) {
-continue;
-}
  if (Debug.infoOn()) {
  Debug.logInfo("Current file : " + fileInfo.getFileName(),
module);
  }
@@ -157,11 +152,12 @@ public class LabelManagerFactory {
  for (Node valueNode : 
UtilXml.childNodeList(propertyElem.getFirstChild()))
{
  if (valueNode instanceof Element) {
  Element valueElem = (Element) valueNode;
-// Support old way of specifying xml:lang
value.
+// No longer supporting old way of specifying
xml:lang value.
  // Old way: en_AU, new way: en-AU
  String localeName =
valueElem.getAttribute("xml:lang");
  if( localeName.contains("_")) {
-localeName = localeName.replace('_', '-');
+GeneralException e = new
GeneralException("Confusion in labels with the separator used between
languages and countries. Please use a dash instead of an underscore.");
+throw e;
  }
  String labelValue = UtilCodec.canonicalize(
UtilXml.nodeValue(valueElem.getFirstChild()));
  LabelInfo label = labels.get(labelKey +
keySeparator + fileInfo.getFileName());

Re: svn commit: r1786919 - in /ofbiz/ofbiz-framework/trunk/applications/accounting/widget: FieldLookupForms.xml LookupScreens.xml

Thanks James,

Here are some more elements to convince Taher that it was not a shoot in the 
dark.

They are all available from http://ofbiz.apache.org/release-notes-16.11.01.html, just 
look for "grid"

http://markmail.org/message/4m3vgq4wdvo7ziaj

https://issues.apache.org/jira/browse/OFBIZ-6404

https://issues.apache.org/jira/browse/OFBIZ-6501

https://issues.apache.org/jira/browse/OFBIZ-6502

https://issues.apache.org/jira/browse/OFBIZ-7029

So it's not 100% done, but I don't see myself reverting all this work with 
really good reasons!

Jacques

Le 15/03/2017 à 10:05, james yong a écrit :

Hi Taher,

Common grid functionalities include pivots, sorting columns, multiple-row
header, aggregate functions, in-grid editing etc. IMO, these should be
standard grid features for modern ERP. I see the value of the extraction. It
would be difficult to innovate in the future if lists are still coupled with
forms.

Regards,
James Yong

taher wrote

Still seems unclear. What is the value of this extraction? How is it
implemented? Who intends on implementing the new features if any? What are
the new features? How does that play into the UI refactoring intended
within themes? What do we gain by this whole exercise? Given that we lost
Adrian, someone should have answers to these questions before we commit to
such a large body of work. There are hundreds if not thousands of such
forms all over the code base.

On Wed, Mar 15, 2017 at 11:29 AM, Pierre Smits <
pierre.smits@
>
wrote:

That is what you get in transitional stages. But then again, OFBiz offers
lots of flexibility in order to get from A to Z.

As I read it, it was the intention of Adrian to simplify (I would like to
extract list functionality from the form widget and create a new grid
widget). But you can't remove the functionality until all referenced
widgets are converted (the backward compatibility).

Best regards,

Pierre Smits

ORRTIZ.COM ;
OFBiz based solutions & services

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

On Wed, Mar 15, 2017 at 6:49 AM, Taher Alkhateeb <

slidingfilaments@

wrote:
So it's two widgets that output an identical HTML structure with no

plan
in

sight of making a differentiation. This is now putting in the code base

two

ways of achieving the same thing (more complexity) for no added value.
Maybe we need to discuss the added value and direction of such work.

On Tue, Mar 14, 2017 at 7:20 PM, Jacques Le Roux <

jacques.le.roux@

wrote:

Hi Taher,

It's explained here http://markmail.org/message/77swtjvr6q25rq4d

Quoting Adrian.

< > widget

and create a new grid widget. So, instead of a form widget

representing a

single data entry form OR a list, it will ONLY represent a single

form.

If

you want a list, you use the grid widget. Initially, this change will

be

backwards-compatible - the XML parser will accept a

  element for

both

types and it will create the correct model based on the type

attribute.>>

Initially I wondered if Adrian had not a CSS idea in mind, I can't

clearly

remember if we discussed it or not

Jacques

Le 14/03/2017 à 17:06, Taher Alkhateeb a écrit :

Hi Jacques,

What is the purpose of converting list forms to grids?

Regards,

Taher Alkhateeb

On Mar 14, 2017 6:59 PM, <

jleroux@
> wrote:

Author: jleroux

Date: Tue Mar 14 15:59:23 2017
New Revision: 1786919

URL: http://svn.apache.org/viewvc?rev=1786919&view=rev
Log:
Improved: refactor list related forms in Lookup widgets
(OFBIZ-9232)

Refactoring various list forms into grids
Refactoring various list form references in screen widgets

Thanks: Pierre Smits

Modified:
  ofbiz/ofbiz-framework/trunk/applications/accounting/
widget/FieldLookupForms.xml
  ofbiz/ofbiz-framework/trunk/applications/accounting/
widget/LookupScreens.xml

Modified: ofbiz/ofbiz-framework/trunk/applications/accounting/
widget/FieldLookupForms.xml
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/accounting/widget/FieldLookupForms.xml?
rev=1786919&r1=1786918&r2=1786919&view=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
FieldLookupForms.xml
(original)
+++ ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
FieldLookupForms.xml
Tue Mar 14 15:59:23 2017
@@ -36,7 +36,7 @@ under the License.

widget-style="smallSubmit">

-

 >>> type="list" paginate-target="LookupFixedAsset"

+

 >>> paginate-target="LookupFixedAsset"

   odd-row-style="alternate-row" default-table-style="basic-

table

hover-bar">

 >>> result-map-list="listIt">

@@ -51,7 +51,7 @@ under the License.

 >>> entity-name="FixedAssetType"/>

-

+

 >>> type="single"

   header-row-style="header-row"

default-table-style="

Re: svn commit: r1787047 - /ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/java/org/apache/of biz/webtools/labelmanager/LabelManagerFactory.java


BTW before asking you can check by yourself, it's not a big deal ;)

Jacques


Le 16/03/2017 à 07:06, Jacques Le Roux a écrit :

Hi Taher

Inline

Le 15/03/2017 à 22:46, Taher Alkhateeb a écrit :

How do you know that this does not crash existing code?

Because I tested it

You are switching from an ignore behavior to throwing an exception! Did you 
check all
reference and calls to it?

Of course I did

Jacques


On Wed, Mar 15, 2017 at 4:56 PM,  wrote:


Author: jleroux
Date: Wed Mar 15 13:56:38 2017
New Revision: 1787047

URL: http://svn.apache.org/viewvc?rev=1787047&view=rev
Log:
Improved: Handle only labels with the "_" separator between languages and
countries
(OFBIZ-9261)

This is handled in LabelManagerFactory.java

 Element valueElem = (Element) valueNode;
 // Support old way of specifying xml:lang value.
 // Old way: en_AU, new way: en-AU
 String localeName = valueElem.getAttribute("xml:lang");
 if( localeName.contains("_")) {
 localeName = localeName.replace('_', '-');
 }

I replaces this snippet by throwing an exception in order to now to
automatically detect issues

Moreover I notices that there are no longer reasons to bypass the
ExampleEntityLabels and ProductPromoUiLabels files

Modified:
 ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java

Modified: ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager/
LabelManagerFactory.java?rev=1787047&r1=1787046&r2=1787047&view=diff

==
--- ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
(original)
+++ ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java Wed
Mar 15 13:56:38 2017
@@ -114,11 +114,6 @@ public class LabelManagerFactory {
  if (UtilValidate.isNotEmpty(fileName) &&
!fileName.equals(fileInfo.getFileName())) {
  continue;
  }
-if ("ExampleEntityLabels.xml".equals(fileInfo.getFileName())
-|| "ProductPromoUiLabels.xml".
equals(fileInfo.getFileName())
-) {
-continue;
-}
  if (Debug.infoOn()) {
  Debug.logInfo("Current file : " + fileInfo.getFileName(),
module);
  }
@@ -157,11 +152,12 @@ public class LabelManagerFactory {
  for (Node valueNode : 
UtilXml.childNodeList(propertyElem.getFirstChild()))
{
  if (valueNode instanceof Element) {
  Element valueElem = (Element) valueNode;
-// Support old way of specifying xml:lang
value.
+// No longer supporting old way of specifying
xml:lang value.
  // Old way: en_AU, new way: en-AU
  String localeName =
valueElem.getAttribute("xml:lang");
  if( localeName.contains("_")) {
-localeName = localeName.replace('_', '-');
+GeneralException e = new
GeneralException("Confusion in labels with the separator used between
languages and countries. Please use a dash instead of an underscore.");
+throw e;
  }
  String labelValue = UtilCodec.canonicalize(
UtilXml.nodeValue(valueElem.getFirstChild()));
  LabelInfo label = labels.get(labelKey +
keySeparator + fileInfo.getFileName());

Re: Remove the 91% message from gradle when running tasks (ofbiz, ofbizDebug, etc) or altogether


That's quite a good idea James,

Did you try it's possible?

Thanks

Jacques


Le 16/03/2017 à 04:53, james yong a écrit :

Hi,

I think it is better to explicitly inform the user in the log message that
OFBiz has started after all the components are loaded.
Something like this, but can be improved with some ANSI/ASCII artwork.

##
## OFBiz has started and ready for use
##

So there is less focus on the 91% message from gradle.

Regards,
James


Jacques Le Roux wrote

Hi,

Do you agree about https://issues.apache.org/jira/browse/OFBIZ-9263 ?

Thanks

Jacques





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Remove-the-91-message-from-gradle-when-running-tasks-ofbiz-ofbizDebug-etc-or-altogether-tp4703413p4703423.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: svn commit: r1787047 - /ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/java/org/apache/of biz/webtools/labelmanager/LabelManagerFactory.java


Hi Taher

Inline

Le 15/03/2017 à 22:46, Taher Alkhateeb a écrit :

How do you know that this does not crash existing code?

Because I tested it

You are switching from an ignore behavior to throwing an exception! Did you 
check all
reference and calls to it?

Of course I did

Jacques


On Wed, Mar 15, 2017 at 4:56 PM,  wrote:


Author: jleroux
Date: Wed Mar 15 13:56:38 2017
New Revision: 1787047

URL: http://svn.apache.org/viewvc?rev=1787047&view=rev
Log:
Improved: Handle only labels with the "_" separator between languages and
countries
(OFBIZ-9261)

This is handled in LabelManagerFactory.java

 Element valueElem = (Element) valueNode;
 // Support old way of specifying xml:lang value.
 // Old way: en_AU, new way: en-AU
 String localeName = valueElem.getAttribute("xml:lang");
 if( localeName.contains("_")) {
 localeName = localeName.replace('_', '-');
 }

I replaces this snippet by throwing an exception in order to now to
automatically detect issues

Moreover I notices that there are no longer reasons to bypass the
ExampleEntityLabels and ProductPromoUiLabels files

Modified:
 ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java

Modified: ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager/
LabelManagerFactory.java?rev=1787047&r1=1787046&r2=1787047&view=diff

==
--- ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
(original)
+++ ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java Wed
Mar 15 13:56:38 2017
@@ -114,11 +114,6 @@ public class LabelManagerFactory {
  if (UtilValidate.isNotEmpty(fileName) &&
!fileName.equals(fileInfo.getFileName())) {
  continue;
  }
-if ("ExampleEntityLabels.xml".equals(fileInfo.getFileName())
-|| "ProductPromoUiLabels.xml".
equals(fileInfo.getFileName())
-) {
-continue;
-}
  if (Debug.infoOn()) {
  Debug.logInfo("Current file : " + fileInfo.getFileName(),
module);
  }
@@ -157,11 +152,12 @@ public class LabelManagerFactory {
  for (Node valueNode : 
UtilXml.childNodeList(propertyElem.getFirstChild()))
{
  if (valueNode instanceof Element) {
  Element valueElem = (Element) valueNode;
-// Support old way of specifying xml:lang
value.
+// No longer supporting old way of specifying
xml:lang value.
  // Old way: en_AU, new way: en-AU
  String localeName =
valueElem.getAttribute("xml:lang");
  if( localeName.contains("_")) {
-localeName = localeName.replace('_', '-');
+GeneralException e = new
GeneralException("Confusion in labels with the separator used between
languages and countries. Please use a dash instead of an underscore.");
+throw e;
  }
  String labelValue = UtilCodec.canonicalize(
UtilXml.nodeValue(valueElem.getFirstChild()));
  LabelInfo label = labels.get(labelKey +
keySeparator + fileInfo.getFileName());

Re: Remove the 91% message from gradle when running tasks (ofbiz, ofbizDebug, etc) or altogether

Hi,

I think it is better to explicitly inform the user in the log message that
OFBiz has started after all the components are loaded.
Something like this, but can be improved with some ANSI/ASCII artwork. 

##
## OFBiz has started and ready for use 
##

So there is less focus on the 91% message from gradle.

Regards,
James


Jacques Le Roux wrote
> Hi,
> 
> Do you agree about https://issues.apache.org/jira/browse/OFBIZ-9263 ?
> 
> Thanks
> 
> Jacques





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Remove-the-91-message-from-gradle-when-running-tasks-ofbiz-ofbizDebug-etc-or-altogether-tp4703413p4703423.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: svn commit: r1787047 - /ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java

How do you know that this does not crash existing code? You are switching
from an ignore behavior to throwing an exception! Did you check all
reference and calls to it?

On Wed, Mar 15, 2017 at 4:56 PM,  wrote:

> Author: jleroux
> Date: Wed Mar 15 13:56:38 2017
> New Revision: 1787047
>
> URL: http://svn.apache.org/viewvc?rev=1787047&view=rev
> Log:
> Improved: Handle only labels with the "_" separator between languages and
> countries
> (OFBIZ-9261)
>
> This is handled in LabelManagerFactory.java
>
> Element valueElem = (Element) valueNode;
> // Support old way of specifying xml:lang value.
> // Old way: en_AU, new way: en-AU
> String localeName = valueElem.getAttribute("xml:lang");
> if( localeName.contains("_")) {
> localeName = localeName.replace('_', '-');
> }
>
> I replaces this snippet by throwing an exception in order to now to
> automatically detect issues
>
> Moreover I notices that there are no longer reasons to bypass the
> ExampleEntityLabels and ProductPromoUiLabels files
>
> Modified:
> ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
> java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
>
> Modified: ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
> java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager/
> LabelManagerFactory.java?rev=1787047&r1=1787046&r2=1787047&view=diff
> 
> ==
> --- ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
> java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java
> (original)
> +++ ofbiz/ofbiz-framework/trunk/framework/webtools/src/main/
> java/org/apache/ofbiz/webtools/labelmanager/LabelManagerFactory.java Wed
> Mar 15 13:56:38 2017
> @@ -114,11 +114,6 @@ public class LabelManagerFactory {
>  if (UtilValidate.isNotEmpty(fileName) &&
> !fileName.equals(fileInfo.getFileName())) {
>  continue;
>  }
> -if ("ExampleEntityLabels.xml".equals(fileInfo.getFileName())
> -|| "ProductPromoUiLabels.xml".
> equals(fileInfo.getFileName())
> -) {
> -continue;
> -}
>  if (Debug.infoOn()) {
>  Debug.logInfo("Current file : " + fileInfo.getFileName(),
> module);
>  }
> @@ -157,11 +152,12 @@ public class LabelManagerFactory {
>  for (Node valueNode : 
> UtilXml.childNodeList(propertyElem.getFirstChild()))
> {
>  if (valueNode instanceof Element) {
>  Element valueElem = (Element) valueNode;
> -// Support old way of specifying xml:lang
> value.
> +// No longer supporting old way of specifying
> xml:lang value.
>  // Old way: en_AU, new way: en-AU
>  String localeName =
> valueElem.getAttribute("xml:lang");
>  if( localeName.contains("_")) {
> -localeName = localeName.replace('_', '-');
> +GeneralException e = new
> GeneralException("Confusion in labels with the separator used between
> languages and countries. Please use a dash instead of an underscore.");
> +throw e;
>  }
>  String labelValue = UtilCodec.canonicalize(
> UtilXml.nodeValue(valueElem.getFirstChild()));
>  LabelInfo label = labels.get(labelKey +
> keySeparator + fileInfo.getFileName());
>
>
>

Re: Remove the 91% message from gradle when running tasks (ofbiz, ofbizDebug, etc) or altogether

By that logic we should include in README.md things like:

- ignore the warnings from the log file
- ignore the exceptions thrown because we have some faulty forms
- ignore the system crashing if you don't load data
- ignore all anomalies and corner cases

This is a trivial issue that is being converted into a major issue. I'm not
sure it warrants all this discussion, opening a JIRA and quoting our
hipchat discussion like it's a big issue while we leave the more critical
issues. We have a problem in port mapping, UI refactoring, and tons of work
in critical areas. Why not spend energy where it is due.

My opinion is that this is an insignificant cosmetic issue that can be very
easily addressed. You can define the environment variable in the wrapper
startup script for example and be done with this whole discussion. To my
memory this discussion came up twice, so definitely not a recurring
question that happens everyday on the ML.

This reminds me when we first started migrating to gradle of discussions
like oh let's have an alias like g instead of gradlew or let's try to
customize the gradle gui to handle corner cases while leaving the important
and critical work of the actual migration.

On Mar 15, 2017 11:33 PM, "Jacques Le Roux" 
wrote:

> Hi,
>
> Do you agree about https://issues.apache.org/jira/browse/OFBIZ-9263 ?
>
> Thanks
>
> Jacques
>
>

Remove the 91% message from gradle when running tasks (ofbiz, ofbizDebug, etc) or altogether


Hi,

Do you agree about https://issues.apache.org/jira/browse/OFBIZ-9263 ?

Thanks

Jacques

Re: Plugins: skipped obstructing working copy (error message)


Le 15/03/2017 à 16:21, Jacques Le Roux a écrit :

Le 15/03/2017 à 15:10, Jacques Le Roux a écrit :
In other words, because of the plugins/README.txt file when you create a working copy from the ofbiz-framework/trunk branch you generate a .svn in 
root folder where there is a "knowledge" of this file and the plugins directory.


So, we can't delete it and replace it by another different plugins directory. 
I created https://issues.apache.org/jira/browse/OFBIZ-9262 and tried something w/o success so far, a bit worrisome, but there is a plan B: have as 
much as WCs than plugins, something I was worrying about initially...


Jacques



And of course an (IMO) even better PLAN A': remove the plugins folder and 
document it in the main README.MD file

Jacques

Re: Plugins: skipped obstructing working copy (error message)


Le 15/03/2017 à 15:10, Jacques Le Roux a écrit :
In other words, because of the plugins/README.txt file when you create a working copy from the ofbiz-framework/trunk branch you generate a .svn in 
root folder where there is a "knowledge" of this file and the plugins directory.


So, we can't delete it and replace it by another different plugins directory. 
I created https://issues.apache.org/jira/browse/OFBIZ-9262 and tried something w/o success so far, a bit worrisome, but there is a plan B: have as 
much as WCs than plugins, something I was worrying about initially...


Jacques

Re: Plugins: skipped obstructing working copy (error message)


Taher, Deepak,

I already explained the reason of the problem in the initial thread message.

<(plugins folder) and the main .svn gets confused (in root) >>


In other words, because of the plugins/README.txt file when you create a working copy from the ofbiz-framework/trunk branch you generate a .svn in 
root folder where there is a "knowledge" of this file and the plugins directory.


So, we can't delete it and replace it by another different plugins directory.

I'll give a try on changing pullAllPluginsSource now

Jacques


Le 15/03/2017 à 09:51, Taher Alkhateeb a écrit :

Hi Deepak,

Just to be on the safe side though, do you think that would solve the
subversion issue? I mean does subversion complain because of folder
deletion and then creation? or does it complain because of move a .svn
based repo from one subdirectory to another?

Also what about the idea of ignoring /plugins and then just creating it
when starting any server task in OFBiz?

What would you recommend as the more "friendly to subversion" approach? I'm
not a very big fan of subversion so that's why I ask for suggestions to
guide me through :)

On Wed, Mar 15, 2017 at 11:13 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:


Thanks Taher,

Make sense, I am fine with following approach.

Would that solve the subversion problem? Let me just reiterate the steps:

- checkout plugins into /temp
- delete everything _inside_ /plugins
- move everything (including .svn) from /temp to /plugins
- delete /temp

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

On Wed, Mar 15, 2017 at 1:06 PM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:
Hi Deepak,

So there are multiple issues with this code that I attempt summarize

below:

- First, you are directly using the subversion command in an "exec"

block.

We used the subversion plugin to avoid having gradle depend on anything
other than gradle. I think it might be better to try and list the plugins
through the subversion-plugin for gradle.
- It would be very slow, memory consuming and inefficient to use the
gradlewSubprocess for each plugin individually and it might choke

resources

on your computer
- Finally, the way you wrote this task would create a ".svn" directory

for

each plugin individually instead of having a single ".svn" directory for
all of them under /plugins.

Maybe an easier way is to keep the pullAllPluginSource task as is, but
instead of deleting plugins, we just delete everything _inside_ plugins

and

then move the checkout resources to there.

Would that solve the subversion problem? Let me just reiterate the steps:

- checkout plugins into /temp
- delete everything _inside_ /plugins
- move everything (including .svn) from /temp to /plugins
- delete /temp

Regards,

Taher Alkhateeb

On Wed, Mar 15, 2017 at 9:33 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:


Hi Taher,

I tried to change it with following bug not able to run sub process.

{code}

task pullAllPluginsSource(group: ofbizPlugin,
 description: 'Download and install all plugins from source
control.') {
 def svnOutput = new ByteArrayOutputStream()
 exec {
commandLine 'svn', 'list','--xml',
'https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk'
standardOutput = svnOutput
 }
 def plugins= new XmlParser().parseText(svnOutput.toString())
 plugins.list.entry.each {plugin ->
def pluginId =  plugin.name.text()
gradlewSubprocess(['pullPluginSource',

"-PpluginId=${pluginId}"])

 }
}

{code}


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

On Wed, Mar 15, 2017 at 11:22 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:


Sure, let's change the implementation. I'd be glad to help if I

receive

some suggestions. For now .. the implementation is as follows:

- create a temp directory
- checkout to that directory
- delete /plugins
- rename temp to plugins

I'm all ears for the best approach.

On Wed, Mar 15, 2017 at 8:15 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:


We need to enhance pullAllPluginsSource task, after running this

you

will

not able to commit or run any svn command on plugins, as it do

checkout

of

plugins/trunk and copy its folder into plugins.


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

On Wed, Mar 15, 2017 at 12:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


That would be better indeed, I did not look a it yet.

Jacques



Le 14/03/2017 à 19:04, Deepak Dixit a écrit :


I think we can improve gradle task and instead of deleting

plugins

it

will

its delete sub-folder.
I am sure gradle should have ability to delete sub-folder. :)

If we delete README.txt then it will not be available in git as

git

does

not support empty folder.



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

On Tue, Mar 14, 2017 at 6:46 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,

I just crossed an issue while updating my ofbiz-framework

working

c

buildbot failure in on ofbiz-trunk-framework

2017-03-15 Thread buildbot

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

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

Buildslave for this Build: silvanus_ubuntu

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

BUILD FAILED: failed shell_2

Sincerely,
 -The Buildbot

Re: Confusion in labels with the separator used between languages and countries


I confirm this is handled in LabelManagerFactory.java

Element valueElem = (Element) valueNode;
// Support old way of specifying xml:lang value.
// Old way: en_AU, new way: en-AU
String localeName = 
valueElem.getAttribute("xml:lang");
if( localeName.contains("_")) {
localeName = localeName.replace('_', '-');
}
I'll replace this snippet by throwing an exception in order to now to 
automatically detect such issues

Jacques


Le 15/03/2017 à 12:17, Jacques Le Roux a écrit :

Hi committers,

This is mostly for Chinese committers who are the most active in this area at 
the moment, but others could be interested also...

I know it's confusing because Java uses underscore to separate languages from 
countries

http://www.oracle.com/us/technologies/java/locale-140624.html

when a dash is required by XML :/

See errors reported in https://issues.apache.org/jira/browse/OFBIZ-9260 
description

Thanks to care next time :)

Jacques

buildbot exception in on ofbiz-trunk-framework

2017-03-15 Thread buildbot

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

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

Buildslave for this Build: silvanus_ubuntu

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

BUILD FAILED: exception shell upload_1

Sincerely,
 -The Buildbot

Confusion in labels with the separator used between languages and countries


Hi committers,

This is mostly for Chinese committers who are the most active in this area at 
the moment, but others could be interested also...

I know it's confusing because Java uses underscore to separate languages from 
countries

http://www.oracle.com/us/technologies/java/locale-140624.html

when a dash is required by XML :/

See errors reported in https://issues.apache.org/jira/browse/OFBIZ-9260 
description

Thanks to care next time :)

Jacques

buildbot success in on ofbiz-branch16

2017-03-15 Thread buildbot

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

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

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz16-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release16.11] 1787024
Blamelist: jleroux

Build succeeded!

Sincerely,
 -The Buildbot

Re: svn commit: r1786919 - in /ofbiz/ofbiz-framework/trunk/applications/accounting/widget: FieldLookupForms.xml LookupScreens.xml

Hi Taher,

Common grid functionalities include pivots, sorting columns, multiple-row
header, aggregate functions, in-grid editing etc. IMO, these should be
standard grid features for modern ERP. I see the value of the extraction. It
would be difficult to innovate in the future if lists are still coupled with
forms.

Regards,
James Yong


taher wrote
> Still seems unclear. What is the value of this extraction? How is it
> implemented? Who intends on implementing the new features if any? What are
> the new features? How does that play into the UI refactoring intended
> within themes? What do we gain by this whole exercise? Given that we lost
> Adrian, someone should have answers to these questions before we commit to
> such a large body of work. There are hundreds if not thousands of such
> forms all over the code base.
> 
> On Wed, Mar 15, 2017 at 11:29 AM, Pierre Smits <

> pierre.smits@

> >
> wrote:
> 
>> That is what you get in transitional stages. But then again, OFBiz offers
>> lots of flexibility in order to get from A to Z.
>>
>> As I read it, it was the intention of Adrian to simplify (I would like to
>> extract list functionality from the form widget and create a new grid
>> widget). But you can't remove the functionality until all referenced
>> widgets are converted (the backward compatibility).
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM ;
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Wed, Mar 15, 2017 at 6:49 AM, Taher Alkhateeb <
>> 

> slidingfilaments@

>> > wrote:
>>
>> > So it's two widgets that output an identical HTML structure with no
>> plan
>> in
>> > sight of making a differentiation. This is now putting in the code base
>> two
>> > ways of achieving the same thing (more complexity) for no added value.
>> > Maybe we need to discuss the added value and direction of such work.
>> >
>> > On Tue, Mar 14, 2017 at 7:20 PM, Jacques Le Roux <
>> > 

> jacques.le.roux@

>> wrote:
>> >
>> > > Hi Taher,
>> > >
>> > > It's explained here http://markmail.org/message/77swtjvr6q25rq4d
>> > >
>> > > Quoting Adrian.
>> > >
>> > > <> form
> > > widget
>> > > and create a new grid widget. So, instead of a form widget
>> representing a
>> > > single data entry form OR a list, it will ONLY represent a single
>> form.
>> > If
>> > > you want a list, you use the grid widget. Initially, this change will
>> be
>> > > backwards-compatible - the XML parser will accept a 
> 
>  element for
>> > both
>> > > types and it will create the correct model based on the type
>> attribute.>>
>> > >
>> > > Initially I wondered if Adrian had not a CSS idea in mind, I can't
>> > clearly
>> > > remember if we discussed it or not
>> > >
>> > > Jacques
>> > >
>> > >
>> > >
>> > > Le 14/03/2017 à 17:06, Taher Alkhateeb a écrit :
>> > >
>> > >> Hi Jacques,
>> > >>
>> > >> What is the purpose of converting list forms to grids?
>> > >>
>> > >> Regards,
>> > >>
>> > >> Taher Alkhateeb
>> > >>
>> > >> On Mar 14, 2017 6:59 PM, <

> jleroux@

> > wrote:
>> > >>
>> > >> Author: jleroux
>> > >>> Date: Tue Mar 14 15:59:23 2017
>> > >>> New Revision: 1786919
>> > >>>
>> > >>> URL: http://svn.apache.org/viewvc?rev=1786919&view=rev
>> > >>> Log:
>> > >>> Improved: refactor list related forms in Lookup widgets
>> > >>> (OFBIZ-9232)
>> > >>>
>> > >>> Refactoring various list forms into grids
>> > >>> Refactoring various list form references in screen widgets
>> > >>>
>> > >>>
>> > >>> Thanks: Pierre Smits
>> > >>>
>> > >>> Modified:
>> > >>>  ofbiz/ofbiz-framework/trunk/applications/accounting/
>> > >>> widget/FieldLookupForms.xml
>> > >>>  ofbiz/ofbiz-framework/trunk/applications/accounting/
>> > >>> widget/LookupScreens.xml
>> > >>>
>> > >>> Modified: ofbiz/ofbiz-framework/trunk/applications/accounting/
>> > >>> widget/FieldLookupForms.xml
>> > >>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
>> > >>> applications/accounting/widget/FieldLookupForms.xml?
>> > >>> rev=1786919&r1=1786918&r2=1786919&view=diff
>> > >>> 
>> > >>> ==
>> > >>> --- ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
>> > >>> FieldLookupForms.xml
>> > >>> (original)
>> > >>> +++ ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
>> > >>> FieldLookupForms.xml
>> > >>> Tue Mar 14 15:59:23 2017
>> > >>> @@ -36,7 +36,7 @@ under the License.
>> > >>>   
> 
> 

> 
>> > >>>   
> > > >>> widget-style="smallSubmit">
> 
> 
>> > >>>   
> 
>> > >>> -
> >
>  > >>> type="list" paginate-target="LookupFixedAsset"
>> > >>> +
> >
>  > >>> paginate-target="LookupFixedAsset"
>> > >>>   odd-row-style="alternate-row" default-table-style="basic-
>> > table
>> > >>> hover-bar">
>> > >>>   
> 
>> > >>>   
> >
>  > >>> result-map-list="listIt">
>> > >>> @@ -5

Re: svn commit: r1786919 - in /ofbiz/ofbiz-framework/trunk/applications/accounting/widget: FieldLookupForms.xml LookupScreens.xml

Still seems unclear. What is the value of this extraction? How is it
implemented? Who intends on implementing the new features if any? What are
the new features? How does that play into the UI refactoring intended
within themes? What do we gain by this whole exercise? Given that we lost
Adrian, someone should have answers to these questions before we commit to
such a large body of work. There are hundreds if not thousands of such
forms all over the code base.

On Wed, Mar 15, 2017 at 11:29 AM, Pierre Smits 
wrote:

> That is what you get in transitional stages. But then again, OFBiz offers
> lots of flexibility in order to get from A to Z.
>
> As I read it, it was the intention of Adrian to simplify (I would like to
> extract list functionality from the form widget and create a new grid
> widget). But you can't remove the functionality until all referenced
> widgets are converted (the backward compatibility).
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Mar 15, 2017 at 6:49 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com
> > wrote:
>
> > So it's two widgets that output an identical HTML structure with no plan
> in
> > sight of making a differentiation. This is now putting in the code base
> two
> > ways of achieving the same thing (more complexity) for no added value.
> > Maybe we need to discuss the added value and direction of such work.
> >
> > On Tue, Mar 14, 2017 at 7:20 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> > > Hi Taher,
> > >
> > > It's explained here http://markmail.org/message/77swtjvr6q25rq4d
> > >
> > > Quoting Adrian.
> > >
> > > < > widget
> > > and create a new grid widget. So, instead of a form widget
> representing a
> > > single data entry form OR a list, it will ONLY represent a single form.
> > If
> > > you want a list, you use the grid widget. Initially, this change will
> be
> > > backwards-compatible - the XML parser will accept a  element for
> > both
> > > types and it will create the correct model based on the type
> attribute.>>
> > >
> > > Initially I wondered if Adrian had not a CSS idea in mind, I can't
> > clearly
> > > remember if we discussed it or not
> > >
> > > Jacques
> > >
> > >
> > >
> > > Le 14/03/2017 à 17:06, Taher Alkhateeb a écrit :
> > >
> > >> Hi Jacques,
> > >>
> > >> What is the purpose of converting list forms to grids?
> > >>
> > >> Regards,
> > >>
> > >> Taher Alkhateeb
> > >>
> > >> On Mar 14, 2017 6:59 PM,  wrote:
> > >>
> > >> Author: jleroux
> > >>> Date: Tue Mar 14 15:59:23 2017
> > >>> New Revision: 1786919
> > >>>
> > >>> URL: http://svn.apache.org/viewvc?rev=1786919&view=rev
> > >>> Log:
> > >>> Improved: refactor list related forms in Lookup widgets
> > >>> (OFBIZ-9232)
> > >>>
> > >>> Refactoring various list forms into grids
> > >>> Refactoring various list form references in screen widgets
> > >>>
> > >>>
> > >>> Thanks: Pierre Smits
> > >>>
> > >>> Modified:
> > >>>  ofbiz/ofbiz-framework/trunk/applications/accounting/
> > >>> widget/FieldLookupForms.xml
> > >>>  ofbiz/ofbiz-framework/trunk/applications/accounting/
> > >>> widget/LookupScreens.xml
> > >>>
> > >>> Modified: ofbiz/ofbiz-framework/trunk/applications/accounting/
> > >>> widget/FieldLookupForms.xml
> > >>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> > >>> applications/accounting/widget/FieldLookupForms.xml?
> > >>> rev=1786919&r1=1786918&r2=1786919&view=diff
> > >>> 
> > >>> ==
> > >>> --- ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
> > >>> FieldLookupForms.xml
> > >>> (original)
> > >>> +++ ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
> > >>> FieldLookupForms.xml
> > >>> Tue Mar 14 15:59:23 2017
> > >>> @@ -36,7 +36,7 @@ under the License.
> > >>>   
> > >>>> >>> widget-style="smallSubmit">
> > >>>   
> > >>> - > >>> type="list" paginate-target="LookupFixedAsset"
> > >>> + > >>> paginate-target="LookupFixedAsset"
> > >>>   odd-row-style="alternate-row" default-table-style="basic-
> > table
> > >>> hover-bar">
> > >>>   
> > >>>> >>> result-map-list="listIt">
> > >>> @@ -51,7 +51,7 @@ under the License.
> > >>>   
> > >>>   
> > >>>> >>> entity-name="FixedAssetType"/>
> > >>> -
> > >>> +
> > >>>> >>> type="single"
> > >>>   header-row-style="header-row"
> default-table-style="basic-tab
> > >>> le">
> > >>>> >>> default-field-type="hidden"/>
> > >>> @@ -94,7 +94,7 @@ under the License.
> > >>>   
> > >>>> >>> widget-style="smallSubmit">
> > >>>   
> > >>> - > >>> type="list" paginate-target="LookupBillingAccount"
> > >>> + > >>> paginate-target="LookupBillingAccount"
> > >>>   odd-row-style="alternate-row" default

Re: Plugins: skipped obstructing working copy (error message)

Hi Deepak,

Just to be on the safe side though, do you think that would solve the
subversion issue? I mean does subversion complain because of folder
deletion and then creation? or does it complain because of move a .svn
based repo from one subdirectory to another?

Also what about the idea of ignoring /plugins and then just creating it
when starting any server task in OFBiz?

What would you recommend as the more "friendly to subversion" approach? I'm
not a very big fan of subversion so that's why I ask for suggestions to
guide me through :)

On Wed, Mar 15, 2017 at 11:13 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:

> Thanks Taher,
>
> Make sense, I am fine with following approach.
>
> >
> Would that solve the subversion problem? Let me just reiterate the steps:
>
> - checkout plugins into /temp
> - delete everything _inside_ /plugins
> - move everything (including .svn) from /temp to /plugins
> - delete /temp
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Wed, Mar 15, 2017 at 1:06 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com
> > wrote:
>
> > Hi Deepak,
> >
> > So there are multiple issues with this code that I attempt summarize
> below:
> > - First, you are directly using the subversion command in an "exec"
> block.
> > We used the subversion plugin to avoid having gradle depend on anything
> > other than gradle. I think it might be better to try and list the plugins
> > through the subversion-plugin for gradle.
> > - It would be very slow, memory consuming and inefficient to use the
> > gradlewSubprocess for each plugin individually and it might choke
> resources
> > on your computer
> > - Finally, the way you wrote this task would create a ".svn" directory
> for
> > each plugin individually instead of having a single ".svn" directory for
> > all of them under /plugins.
> >
> > Maybe an easier way is to keep the pullAllPluginSource task as is, but
> > instead of deleting plugins, we just delete everything _inside_ plugins
> and
> > then move the checkout resources to there.
> >
> > Would that solve the subversion problem? Let me just reiterate the steps:
> >
> > - checkout plugins into /temp
> > - delete everything _inside_ /plugins
> > - move everything (including .svn) from /temp to /plugins
> > - delete /temp
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Wed, Mar 15, 2017 at 9:33 AM, Deepak Dixit <
> > deepak.di...@hotwaxsystems.com> wrote:
> >
> > > Hi Taher,
> > >
> > > I tried to change it with following bug not able to run sub process.
> > >
> > > {code}
> > >
> > > task pullAllPluginsSource(group: ofbizPlugin,
> > > description: 'Download and install all plugins from source
> > > control.') {
> > > def svnOutput = new ByteArrayOutputStream()
> > > exec {
> > >commandLine 'svn', 'list','--xml',
> > > 'https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk'
> > >standardOutput = svnOutput
> > > }
> > > def plugins= new XmlParser().parseText(svnOutput.toString())
> > > plugins.list.entry.each {plugin ->
> > >def pluginId =  plugin.name.text()
> > >gradlewSubprocess(['pullPluginSource',
> "-PpluginId=${pluginId}"])
> > > }
> > > }
> > >
> > > {code}
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > > www.hotwaxsystems.com
> > >
> > > On Wed, Mar 15, 2017 at 11:22 AM, Taher Alkhateeb <
> > > slidingfilame...@gmail.com> wrote:
> > >
> > > > Sure, let's change the implementation. I'd be glad to help if I
> receive
> > > > some suggestions. For now .. the implementation is as follows:
> > > >
> > > > - create a temp directory
> > > > - checkout to that directory
> > > > - delete /plugins
> > > > - rename temp to plugins
> > > >
> > > > I'm all ears for the best approach.
> > > >
> > > > On Wed, Mar 15, 2017 at 8:15 AM, Deepak Dixit <
> > > > deepak.di...@hotwaxsystems.com> wrote:
> > > >
> > > > > We need to enhance pullAllPluginsSource task, after running this
> you
> > > will
> > > > > not able to commit or run any svn command on plugins, as it do
> > checkout
> > > > of
> > > > > plugins/trunk and copy its folder into plugins.
> > > > >
> > > > >
> > > > > Thanks & Regards
> > > > > --
> > > > > Deepak Dixit
> > > > > www.hotwaxsystems.com
> > > > >
> > > > > On Wed, Mar 15, 2017 at 12:18 AM, Jacques Le Roux <
> > > > > jacques.le.r...@les7arts.com> wrote:
> > > > >
> > > > > > That would be better indeed, I did not look a it yet.
> > > > > >
> > > > > > Jacques
> > > > > >
> > > > > >
> > > > > >
> > > > > > Le 14/03/2017 à 19:04, Deepak Dixit a écrit :
> > > > > >
> > > > > >> I think we can improve gradle task and instead of deleting
> plugins
> > > it
> > > > > will
> > > > > >> its delete sub-folder.
> > > > > >> I am sure gradle should have ability to delete sub-folder. :)
> > > > > >>
> > > > > >> If we delete README.txt then it will not be available in git as
> > git
> > > > does
> > > > > >> not support empty folder.
> > > > > >>
> > > > > >>
> > > > > >>

Re: Welcome James Yong as a new committer

2017-03-15 Thread Pranay Pandey

Many congratulations James!!!

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Tue, Mar 14, 2017 at 2:26 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> The OFBiz PMC has invited James Yong to become a new committer and we are
> happy to announce that he has accepted.
>
> James has been involved in OFBiz for years providing patches, reporting
> bugs, discussing issues and also providing help and advice to others on the
> mailing lists.
> James has a nice positive attitude and is constructive and community
> oriented and has been active on both the development and user mailing lists
> responding to some quite technical functional questions.
>
> Please join me in welcoming and congratulating James.
>
> Thanks
>
> Jacopo
>

Re: svn commit: r1786919 - in /ofbiz/ofbiz-framework/trunk/applications/accounting/widget: FieldLookupForms.xml LookupScreens.xml

2017-03-15 Thread Pierre Smits

That is what you get in transitional stages. But then again, OFBiz offers
lots of flexibility in order to get from A to Z.

As I read it, it was the intention of Adrian to simplify (I would like to
extract list functionality from the form widget and create a new grid
widget). But you can't remove the functionality until all referenced
widgets are converted (the backward compatibility).

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Wed, Mar 15, 2017 at 6:49 AM, Taher Alkhateeb  wrote:

> So it's two widgets that output an identical HTML structure with no plan in
> sight of making a differentiation. This is now putting in the code base two
> ways of achieving the same thing (more complexity) for no added value.
> Maybe we need to discuss the added value and direction of such work.
>
> On Tue, Mar 14, 2017 at 7:20 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi Taher,
> >
> > It's explained here http://markmail.org/message/77swtjvr6q25rq4d
> >
> > Quoting Adrian.
> >
> > < widget
> > and create a new grid widget. So, instead of a form widget representing a
> > single data entry form OR a list, it will ONLY represent a single form.
> If
> > you want a list, you use the grid widget. Initially, this change will be
> > backwards-compatible - the XML parser will accept a  element for
> both
> > types and it will create the correct model based on the type attribute.>>
> >
> > Initially I wondered if Adrian had not a CSS idea in mind, I can't
> clearly
> > remember if we discussed it or not
> >
> > Jacques
> >
> >
> >
> > Le 14/03/2017 à 17:06, Taher Alkhateeb a écrit :
> >
> >> Hi Jacques,
> >>
> >> What is the purpose of converting list forms to grids?
> >>
> >> Regards,
> >>
> >> Taher Alkhateeb
> >>
> >> On Mar 14, 2017 6:59 PM,  wrote:
> >>
> >> Author: jleroux
> >>> Date: Tue Mar 14 15:59:23 2017
> >>> New Revision: 1786919
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1786919&view=rev
> >>> Log:
> >>> Improved: refactor list related forms in Lookup widgets
> >>> (OFBIZ-9232)
> >>>
> >>> Refactoring various list forms into grids
> >>> Refactoring various list form references in screen widgets
> >>>
> >>>
> >>> Thanks: Pierre Smits
> >>>
> >>> Modified:
> >>>  ofbiz/ofbiz-framework/trunk/applications/accounting/
> >>> widget/FieldLookupForms.xml
> >>>  ofbiz/ofbiz-framework/trunk/applications/accounting/
> >>> widget/LookupScreens.xml
> >>>
> >>> Modified: ofbiz/ofbiz-framework/trunk/applications/accounting/
> >>> widget/FieldLookupForms.xml
> >>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
> >>> applications/accounting/widget/FieldLookupForms.xml?
> >>> rev=1786919&r1=1786918&r2=1786919&view=diff
> >>> 
> >>> ==
> >>> --- ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
> >>> FieldLookupForms.xml
> >>> (original)
> >>> +++ ofbiz/ofbiz-framework/trunk/applications/accounting/widget/
> >>> FieldLookupForms.xml
> >>> Tue Mar 14 15:59:23 2017
> >>> @@ -36,7 +36,7 @@ under the License.
> >>>   
> >>>>>> widget-style="smallSubmit">
> >>>   
> >>> - >>> type="list" paginate-target="LookupFixedAsset"
> >>> + >>> paginate-target="LookupFixedAsset"
> >>>   odd-row-style="alternate-row" default-table-style="basic-
> table
> >>> hover-bar">
> >>>   
> >>>>>> result-map-list="listIt">
> >>> @@ -51,7 +51,7 @@ under the License.
> >>>   
> >>>   
> >>>>>> entity-name="FixedAssetType"/>
> >>> -
> >>> +
> >>>>>> type="single"
> >>>   header-row-style="header-row" default-table-style="basic-tab
> >>> le">
> >>>>>> default-field-type="hidden"/>
> >>> @@ -94,7 +94,7 @@ under the License.
> >>>   
> >>>>>> widget-style="smallSubmit">
> >>>   
> >>> - >>> type="list" paginate-target="LookupBillingAccount"
> >>> + >>> paginate-target="LookupBillingAccount"
> >>>   odd-row-style="alternate-row" default-table-style="basic-
> table
> >>> hover-bar">
> >>>   
> >>>>>> result-map-list="listIt">
> >>> @@ -110,7 +110,7 @@ under the License.
> >>>   
> >>>   
> >>>   
> >>> -
> >>> +
> >>>
> >>>>>> type="single"
> >>>   header-row-style="header-row" default-table-style="basic-tab
> >>> le">
> >>> @@ -134,7 +134,8 @@ under the License.
> >>>   
> >>>>>> widget-style="smallSubmit">
> >>>   
> >>> - >>> type="list" paginate-target="LookupGlAccount"
> >>> +
> >>> + >>> paginate-target="LookupGlAccount"
> >>>   odd-row-style="alternate-row" default-table-style="basic-
> table
> >>> hover-bar">
> >>>   
> >>>>>> result-map-list="listIt">
> >>> @@ -151,6 +152,7 @@ under the License.
> >>>

Re: Plugins: skipped obstructing working copy (error message)

2017-03-15 Thread Deepak Dixit

Thanks Taher,

Make sense, I am fine with following approach.

>
Would that solve the subversion problem? Let me just reiterate the steps:

- checkout plugins into /temp
- delete everything _inside_ /plugins
- move everything (including .svn) from /temp to /plugins
- delete /temp

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

On Wed, Mar 15, 2017 at 1:06 PM, Taher Alkhateeb  wrote:

> Hi Deepak,
>
> So there are multiple issues with this code that I attempt summarize below:
> - First, you are directly using the subversion command in an "exec" block.
> We used the subversion plugin to avoid having gradle depend on anything
> other than gradle. I think it might be better to try and list the plugins
> through the subversion-plugin for gradle.
> - It would be very slow, memory consuming and inefficient to use the
> gradlewSubprocess for each plugin individually and it might choke resources
> on your computer
> - Finally, the way you wrote this task would create a ".svn" directory for
> each plugin individually instead of having a single ".svn" directory for
> all of them under /plugins.
>
> Maybe an easier way is to keep the pullAllPluginSource task as is, but
> instead of deleting plugins, we just delete everything _inside_ plugins and
> then move the checkout resources to there.
>
> Would that solve the subversion problem? Let me just reiterate the steps:
>
> - checkout plugins into /temp
> - delete everything _inside_ /plugins
> - move everything (including .svn) from /temp to /plugins
> - delete /temp
>
> Regards,
>
> Taher Alkhateeb
>
> On Wed, Mar 15, 2017 at 9:33 AM, Deepak Dixit <
> deepak.di...@hotwaxsystems.com> wrote:
>
> > Hi Taher,
> >
> > I tried to change it with following bug not able to run sub process.
> >
> > {code}
> >
> > task pullAllPluginsSource(group: ofbizPlugin,
> > description: 'Download and install all plugins from source
> > control.') {
> > def svnOutput = new ByteArrayOutputStream()
> > exec {
> >commandLine 'svn', 'list','--xml',
> > 'https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk'
> >standardOutput = svnOutput
> > }
> > def plugins= new XmlParser().parseText(svnOutput.toString())
> > plugins.list.entry.each {plugin ->
> >def pluginId =  plugin.name.text()
> >gradlewSubprocess(['pullPluginSource', "-PpluginId=${pluginId}"])
> > }
> > }
> >
> > {code}
> >
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > www.hotwaxsystems.com
> >
> > On Wed, Mar 15, 2017 at 11:22 AM, Taher Alkhateeb <
> > slidingfilame...@gmail.com> wrote:
> >
> > > Sure, let's change the implementation. I'd be glad to help if I receive
> > > some suggestions. For now .. the implementation is as follows:
> > >
> > > - create a temp directory
> > > - checkout to that directory
> > > - delete /plugins
> > > - rename temp to plugins
> > >
> > > I'm all ears for the best approach.
> > >
> > > On Wed, Mar 15, 2017 at 8:15 AM, Deepak Dixit <
> > > deepak.di...@hotwaxsystems.com> wrote:
> > >
> > > > We need to enhance pullAllPluginsSource task, after running this you
> > will
> > > > not able to commit or run any svn command on plugins, as it do
> checkout
> > > of
> > > > plugins/trunk and copy its folder into plugins.
> > > >
> > > >
> > > > Thanks & Regards
> > > > --
> > > > Deepak Dixit
> > > > www.hotwaxsystems.com
> > > >
> > > > On Wed, Mar 15, 2017 at 12:18 AM, Jacques Le Roux <
> > > > jacques.le.r...@les7arts.com> wrote:
> > > >
> > > > > That would be better indeed, I did not look a it yet.
> > > > >
> > > > > Jacques
> > > > >
> > > > >
> > > > >
> > > > > Le 14/03/2017 à 19:04, Deepak Dixit a écrit :
> > > > >
> > > > >> I think we can improve gradle task and instead of deleting plugins
> > it
> > > > will
> > > > >> its delete sub-folder.
> > > > >> I am sure gradle should have ability to delete sub-folder. :)
> > > > >>
> > > > >> If we delete README.txt then it will not be available in git as
> git
> > > does
> > > > >> not support empty folder.
> > > > >>
> > > > >>
> > > > >>
> > > > >> Thanks & Regards
> > > > >> --
> > > > >> Deepak Dixit
> > > > >> www.hotwaxsystems.com
> > > > >>
> > > > >> On Tue, Mar 14, 2017 at 6:46 PM, Jacques Le Roux <
> > > > >> jacques.le.r...@les7arts.com> wrote:
> > > > >>
> > > > >> Hi,
> > > > >>>
> > > > >>> I just crossed an issue while updating my ofbiz-framework working
> > > copy
> > > > >>> after having used pullAllPluginsSource. I get an error message
> > > "Skipped
> > > > >>> obstructing working copy".
> > > > >>>
> > > > >>> This is because we have already a plugins folder in the
> > > > >>> ofbiz-framework/trunk branch and when we use pullAllPluginsSource
> > we
> > > > >>> replace it by a new one (plugins folder) and the main .svn gets
> > > > confused
> > > > >>> (in root)
> > > > >>>
> > > > >>> I think we can live w/o the README.txt in the plugins folder and
> > the
> > > > >>> folder altogether and document it another way if needed (in the
> > main
> > > > >>> R

Re: Plugins: skipped obstructing working copy (error message)

Hi Deepak,

So there are multiple issues with this code that I attempt summarize below:
- First, you are directly using the subversion command in an "exec" block.
We used the subversion plugin to avoid having gradle depend on anything
other than gradle. I think it might be better to try and list the plugins
through the subversion-plugin for gradle.
- It would be very slow, memory consuming and inefficient to use the
gradlewSubprocess for each plugin individually and it might choke resources
on your computer
- Finally, the way you wrote this task would create a ".svn" directory for
each plugin individually instead of having a single ".svn" directory for
all of them under /plugins.

Maybe an easier way is to keep the pullAllPluginSource task as is, but
instead of deleting plugins, we just delete everything _inside_ plugins and
then move the checkout resources to there.

Would that solve the subversion problem? Let me just reiterate the steps:

- checkout plugins into /temp
- delete everything _inside_ /plugins
- move everything (including .svn) from /temp to /plugins
- delete /temp

Regards,

Taher Alkhateeb

On Wed, Mar 15, 2017 at 9:33 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:

> Hi Taher,
>
> I tried to change it with following bug not able to run sub process.
>
> {code}
>
> task pullAllPluginsSource(group: ofbizPlugin,
> description: 'Download and install all plugins from source
> control.') {
> def svnOutput = new ByteArrayOutputStream()
> exec {
>commandLine 'svn', 'list','--xml',
> 'https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk'
>standardOutput = svnOutput
> }
> def plugins= new XmlParser().parseText(svnOutput.toString())
> plugins.list.entry.each {plugin ->
>def pluginId =  plugin.name.text()
>gradlewSubprocess(['pullPluginSource', "-PpluginId=${pluginId}"])
> }
> }
>
> {code}
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Wed, Mar 15, 2017 at 11:22 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
> > Sure, let's change the implementation. I'd be glad to help if I receive
> > some suggestions. For now .. the implementation is as follows:
> >
> > - create a temp directory
> > - checkout to that directory
> > - delete /plugins
> > - rename temp to plugins
> >
> > I'm all ears for the best approach.
> >
> > On Wed, Mar 15, 2017 at 8:15 AM, Deepak Dixit <
> > deepak.di...@hotwaxsystems.com> wrote:
> >
> > > We need to enhance pullAllPluginsSource task, after running this you
> will
> > > not able to commit or run any svn command on plugins, as it do checkout
> > of
> > > plugins/trunk and copy its folder into plugins.
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > > www.hotwaxsystems.com
> > >
> > > On Wed, Mar 15, 2017 at 12:18 AM, Jacques Le Roux <
> > > jacques.le.r...@les7arts.com> wrote:
> > >
> > > > That would be better indeed, I did not look a it yet.
> > > >
> > > > Jacques
> > > >
> > > >
> > > >
> > > > Le 14/03/2017 à 19:04, Deepak Dixit a écrit :
> > > >
> > > >> I think we can improve gradle task and instead of deleting plugins
> it
> > > will
> > > >> its delete sub-folder.
> > > >> I am sure gradle should have ability to delete sub-folder. :)
> > > >>
> > > >> If we delete README.txt then it will not be available in git as git
> > does
> > > >> not support empty folder.
> > > >>
> > > >>
> > > >>
> > > >> Thanks & Regards
> > > >> --
> > > >> Deepak Dixit
> > > >> www.hotwaxsystems.com
> > > >>
> > > >> On Tue, Mar 14, 2017 at 6:46 PM, Jacques Le Roux <
> > > >> jacques.le.r...@les7arts.com> wrote:
> > > >>
> > > >> Hi,
> > > >>>
> > > >>> I just crossed an issue while updating my ofbiz-framework working
> > copy
> > > >>> after having used pullAllPluginsSource. I get an error message
> > "Skipped
> > > >>> obstructing working copy".
> > > >>>
> > > >>> This is because we have already a plugins folder in the
> > > >>> ofbiz-framework/trunk branch and when we use pullAllPluginsSource
> we
> > > >>> replace it by a new one (plugins folder) and the main .svn gets
> > > confused
> > > >>> (in root)
> > > >>>
> > > >>> I think we can live w/o the README.txt in the plugins folder and
> the
> > > >>> folder altogether and document it another way if needed (in the
> main
> > > >>> README.MD?), it will fix this problem.
> > > >>>
> > > >>> Opinions?
> > > >>>
> > > >>> Jacques
> > > >>>
> > > >>>
> > > >>>
> > > >
> > >
> >
>

Re: Plugins: skipped obstructing working copy (error message)