As a general rule, minilang adds to the technical debt of this project. It is hard to understand or maintain even simple constructs in minilang.
To generalize this concept... Patch != Good patch. So I recommend that everything goes through the funnel of good old reviews. Good code has no shortcuts, it is blood sweat and tears both for the provider and the reviewer of patches. On Mon, Jun 3, 2019, 4:20 PM Michael Brohl <michael.br...@ecomify.de> wrote: > I explained my POV in the Jira [1]. > > Why not encourage the contributors to move their minilang tests to > Groovy code? I can see that this has already been done, e.g. here [2] > (thanks everyone involved!). > > I'm sure that the remaining patches will get converted soon, no need to > choose the "easy way" and commit the minilang versions. > > If we will allow more minilang commits, we will always have the > discussion and won't ever get rid of it. > > Thanks, > > Michael > > [1] https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-1463 > > [2] https://issues.apache.org/jira/browse/OFBIZ-9002 > > > > Am 03.06.19 um 13:21 schrieb Jacques Le Roux: > > OK if this is a veto, no need to continue the discussion.- > > > > Else could you explain your POV Michael, notably about missing to put > > in some new tests that could be helpful in the meantime? > > > > Thanks > > > > Le 02/06/2019 à 21:27, Michael Brohl a écrit : > >> -1 to introduce more minilang code to the codebase. New code should > >> be provided in either Java or Groovy code. > >> > >> Thanks, > >> Michael > >> > >> > >> > >>> Am 02.06.2019 um 12:56 schrieb Jacques Le Roux > >>> <jacques.le.r...@les7arts.com>: > >>> > >>> Hi All, > >>> > >>> We started a discussion in OFBIZ-1463 about committing or not the > >>> Minilang test patches. > >>> > >>> There are already few mixed opinions there (Michael, Aditya, Suraj > >>> and I). > >>> > >>> Before voting I'd like to know if we can come to a consensus. > >>> > >>> Please read in OFBIZ-1463 and come back with your opinion. > >>> > >>> I have just changed mine because I believe using the tests as soon > >>> they are reading is a good thing. > >>> > >>> Waiting would be a waste of not only work done but also time for > >>> code safety. We can still move them to Groovy later, it's not more > >>> work, I guess it's > >>> even less. > >>> > >>> Jacques > >>> > >> > >
