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
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 <
>>>>>> 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/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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>

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