Should we do binary releases?
Locked
Should we do binary releases?
 
Administrator
|
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 |
|
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 < [hidden email]> 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 > > > |
Re: Should we do binary releases?
|
Administrator
|
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/resolved.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 < > [hidden email]> 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 >> >> >> |
|
|
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. On a different but relevant note, why do we want binary releases in the first place? What is the purpose? 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 < [hidden email]> 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/resolved.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 < >> [hidden email]> 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 >>> >>> >>> >>> > |
Re: Should we do binary releases?
|
Administrator
|
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+Ca0jc2QWQBQfRdZnCwVpA@...%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 < > [hidden email]> 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/resolved.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 < >>> [hidden email]> 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 >>>> >>>> >>>> >>>> |
Re: Should we do binary releases?
|
In reply to this post by Jacques Le Roux
A couple of comments:
1) a "release" at the ASF is a "source release". It would be better, to avoid any confusion in the future, if we name "binary packages" the (optional) files that we could produce from a release 2) my preference would be to not issue binary packages: focusing on publishing good (source) releases is already a challenging effort for this community; in the future, if a large set of users will start to ask for them, we could revisit this discussion Just my 2 cents Jacopo On Wed, Aug 24, 2016 at 4:36 PM, Jacques Le Roux < [hidden email]> 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 > > > |
|
|
In reply to this post by Jacques Le Roux
Hi Jacques,
Sorry but I'm a little confused. I note the following: - OFBiz did not create binary releases in the past - You started a thread to discuss whether we should create binary releases - When I ask you for the purpose of these releases you reply by saying, that's why I started this thread. 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? 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? Regards, Taher Alkhateeb On Thu, Aug 25, 2016 at 7:32 AM, Jacques Le Roux < [hidden email]> 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 > [hidden email]%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 < >> [hidden email]> 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/resolved.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 < >>>> [hidden email]> 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 >>>>> >>>>> >>>>> >>>>> >>>>> > |
Re: Should we do binary releases?
|
Administrator
|
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 < > [hidden email]> 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 >> [hidden email]%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 < >>> [hidden email]> 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/resolved.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 < >>>>> [hidden email]> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> |
|
|
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. 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 - You can also copy the .gradle cache from another computer and start using it with the --offline flag - 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! Regards, Taher Alkhateeb On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < [hidden email]> 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 < >> [hidden email]> 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 >>> [hidden email]%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 < >>>> [hidden email]> 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/resolved.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 < >>>>>> [hidden email]> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > |
Re: Should we do binary releases?
|
Administrator
|
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,_and_compliance Jacques > > Regards, > > Taher Alkhateeb > > On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < > [hidden email]> 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 < >>> [hidden email]> 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 >>>> [hidden email]%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 < >>>>> [hidden email]> 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/resolved.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 < >>>>>>> [hidden email]> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> |
|
|
Glad you got the workarounds docs :)
What do you mean by "your servers cannot connect to the Internet (but Internet can connect to them)"? Is that a DMZ, .iptables, port blocking, or what exactly? Sounds like what you're saying is not (no internet) but certain custom firewall / network settings On Thu, Aug 25, 2016 at 2:03 PM, Jacques Le Roux < [hidden email]> wrote: > 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,_and_compliance > > > Jacques > > >> Regards, >> >> Taher Alkhateeb >> >> On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < >> [hidden email]> 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 < >>>> [hidden email]> 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 >>>>> [hidden email]%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 < >>>>>> [hidden email]> 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/resolved.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 < >>>>>>>> [hidden email]> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > |
Re: Should we do binary releases?
|
|
In reply to this post by Jacques Le Roux
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,_and_compliance > > Jacques > >> >> Regards, >> >> Taher Alkhateeb >> >> On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < >> [hidden email]> 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 < >>>> [hidden email]> 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 >>>>> [hidden email]%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 < >>>>>> [hidden email]> 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/resolved.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 < >>>>>>>> [hidden email]> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > > |
Re: Should we do binary releases?
|
Administrator
|
In reply to this post by taher
Le 25/08/2016 à 13:16, Taher Alkhateeb a écrit :
> Glad you got the workarounds docs :) > > What do you mean by "your servers cannot connect to the Internet (but > Internet can connect to them)"? Is that a DMZ, .iptables, port blocking, or > what exactly? Sounds like what you're saying is not (no internet) but > certain custom firewall / network settings Oh, they have clever enough engineers there to put you enough sticks in your wheels, believe me ;) Eg: working with a PayPal sandbox w/o a browser installed on the test server and no global Internet access (but specific dispensation, ie indeed I guess several layers of .iptables, I mean several layers of servers with of course also firewalls and such) Jacques |
Re: Should we do binary releases?
|
|
Before I answer the question that Jacques raised ( rephrased into: Should
we generate binary packages aka zip files of our source releases as a convenience to our potential and existing adopters?), I will give my take on why I believe projects do provide those to the broader audience. Projects provide these convenience downloads as a sign of maturity (of the code), as a statement (at that moment in time) of confidence to be able to say: 'if you run this -as is- you can use it for what we say you can use it for, as a means to promote the project and it's project as with each release there is something new to talk about. Each release, conveniently packaged into a zip, tar or whatever variant having something that can be run out of the box!. It is - also - the 'easy to run as is' that drives the success of adoption. Look at the success of products like ActiveMQ, Directory, Httpd, Studio, Tomcat, and many more under the umbrella of the ASF and elsewhere... Easy to run OOTB is key in this. Ease of use for first timers creates buzz, validates the reasons why contributors participate in the project. And yes, easy to extend help as much too. It is not the 'go download, configure, read documents (or in our project: filter through 1000s of email postings and out-of-date wiki pages), etc. etc. first to run it' that drives first time adopters, to see the success of the product, like we (the project) see it. It drives first timers away, because to difficult, community not participating enough... The various projects (including the one of which I am a part of PMC) ensure that the person downloading their product can have a one-click (entering a single statement through the cli) running product. Just 1 click/ statement, a bit of waiting and go use! (I would even go as far as in saying: the majority of projects of the ASF work towards providing that 1-click experience). Can this project provide that experience? Yes it can! But it requires volunteers willing to work towards that goal. After all, it's about scratching one's own itch, right? For the benefit of the first timer, the returning adopter, the project, this community and everyone participating in it. Now, having a product mature enough to be able to provide it to the intended audience (first timers in this case, not the the existing adopters who want to explore new stuff in the release in their own environment with their own data - although that is relatively easy to configure) requires a few extra steps: 1. create the binary package aka the zip file (build tools are used for that...) 2. sign the zip 3. make it available somewhere We have done so with every release in the past (and I thank Jacopo for each time he has taken that burden upon himself), expressing our confidence in the product as it was at that time. Having each time our moment to generate buzz. Now, we didn't deliver a 1 click experience, but what we provided OOTB was easy enough. And the community willing to help that new first timer. Through answers to questions posted. Some even wrote books about it. All acceptable. Nobody ever complained (AFAICT). So, back to the question: Should we generate binary packages aka zip files of our source releases as a convenience to our potential and existing adopters? Yes, we should! Each time we have a release! Each time this moment of celebration has arrived! I provided some arguments above. I feel confident there are enough +1 arguments one can image on this that outweigh the -1 arguments. It won't hurt our audience. It won't hurt the volunteer taking the extra step. It won't hurt the project or this community. In the previous postings I read arguments like 'it requires additional downloads, etc.' as one of the main reasons not to do these zips. I say: the build process takes care of this for that 1st time experience, and can take care of that 1-click experience. The product contains enough to extend that (and the project provides more than just that release) for those who want more. There are 2 things I see - with respect to that 1-click/1-statement experience - that are missing: 1. download of the external library that is required to facilitate the experience 2. incomplete cleanup process. It seems to me these omissions can be fixed easily before our next release. FWIW, issue OFBIZ-7783 <https://issues.apache.org/jira/browse/OFBIZ-7783> can be regarded as part of a 1-click experience. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Thu, Aug 25, 2016 at 1:31 PM, Jacques Le Roux < [hidden email]> wrote: > Le 25/08/2016 à 13:16, Taher Alkhateeb a écrit : > >> Glad you got the workarounds docs :) >> >> What do you mean by "your servers cannot connect to the Internet (but >> Internet can connect to them)"? Is that a DMZ, .iptables, port blocking, >> or >> what exactly? Sounds like what you're saying is not (no internet) but >> certain custom firewall / network settings >> > > Oh, they have clever enough engineers there to put you enough sticks in > your wheels, believe me ;) > > Eg: working with a PayPal sandbox w/o a browser installed on the test > server and no global Internet access (but specific dispensation, ie indeed > I guess several layers of .iptables, I mean several layers of servers with > of course also firewalls and such) > > Jacques > |
|
|
Hi Pierre, Everyone
This was a long post, but I'll try to summarize your points to reply to them: 1- Projects provide these convenience downloads as a sign of maturity 2- The binary package provide an easy to run product which drives adoption with a "Just 1 click/ statement," 3- Other ASF projects have high adoption because of these packages like httpd and tomcat So in reply: 1- Some projects are less than 3 months old with binary packages. That is not a sign of maturity, it's just a convenience download. There are countless examples in Github 2- What is so difficult with ./gradlew loadDefault ofbiz? That is all you need to run the system. Oh and by the way, you still need to install Java right? You need to install Java whether it is a binary release or not. Someone with enough experience to download and install Java would probably be able to type ./gradlew loadDefault ofbiz in the command line. Furthermore, you cannot really use OFBiz OOTB right now can you? The accounting component needs configuring, the demo data needs to be removed, and almost every component needs tweaking to make it work for your business. This is much, much more complex and difficult than ./gradlew loadDefault ofbiz 3- You are comparing oranges and apples. Tomcat and httpd for example are web servers. They are things you just want to run and don't care much about (at least as a beginner) because what you care about is deploying YOUR web application on it. With OFBiz the story is different, this is a complex ERP system that does not just work OOTB (see my comments above). If anything, the only thing I would do with each release is to perhaps zip or tar the source and that's it. Then every user would download it, unzip, ./gradlew loadDefault ofbiz ... Done! Regards, Taher Alkhateeb On Thu, Aug 25, 2016 at 9:04 PM, Pierre Smits <[hidden email]> wrote: > Before I answer the question that Jacques raised ( rephrased into: Should > we generate binary packages aka zip files of our source releases as a > convenience to our potential and existing adopters?), I will give my take > on why I believe projects do provide those to the broader audience. > > Projects provide these convenience downloads as a sign of maturity (of the > code), as a statement (at that moment in time) of confidence to be able to > say: 'if you run this -as is- you can use it for what we say you can use it > for, as a means to promote the project and it's project as with each > release there is something new to talk about. Each release, conveniently > packaged into a zip, tar or whatever variant having something that can be > run out of the box!. > > It is - also - the 'easy to run as is' that drives the success of > adoption. Look at the success of products like ActiveMQ, Directory, Httpd, > Studio, Tomcat, and many more under the umbrella of the ASF and > elsewhere... Easy to run OOTB is key in this. Ease of use for first timers > creates buzz, validates the reasons why contributors participate in the > project. And yes, easy to extend help as much too. > > It is not the 'go download, configure, read documents (or in our project: > filter through 1000s of email postings and out-of-date wiki pages), etc. > etc. first to run it' that drives first time adopters, to see the success > of the product, like we (the project) see it. It drives first timers away, > because to difficult, community not participating enough... > > The various projects (including the one of which I am a part of PMC) ensure > that the person downloading their product can have a one-click (entering a > single statement through the cli) running product. Just 1 click/ statement, > a bit of waiting and go use! (I would even go as far as in saying: the > majority of projects of the ASF work towards providing that 1-click > experience). > > Can this project provide that experience? Yes it can! But it requires > volunteers willing to work towards that goal. After all, it's about > scratching one's own itch, right? For the benefit of the first timer, the > returning adopter, the project, this community and everyone participating > in it. > > Now, having a product mature enough to be able to provide it to the > intended audience (first timers in this case, not the the existing adopters > who want to explore new stuff in the release in their own environment with > their own data - although that is relatively easy to configure) requires a > few extra steps: > > 1. create the binary package aka the zip file (build tools are used for > that...) > 2. sign the zip > 3. make it available somewhere > > We have done so with every release in the past (and I thank Jacopo for each > time he has taken that burden upon himself), expressing our confidence in > the product as it was at that time. Having each time our moment to generate > buzz. > Now, we didn't deliver a 1 click experience, but what we provided OOTB was > easy enough. And the community willing to help that new first timer. > Through answers to questions posted. Some even wrote books about it. All > acceptable. Nobody ever complained (AFAICT). > > So, back to the question: Should we generate binary packages aka zip files > of our source releases as a convenience to our potential and existing > adopters? > > Yes, we should! Each time we have a release! Each time this moment of > celebration has arrived! I provided some arguments above. I feel confident > there are enough +1 arguments one can image on this that outweigh the -1 > arguments. > > It won't hurt our audience. It won't hurt the volunteer taking the extra > step. It won't hurt the project or this community. > > In the previous postings I read arguments like 'it requires additional > downloads, etc.' as one of the main reasons not to do these zips. I say: > the build process takes care of this for that 1st time experience, and can > take care of that 1-click experience. The product contains enough to extend > that (and the project provides more than just that release) for those who > want more. > > There are 2 things I see - with respect to that 1-click/1-statement > experience - that are missing: > > 1. download of the external library that is required to facilitate the > experience > 2. incomplete cleanup process. > > It seems to me these omissions can be fixed easily before our next release. > > FWIW, issue OFBIZ-7783 <https://issues.apache.org/jira/browse/OFBIZ-7783> > can > be regarded as part of a 1-click experience. > > Best regards, > > > > > > > > > > > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Thu, Aug 25, 2016 at 1:31 PM, Jacques Le Roux < > [hidden email]> wrote: > > > Le 25/08/2016 à 13:16, Taher Alkhateeb a écrit : > > > >> Glad you got the workarounds docs :) > >> > >> What do you mean by "your servers cannot connect to the Internet (but > >> Internet can connect to them)"? Is that a DMZ, .iptables, port blocking, > >> or > >> what exactly? Sounds like what you're saying is not (no internet) but > >> certain custom firewall / network settings > >> > > > > Oh, they have clever enough engineers there to put you enough sticks in > > your wheels, believe me ;) > > > > Eg: working with a PayPal sandbox w/o a browser installed on the test > > server and no global Internet access (but specific dispensation, ie > indeed > > I guess several layers of .iptables, I mean several layers of servers > with > > of course also firewalls and such) > > > > Jacques > > > |
Re: Should we do binary releases?
|
|
Hi all, Taher,
That some projects are sporting convenience downloads for their potential adopters (even if the project is as young as 3 months old) goes to show how mature they are with respect to them (the adopters) an optimal experience. I applaud them. Our project is nearing its 10th aniverisary as a TLP. We should continue what we have done before with our releases.. './gradlew loadDefault ofbiz' is not providing a 1-statement experience ( are we not forgetting the additional 'cleanAll', but who is counting) './ofbiz start' is. <-- nice brand recognition/strengthening, by the way. And why should we consider loading the demo dataset as ready to run OOTB. If adopters want to experience how OFBiz is with demo data, we can redirect them to our demo sites. This project does its utmost (thank you, Jacques) provide that experience. Ready OOTB consists of making everything needed available to the user to start OFBiz and use as defined, but nothing more. That doesn't mean including the demo dataset. The seed and seed-initial datasets are enough for that. Creating the 1-statement experience(./ofbiz start) entails that the command does everything needed (check build, and build if ofbiz.jar is not available, load data and start) so that the adopter can go to the provided localhost url in his browser and see that it working and start using it. And with respect to configuration thereafter: the project has done everything to make that experience as pleasant/least complex as possible: it provides an excellent set of functions to upload configuration data files and/or single record adjustment in the webtools component. Every component (even accounting) consist of functions to work with them as intended. Comparing OFBiz to HTTPD or Tomcat is not like comparing apples and oranges: Run their defaults and what you get is the following out of the box: - Apache HTTPD: https://assets.digitalocean.com/articles/lamp_1404/default_apache.png - Apache Tomcat: https://assets.digitalocean.com/articles/tomcat8_1604/splashscreen.png With those products also, more needs to be done afterwards to have them working as desired. Same thing there. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Fri, Aug 26, 2016 at 11:04 AM, Taher Alkhateeb < [hidden email]> wrote: > Hi Pierre, Everyone > > This was a long post, but I'll try to summarize your points to reply to > them: > > 1- Projects provide these convenience downloads as a sign of maturity > 2- The binary package provide an easy to run product which drives adoption > with a "Just 1 click/ statement," > 3- Other ASF projects have high adoption because of these packages like > httpd and tomcat > > So in reply: > > 1- Some projects are less than 3 months old with binary packages. That is > not a sign of maturity, it's just a convenience download. There are > countless examples in Github > 2- What is so difficult with ./gradlew loadDefault ofbiz? That is all you > need to run the system. Oh and by the way, you still need to install Java > right? You need to install Java whether it is a binary release or not. > Someone with enough experience to download and install Java would probably > be able to type ./gradlew loadDefault ofbiz in the command line. > Furthermore, you cannot really use OFBiz OOTB right now can you? The > accounting component needs configuring, the demo data needs to be removed, > and almost every component needs tweaking to make it work for your > business. This is much, much more complex and difficult than ./gradlew > loadDefault ofbiz > 3- You are comparing oranges and apples. Tomcat and httpd for example are > web servers. They are things you just want to run and don't care much about > (at least as a beginner) because what you care about is deploying YOUR web > application on it. With OFBiz the story is different, this is a complex ERP > system that does not just work OOTB (see my comments above). > > If anything, the only thing I would do with each release is to perhaps zip > or tar the source and that's it. Then every user would download it, unzip, > ./gradlew loadDefault ofbiz ... Done! > > Regards, > > Taher Alkhateeb > > > On Thu, Aug 25, 2016 at 9:04 PM, Pierre Smits <[hidden email]> > wrote: > > > Before I answer the question that Jacques raised ( rephrased into: Should > > we generate binary packages aka zip files of our source releases as a > > convenience to our potential and existing adopters?), I will give my take > > on why I believe projects do provide those to the broader audience. > > > > Projects provide these convenience downloads as a sign of maturity (of > the > > code), as a statement (at that moment in time) of confidence to be able > to > > say: 'if you run this -as is- you can use it for what we say you can use > it > > for, as a means to promote the project and it's project as with each > > release there is something new to talk about. Each release, conveniently > > packaged into a zip, tar or whatever variant having something that can be > > run out of the box!. > > > > It is - also - the 'easy to run as is' that drives the success of > > adoption. Look at the success of products like ActiveMQ, Directory, > Httpd, > > Studio, Tomcat, and many more under the umbrella of the ASF and > > elsewhere... Easy to run OOTB is key in this. Ease of use for first > timers > > creates buzz, validates the reasons why contributors participate in the > > project. And yes, easy to extend help as much too. > > > > It is not the 'go download, configure, read documents (or in our project: > > filter through 1000s of email postings and out-of-date wiki pages), etc. > > etc. first to run it' that drives first time adopters, to see the success > > of the product, like we (the project) see it. It drives first timers > away, > > because to difficult, community not participating enough... > > > > The various projects (including the one of which I am a part of PMC) > ensure > > that the person downloading their product can have a one-click (entering > a > > single statement through the cli) running product. Just 1 click/ > statement, > > a bit of waiting and go use! (I would even go as far as in saying: the > > majority of projects of the ASF work towards providing that 1-click > > experience). > > > > Can this project provide that experience? Yes it can! But it requires > > volunteers willing to work towards that goal. After all, it's about > > scratching one's own itch, right? For the benefit of the first timer, the > > returning adopter, the project, this community and everyone participating > > in it. > > > > Now, having a product mature enough to be able to provide it to the > > intended audience (first timers in this case, not the the existing > adopters > > who want to explore new stuff in the release in their own environment > with > > their own data - although that is relatively easy to configure) requires > a > > few extra steps: > > > > 1. create the binary package aka the zip file (build tools are used > for > > that...) > > 2. sign the zip > > 3. make it available somewhere > > > > We have done so with every release in the past (and I thank Jacopo for > each > > time he has taken that burden upon himself), expressing our confidence in > > the product as it was at that time. Having each time our moment to > generate > > buzz. > > Now, we didn't deliver a 1 click experience, but what we provided OOTB > was > > easy enough. And the community willing to help that new first timer. > > Through answers to questions posted. Some even wrote books about it. All > > acceptable. Nobody ever complained (AFAICT). > > > > So, back to the question: Should we generate binary packages aka zip > files > > of our source releases as a convenience to our potential and existing > > adopters? > > > > Yes, we should! Each time we have a release! Each time this moment of > > celebration has arrived! I provided some arguments above. I feel > confident > > there are enough +1 arguments one can image on this that outweigh the -1 > > arguments. > > > > It won't hurt our audience. It won't hurt the volunteer taking the extra > > step. It won't hurt the project or this community. > > > > In the previous postings I read arguments like 'it requires additional > > downloads, etc.' as one of the main reasons not to do these zips. I say: > > the build process takes care of this for that 1st time experience, and > can > > take care of that 1-click experience. The product contains enough to > extend > > that (and the project provides more than just that release) for those who > > want more. > > > > There are 2 things I see - with respect to that 1-click/1-statement > > experience - that are missing: > > > > 1. download of the external library that is required to facilitate the > > experience > > 2. incomplete cleanup process. > > > > It seems to me these omissions can be fixed easily before our next > release. > > > > FWIW, issue OFBIZ-7783 <https://issues.apache.org/jira/browse/OFBIZ-7783 > > > > can > > be regarded as part of a 1-click experience. > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > Pierre Smits > > > > ORRTIZ.COM <http://www.orrtiz.com> > > OFBiz based solutions & services > > > > OFBiz Extensions Marketplace > > http://oem.ofbizci.net/oci-2/ > > > > On Thu, Aug 25, 2016 at 1:31 PM, Jacques Le Roux < > > [hidden email]> wrote: > > > > > Le 25/08/2016 à 13:16, Taher Alkhateeb a écrit : > > > > > >> Glad you got the workarounds docs :) > > >> > > >> What do you mean by "your servers cannot connect to the Internet (but > > >> Internet can connect to them)"? Is that a DMZ, .iptables, port > blocking, > > >> or > > >> what exactly? Sounds like what you're saying is not (no internet) but > > >> certain custom firewall / network settings > > >> > > > > > > Oh, they have clever enough engineers there to put you enough sticks in > > > your wheels, believe me ;) > > > > > > Eg: working with a PayPal sandbox w/o a browser installed on the test > > > server and no global Internet access (but specific dispensation, ie > > indeed > > > I guess several layers of .iptables, I mean several layers of servers > > with > > > of course also firewalls and such) > > > > > > Jacques > > > > > > |
Re: Should we do binary releases?
|
Administrator
|
In reply to this post by Nicolas Malin-2
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\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 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,_and_compliance >> >> Jacques >> >>> >>> Regards, >>> >>> Taher Alkhateeb >>> >>> On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < >>> [hidden email]> 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 < >>>>> [hidden email]> 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 >>>>>> [hidden email]%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 < >>>>>>> [hidden email]> 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/resolved.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 < >>>>>>>>> [hidden email]> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> >> > > |
|
|
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" <[hidden email]> 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 < >>>> [hidden email]> 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 < >>>>>> [hidden email]> 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 >>>>>>> [hidden email]%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 < >>>>>>>> [hidden email]> 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 < >>>>>>>>>> [hidden email]> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> >>> >> >> > |
Re: Should we do binary releases?
|
Administrator
|
Done
Jacques Le 30/08/2016 à 08:09, Taher Alkhateeb a écrit : > 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" <[hidden email]> > 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 < >>>>> [hidden email]> 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 < >>>>>>> [hidden email]> 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 >>>>>>>> [hidden email]%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 < >>>>>>>>> [hidden email]> 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 < >>>>>>>>>>> [hidden email]> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>> >>> |
LoadDefault vs LoadDemo was [Re: Should we do binary releases?]
|
Administrator
|
In reply to this post by Pierre Smits
Hi Pierre,
You did not get a clear answer about LoadDefault here. Actually I think you got at least one from Taher elsewhere but I miss it. Anyway, I answer only to this part ("LoadDefault vs LoadDemo") inline below. Le 26/08/2016 à 18:27, Pierre Smits a écrit : > [snip] > Why should we consider loading the demo dataset as ready to run OOTB. > If adopters want to experience how OFBiz is with demo data, we can redirect > them to our demo sites. Or locally they would use a new loadDemo (currently named loadDefault) > Ready OOTB consists of making everything needed available to the user to > start OFBiz and use as defined, but nothing more. That doesn't mean > including the demo dataset. The seed and seed-initial datasets are enough > for that. We would have the new LoadDefault doing, as documented in build.gradle: #### load ext data Load seed, seed-initial and ext data; meant for manual/generic testing, development, or going into production with a derived system based on stock OFBiz where the ext data basically replaces the demo data `gradlew "ofbiz --load-data readers=seed,seed-initial,ext"` So users could possibly and *initially* add their ext data. This new LoadDefault target should be used *once*, because of *seed-initial* The old LoadDefault would be renamed LoadDemo Note that when using this new LoadDefault the ecommerce application would not work OOTB (no product store) For the backend I think a default could be to get into the setup webapp, but this component would need more work, and more work is needed anyway For instance an admin (or a prividleged user) is necessary to get into the backend (AFAIK only the system user created with seed data but w/o password). It could be created within a start task as suggest below. This start task eventually calling the ofbiz task. > Creating the 1-statement experience(./ofbiz start) entails that the command > does everything needed (check build, and build if ofbiz.jar is not > available, load data and start) so that the adopter can go to the provided > localhost url in his browser and see that it working and start using it. Most new users would indeed appreciate that but would also feel frustrated compared to what is currently recommended at http://ofbiz.apache.org/download.html So we would need to simply but clearly explain the 2 options there (and in readme, etc.) > And with respect to configuration thereafter: the project has done > everything to make that experience as pleasant/least complex as possible: > it provides an excellent set of functions to upload configuration data > files and/or single record adjustment in the webtools component. Every > component (even accounting) consist of functions to work with them as > intended. > > Comparing OFBiz to HTTPD or Tomcat is not like comparing apples and oranges: > Run their defaults and what you get is the following out of the box: > > - Apache HTTPD: > https://assets.digitalocean.com/articles/lamp_1404/default_apache.png > - Apache Tomcat: > https://assets.digitalocean.com/articles/tomcat8_1604/splashscreen.png > > With those products also, more needs to be done afterwards to have them > working as desired. Same thing there. OFBiz is not the same than HTTPD or TOMCAT, it's (at least) one layer higher and that's what the demo data provide. I though agree the demo data does not provide a sufficient OOTB experience when you start working toward production, so loadDefault seems misnamed Jacques |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |