date:20170704

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/76

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

Buildslave for this Build: lares_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot

buildbot success in on ofbiz-trunk-framework-plugins

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

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

Buildslave for this Build: orcus_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Improving the OFBiz User Interface

2017-07-04 Thread Taher Alkhateeb

Hi Michael,

I think we agree, just a difference in semantics. What I mean by web
is anything CSS, JavaScript, or HTML, not FreeMarker (for now). The
smaller the effort the bigger the chances to move this initiative
forward, so yeah I think we're on the same page.

On Wed, Jul 5, 2017 at 12:35 AM, Michael Brohl  wrote:
> Hi Taher,
>
> I agree that all ressources like images, css etc. should be moved away in a
> foundation component. I am not sure if I can follow your suggestion to move
> everything web-related from the framework to another component. In my mind,
> the foundation for the UI development (Renderer, macro libraries,
> transformers etc.) should reside in the framework.
>
> I think it would be also a too big move to rewrite/move all this at once and
> has not enough visible impact for users to be highly prioritized.
>
> For me, a new and modern UI would be the highest priority at the moment. I
> hope that this will attract more contributors and more users to grow the
> community.
>
> After this, more restructuring and separation can be done.
>
> At ecomify, we are currently evaluating if we can set a team on it to
> implement a new UI. It will be a lot of work and a big effort for us but I
> think it's worth it. We'll see how this will work out and how we can
> contribute this back to the project.
>
> Best regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 04.07.17 um 20:53 schrieb Taher Alkhateeb:
>
>> I agree with Michael, baby steps for the win. I propose we perhaps
>> just postpone "big ideas" for now and focus on things that can get
>> results quickly to put life back into this initiative. Maybe next
>> actions could be the following:
>>
>> - Create a base theme
>> - Move all artifacts from framework/images to the base theme (jquery,
>> bootstrap or whatever already exists) and do the rewiring. Also look
>> for any web artifacts anywhere and move them to the base theme.
>> Essentially, remove any thing that is web-based and centralize it in
>> the theme.
>> - Create an implementation theme on top of the base theme
>>
>> Once the above is done, then we can have a discussion of what to do
>> next. There are _many_ ideas, but I will restrain myself this time
>> until we get some action first :)
>>
>> On Tue, Jul 4, 2017 at 6:31 PM, Jacques Le Roux
>>  wrote:
>>>
>>> Le 04/07/2017 à 16:57, Michael Brohl a écrit :

 Hi James,

 thanks for your suggestions.

 As far as I know, JSF would introduce some new technologies because it
 relies on beans and JSP's (correct me if I'm wrong). I'm not sure if we
 want
 to go so far.
>>>
>>>
>>> Facelet is now the recommended technology for JSF
>>>
>>> https://stackoverflow.com/questions/2095397/what-is-the-difference-between-jsf-servlet-and-jsp
>>> and both are parts of JavaEE.
>>>
>>> I agree with Michael and would not like to change OFBiz widgets for JSF.
>>> Not
>>> that I don't like nor trust JSF (and Oracle, but then a bit less), but
>>> the
>>> work is overwhelming and obviously we don't have the resources for that.
>>>
 I digged a little deeper into the UI stuff, templates and theming and
 have
 to correct my summary a bit: I mentioned AngularJS and Bootstrap on the
 same
 level which is like comparing apples and oranges. AngularJS is a
 client-side
 JavaScript framework to build single page applications, icluding his own
 model-view-controller mechanism while Bootsrap is a CSS framework which
 provides comprehensive UI elements in a structured way.

 I guess that the use of Angular would need a whole lot more changes in
 OFBiz than the use of Bootstrap.

 So I tend to think that we have to agree on a CSS framework like
 Bootstrap
 and rewrite the UI to use the proper CSS classes for this framework.
 That
 would possibly reduce the complexity and makes this statement of mine
 obsolete:

> - we will need a new approach to be able to "plug in" different UI
> frameworks. We'll need a UI layer who represents the screen contents in
> an
> abstracted way (possbly an enhanced Freemarker macro library) and make
> it
> possible to generate HTML code with the right css attributes for the
> target
> library.

 It's maybe too ambitious wanting OFBiz to be able to be used with
 different frameworks. The Bootstrap CSS world is well documented [1] and
 there are a lot of really good looking and functional free templates out
 there. So if we provide the UI code for it, together with one basic
 theme,
 users can put their own themes on top of it.

 Maybe this is a way to come to a competitive UI in a relative short
 amount
 of time. I don't think that we can afford to make this a year-long
 project.

 What do others think?
>>>
>>>
>>> I agree that using Bootstrap would be a good thing. An

Re: [DISCUSSION] Improving the OFBiz User Interface

Hi Taher,

I agree that all ressources like images, css etc. should be moved away
in a foundation component. I am not sure if I can follow your suggestion
to move everything web-related from the framework to another component.
In my mind, the foundation for the UI development (Renderer, macro
libraries, transformers etc.) should reside in the framework.

I think it would be also a too big move to rewrite/move all this at once
and has not enough visible impact for users to be highly prioritized.

