Proposal to remove excess runtime libraries

[Taher Alkhateeb]

Hello Everyone,

I would like to propose deleting the following libraries from build.gradle

runtime 'apache-xerces:resolver:2.9.1'
runtime 'commons-el:commons-el:1.0'
runtime 'net.sf.dozer:dozer:4.2.1'
runtime 'org.apache.axis2:axis2-adb:1.7.1'
runtime 'org.apache.httpcomponents:httpcore:4.4.1'
runtime
'org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:1.1.4c_7'
runtime 'org.apache.tomcat.extras:tomcat-extras-juli-adapters:8.0.39'
runtime 'org.apache.xalan:com.springsource.org.apache.xml.serializer:2.7.1'
runtime 'ws-commons-java5:ws-commons-java5:1.0.1'

I made multiple tests in removing them in combination with removing
specialpurpose components and I don't observe anything breaking. Some of
them are replaced by dependencies when deleted while others are just gone.

So I prefer to remove them and it's always easy to introduce things back if
we discover any issues that we missed. They seem to be mostly things that
had a PoC from the past like bean mappers or so.

Should I go ahead? opinions?

Taher Alkhateeb

buildbot failure in on ofbiz-branch13

[buildbot]

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

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

Buildslave for this Build: lares_ubuntu

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

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Taher Alkhateeb]

Hi Scott,

Thank you for sharing your thoughts, it's always good to see things from a
new perspective.

If you look at my earlier post, you'll notice that we both agree that the
points of strength in OFBiz are the domain model and business logic. It is
also an excellent idea to incorporate RESTful calls into the framework and
to refactor the services. All excellent suggestions.

I think where we might differ a bit though is in the assumption that the UI
is not that important. It would probably get the top priority position for
me for the following reasons:

- There are competing ERP systems out there that are gaining big market
shares because of the appeal of a refined user interface.
- The user interface gets more "end-users" to the community instead of only
developers and consultants which greatly widens the community and
eco-system. This is the main driver for big adoption in my opinion and I
know people who adopted systems because of this very reason.
- Once these non-technical end-users download the system and like it, they
shortly start contacting vendors for customization support. I live in a
very small country and yet one ERP system has two representative companies
just because of the appeal of the user interface they have and people
really like their software even though it might be inferior in other ways.
- In my experience, the user interface to a large degree drives the design.
You said it yourself, some of the services are written in an ugly way to
work around the UI mess. The UI really makes it clear how things _should_
work on every level of the stack. It is also the communication gateway
between users and developers.
- I think we have a cultural problem in the community that focuses on
functionality over beauty. We overlook the massive importance of beautiful
interfaces as an appeal for end-users and people who are thinking about and
shortlisting products to use.

You stated that you always prefer to drop down to FreeMarker templates for
getting work done. This means our current widget system is not sufficient
for your needs. But wait, does that mean we cannot improve it? Of course we
can, that's the whole purpose of this discussion and you can provide great
value with your experience in that area.

I agree with you 100% that the current widget system does not work well for
things like interactive UIs and single page applications. So let's rewrite
that! Let's get a better DSL, let's use something other than form widgets.
For example, one idea that comes to mind is to make the DSL go all the way
down to detailed components and then compose them. We can enhance it to be
RESTful and interactive, and I would really love to get input from you on
some details.

So to summarize, I think although the UI is a weakness point in OFBiz but
we can and should change that. I know it's hard work, but I cannot think of
a more powerful adoption impact than a simple beautiful modern interface
(mobile-first, RESTful, interactive, etc ...)

Cheers, and sorry for the long blinding post :)

Taher Alkhateeb

On Sat, Dec 3, 2016 at 2:03 AM, Scott Gray 
wrote:

