Taher

Actually I though more about it, we really need something like that.

Actually we need to help our users when they are in a situation like I crossed 
once and reported here http://markmail.org/message/livdricudqdj6tmi :

"Also, as Pierre outlined, there are situations were you can't use Gradle but on dev machines. I experienced that, no servers were allowed to connect to the Internet at all..."

When I say that we need to help our users I mean that we need to lead them to a 
solution, and even if possible provide an easy way for them to build one.

In other words, if you have no access to Internet on production servers, and still want to use Gradle as it comes OOTB, you need to create an use your own repository.

This is what we are currently missing in the documentation. We don't need to provide the mean, but at least to document how to do it. If we could facilitate the needed work in this case it would be even better...

Jacques


Le 19/08/2016 à 18:22, Taher Alkhateeb a écrit :
Hi Jacques,

I think there should be an added value beyond "because it used to be
there". What is the purpose of keeping it with disclaimers in your opinion?

Regards,

Taher Alkhateeb

On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Taher,

I'd not be against (still in the lean way), but should we not keep at
least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
precaution)?

What are other opinions?

Jacques



Le 19/08/2016 à 17:50, Taher Alkhateeb a écrit :

Hi Jacques,

On a quick skim through, I highly recommend removing completely any traces
of "java -jar". The reason for my recommendation is that gradle automates
the build process. Exposing end-users to how things happen means exposing
them to implementation details. This has the following negative outcomes:

- Users need to be aware of JVM arguments to properly execute commands
- Changes we might decide to do in the future would break existing systems
because users are exposed to the details of how the system is constructed.
- The ofbiz.jar which is constructed from gradle has hardcoded library
paths that depend on each user's computer setup. Any changes to the setup
would not be reflected correctly using raw java commands. This would
probably confuse people a lot and debugging would be a pain. If you let
Gradle take over the whole thing then you minimize the confusion.
- The syntax for java -jar is more complex

So my recommendation is to replace every occurence of java -jar with
./gradlew "ofbiz --whatever-commands-here".

Taher Alkhateeb

On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,
I have done some wiki documentation update with respect to Gradle
recently. Today I got issues with Confluence which broke my working flow
on
the Apache OFBiz Technical Production Setup Guide <
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
appreciate reviews, not only on this page but on all recently changed
pages. If you follow Confluence changes, you should be aware of them.

Thanks

Jacques



Reply via email to