Hi Jacques, I think to get the absolute minimum cache size you do the following: - delete .gradle - ./gradlew cleanAll build (do not run eclipse so that you do not download the source dependencies)
This would give you the minimum cache needed for OFBiz to run. Taher Alkhateeb On Tue, Aug 30, 2016 at 1:38 PM, Jacques Le Roux < [email protected]> wrote: > Le 30/08/2016 à 11:25, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> I know you probably meant this as a friendly joke but this is our official >> ML, so I have to state for the record that I did not play a "trick", my >> objective was to say that you changed the topic and therefore we need to >> start a new thread. Choosing the new topic is entirely within your >> control. >> > > Yes of course, only a friendly joke :) > > Now as you probably already know Gradle has different dependencies such as >> compile and runtime. Part of the difference in size could be due to >> copying >> only one of these dependencies and not all of them. For example the copy >> libs task (discussed earlier) only copied runtime dependencies. But is >> this >> the right thing to do? are you not going to compile anything in the future >> in the production environment? Maybe yes maybe no it depends doesn't it? >> It's different from one deployment to another. Therefore it is specific to >> each user in their own environment. >> > > Yes, that's why I did not continue this way. I have though still to find a > right solution for OWASP-DC > I mean https://issues.apache.org/jira/browse/OFBIZ-7930 > > Another reason could be that the development machine contains additional >> unneeded dependencies. So if you try to delete the cache folder and run >> the >> build again you might get a smaller size upon copying. >> > > I just tried, after downloading the Internet again (kiiiidiiing ;)) it's > indeed much smaller (Eclipse included) it's only 350 MB, a good news! > > BTW handling (copying, deleting, moving) the caches on Windows is "a bit" > long. Because Windows does not handle well a folder with plenty of files (I > guess some are small did not check). > Not a big deal since most of the time (if not all the time) Windows is not > used as a server. > > Also for the record, if no internet connection is a substantial enough >> problem and multiple people are facing it then it makes sense that we help >> our users, but this needs to be discussed thoroughly in ML to come up with >> a good clean solution before starting multiple jiras like the ones >> mentioned earlier. To me personally I don't think this is a big issue but >> I >> could be wrong so I leave it to others to have their say. >> > > I agree a plethora of Jira is not good. I think we have discussed this > enough, now we need to continue to update the documentation. > For that you need 1st to know what you are talking about, hence this > discussion indeed. > > I wonder about the dependencies introduced in Gradle cache by Eclipse > Could someone using IntelliJ confirm it has much less than 350 MB in cache? > > Thanks > > Jacques > > > >> Regards, >> >> Taher Alkhateeb >> >> On Aug 30, 2016 11:50 AM, "Jacques Le Roux" <[email protected] >> > >> wrote: >> >> 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 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 >>>>> >>>>> >>>>> >