For me, a new and modern UI would be the highest priority at the moment.
I hope that this will attract more contributors and more users to grow
the community.

After this, more restructuring and separation can be done.

At ecomify, we are currently evaluating if we can set a team on it to
implement a new UI. It will be a lot of work and a big effort for us but
I think it's worth it. We'll see how this will work out and how we can
contribute this back to the project.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 04.07.17 um 20:53 schrieb Taher Alkhateeb:

I agree with Michael, baby steps for the win. I propose we perhaps
just postpone "big ideas" for now and focus on things that can get
results quickly to put life back into this initiative. Maybe next
actions could be the following:

- Create a base theme
- Move all artifacts from framework/images to the base theme (jquery,
bootstrap or whatever already exists) and do the rewiring. Also look
for any web artifacts anywhere and move them to the base theme.
Essentially, remove any thing that is web-based and centralize it in
the theme.
- Create an implementation theme on top of the base theme

Once the above is done, then we can have a discussion of what to do
next. There are _many_ ideas, but I will restrain myself this time
until we get some action first :)

On Tue, Jul 4, 2017 at 6:31 PM, Jacques Le Roux
wrote:

Le 04/07/2017 à 16:57, Michael Brohl a écrit :

Hi James,

thanks for your suggestions.

As far as I know, JSF would introduce some new technologies because it
relies on beans and JSP's (correct me if I'm wrong). I'm not sure if we want
to go so far.

Facelet is now the recommended technology for JSF
https://stackoverflow.com/questions/2095397/what-is-the-difference-between-jsf-servlet-and-jsp
and both are parts of JavaEE.

I agree with Michael and would not like to change OFBiz widgets for JSF. Not
that I don't like nor trust JSF (and Oracle, but then a bit less), but the
work is overwhelming and obviously we don't have the resources for that.

I digged a little deeper into the UI stuff, templates and theming and have
to correct my summary a bit: I mentioned AngularJS and Bootstrap on the same
level which is like comparing apples and oranges. AngularJS is a client-side
JavaScript framework to build single page applications, icluding his own
model-view-controller mechanism while Bootsrap is a CSS framework which
provides comprehensive UI elements in a structured way.

I guess that the use of Angular would need a whole lot more changes in
OFBiz than the use of Bootstrap.

So I tend to think that we have to agree on a CSS framework like Bootstrap
and rewrite the UI to use the proper CSS classes for this framework. That
would possibly reduce the complexity and makes this statement of mine
obsolete:

- we will need a new approach to be able to "plug in" different UI
frameworks. We'll need a UI layer who represents the screen contents in an
abstracted way (possbly an enhanced Freemarker macro library) and make it
possible to generate HTML code with the right css attributes for the target
library.

It's maybe too ambitious wanting OFBiz to be able to be used with
different frameworks. The Bootstrap CSS world is well documented [1] and
there are a lot of really good looking and functional free templates out
there. So if we provide the UI code for it, together with one basic theme,
users can put their own themes on top of it.

Maybe this is a way to come to a competitive UI in a relative short amount
of time. I don't think that we can afford to make this a year-long project.

What do others think?

I agree that using Bootstrap would be a good thing. An alternative is
Foundation https://www.keycdn.com/blog/bootstrap-vs-foundation, this could
be possibly discussed.
That's what ilscipio has used, with some success at the UI level I'd say
(they now tend to lean to Foundation). Now they derived from OFBiz at other
technology levels (no or less form widgets but more FTL macros, even an API
of FTL macros). So I'd try to compare the rest...

I'd also let Angular out of the picture. Some prefer React (initially from
FB) and I wonder what those who have used Angular 1 think about Angular 2! I
also remember another Google "attempt": GWT. Are there still people using it
with OFBiz? I guess you get my point, trends pass and tools with them...

Jacques

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Re: svn commit: r1800245 - in /ofbiz/ofbiz-framework/trunk/applications/accounting: groovyScripts/rate/RateServices.groovy minilang/rate/ servicedef/services_rate.xml

2017-07-04 Thread Nicolas Malin


Come back,

Le 03/07/2017 à 21:19, Scott Gray a écrit :

Hi Nicolas,

My first code review in a while so I apologize if I'm wrong on any points,
or if they've been discussed already.

1. It would be good if the services were converted one per commit, with the
empty minilang file removed at the end with a separate commit.  That would
allow reviewers to compare the removed XML code with the new groovy code.
No problem, I wished realize one commit per file but it's too 
complicate, and you remark is good. Now I need to take time for repair 
my broken git repository because it's more easier to do this with git 
compare to svn (for me).

2. Defaults should (where possible) be moved to the service definition
Agree, I will check. If you found some move forget, it's a mistake. 
Don't hesitate to spot them.

3. I could be wrong about this but I don't think it is a good practice to
assign/change values in the parameters map, I think callers would not
expect their inputs to be changed by the service.  But I'm not sure if that
is actually happening or if groovy has copied the map beforehand, I'm also
unsure of how minilang used to handle the same.

I see. The problem to convert directly a language :)

