ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: How to deploy OFBiz without Gradle
Date Tue, 30 Aug 2016 08:50:23 GMT
Le 30/08/2016 à 09:21, Taher Alkhateeb a écrit :
> 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 
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 
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!


> 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 <
> jacques.le.roux@les7arts.com> 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/distributions/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

View raw message