> I don't think it's really our UI that inhibits adoption.  With any
> reasonably sized project there is going to be a large amount of UI
> customization where the front-end will be almost completely written from
> scratch and the back-end at least partially so.  This has been my
> experience at least over the past 9 years.
>
> It's also been my experience that form widgets don't play a large role in
> this effort with most development being done using Freemarker.
> Increasingly common in the last few years there has been a desire to use
> SPA frameworks such as AngularJS for the admin apps and smaller front-end
> apps.
>
> It's my opinion that while a custom UI framework is a "nice to have", it is
> by no means offers much of a selling point when you compare it to things
> like the domain model and the extensive business logic supported in OFBiz.
> Telling non-OFBiz front-end developers that they must now use the widget
> framework to build their AJAX intensive screens isn't much fun to be
> honest.
>
> A good majority of the data gathering logic is tightly coupled to the OOTB
> UI and isn't particularly re-usable.  Writing a JSON-RPC or REST based API
> for custom screens is usually quite a bit of work because there isn't any
> inherent support for it in the framework and you tend to just hack
> something together on the fly due to time/budget constraints.
>
> We have thousands of services in OFBiz with very little documentation and
> often overlapping responsibilities.  For example, cancelling an order,
> should I use "updateOrderHeader"? "changeOrderStatus"? Maybe
> "massCancelOrders"? Not to mention a large number of the services are
> intended to be ECAs only and not called directly, but there's generally no
> way of knowing that.  Virtually every time you go to use a service you have
> to go and look at the implementation and see if it's actually going

buildbot success in on ofbiz-trunk-rat

[buildbot]

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

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] 1762349
Blamelist: 

Build succeeded!

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Scott Gray]

I don't think it's really our UI that inhibits adoption.  With any
reasonably sized project there is going to be a large amount of UI
customization where the front-end will be almost completely written from
scratch and the back-end at least partially so.  This has been my
experience at least over the past 9 years.

It's also been my experience that form widgets don't play a large role in
this effort with most development being done using Freemarker.
Increasingly common in the last few years there has been a desire to use
SPA frameworks such as AngularJS for the admin apps and smaller front-end
apps.

It's my opinion that while a custom UI framework is a "nice to have", it is
by no means offers much of a selling point when you compare it to things
like the domain model and the extensive business logic supported in OFBiz.
Telling non-OFBiz front-end developers that they must now use the widget
framework to build their AJAX intensive screens isn't much fun to be honest.

A good majority of the data gathering logic is tightly coupled to the OOTB
UI and isn't particularly re-usable.  Writing a JSON-RPC or REST based API
for custom screens is usually quite a bit of work because there isn't any
inherent support for it in the framework and you tend to just hack
something together on the fly due to time/budget constraints.

We have thousands of services in OFBiz with very little documentation and
often overlapping responsibilities.  For example, cancelling an order,
should I use "updateOrderHeader"? "changeOrderStatus"? Maybe
"massCancelOrders"? Not to mention a large number of the services are
intended to be ECAs only and not called directly, but there's generally no
way of knowing that.  Virtually every time you go to use a service you have
to go and look at the implementation and see if it's actually going to do
what you expect it to and what the side-effects might be.

And then even with these thousands of services, there's virtually no
services for gathering and returning data.  That's all done in the data
prep for screens and isn't particularly re-usable and even if it were, how
would you know without sifting through the implementation because there's
no documentation for these scripts.  Sometimes it's a mix of a few widget
actions gathering data in different ways (XML lookups in the actions,
service calls and groovy scripts).

So while I see our web layer as a nice to have,  I strongly believe that
were OFBiz needs the most enhancement is in the business logic API.

Modern UI frameworks take a lot of the legwork out building a good UI these
days, but we don't stand to benefit from any of that while we continue to
try and build our own solution that will never be any where near as good.
The strength of OFBiz is in the business logic and I think we do ourselves
a disservice by considering our web framework to be the primary means of
accessing it.

I'm increasingly leaning towards wanting to find a way to deeply
incorporate RESTfulness deeply into our framework.  Primarily because of
the API simplification it would entail.  For example, instead of 10s if not
100s of services relating to creating/updating an order, you would simply
have get/put/post that works against a full order resource.  We'd then use
something similar to our ECAs and service engine to validate the document
and execute related operations against the modified resource.  In this
manner you'd reduce our main API down from thousands of services to less
than one hundred resource models.