4. Because groovy has "Groovy Truth", UtilValidate.isEmpty/isNotEmpty isn't
required, you can simply do "if (parameters.ratesList)".  An empty list or
null would return false.

My bad, in my mind groovy tested only null, thanks for the correction

5. I think it would be better to add the service documentation to the
service definition instead of a comment inline with the code.
:) Lazy I'm, just a copy paste the minilang to convert on the fly. I 
will correct that

6. I'm curious about the getRateAmount() "level" variable, I see it is only
defined within the local scope of the if/else blocks whereas "serviceName"
was defined at the method scope.  Does groovy allow "level" to take on the
method scope or is it an error?
heuuu je sais pas, I will look that. To ensure they are no regression I 
use the integration test and some ui test, so maybe I didn't test the 
area where this is used, or it was no impact on the code ^^


Thanks Scott I will do a second pass on the code with your remarks.
Cheers,
Nicolas

Regards
Scott

On 29 June 2017 at 19:46,  wrote:


Author: nmalin
Date: Thu Jun 29 07:46:02 2017
New Revision: 1800245

URL: http://svn.apache.org/viewvc?rev=1800245=rev
Log:
Improved: Convert RateServices.xml mini-lang to groovyDSL (OFBIZ-9381)
finish the service conversion : getRateAmount,
getRatesAmountsFromWorkEffortId, getRatesAmountsFromPartyId,
getRatesAmountsFromEmplPositionTypeId and filterRateAmountList
I create a generic groovy function getRateAmoutForm to remove duplicate
code and refactoring the filterRateAmount for simplicity

Removed:
 ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/rate/
Modified:
 ofbiz/ofbiz-framework/trunk/applications/accounting/
groovyScripts/rate/RateServices.groovy
 ofbiz/ofbiz-framework/trunk/applications/accounting/
servicedef/services_rate.xml

Modified: ofbiz/ofbiz-framework/trunk/applications/accounting/
groovyScripts/rate/RateServices.groovy
URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/
applications/accounting/groovyScripts/rate/RateServices.groovy?rev=
1800245=1800244=1800245=diff

==
--- ofbiz/ofbiz-framework/trunk/applications/accounting/
groovyScripts/rate/RateServices.groovy (original)
+++ ofbiz/ofbiz-framework/trunk/applications/accounting/
groovyScripts/rate/RateServices.groovy Thu Jun 29 07:46:02 2017
@@ -128,3 +128,142 @@ def expirePartyRate() {
  }
  return success()
  }
