This is Shifting the subject from "should we do binary releases" to "How to deploy OFBiz without Gradle". Although this has been discussed extensively if you still want to discuss it I suggest to start a new thread instead of changing the subject.
On Aug 30, 2016 8:56 AM, "Jacques Le Roux" <[email protected]> wrote: > Hi Nicolas, Taher, All, > > I also agree about not creating binary releases. At least not yet, this > can be revisited... > > 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 this 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\4xsgxlfjcxvrea7akf > 941nvc7\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 > > > Le 25/08/2016 à 13:17, Nicolas Malin a écrit : > >> Long thread at all :) >> >> I agree with Jacopo to don't create binary package at this time. We >> missing time to improve the project :( so don't waste time on non valuable >> task. >> >> I understand the mostly reason for QA and no internet access (and I'm >> concerned :)) but if an administrator team have the skill to block >> internet, they have also the skill to create a proxy cache for gradle (or >> something like that). >> >> But sure thanks jacques to raise this potential problem ! >> >> Nicolas >> >> Le 25/08/2016 à 13:03, Jacques Le Roux a écrit : >> >>> Le 25/08/2016 à 12:32, Taher Alkhateeb a écrit : >>> >>>> Hi Jacques, >>>> >>>> Ok great thank you for clarifying. >>>> >>>> It is hard to find modern systems that do not utilize the internet. >>>> Anything from node.js, ruby on rails, grails ... the list goes on and >>>> on. >>>> Even on the user interface, most of the javascript you see when you >>>> visit a >>>> page requires an internet connection to pull the resources for the UI to >>>> work. Many projects rely less and less on downloading and storing >>>> copies of >>>> anything. We are in the age where everything connects to everything and >>>> cloud computing is the norm. For example, most websites do not keep a >>>> local >>>> copy of jQuery, but the client (browser) fetches it on demand. This both >>>> reduces the load on the website server and improves the experience for >>>> the >>>> user. >>>> >>> >>> I can't get into details but I speak about one of the most important >>> Internet services provider (in 2012: 2,4 G€ revenue, 6000+ employees almost >>> same number of contractors, Market Cap in 2015: 7.40 G€) >>> The idea is if your servers cannot connect to the Internet (but Internet >>> can connect to them) you are already safer. They have of course also >>> several firewalls layers, etc. (not really fun to work with) >>> >>> Now for the less common cases where people do not have internet (wow) >>>> there >>>> are workarounds: >>>> - ./gradlew --offline yourCommandsHere. The --offline flag description >>>> is: >>>> "The build should operate without accessing network resources" However >>>> you >>>> should have the cache downloaded before using this flag >>>> >>> >>> Thanks Taher, seems we have almost our workaround already documented :) >>> >>> - You can also copy the .gradle cache from another computer and start >>>> using >>>> it with the --offline flag >>>> >>> >>> Yep, I thought about that. I needed to extract only the OFBiz related >>> libs for OWASP-DC but with OFBIZ-7930 it's no longer needed. >>> This nicely completes the point above! >>> >>> - You can always customize for special deployment requirements on your >>>> own. >>>> Gradle makes it very easy as is proven by your patch in OFBIZ-7783 in >>>> which >>>> you copied the libs in 3 lines of code! >>>> >>> >>> I agree, from a developer perspective Gradle is the best build system I >>> know. >>> Also a good tool for a sysadmin/devops as long as your GRC allows them >>> https://en.wikipedia.org/wiki/Governance,_risk_management,_a >>> nd_compliance >>> >>> Jacques >>> >>> >>>> Regards, >>>> >>>> Taher Alkhateeb >>>> >>>> On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < >>>> [email protected]> wrote: >>>> >>>> Le 25/08/2016 à 11:33, Taher Alkhateeb a écrit : >>>>> >>>>> Hi Jacques, >>>>>> >>>>>> Sorry but I'm a little confused. I note the following: >>>>>> >>>>>> - OFBiz did not create binary releases in the past >>>>>> >>>>>> Mmm, this is a delicate thing, I'll not say more, you might check by >>>>> yourself. >>>>> >>>>> - You started a thread to discuss whether we should create binary >>>>> releases >>>>> Yep, nothing prevents us to deliver binary packages (package is the >>>>> right >>>>> name as Jacopo outlined) >>>>> >>>>> - When I ask you for the purpose of these releases you reply by saying, >>>>> >>>>>> that's why I started this thread. >>>>>> >>>>>> The purpose is possibly ease for our users. >>>>> I initially thought about the case an user is unable to use Gradle on >>>>> her >>>>> test/QA/Prod servers (no internet connection on these servers, I was >>>>> there, >>>>> did not get the t-shirt, survived). Then the OOTB setting does not >>>>> work and >>>>> the user has to find a workaround. >>>>> So I though that by providing a binary package we would help users in >>>>> this >>>>> and other similar cases. Another possibility is to document a >>>>> workaround. >>>>> Nothing is mandatory, only well done source releases are mandatory. >>>>> >>>>> What is it that you are seeking? Are you interested in binary releases >>>>> and >>>>> >>>>>> want to know if it is a good idea to pursue? >>>>>> >>>>>> Yep, exactly >>>>> >>>>> If you are interested, then I >>>>> >>>>>> would qualify that as the "purpose" that I asked you about. If you >>>>>> are not >>>>>> interested, then why did you start the thread? >>>>>> >>>>>> To know if the community is interested. Jacopo at least is not, and >>>>> you as >>>>> well I believe. >>>>> >>>>> I'm now in the same mindset because, as Jacopo said, it's much work >>>>> and I >>>>> now think that simply document a workaround for the case above (and >>>>> similar) is enough (like using a local Gradle repository) >>>>> We can of course neglect it but it could be a difficult turn for some >>>>> users w/o this documentation >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>> Regards, >>>>>> >>>>>> Taher Alkhateeb >>>>>> >>>>>> On Thu, Aug 25, 2016 at 7:32 AM, Jacques Le Roux < >>>>>> [email protected]> wrote: >>>>>> >>>>>> Le 24/08/2016 à 23:15, Taher Alkhateeb a écrit : >>>>>> >>>>>>> Hi Jacques, >>>>>>> >>>>>>>> I'm not sure how am I supposed to understand it? To me it seems >>>>>>>> clear .. >>>>>>>> You cannot add binaries unless they are the result of compiling the >>>>>>>> source >>>>>>>> code of the release you are preparing, it's written so very >>>>>>>> clearly. It >>>>>>>> also makes sense as it is saying that you can provide binary >>>>>>>> releases >>>>>>>> that >>>>>>>> represent the binary form of YOUR code. >>>>>>>> >>>>>>>> Eventually it boils down to this >>>>>>>> >>>>>>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ >>>>>>> 201606.mbox/%3cCAAS6=7gVXGHqeKVeFV_r1849Qpi0+Ca0jc2QWQBQfRdZ >>>>>>> [email protected]%3e >>>>>>> >>>>>>> <<Untrusted jar files (from wherever) are allowed. They must >>>>>>> represent >>>>>>> compilation of open source dependencies>> >>>>>>> >>>>>>> BTW from this complete answer it seems not recommended to release >>>>>>> binaries >>>>>>> though they can also be done by a 3rd party (ie not endorsed by the >>>>>>> ASF) >>>>>>> >>>>>>> On a different but relevant note, why do we want binary releases in >>>>>>> the >>>>>>> >>>>>>> first place? What is the purpose? >>>>>>>> >>>>>>>> The question of this thread is "Should we do binary releases?" >>>>>>>> >>>>>>> It seems more and more to me that we should neglect them, notably for >>>>>>> security reasons. >>>>>>> Note though that from my OWASP dependency checks (OWAPS-DC), so far >>>>>>> Gradle does not guarantee you from vulnerabilities as I was hoping >>>>>>> for. >>>>>>> This still needs to be clarified because OWAPS-DC generates a lot of >>>>>>> false >>>>>>> positive... >>>>>>> In this area there is nothing worse than a false sense of security. >>>>>>> And >>>>>>> it's our responsibility to do our best for our users. >>>>>>> >>>>>>> But in last resort, it's the community to decide if we do binary >>>>>>> releases >>>>>>> or not and the reasons for that. Should we do a vote for that? >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> This is not a desktop application or a >>>>>>> >>>>>>> web server that you just want to fire up and start using. There is >>>>>>>> preparation work (loading data, configuring, etc ...). It would make >>>>>>>> sense >>>>>>>> to have a binary version of Tomcat, because I just want to start it >>>>>>>> up >>>>>>>> with >>>>>>>> defaults and run web applications against it. It would also make >>>>>>>> sense >>>>>>>> to >>>>>>>> want a binary version of a desktop application because I just want >>>>>>>> to >>>>>>>> use >>>>>>>> it. The story is completely different with OFBiz, this is not some >>>>>>>> software >>>>>>>> that you just compile and ship, it's a very customizable, tweakable >>>>>>>> system >>>>>>>> with many moving parts, especially the database! Having the build >>>>>>>> system >>>>>>>> is >>>>>>>> essential to its operation, so the whole idea of a binary stripped >>>>>>>> out >>>>>>>> release does not make much sense to me. >>>>>>>> >>>>>>>> Taher Alkhateeb >>>>>>>> >>>>>>>> On Wed, Aug 24, 2016 at 11:54 PM, Jacques Le Roux < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> Taher, >>>>>>>> >>>>>>>> Wait, either Tomcat, Ant and JMeter are doing it wrong or we don't >>>>>>>>> understand this sentence (I agree with you) or it's incomplete. >>>>>>>>> >>>>>>>>> Because if you download each of their binary releases you will >>>>>>>>> find in >>>>>>>>> them "binary/bytecode files" which are not the "result of compiling >>>>>>>>> that >>>>>>>>> version of the source code release" >>>>>>>>> >>>>>>>>> Tomcat: ecj >>>>>>>>> >>>>>>>>> Ant: ivy (+ 3 optionals) >>>>>>>>> >>>>>>>>> JMeter: ~50 externals libs >>>>>>>>> >>>>>>>>> I just checked Wicket: only own binaries, not even optionals like >>>>>>>>> Ant. >>>>>>>>> >>>>>>>>> For Tomcat and Ivy it's maybe optional, but for JMeter it's not it >>>>>>>>> seems. >>>>>>>>> I mean JMeter seems to depends on these external libs and they are >>>>>>>>> delivered in the binary. To be confirmed because I did not dig >>>>>>>>> deeper. >>>>>>>>> >>>>>>>>> It's even more obvious on Geronimo download page: >>>>>>>>> http://geronimo.apache.org/apache-geronimo-v301-release.html >>>>>>>>> >>>>>>>>> <<Following distributions use Tomcat as the Web container and >>>>>>>>> Axis2 as >>>>>>>>> the >>>>>>>>> Web Services engine.>> >>>>>>>>> >>>>>>>>> I did download the 91 MB, and can confirm it has a total of 346 >>>>>>>>> jars, >>>>>>>>> most >>>>>>>>> not being "result of compiling that version of the source code >>>>>>>>> release" >>>>>>>>> >>>>>>>>> I guess the external libraries are runtime dependencies, in certain >>>>>>>>> cases >>>>>>>>> only optional. >>>>>>>>> >>>>>>>>> I also read at http://www.apache.org/legal/re >>>>>>>>> solved.html#category-b >>>>>>>>> >>>>>>>>> <<software under the following licenses may be included in binary >>>>>>>>> form >>>>>>>>> within an Apache product if the inclusion is appropriately labeled >>>>>>>>> (see >>>>>>>>> below):>> >>>>>>>>> >>>>>>>>> So I don't think we can say "In other words we *cannot* include the >>>>>>>>> dependencies in the binary releases anyway. So people *must* use >>>>>>>>> Gradle >>>>>>>>> to >>>>>>>>> download the dependencies" >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 24/08/2016 à 17:12, Taher Alkhateeb a écrit : >>>>>>>>> >>>>>>>>> Hi Jacques, >>>>>>>>> >>>>>>>>> The discussion we had in OFBIZ-7783 was basically around whether or >>>>>>>>>> not >>>>>>>>>> we >>>>>>>>>> should have a task to copy the gradle dependencies into a certain >>>>>>>>>> directory. We went through many discussions, the last one being >>>>>>>>>> that >>>>>>>>>> this >>>>>>>>>> task might be needed for binary releases. >>>>>>>>>> >>>>>>>>>> However, if you look at the reference that _you_ provided you will >>>>>>>>>> notice >>>>>>>>>> that is says that you "may only add binary/bytecode files that >>>>>>>>>> are the >>>>>>>>>> result of compiling that version of the source code release" >>>>>>>>>> >>>>>>>>>> We are _NOT_ compiling any of the dependencies, instead, the build >>>>>>>>>> system >>>>>>>>>> downloads them from jcenter in a precompiled form. In other words >>>>>>>>>> we >>>>>>>>>> cannot >>>>>>>>>> include the dependencies in the binary releases anyway. So people >>>>>>>>>> must >>>>>>>>>> use >>>>>>>>>> Gradle to download the dependencies, and so the whole purpose of >>>>>>>>>> the >>>>>>>>>> binary >>>>>>>>>> release becomes unnecessary as you must have gradle and java >>>>>>>>>> installed >>>>>>>>>> on >>>>>>>>>> your computer. >>>>>>>>>> >>>>>>>>>> Taher Alkhateeb >>>>>>>>>> >>>>>>>>>> On Wed, Aug 24, 2016 at 5:36 PM, Jacques Le Roux < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> At https://issues.apache.org/jira/browse/OFBIZ-7783 we recently >>>>>>>>>> had a >>>>>>>>>> >>>>>>>>>>> discussion with Taher about doing or not binary releases. >>>>>>>>>>> >>>>>>>>>>> This is how the ASF defines a binary release ( >>>>>>>>>>> http://www.apache.org/dev/release.html#what) >>>>>>>>>>> >>>>>>>>>>> <<All releases are in the form of the source materials needed to >>>>>>>>>>> make >>>>>>>>>>> changes to the software being released. In some cases, >>>>>>>>>>> binary/bytecode >>>>>>>>>>> packages are also produced as a convenience to users that might >>>>>>>>>>> not >>>>>>>>>>> have >>>>>>>>>>> the appropriate tools to build a compiled version of the source. >>>>>>>>>>> In >>>>>>>>>>> all >>>>>>>>>>> such cases, the binary/bytecode package must have the same >>>>>>>>>>> version >>>>>>>>>>> number >>>>>>>>>>> as the source release and may only add binary/bytecode files >>>>>>>>>>> that are >>>>>>>>>>> the >>>>>>>>>>> result of compiling that version of the source code release.>> >>>>>>>>>>> >>>>>>>>>>> So the question is simple (not the answer, you need to think >>>>>>>>>>> ahead): >>>>>>>>>>> do >>>>>>>>>>> we >>>>>>>>>>> want to do binary releases? It comes with some burden, does it >>>>>>>>>>> worth >>>>>>>>>>> it? >>>>>>>>>>> No >>>>>>>>>>> needs to rush an answer :) >>>>>>>>>>> >>>>>>>>>>> If you want more information you can already look at the >>>>>>>>>>> conversation >>>>>>>>>>> we >>>>>>>>>>> had Pierre, Taher and I at OFBIZ-7783 >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> >>> >> >> >