That's just an idea though, the main point here is that I think our UI
matters less than providing a means for implementers to access the business
logic using any means they deem necessary through a simple comprehensive
well-documented API.

Regards
Scott

On 28/11/2016 23:08, "Sharan Foga"  wrote:

> Hi Everyone
>
> One of the topics that came up during the brainstorming in Seville was
> that the project desperately needs a clear strategy and roadmap.
>
> Benefits:
> - A strategy will provide a clear path for people to follow
> - A strategy will allow us to set goals / milestones and metrics about
> progress
>
> In past maybe we have tried to do too much (tried to do it all at once -
> which is why we find it h ard to focus).
>
> - One suggestion was to set a maximum of 3 goals and then work only on
> these. To define these goals we need to look at what is the most important
> thing that we want to achieve - and base them on that.
> - Another suggestion was that the most important thing for the project is
> driving adoption. If this is true then what are the key blockers that stop
> user adoption of OFBiz? (the UI!)
> - Suggestion to organise / setup teams from the community that focus on
> specific areas (e.g. workgroups) - this could really help progress
>
> So to get the discussion started:
>
> 1. Do people agree that the project needs to focus on driving adoption?
> 2. Do people think that the UI is one of the key things that stops this ?
> (If, not then ple

buildbot success in on ofbiz-branch13

[buildbot]

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

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

Buildslave for this Build: lares_ubuntu

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

Build succeeded!

Sincerely,
 -The Buildbot

Re: Need feedback and testing

[Taher Alkhateeb]

Hello Folks,

I'm very happy to state that I have a massive patch in
https://issues.apache.org/jira/browse/OFBIZ-8337 that among many other
things finally gets rid of the NativeLibClassLoader and substantially
simplifies the startup logic.

As usual, all help is appreciated in reviewing the work.

Cheers,

Taher Alkhateeb

On Sun, Nov 27, 2016 at 3:40 PM, Taher Alkhateeb  wrote:

> Hi Everyone,
>
> I just finished refactoring some of the messiest code I've ever seen.
> Again, I have a new patch in https://issues.apache.org/jira/browse/OFBIZ-
> 8337 that contains refactoring of the startup logic, mostly for the
> ComponentContainer. A fresh pair of eyes before committing would be great!
>
> Cheers,
>
> Taher Alkhateeb
>
> On Fri, Oct 7, 2016 at 6:13 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
>> Hello Everyone,
>>
>> I have a big patch in https://issues.apache.org/jira/browse/OFBIZ-8337
>>
>> This is a major refactoring of the Start and Base components to
>> substantially simplify and cleanup the startup sequence. All tests are
>> passing but further testing and feedback would be great.
>>
>>
>>
>

Re: [DISCUSSION] Organising OFBiz Events or Meetups

[Taher Alkhateeb]

A strategy without follow up is just a statement. So yeah I really think we
need some form of regular meetings to see where we are and whether we are
going on the right direction.

Perhaps something like once a month? Maybe for one hour or so, we can
gather on HipChat or have some form of voice conference to discuss things.

On Fri, Dec 2, 2016 at 4:46 PM, Sharan Foga  wrote:

> Hi Everyone
>
> Another topic that came up from the discussions in Seville was to look at
> the possibility of organising and running some OFBiz meetups or events.
>
> Meeting up at Apachecon is a great way to strengthen relationships and
> also collaborate. Could we make use of meetups (real and virtual) to bring
> the community together?
>
> Many other ASF projects have meetups but OFBiz doesn't - we tend to meetup
> at Apachecon and that's it. Could we look at organising some meetups,
> hackathons, training etc?  We have a lot of work so the meetups could be a
> way for a group of people to work together on a specific topic. It could
> also be used to do some outreach (recruit new members) as well as providing
> some valuable information / training etc for existing community members.
>
> We have a strong community in Europe – would a separate OFBiz event /
> meetup in Europe work? (or should we continue to use Apachecon?). What
> about the US?
> By the way -  I understand that there is now a focus on getting projects
> to run their 'summits' as part of Apachecon, so this could be something we
> could look at?
>
> I've also heard that there is a large OFBiz community in India -  so could
> this be an option?
>
> Anyway I'd like to find out if there is any interest so please let me have
> your feedback and comments.
>
> Thanks
> Sharan
>

[DISCUSSION] Organising OFBiz Events or Meetups

[Sharan Foga]

Hi Everyone

Another topic that came up from the discussions in Seville was to look at the 
possibility of organising and running some OFBiz meetups or events. 

Meeting up at Apachecon is a great way to strengthen relationships and also 
collaborate. Could we make use of meetups (real and virtual) to bring the 
community together?

Many other ASF projects have meetups but OFBiz doesn't - we tend to meetup at 
Apachecon and that's it. Could we look at organising some meetups, hackathons, 
training etc?  We have a lot of work so the meetups could be a way for a group 
of people to work together on a specific topic. It could also be used to do 
some outreach (recruit new members) as well as providing some valuable 
information / training etc for existing community members.

We have a strong community in Europe – would a separate OFBiz event / meetup 
in Europe work? (or should we continue to use Apachecon?). What about the US? 
By the way -  I understand that there is now a focus on getting projects to run 
their 'summits' as part of Apachecon, so this could be something we could look 
at?

I've also heard that there is a large OFBiz community in India -  so could this 
be an option? 

Anyway I'd like to find out if there is any interest so please let me have your 
feedback and comments.

Thanks
Sharan

Re: [DISCUSSION] Defining an OFBiz Project Strategy

[Sharan Foga]

Hi Everyone

Thanks very much for all the feedback on this thread. 

It's time to summarise and make a working document out of what we have 
discussed. (I know some people are already busy on various POCs but we need to 
really link everything we are doing back in to the overall project strategy and 
direction).

I'm going to create a new wiki page for this project strategy. It will be a 
brief high level document, pulling in the main areas mentioned. I don't want it 
to become too detailed, I think it should just be like an overview where anyone 
can quickly read it and understand the project direction and focus.

Under each main area – I am going to limit it to a maximum 2 (maybe 3:-) 
milestones / goals / workareas. (so please make sure you think about the high 
level goal of what we want to achieve)

Once the page is done, we can do another consensus check to make sure we have 
community agreement on it.

Thanks
Sharan
On 2016-11-28 11:08 (+0100), "Sharan Foga" wrote: 
> Hi Everyone
> 
> One of the topics that came up during the brainstorming in Seville was that 
> the project desperately needs a clear strategy and roadmap. 
> 
> Benefits:
> - A strategy will provide a clear path for people to follow
> - A strategy will allow us to set goals / milestones and metrics about 
> progress
> 
> In past maybe we have tried to do too much (tried to do it all at once - 
> which is why we find it h ard to focus).
> 
> - One suggestion was to set a maximum of 3 goals and then work only on these. 
> To define these goals we need to look at what is the most important thing 
> that we want to achieve - and base them on that.
> - Another suggestion was that the most important thing for the project is 
> driving adoption. If this is true then what are the key blockers that stop 
> user adoption of OFBiz? (the UI!) 
> - Suggestion to organise / setup teams from the community that focus on 
> specific areas (e.g. workgroups) - this could really help progress
> 
> So to get the discussion started: 
> 
> 1. Do people agree that the project needs to focus on driving adoption?
> 2. Do people think that the UI is one of the key things that stops this ? 
> (If, not then please include what do you think is)
> 3. What goals could we set?
> 4. Are people interested in working in workgroups, to focus on specific areas 
> (or goals)?
> 
> (I know there are some ideas/work around the UI going on, but I will post the 
> Seville details and notes about that in separate discussion thread.)
> 
> Thanks
> Sharan
> 
> 

Re: [DISCUSSION] Improving the OFBiz User Interface

[Julien NICOLAS]

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: [DISCUSSION] Improving the OFBiz User Interface

[pierre]

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







--
logoNrd 
Pierre GAUDIN
Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre
informat...@nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54 - mob: 06 08 40 25 70

ofbiz-fr  | réseau LE

Re: Release specific documentation, was: Starting OfBiz at boot in the user list

[Pierre Smits]

Great initiative, Michael,

Looking forward to seeing the end result.

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 11:10 AM, Michael Brohl 
wrote:

> Hi Jacques,
>
> We should indeed have an additional Wiki page where the deployment,
> running and hosting informations for releases 16.x + are documented.
>
> Which brings me to an idea: we should see if we can reorganise the
> documentation to have an entry point by release/version so that all
> informations are consistent within a release. We may have other impacting
> changes in the project and we should enable users to easily find all
> informations.
>
> That would be a good start for contributors who want to contribute apart
> from code.
>
> An example would be: http://camel.apache.org/manual.html
> Regards,
>
> Michael
>
> Am 02.12.16 um 09:41 schrieb Jacques Le Roux:
>
>> Craig,
>>
>> Could you tell us what you used in May (OFBiz version, scripts changes,
>> etc.)
>>
>> This is order to amend https://cwiki.apache.org/confl
>> uence/display/OFBIZ/How+to+run+OFBiz+as+a+Service if needed (I guess
>> it's needed ;))
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 02/12/2016 à 04:34, Craig Parker a écrit :
>>
>>> I got this going finally back in May, but downloaded 16 tonight and
>>> can't fire it up. Here's how I got there a few months back...
>>>
>>> http://65.175.244.105:31415/ofbizdocs/?p=352
>>>
>>>
>>> On 05/03/2016 09:43 PM, Craig Parker wrote:
>>>
 I've been following along on this site:
 https://cwiki.apache.org/confluence/display/OFBIZ/How+to+
 run+OFBiz+as+a+Service

 and can /etc/init.t/ofbiz start/stop/restart as root, but it won't fire
 up at boot. Before I edited /etc/init.d/ofbiz, there was a line that said
 "OFBIZ_USER=ofbiz" When I tried, as root to run /etc/init.d/ofbiz start,
 I'd get an error:
 Starting OFBiz: failure

 Only users root or ofbiz should start/stop the application

 Like I said, I can start it now manually as root, but it won't fire up
 as boot. In /var/log/boot.log, I see that same error, except now it says
 "...Only users root or root..."

 What'd I miss? I'm running Ubuntu Server 14.04 just using the default
 built in database at the moment.

>>>
>>>
>>>
>>
>
>

Release specific documentation, was: Starting OfBiz at boot in the user list

[Michael Brohl]

Hi Jacques,

We should indeed have an additional Wiki page where the deployment, 
running and hosting informations for releases 16.x + are documented.


Which brings me to an idea: we should see if we can reorganise the 
documentation to have an entry point by release/version so that all 
informations are consistent within a release. We may have other 
impacting changes in the project and we should enable users to easily 
find all informations.


That would be a good start for contributors who want to contribute apart 
from code.


An example would be: http://camel.apache.org/manual.html
Regards,

Michael

Am 02.12.16 um 09:41 schrieb Jacques Le Roux:

Craig,

Could you tell us what you used in May (OFBiz version, scripts 
changes, etc.)


This is order to amend 
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+run+OFBiz+as+a+Service 
if needed (I guess it's needed ;))


Thanks

Jacques


Le 02/12/2016 à 04:34, Craig Parker a écrit :
I got this going finally back in May, but downloaded 16 tonight and 
can't fire it up. Here's how I got there a few months back...


http://65.175.244.105:31415/ofbizdocs/?p=352


On 05/03/2016 09:43 PM, Craig Parker wrote:

I've been following along on this site:
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+run+OFBiz+as+a+Service 



and can /etc/init.t/ofbiz start/stop/restart as root, but it won't 
fire up at boot. Before I edited /etc/init.d/ofbiz, there was a line 
that said "OFBIZ_USER=ofbiz" When I tried, as root to run 
/etc/init.d/ofbiz start, I'd get an error:

Starting OFBiz: failure

Only users root or ofbiz should start/stop the application

Like I said, I can start it now manually as root, but it won't fire 
up as boot. In /var/log/boot.log, I see that same error, except now 
it says "...Only users root or root..."


What'd I miss? I'm running Ubuntu Server 14.04 just using the 
default built in database at the moment.










smime.p7s
Description: S/MIME Cryptographic Signature

Re: [DISCUSSION] Improving the OFBiz User Interface

[Darshan kumar]

Hi everyone,

Sorry for the delay in reply.

@Julien thanks for pulling me in.

I would suggest if we can have API in place and meanwhile work on UX part
along with the choice of Front end framework to start with.

Lets Plan in detail.

Thank you

Thanks and Regards,
Darshan Kumar
 +919900568729

On Wed, Nov 30, 2016 at 4:05 AM, Julien NICOLAS 
wrote:

> Hi Sharan, everyone,
>
> It was idea like seed that start to grow up in my mind since I start with
> OFBiz. Today, after several try on the project I think the community is
> very closed to find the best way to improve the UI.
>
> The first sharing was with Gil and Nicolas, then we decide to submit a
> talk about that. The big surprise was that Taher have the quite same ideas
> than us !!!
>
> There are many things that must be done to have a good UI.
>
>  - All the UI could be managed by the theme without modifying the
> framework.
>
>  - Each screen must be linked to a screen structure.
>
>  - We need a UI standard that the developer need to follow for screen
> creation.
>
>  - We must have a common theme (remove all theming stuff from the
> framework)
>
>  - It could be interesting to have a new component to improve / test a new
> theme
>
>  - We have to create at least a new theme without limits ! Be crazy !
>
> It's a long term project, but it must be our concern, all the people that
> want a beautiful and UX UI must be involved \o/ I remember when I start
> bootstrap topics, that we were many ;)
>
> This project is more ambitious, a long term one that will improve the
> theming automatism to provide to the webdesigner an unlimited tool and, in
> the same time, an easy to maintain framework for us ;)
>
>
> Why we need a new component to test new theme ?
>
> When I start working with OFBiz, I was so surprised that the UI is too
> heavy. Then I was thinking that I have to improve the UI to provide a best
> one. After several try I understand that the actual UI is not a final user
> interface. It is a developer one. It's a developer UI because it contain
> all the features developed. But definitively, we can't provide this kind of
> UI to final users, we have to simplify it. In the same times, we can't
> delete the current UI because developers need to improve it with new
> features that will help us to deploy new features to our final users.
>
> For this new component, we can implement an existing component but
> simplified and ready for the new theme(s).
>
> In conclusion, if the new component dedicated for test a new theme match
> to the community needs, Taher think to a super simplified developer user
> interface that facilitate developers to improve the software. A new
> interface without any constraint that allow developers to develop easily
> new features.
>
>
> What about the new theme ?
>
> A new theme, maybe more than one theme. It could be crazy but if we need
> to be sure that we can do anything we want and that the screen structure
> allow webdesigner to do whatever we want, we can imagine 2 new themes
> exactly different in structure :)
>
> I have at least an idea, just for the look and feel. I can share it and we
> can improve it all together (or just scrap it and start with a new idea
> ^^). In the same times, at the Apache Con we meet Victoria Bondarchuk
> 
> (work in UX project management) that want to help us in this task, and
> Darshan Kumar (work also in UX) who want to join the OFBiz project starting
> on that task.
>
>
> How to start ?
>
> I propose to start by creating a main Jira about Improve the UI (maybe
> this one already exist since a long long time ago ^^) and then link all the
> subtasks to this main one. Maybe we can start a topic by subtask to share
> with the community.
>
>
> Before creating anything it could be interesting to have opinion of all
> people who want UI changes. All the community I think, so I hope server
> will not be down because of the OFBiz community involving ^^
>
> I hope Paul, Gaurav and all the people that try or already improve the UI
> will help on this task \o/
>
> I want to be an actor of this changes and I hope you want it too !
>
> Thanks for all your help in advance.
>
> Julien.
>
> 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 cou