+
+// Get the applicable rate amount value
+def getRateAmount() {
+/* Search for the applicable rate from most specific to most general
in the RateAmount entity
+Defaults for periodTypeId is per hour and default currency is the
currency in general.properties
+The order is:
+1. for specific rateTypeId, workEffortId (workEffort)
+2. for specific rateTypeId, partyId (party)
+3. for specific rateTypeId, emplPositionTypeId (emplPositionType)
+4. for specific rateTypeId (rateType)
+
+Then, the results are filtered to improve the result. If you pass a
workEffortId and a partyId,
+the service will first search the list of all the rateAmount with the
specified workEffortId. Then, if
+there is at least one rateAmount with same partyId than the one in
the parameter in the list, the list will
+be reduced to those entries.
+At the end, the first record of the list is chosen.
+
+For a easier debugging time, there is a log triggered when no records
are found for the input. This log
+shows up when there are rateAmounts corresponding to the input
parameters without the rateCurrencyUomId and
+the periodTypeId.*/
+if (!parameters.rateCurrencyUomId) {
+parameters.rateCurrencyUomId = UtilProperties.

Updating 10 year old version of entity engine and service engine.

2017-07-04 Thread Mark Gordon

Hi,

I have been tasked with updating a 10 year old version of ofbiz
entityengine and service engine to the latest version.

Would anyone know of a document that outlines the changes to just these
modules? I didn't think so :-)

It seems that many of the helper methods have been removed from the
delegator.  Just as a single example, findByPrimaryKey(String, Map) it is
now findByPrimaryKeyPartial(GenericPK primaryKey, Set keys).  In
the old version the entityname (string) was converted to the GenericPK for
that entity and basically the final call was to a method similar to this.

Just wondering if there is anyone that has been around for the past 10
years that can explain some of the history of the changes.

I am faced with either writing my own delegator that is a layer over the
existing delegator that puts the needed methods back and calls the new
methods.  Or editing the entire system fixing all the delegator calls.

I have not gotten into the service engine yet, I would guess the past 10
years have seen many changes here as well.

Thanks,
Mark

Re: [DISCUSSION] Improving the OFBiz User Interface

2017-07-04 Thread Taher Alkhateeb

I agree with Michael, baby steps for the win. I propose we perhaps
just postpone "big ideas" for now and focus on things that can get
results quickly to put life back into this initiative. Maybe next
actions could be the following:

- Create a base theme
- Move all artifacts from framework/images to the base theme (jquery,
bootstrap or whatever already exists) and do the rewiring. Also look
for any web artifacts anywhere and move them to the base theme.
Essentially, remove any thing that is web-based and centralize it in
the theme.
- Create an implementation theme on top of the base theme

Once the above is done, then we can have a discussion of what to do
next. There are _many_ ideas, but I will restrain myself this time
until we get some action first :)

On Tue, Jul 4, 2017 at 6:31 PM, Jacques Le Roux
 wrote:
> Le 04/07/2017 à 16:57, Michael Brohl a écrit :
>>
>> Hi James,
>>
>> thanks for your suggestions.
>>
>> As far as I know, JSF would introduce some new technologies because it
>> relies on beans and JSP's (correct me if I'm wrong). I'm not sure if we want
>> to go so far.
>
>
> Facelet is now the recommended technology for JSF
> https://stackoverflow.com/questions/2095397/what-is-the-difference-between-jsf-servlet-and-jsp
> and both are parts of JavaEE.
>
> I agree with Michael and would not like to change OFBiz widgets for JSF. Not
> that I don't like nor trust JSF (and Oracle, but then a bit less), but the
> work is overwhelming and obviously we don't have the resources for that.
>
>>
>> I digged a little deeper into the UI stuff, templates and theming and have
>> to correct my summary a bit: I mentioned AngularJS and Bootstrap on the same
>> level which is like comparing apples and oranges. AngularJS is a client-side
>> JavaScript framework to build single page applications, icluding his own
>> model-view-controller mechanism while Bootsrap is a CSS framework which
>> provides comprehensive UI elements in a structured way.
>>
>> I guess that the use of Angular would need a whole lot more changes in
>> OFBiz than the use of Bootstrap.
>>
>> So I tend to think that we have to agree on a CSS framework like Bootstrap
>> and rewrite the UI to use the proper CSS classes for this framework. That
>> would possibly reduce the complexity and makes this statement of mine
>> obsolete:
>>
>> > - we will need a new approach to be able to "plug in" different UI
>> > frameworks. We'll need a UI layer who represents the screen contents in an
>> > abstracted way (possbly an enhanced Freemarker macro library) and make it
>> > possible to generate HTML code with the right css attributes for the target
>> > library.
>>
>> It's maybe too ambitious wanting OFBiz to be able to be used with
>> different frameworks. The Bootstrap CSS world is well documented [1] and
>> there are a lot of really good looking and functional free templates out
>> there. So if we provide the UI code for it, together with one basic theme,
>> users can put their own themes on top of it.
>>
>> Maybe this is a way to come to a competitive UI in a relative short amount
>> of time. I don't think that we can afford to make this a year-long project.
>>
>> What do others think?
>
>
> I agree that using Bootstrap would be a good thing. An alternative is
> Foundation https://www.keycdn.com/blog/bootstrap-vs-foundation, this could
> be possibly discussed.
> That's what ilscipio has used, with some success at the UI level I'd say
> (they now tend to lean to Foundation). Now they derived from OFBiz at other
> technology levels (no or less form widgets but more FTL macros, even an API
> of FTL macros). So I'd try to compare the rest...
>
> I'd also let Angular out of the picture. Some prefer React (initially from
> FB) and I wonder what those who have used Angular 1 think about Angular 2! I
> also remember another Google "attempt": GWT. Are there still people using it
> with OFBiz? I guess you get my point, trends pass and tools with them...
>
> Jacques
>
>
>>
>> Best regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>> [1] https://www.w3schools.com/bootstrap/bootstrap_ref_all_classes.asp
>>
>>
>> Am 03.07.17 um 15:00 schrieb James Yong:
>>>
>>> Hi Michael and all,
>>>
>>> We can look into JSF 2.2 as a possible candidate. It is similar to OFBiz
>>> Widget and seems to fit the new requirements described so far in this
>>> thread.
>>>
>>> Regards,
>>> James Yong
>>>
>>> On 2017-07-03 17:42 (+0800), Michael Brohl 
>>> wrote:

 Hi Sharan,

 thanks for the reminder.

 It's fine to have another theme to choose for the "old" UI, I just want
 to point out that (in my mind) the new theme/UI initiative goes far
 beyond having just another theme on base of the current technological
 stack:

 - new themes should be responsive

 - we should be able to use different UI frameworks like Bootstrap and
 AngularJS who take care of responsiveness

Re: buildbot failure in on ofbiz-trunk-framework-plugins

2017-07-04 Thread Taher Alkhateeb

This is a classic "hidden dependency" because of some sort of "global
state". I'm glad we're facing this problem because it shows the value
of separating the project into two repos.

I checked the logs and I think it would take a while to see exactly
where that null reference is coming from. So I think the best thing to
do here is run the debugger for these tests and go line by line
unfortunately.

I faced this problem so many times, I change something in one place
and something breaks on the other end of the world! Heck maybe it's a
combo of a few commits that lead to this bug.

On Tue, Jul 4, 2017 at 7:31 PM, Jacques Le Roux
 wrote:
