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: 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 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) 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. 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' " 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. 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/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 >
