Taher raises a good point when he mentioned an adopter being sophisticated enough, as it leads back to one of the most basic questions: for whom is OFBiz intended?
Is the message to our adopters: 'Don't use our product if you're not sophisticated (or qualified) enough, as we don't want to provide you with some basic scripts that facilitate you'? I guess that was never the intent. But I welcome a shared agreement on that matter, as this clears up the confusion who it is this projects wants to have as adopters of the product or as contributors. When we have a clear answer to that aspect, we can clear this discussion very easy. When it is 'we only want those who meet the onboarding criteria (and I do trust you will then define explicitly what they are)', then we don't need to have these kind of discussions and any issue that doesn't make the cut can be closed. When it is 'we welcome all kinds of adopters and contributors', it is my believe that we should build in hurdles down the line (in code, or what qualifies as an issue or a discussion), but we should adhere more to that intent. So basically, the scripts to create tenants or components the gradle way is a degradation in service. Something that worked and was testable in ant. And now we are told: we shouldn't because it is difficult to test. Or, because it another 'feature' obscures something. Perhaps those who are implementing the gradle scripts are having a problem with looking beyond the obvious, and the only thing they see is: gradle, gradle and gradle. And anything else is wrong. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Sun, Jul 10, 2016 at 1:42 PM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > Hi Jacques and all, > > Michael makes a good point. It is not a very good practice to have user > input in build scripts. > > Now, it is easy to create such tasks, and you can even make the input from > a full GUI application if you want to using swing. But the time and effort > to put into these tasks is not worth it for multiple reasons: > > 1- You cannot automate it > 2- The command prompt would have some issues because the gradle status bar > (at the bottom with progress %) might obscure it > 3- It is harder to test > 4- It blocks! now remember Gradle is a multi-process system. It can execute > tasks in parallel increasing efficiency and throughput. What happens if you > mix commands together? This complicates matters > 5- Many other tasks require flags which did not have user input. Take for > example the data loading tasks and the integration testing tasks. > > If someone is sophisticated enough to create a new component or a new > tenant in the system I doubt they would need THAT much hand-holding. > Furthermore, everything is thoroughly documented in README.md that it would > take less than a few seconds to copy paste the command and change the flags > to your liking. > > Regards, > > Taher Alkhateeb > > On Sun, Jul 10, 2016 at 2:04 PM, Michael Brohl <michael.br...@ecomify.de> > wrote: > > > Hi Jacques, > > > > I think builds should work without interaction on the command line, which > > makes automation difficult and is less error prone. > > > > I think it is sufficient to provide the functionality with task > > parameters. If one wants interactive wizards, he could provide some for > the > > project. > > > > Regards, > > > > Michael Brohl > > ecomify GmbH > > www.ecomify.de > > > > > > Am 10.07.16 um 12:48 schrieb Jacques Le Roux: > > > > Hi, > >> > >> See https://issues.apache.org/jira/browse/OFBIZ-7773 and > >> https://issues.apache.org/jira/browse/OFBIZ-7772 > >> > >> Opinions (about the question in title: "Should we?") > >> > >> Thanks > >> > >> Jacques > >> > >> > > > > >