> I also tried to locally revert your commit and then all the tests (plugins
> included pass), it's a weird one for sure.
>
> Jacques
>
>
>
> Le 04/07/2017 à 18:05, Michael Brohl a écrit :
>>
>> I can reproduce it when I run all integration tests with the plugins.
>>
>> It's strange that it comes up now, the last commits to plugins are a few
>> days ago...
>>
>>
>> Am 04.07.17 um 17:59 schrieb Jacques Le Roux:
>>>
>>> You are right
>>> https://ci.apache.org/builders/ofbiz-trunk-framework/builds/248
>>>
>>> It's still an issue, a weird one I'd say. Because only one of the tests
>>> which fail is in lucene plugin, the 3 others are in accounting and order. So
>>> we need to investigate that, I hope it's a data location issue...
>>>
>>> Jacques
>>>
>>>
>>> Le 04/07/2017 à 17:20, Michael Brohl a écrit :

 Hi Jacques,

 I cannot reproduce this with a clean framework (no plugins). The last
 change was only in the framework/content manager.

 Regards,

 Michael


 Am 04.07.17 um 16:57 schrieb Jacques Le Roux:
>
> Hi Michael,
>
> I reproduce locally so it's not a Buildbot issue, could you please
> check on you end?
>
> Thanks
>
> Jacques
>
>
> Le 04/07/2017 à 15:33, build...@apache.org a écrit :
>>
>> The Buildbot has detected a new failure on builder
>> ofbiz-trunk-framework-plugins while building . Full details are available
>> at:
>>
>> https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/202
>>
>> Buildbot URL: https://ci.apache.org/
>>
>> Buildslave for this Build: lares_ubuntu
>>
>> Build Reason: The AnyBranchScheduler scheduler named
>> 'on-ofbiz-framework-commit' triggered this build
>> Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1800780
>> Blamelist: mbrohl
>>
>> BUILD FAILED: failed shell_4
>>
>> Sincerely,
>>   -The Buildbot
>>
>>
>>
>>
>


>>>
>>
>>
>

Re: buildbot failure in on ofbiz-trunk-framework-plugins

I also tried to locally revert your commit and then all the tests (plugins
included pass), it's a weird one for sure.

Jacques

Le 04/07/2017 à 18:05, Michael Brohl a écrit :

I can reproduce it when I run all integration tests with the plugins.

It's strange that it comes up now, the last commits to plugins are a few days
ago...

Am 04.07.17 um 17:59 schrieb Jacques Le Roux:

You are right https://ci.apache.org/builders/ofbiz-trunk-framework/builds/248

It's still an issue, a weird one I'd say. Because only one of the tests which fail is in lucene plugin, the 3 others are in accounting and order.
So we need to investigate that, I hope it's a data location issue...

Jacques

Le 04/07/2017 à 17:20, Michael Brohl a écrit :

Hi Jacques,

I cannot reproduce this with a clean framework (no plugins). The last change
was only in the framework/content manager.

Regards,

Michael

Am 04.07.17 um 16:57 schrieb Jacques Le Roux:

Hi Michael,

I reproduce locally so it's not a Buildbot issue, could you please check on you
end?

Thanks

Jacques

Le 04/07/2017 à 15:33, build...@apache.org a écrit :

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

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

Buildslave for this Build: lares_ubuntu

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

BUILD FAILED: failed shell_4

Sincerely,
-The Buildbot

Re: buildbot failure in on ofbiz-trunk-framework-plugins


Locally, I get only 3 failures in framework, lucene tests are fine:

invoicetests 
invoice-per-shipment-tests.testInvoicePerShipmentSetOrderFalse 
FailureError running the simple-method: 
java.lang.reflect.InvocationTargetException (null) Method = 
testInvoicePerShipmentSetOrderFalse, File = 
file:/Users/mbrohl/Projects/apache-ofbiz/trunk/ofbiz/applications/accounting/minilang/test/InvoicePerShipmentTests.xml, 
Element = , Line 334null


junit.framework.AssertionFailedError: Error running the simple-method: 
java.lang.reflect.InvocationTargetException (null) Method = 
testInvoicePerShipmentSetOrderFalse, File = 
file:/Users/mbrohl/Projects/apache-ofbiz/trunk/ofbiz/applications/accountiing/minilang/test/InvoicePerShipmentTests.xml, 
Element = , Line 334null

at org.apache.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:91)
at 
org.apache.ofbiz.testtools.TestRunContaineer.start(TestRunContainer.java:152)
at 
org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:148)
at 
org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:73)
at 
org.apache.ofbiz.base.start..StartupControlPanel.loadStartupLoaders(StartupControlPanel.java:222)
at 
org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:72)

at org.apache.ofbiz.base.staart.Start.main(Start.java:84)
0.259
invoicetests 
invoice-per-shipment-tests.testInvoicePerShipmentSetOrderTrue Failure
Error running the simple-method: 
java.lang.reflect.InvocationTargetException (null) Method = 
testInvoicePerShipmentSetOrderTrue, File = 
file:/Users/mbrohl/Projects/apache-ofbiz/trunk/ofbiz/applications/accounting/minilang/test/InvoicePerShipmentTests.xml, 
Element = , Line 459null


