ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taher Alkhateeb <slidingfilame...@gmail.com>
Subject Re: How to deploy OFBiz without Gradle
Date Tue, 30 Aug 2016 11:18:21 GMT
Hmmm, not sure if Intellij or eclipse would make a difference in the cache
size? It is gradle that is downloading, not eclipse nor intellij.

On Tue, Aug 30, 2016 at 2:02 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Le 30/08/2016 à 12:43, Taher Alkhateeb a écrit :
>> 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.
> Yep, sure if someone using IntelIJ could share the burden that would be
> easier for me ;)
> Not a big deal anyway
> Jacques
> Taher Alkhateeb
>> On Tue, Aug 30, 2016 at 1:38 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> 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" <
>>>> jacques.le.roux@les7arts.com
>>>> 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
>>>>>> 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
>>>>>> Pierre.
>>>>>> - https://issues.apache.org/jira/browse/OFBIZ-7893 -> Reintroduce
>>>>>> 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
>>>>>> 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.
>>>>>> 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
>>>>>> is
>>>>>> like stripping away a core component. It is already holding a lot
>>>>>> responsibilities and expected to hold a lot more. You must have a
>>>>>> 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
>>>>>> 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
>>>>> 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
>>>>>> 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
>>>>>> "
>>>>>> 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
>>>>>> 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 <
>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>> of
>>>>>>> 150 MB (160MB including OFBiz jars)
>>>>>>> So my next question: should we use that as an advice to our users
>>>>>>> can't use Gradle on their production and alike machines, or should
>>>>>>> try
>>>>>>> to refine and find a better option?
>>>>>>> Thanks
>>>>>>> Jacques

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message