Hi Jacques, All,
Okay just to put things into context, the reason that kick-started this
discussion (multiple times so far) is that Pierre Smits had deployment
requirements in which Gradle is not allowed as detailed in this thread:
http://markmail.org/message/dzq3e55n6z4cwmre
To make things short, I was of the opinion that Pierre's request
represents
unusual and specific deployment requirements and that it should not be
the
default way to deploy OFBiz because people would lose all the power and
advantages from having a powerful build system automating everything.
The
discussions were had between myself, Pierre, Jacques with occasional
input
from others.
Despite my above position, the following JIRAs were created and had
patches
/ initiatives, all of which were very specific to the deployment
requirements of Pierre:
- https://issues.apache.org/jira/browse/OFBIZ-7782 -> The JIRA had a
patch
to create a task to copy all OFBiz runtime libraries to a certain
folder.
I
objected to it as being too specific to the deployment requirements of
Pierre.
- https://issues.apache.org/jira/browse/OFBIZ-7893 -> Reintroduce a
task
to
copy all OFBiz runtime libraries to a certain folder and remove gradle
from
the deployment scripts in /tools. I objected saying this is the wrong
this
to do and that I already objected in OFBIZ-7782
- https://issues.apache.org/jira/browse/OFBIZ-7796 -> Attempted to
strip
away gradle from the deployment scripts and replace it with Java. Again
I
objected to it for being too specific to the deployment requirements of
Pierre.
Sorry for the long introduction but the context is important for people
to
know where we stand exactly. Now to your question of how to deploy OFBiz
without Gradle, I would like to reply in two parts:
OK you played a trick here Taher by suggesting me the title :D
The problem I tried to tackle is not "How to deploy OFBiz without Gradle"
but "How to use Gradle w/o Internet connection"
1- Why without Gradle?
2- Available Options
Why without Gradle?
---------------------------
Imagine if I tell you that I want to deploy a ruby-on-rails application
without rails. Or I want to deploy OFBiz without the widget engine. Is
that
a normal requirement? No, it is not a normal requirement, it is a
requirement specific to my needs.
Gradle is a fundamental part of the OFBiz solution. Stripping it away is
like stripping away a core component. It is already holding a lot of
responsibilities and expected to hold a lot more. You must have a good
reason to want to remove it, and you should have the technical
capabilities
to do such a thing.
So, it is in my opinion unreasonable to require the code base to have a
solution to remove Gradle as an option (A task defined inside Gradle to
copy libs so you can later run java -jar). Because if that is proper
then
we should have such options in the system to remove the service engine,
the
entity engine, the widgets, and many other fundamental components.
Available Options
-----------------------
Taking into consideration that this is an _advanced_ topic and those
involved _should_ have the technical capacity to do it themselves; there
are different scenarios we are discussing here and I provide a sample
solution for each:
1- No internet connection: One solution is to copy the .gradle directory
to
the deployment server and run all gradle commands with --offline
That's what I did above but only with the caches (and the needed
wrapper).
It works but needs 10 times more disk space than before.
Since it's local and servers are supposed to have sufficient disk spaces,
it's only a problem of bandwidth to copy the Gradle cache each time it's
changed
To clarify the OFBiz compiled running code is all build\libs\ofbiz.jar
and
only the external dependencies are in the the Gradle cache, right?
BTW I also tried with the whole .gradle directory (the one in your user
folder) but got issues because I guess I tried only on Windows (too long
file paths).
I see no reasons it would not work, since by simply copying the caches
and
the wrapper it worked for me (only slighter less space: 10MB)
2- Gradle not allowed: One solution is to copy the .gradle directory to
the
deployment server and run java -jar build/ofbiz.jar (make sure to put
the
correct JVM arguments)
Yep, that's also the reason I kept and updated this information in
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
OFBiz+Technical+Production+Setup+Guide, despite your reluctance ;)
I still need to complete it...
Of course the option proposed by Pierre and yourself by having a gradle
task to copy the runtime libraries to some location and then run java
-jar
adding that folder to the classpath works. But it is too specific and
awkward.
The only reason is you have 10(!) times less data to move between
machines...
If you want to customize things to your liking, it is extremely
easy to create a gradle subproject (a file somewhere) and put all the
custom deployment logic in it, and then just create a patch that adds "
apply from: 'foo/bar/my-custom-build-script.gradle' "
OK, I'll consider it (as I did with the 1st post of this commit) before
adding it in the doc
As you can see, I do that to document the possibilities for our users.
Because I know it will happen and it's good for adoption.
So to conclude, if we succumb to every deployment scenario for every
person, we would indeed have a very big code base. I suggest to keep
things
lean and clean, and to avoid adding anything to the code base for the
specific exceptional deployment requirements of some individuals.
I totally agree on that!
Jacques
Regards,
Taher Alkhateeb.
In case of no internet connection, there are multiple options:
- Copy the .gradle directory to the server and run all gradle commands
with
--offline
-
On Tue, Aug 30, 2016 at 9:21 AM, Jacques Le Roux <
[email protected]> wrote:
Hi,
I just tried something which seemed very simple after reading Taher's
suggestion
in OFBIZ-7783
"For example if your problem is simply that you cannot build on a
disconnected computer even though the gradle cache is available then
the
solution is to issue the command ./gradlew --offline tasks-in-here. So
one
solution is to simply archive the gradle cache and restore it."
in the "Should we do binary releases?" thread
"You can also copy the .gradle cache from another computer and start
using
it with the --offline flag"
My idea was to mix --offline with --gradle-user-home Gradle commands,
because I wanted to do this on the same machine and did not know where
to
copy the .gradle cache (where the dependencies are)
-g, --gradle-user-home <-> Specifies the Gradle user home directory.
The default is the .gradle directory in the user's home directory.
So, *on the same machine*, I copied the cache (830 MB) from .gradle
directory to another place (I picked the shortest one, ie c:\gradle). I
got
9 issues with file names too long (was surprised about that since from
the
user's home directory they should be longer)
Then tried to use "gradlew --offline -g c:\gradle ofbiz" but got a
syntax
error and Gradle began to download the Internet again:
La syntaxe du nom de fichier, de répertoire ou de volume est
incorrecte.
"Downloading https://services.gradle.org/di
stributions/gradle-2.13-bin.zip
"
I stopped. I guess I missed something, and rather decided to set the
set
GRADLE_USER_HOME to c:\gradle in the gradlew.bat script. but then got
Exception in thread "main" java.io.FileNotFoundException:
"c:\gradle"\wrapper\dists\gradle-2.13-bin\4xsgxlfjcxvrea7akf941nvc7\
gradle-2.13-bin.zip.lck (La syntaxe du nom de fichier, de répertoire ou
de volumeest incorrecte)
I then copied the missing wrapper folder in c:\gradle (400 MB). Despite
Windows and its damned limitation on paths names, it then worked
perfectly
well.
But it's still disappointing because you have to copy 1,2 GB instead of
150 MB (160MB including OFBiz jars)
So my next question: should we use that as an advice to our users who
can't use Gradle on their production and alike machines, or should we
try
to refine and find a better option?
Thanks
Jacques