junit.framework.AssertionFailedError: Error running the simple-method: 
java.lang.reflect.InvocationTargetException (null) Method = 
testInvoicePerShipmentSetOrderTrue, File = 
file:/Users/mbrohl/Projects/apache-ofbiz/trunk/ofbiz/applications/accountiing/minilang/test/InvoicePerShipmentTests.xml, 
Element = , Line 459null

at org.apache.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:91)
at 
org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:152)
at 
org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:148)
at 
org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:73)
at 
org.apache.ofbiz.base.start..StartupControlPanel.loadStartupLoaders(StartupControlPanel.java:222)
at 
org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:72)

at org.apache.ofbiz.base.staart.Start.main(Start.java:84)
0.337
shoppingcarttestsconfigurableServiceOrder-testFailure Error 
running the simple-method: java.lang.reflect.InvocationTargetException 
(null) Method = testCreateOrderConfigurableServiceProduct, File = 
file:/Users/mbrohl/Projects/apache-ofbiz/trunk/ofbiz/applications/order/minilang/test/ShoppingCartTests.xml, 
Element = , Line 651null


junit.framework.AssertionFailedError: Error running the simple-method: 
java.lang.reflect.InvocationTargetException (null) Method = 
testCreateOrderConfigurableServiceProduct, File = 
file:/Users/mbrohl/Projects/apache-ofbiz/trunk/ofbiz/applicationss/order/minilang/test/ShoppingCartTests.xml, 
Element = , Line 651null

at org.apache.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:91)
at 
org.apache.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:152)
at 
org.apache.ofbiz.base.container.ContainerLoader.startLoadedContainers(ContainerLoader.java:148)
at 
org.apache.ofbiz.base.container.ContainerLoader.load(ContainerLoader.java:73)
at 
org.apache.ofbiz.base.start..StartupControlPanel.loadStartupLoaders(StartupControlPanel.java:222)
at 
org.apache.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:72)

at org.apache.ofbiz.base.staart.Start.main(Start.java:84)
0.145

Regards,

Michael

Am 04.07.17 um 18:05 schrieb Michael Brohl:

I can reproduce it when I run all integration tests with the plugins.

It's strange that it comes up now, the last commits to plugins are a 
few days ago...



Am 04.07.17 um 17:59 schrieb Jacques Le Roux:
You are right 
https://ci.apache.org/builders/ofbiz-trunk-framework/builds/248


It's still an issue, a weird one I'd say. Because only one of the 
tests which fail is in lucene plugin, the 3 others are in accounting 
and order. So we need to investigate that, I hope it's a data 
location issue...


Jacques


Le 04/07/2017 à 17:20, Michael Brohl a écrit :

Hi Jacques,

I cannot reproduce this with a clean framework (no plugins). The 
last change was only in the framework/content manager.


Regards,

Michael


Am 04.07.17 um 16:57 schrieb Jacques Le Roux:

Hi Michael,

I reproduce locally so it's not a Buildbot issue, could you please 
check on you end?


Thanks

Jacques


Le 04/07/2017 à 15:33, build...@apache.org a écrit :
The Buildbot has detected a new failure on builder

Re: buildbot failure in on ofbiz-trunk-framework-plugins


I can reproduce it when I run all integration tests with the plugins.

It's strange that it comes up now, the last commits to plugins are a few 
days ago...



Am 04.07.17 um 17:59 schrieb Jacques Le Roux:
You are right 
https://ci.apache.org/builders/ofbiz-trunk-framework/builds/248


It's still an issue, a weird one I'd say. Because only one of the 
tests which fail is in lucene plugin, the 3 others are in accounting 
and order. So we need to investigate that, I hope it's a data location 
issue...


Jacques


Le 04/07/2017 à 17:20, Michael Brohl a écrit :

Hi Jacques,

I cannot reproduce this with a clean framework (no plugins). The last 
change was only in the framework/content manager.


Regards,

Michael


Am 04.07.17 um 16:57 schrieb Jacques Le Roux:

Hi Michael,

I reproduce locally so it's not a Buildbot issue, could you please 
check on you end?


Thanks

Jacques


Le 04/07/2017 à 15:33, build...@apache.org a écrit :
The Buildbot has detected a new failure on builder 
ofbiz-trunk-framework-plugins while building . Full details are 
available at:
https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/202 



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

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build

Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1800780
Blamelist: mbrohl

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot
















smime.p7s
Description: S/MIME Cryptographic Signature

Re: buildbot failure in on ofbiz-trunk-framework-plugins


You are right https://ci.apache.org/builders/ofbiz-trunk-framework/builds/248

It's still an issue, a weird one I'd say. Because only one of the tests which fail is in lucene plugin, the 3 others are in accounting and order. So 
we need to investigate that, I hope it's a data location issue...


Jacques


Le 04/07/2017 à 17:20, Michael Brohl a écrit :

Hi Jacques,

I cannot reproduce this with a clean framework (no plugins). The last change 
was only in the framework/content manager.

Regards,

Michael


Am 04.07.17 um 16:57 schrieb Jacques Le Roux:

Hi Michael,

I reproduce locally so it's not a Buildbot issue, could you please check on you 
end?

Thanks

Jacques


Le 04/07/2017 à 15:33, build...@apache.org a écrit :

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

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

Buildslave for this Build: lares_ubuntu

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

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot

Re: [DISCUSSION] Improving the OFBiz User Interface

Le 04/07/2017 à 16:57, Michael Brohl a écrit :

Hi James,

thanks for your suggestions.

As far as I know, JSF would introduce some new technologies because it relies on beans and JSP's (correct me if I'm wrong). I'm not sure if we want
to go so far.

Facelet is now the recommended technology for JSF https://stackoverflow.com/questions/2095397/what-is-the-difference-between-jsf-servlet-and-jsp and
both are parts of JavaEE.

I agree with Michael and would not like to change OFBiz widgets for JSF. Not that I don't like nor trust JSF (and Oracle, but then a bit less), but
the work is overwhelming and obviously we don't have the resources for that.

I digged a little deeper into the UI stuff, templates and theming and have to correct my summary a bit: I mentioned AngularJS and Bootstrap on the
same level which is like comparing apples and oranges. AngularJS is a client-side JavaScript framework to build single page applications, icluding
his own model-view-controller mechanism while Bootsrap is a CSS framework which provides comprehensive UI elements in a structured way.

I guess that the use of Angular would need a whole lot more changes in OFBiz
than the use of Bootstrap.

So I tend to think that we have to agree on a CSS framework like Bootstrap and rewrite the UI to use the proper CSS classes for this framework. That
would possibly reduce the complexity and makes this statement of mine obsolete:

> - we will need a new approach to be able to "plug in" different UI frameworks. We'll need a UI layer who represents the screen contents in an
abstracted way (possbly an enhanced Freemarker macro library) and make it possible to generate HTML code with the right css attributes for the
target library.

It's maybe too ambitious wanting OFBiz to be able to be used with different frameworks. The Bootstrap CSS world is well documented [1] and there are
a lot of really good looking and functional free templates out there. So if we provide the UI code for it, together with one basic theme, users can
put their own themes on top of it.

Maybe this is a way to come to a competitive UI in a relative short amount of
time. I don't think that we can afford to make this a year-long project.

What do others think?

I agree that using Bootstrap would be a good thing. An alternative is Foundation https://www.keycdn.com/blog/bootstrap-vs-foundation, this could be
possibly discussed.
That's what ilscipio has used, with some success at the UI level I'd say (they now tend to lean to Foundation). Now they derived from OFBiz at other
technology levels (no or less form widgets but more FTL macros, even an API of FTL macros). So I'd try to compare the rest...

I'd also let Angular out of the picture. Some prefer React (initially from FB) and I wonder what those who have used Angular 1 think about Angular 2!
I also remember another Google "attempt": GWT. Are there still people using it with OFBiz? I guess you get my point, trends pass and tools with them...

Jacques

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

[1] https://www.w3schools.com/bootstrap/bootstrap_ref_all_classes.asp

Am 03.07.17 um 15:00 schrieb James Yong:

Hi Michael and all,

We can look into JSF 2.2 as a possible candidate. It is similar to OFBiz Widget
and seems to fit the new requirements described so far in this thread.

Regards,
James Yong

On 2017-07-03 17:42 (+0800), Michael Brohl wrote:

Hi Sharan,

thanks for the reminder.

It's fine to have another theme to choose for the "old" UI, I just want
to point out that (in my mind) the new theme/UI initiative goes far
beyond having just another theme on base of the current technological stack:

- new themes should be responsive

- we should be able to use different UI frameworks like Bootstrap and
AngularJS who take care of responsiveness and browser compatibility

- it must be easy for developers to write the screen structure and also
easy for webdesigners to build a good design on base of this

- developers should not care about CSS styles and classes, and
webdesigners should not cara about how the screen snippets are put
together or how the screens get their data.

- we will need a new approach to be able to "plug in" different UI
frameworks. We'll need a UI layer who represents the screen contents in
an abstracted way (possbly an enhanced Freemarker macro library) and
make it possible to generate HTML code with the right css attributes for
the target library.

- a rewrite of the screens will be necessary to make the UI less
cluttered and overloaded. This will require some concepts/design work
beforehand

- there are surely many other possible requirements (I am not a UX or
web design expert)

I appreciate the contribution of the new theme. I am also sure that this
will not solve the challenge to drive OFBiz to another level, UI wise.

Thanks and regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 03.07.17 um 10:52 schrieb Sharan Foga:

Re: buildbot failure in on ofbiz-trunk-framework-plugins


Hi Jacques,

I cannot reproduce this with a clean framework (no plugins). The last 
change was only in the framework/content manager.


Regards,

Michael


Am 04.07.17 um 16:57 schrieb Jacques Le Roux:

Hi Michael,

I reproduce locally so it's not a Buildbot issue, could you please 
check on you end?


Thanks

Jacques


Le 04/07/2017 à 15:33, build...@apache.org a écrit :
The Buildbot has detected a new failure on builder 
ofbiz-trunk-framework-plugins while building . Full details are 
available at:

