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 < slidingfilame...@gmail.com> 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 <pierre.sm...@gmail.com> > 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 < > > jacques.le.r...@les7arts.com> 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 > > > > > >
