I think our discussion is shifting so I'll refocus back on my point. All
that I'm suggesting is to keep the manual focused (like you mentioned on
all environment) on gradle only, and only in standard OFBiz setup. Then,
you have an advanced / special / custom section where you discuss whatever
you want including "java -jar" and any other non-standard deployment
options (such copying cache or whatever).
How to design that? I don't know and it's your initiative, I simply suggest
to keep the non-standard stuff in its own section away from the standard
deployment documentation. So java -jar should not be sitting next to
On Fri, Oct 14, 2016 at 6:51 PM, Jacques Le Roux <
> Thanks Taher, that's quite a proposition.
> Le 11/10/2016 à 09:07, Taher Alkhateeb a écrit :
>> How about creating a section in this document called "Advanced environment
>> setup" In this section you explain things like:
>> - how to move from Gradle to plain Java
> I'm not sure quite sure what you mean by "moving from Gradle to plain
> Java". So my answer below may be biased.
> My preference would be to recommend to use Gradle as much as possible in
> all areas (eg: dev, test, QA, stage and prod) and if it's not possible to
> use in one or several of the areas then to switch to plain Java.
> What I mean by "to switch to plain Java" is, as we discussed already, is
> to simply copy the the Gradle cache to a another location and to set the
> location of Gradle cache by a mean or another (eg
> http://markmail.org/message/irm2q3palp65kmqg and sequel)
> We may also want to advice to copy only necessary files (to avoid copy the
> Internet ;)). Something like what I proposed (for another reason: OWASP-DC)
> in this comment
> In other words, if you can't run Gradle in an area but this area is on the
> same LAN than your test instance (most common) then
> 1. You have plenty of disk space and your LAN is not a bottleneck,
> just copy the Gradle Cache, change its location, et voilà
> 2. You can't use the point 1 (ie you want to minimise disk space
> or/and LAN usage, or it's not on the LAN) then a solution like in in my
> above can be used (copy only files OFBiz needs to compile and run).
> 3. You may even compile in a location where you can use Gradle and
> then copy only the OFBiz jars and the runtime ones, something like Pierre
> proposed in this comment
> Then do we need to explain more, ie what you suggest below? It seems they
> are more related to Gradle knowledge and I'd let that to users to work on.
> - how the dependencies are resolved and what to do to download them
>> - How does gradle build the classpath and how to replicate that in pure
>> - How to fine-tune the build script for production (e.g. remove dependency
>> on build for OFBiz server tasks)
>> - How to fine-tune the memory settings for Gradle for optimal performance
>> - How to fine-tune gradle generally ->
>> - All other advanced production setup topics (caching, widgets, etc ..)
>> On Tue, Oct 11, 2016 at 9:30 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>> In the Apache OFBiz Technical Production Setup Guide we have few examples
>>> of command lines
>>> As it was before when using Ant I have shown both options, ie using
>>> Gradlew or directly Java.
>>> I think I already know Taher's answer :) But I'd like to know if we agree
>>> about keeping both examples or if we should simplify and give only the
>>> gradlew examples.
>>> I tend to think that we should simplify and only give users the mean to
>>> know the java way by themselves (ie by running "gradlew 'ofbiz ?'")