https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/202

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

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build

Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1800780
Blamelist: mbrohl

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot











smime.p7s
Description: S/MIME Cryptographic Signature

Re: buildbot failure in on ofbiz-trunk-framework-plugins


Hi Michael,

I reproduce locally so it's not a Buildbot issue, could you please check on you 
end?

Thanks

Jacques


Le 04/07/2017 à 15:33, build...@apache.org a écrit :

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

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

Buildslave for this Build: lares_ubuntu

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

BUILD FAILED: failed shell_4

Sincerely,
  -The Buildbot

Re: [DISCUSSION] Improving the OFBiz User Interface


Hi James,

thanks for your suggestions.

As far as I know, JSF would introduce some new technologies because it 
relies on beans and JSP's (correct me if I'm wrong). I'm not sure if we 
want to go so far.


I digged a little deeper into the UI stuff, templates and theming and 
have to correct my summary a bit: I mentioned AngularJS and Bootstrap on 
the same level which is like comparing apples and oranges. AngularJS is 
a client-side JavaScript framework to build single page applications, 
icluding his own model-view-controller mechanism while Bootsrap is a CSS 
framework which provides comprehensive UI elements in a structured way.


I guess that the use of Angular would need a whole lot more changes in 
OFBiz than the use of Bootstrap.


So I tend to think that we have to agree on a CSS framework like 
Bootstrap and rewrite the UI to use the proper CSS classes for this 
framework. That would possibly reduce the complexity and makes this 
statement of mine obsolete:


> - we will need a new approach to be able to "plug in" different UI 
frameworks. We'll need a UI layer who represents the screen contents in 
an abstracted way (possbly an enhanced Freemarker macro library) and 
make it possible to generate HTML code with the right css attributes for 
the target library.


It's maybe too ambitious wanting OFBiz to be able to be used with 
different frameworks. The Bootstrap CSS world is well documented [1] and 
there are a lot of really good looking and functional free templates out 
there. So if we provide the UI code for it, together with one basic 
theme, users can put their own themes on top of it.


Maybe this is a way to come to a competitive UI in a relative short 
amount of time. I don't think that we can afford to make this a 
year-long project.


What do others think?

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

[1] https://www.w3schools.com/bootstrap/bootstrap_ref_all_classes.asp


Am 03.07.17 um 15:00 schrieb James Yong:

Hi Michael and all,

We can look into JSF 2.2 as a possible candidate. It is similar to OFBiz Widget 
and seems to fit the new requirements described so far in this thread.

Regards,
James Yong

On 2017-07-03 17:42 (+0800), Michael Brohl  wrote:

Hi Sharan,

thanks for the reminder.

It's fine to have another theme to choose for the "old" UI, I just want
to point out that (in my mind) the new theme/UI initiative goes far
beyond having just another theme on base of the current technological stack:

- new themes should be responsive

- we should be able to use different UI frameworks like Bootstrap and
AngularJS who take care of responsiveness and browser compatibility

- it must be easy for developers to write the screen structure and also
easy for webdesigners to build a good design on base of this

- developers should not care about CSS styles and classes, and
webdesigners should not cara about how the screen snippets are put
together or how the screens get their data.

- we will need a new approach to be able to "plug in" different UI
frameworks. We'll need a UI layer who represents the screen contents in
an abstracted way (possbly an enhanced Freemarker macro library) and
make it possible to generate HTML code with the right css attributes for
the target library.

- a rewrite of the screens will be necessary to make the UI less
cluttered and overloaded. This will require some concepts/design work
beforehand

- there are surely many other possible requirements (I am not a UX or
web design expert)


I appreciate the contribution of the new theme. I am also sure that this
will not solve the challenge to drive OFBiz to another level, UI wise.

Thanks and regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 03.07.17 um 10:52 schrieb Sharan Foga:

Hi All

Don't forget that we also had the offer of a theme from Provolve and
Stannah.

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

This is a theme that they are using at the moment (so it working) and
have said it could be contributed back to the project. If it's only a
case of having someone volunteer to implement it into the trunk then
this could be a way to get a nice theme up and running quickly for us.

Thanks
Sharan

On 03/07/17 10:29, Michael Brohl wrote:

Thanks Nicolas,

is there anything, even work in progress, you are able to share at
the moment?

This way other could chime in and help moving further.

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 03.07.17 um 09:26 schrieb Nicolas Malin:

Hi Michael

Le 02/07/2017 Ã  20:42, Michael Brohl a Ã©crit :

Hi Julien, all,

I'd like to resurrect this discussion and the activities to improve
the OFBiz user interface. I think we really should put some focused
effort on it if we want OFBiz to be recognized as a modern ERP.
Also, if we imporve the UI, more users and also developers will be
attracted which will be a win for the community and further
development of OFBiz.

Nicolas and others who have started work on this: can

buildbot failure in on ofbiz-trunk-framework-plugins

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

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

Buildslave for this Build: lares_ubuntu

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

BUILD FAILED: failed shell_4

Sincerely,
 -The Buildbot

buildbot failure in on ofbiz-branch16