buildbot success in on ofbiz-trunk

[buildbot]

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

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

Buildslave for this Build: lares_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot

Re: buildbot failure in on ofbiz-trunk

[Taher Alkhateeb]

Okay, I'm not sure if this is a passing fluke, but all tests pass locally.

On Tue, Dec 6, 2016 at 3:49 PM,  wrote:

> The Buildbot has detected a new failure on builder ofbiz-trunk while
> building . Full details are available at:
> https://ci.apache.org/builders/ofbiz-trunk/builds/1775
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: silvanus_ubuntu
>
> Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit'
> triggered this build
> Build Source Stamp: [branch ofbiz/trunk] 1772879
> Blamelist: taher
>
> BUILD FAILED: failed shell_4
>
> Sincerely,
>  -The Buildbot
>
>
>
>

buildbot failure in on ofbiz-trunk

[buildbot]

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

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

Buildslave for this Build: silvanus_ubuntu

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

BUILD FAILED: failed shell_4

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Improving the OFBiz User Interface

[Pierre Smits]

So you are considering the following:

 ‘A more flexible and extensible approach is to use the FTL XML processing
features directly instead of going through Java classes. With this approach
adding an attribute or support for a whole new element in the widget XML
files is just a matter of adding it to the FTL macros that process XML
elements’


?

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Dec 2, 2016 at 2:05 PM, Julien NICOLAS 
wrote:

> Pierre,
>
> I don't know if we'll need it or not for now. There is so many thing to
> define but it seems interesting. We will have to start this discussion on
> the new theme topic.
>
> Julien.
>
>
>
> On 02/12/2016 11:55, pierre wrote:
>
>> Hi Julien
>>
>> Is there any interest into the integration  of a java UI framework such
>> as vaadin?
>>
>> regards,
>>
>> Pierre
>>
>>
>> On 01/12/2016 23:26, Julien NICOLAS wrote:
>>
>>> Hi all,
>>>
>>> I start a page about the POC for the UI improvement.
>>>
>>> I'm not sure if the content is enough but I was wanted to create it.
>>> We can now start some... Jira ? I was wondering one main Jira linked
>>> to 4 other sub-jira.
>>>
>>> thanks to those Jira, we can have 4 teams or workgroup to go ahead in
>>> both ways.
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement
>>>
>>> Let me know if I'm doing well,
>>>
>>> Kind regards,
>>>
>>> Julien.
>>>
>>> PS : I'm currently checkout the common-theme provided by Nicolas's
>>> github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme)
>>>
>>>
>>> On 28/11/2016 11:28, Sharan Foga wrote:
>>>
 Hi Everyone

 Another one of the topics that came up during the brainstorming in
 Seville was around the UI. In fact we had at least 2 presentations
 from the OFBiz track at Apachecon that were about how we could
 improve our UI.

 If the UI was the main focus - what could the strategy look like
 - User Interface - have 2 versions of the UI, one very clean and
 simple, the other more advanced. (Our current UI could be the
 advanced one?
 - Separate the web part from the widgets
 - We have too many fields on one screen (many of them are not
 mandatory and are just included as optional). What if we slimmed down
 all the screens to have a sensible default UI for users. The UI could
 also be modifiable by service providers. Simplify the screens with
 defaults
 - Use Bootstrap / CSS / Angular
 - Isolate web related
 - Define a graphics charter to be used for the screens
 - Have a CSS convention
 - Remove web from the framework - it shouldn't be there

 What do people think?

 -Do people think it would be a good idea to have 2 versions of the
 UI? (a simple one and a more advanced one?)

 - Are these the things we would need to focus on or have in place if
 we wanted to focus on the UI?

 (Also I know Nicolas has mentioned that he has already started work
 on a Proof of Concept for a common theme  - so do we need to make
 sure we agree conventions etc before much more work is done?)

 Thanks
 Sharan


>>>
>>>
>>
>>
>

Re: Proposal to remove excess runtime libraries

[Taher Alkhateeb]

Thank you folks. Committed in r1772839.

On Mon, Dec 5, 2016 at 4:13 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 05/12/2016 à 14:04, Jacopo Cappellato a écrit :
>
>> On Sat, Dec 3, 2016 at 8:28 AM, Taher Alkhateeb <
>> slidingfilame...@gmail.com>
>> wrote:
>>
>> I would like to propose deleting the following libraries from build.gradle
>>> ...
>>> Should I go ahead? opinions?
>>>
>>> I would go ahead: I suspect that they these declarations are redundant
>> because they can now be resolved by Gradle.
>>
>> Jacopo
>>
>> Yes, that must be the case for org.apache.httpcomponents:httpcore:4.4.1
> for instance
>
> Jacques
>
>