+1 I recommend that you put somewhere in the wiki page the _reasons_ why minilang is deprecated (the ones you listed in this thread).
On Wed, Mar 29, 2017 at 6:12 PM, Michael Brohl <michael.br...@ecomify.de> wrote: > Hi all, > > thank you for your replies and comments to the proposal to deprecate > minilang in OFBiz. > > We had mostly +1's, some questions and remarks and no -1's. It was not an > official vote but I think we can take these results as a confirmation that > the community wants to follow the proposal, right? > > If there are any objections, please speak up now. I will wait for another > 5 days and if there are no objections I will apply lazy consensus and take > the next steps which would be: > > 1. create a Wiki page for the documentation and description of the > migration process and how mini lang will be replaced. > > 2. prominently state in the Wiki that minilang will be deprecated, e.g. in > [1] > > 3. put deprecation tags in the corresponding code > > 4. kindly ask contributors with open patches written in mini lang to > replace them by Java code [2] > > 5. start an initiative to replace existing mini lang code with Java code > where applicable. This needs some more planning and discussion which parts > we'll like to replace with Java code and which parts will better be > replaced by some kind of DSL (which we have to create first). > > Any other important steps you would see to get the initiative started? > Looking forward to you suggestions. > > Thanks and regards, > > Michael > > > [1] https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+ > Language+-+minilang+-+simple-method+-+Reference > > [2] does anyone know a way to batch comment Jira issues like it is > possible in Redmine? > > > Am 18.02.17 um 10:17 schrieb Michael Brohl: > > Hi everyone, >> >> we are currently working hard to make OFBiz a modern, quality, robust and >> easy to use framework. >> There are several ongoing initiatives like refactoring the core, UX, >> changing the build and plugin system and cleaning up the javadocs, only to >> mention a few. >> >> In mini lang I see another part of our project which needs a >> refactoring/change. Here are some reasons: >> >> - Programming in XML is hard to deal with when it comes to refactoring. >> >> - The "code" cannot be debugged and is hard to review and maintain. >> >> - It is slower because of the overhead of parsing and processing XML >> documents >> >> - It is highly verbose, even so more than Java! >> >> - It is difficult to reason about because everything appears as a string >> (variables, maps, objects, etc ...) which makes it very difficult to know >> where something was declared or modified >> >> - It is highly error prone and brittle (again due to string declarations) >> >> - It is not a full programming language (unlike groovy, or any other >> language that supports a DSL). Thus it has many limitations that forces the >> developer to write many more lines of code to achieve the same result. >> >> - The code is not reusable (limitation of the DSL) >> >> - The code is not composable (limitation of the DSL) >> >> - Minilang depends on a lot of Java constructs (implementations, not >> interfaces) that require refactoring, making any improvements to the core >> API more challenging >> >> - Minilang is used inconsistently (different DSL in widgets, services and >> entities). Hence, we need to keep only a minimal DSL to declare things only. >> >> >> We already have Java based implementations for services and events and >> there are ideas to implement a Groovy DSL which can be used as easy (or >> easier) as mini lang and does not have the above mentioned flaws. >> >> I therefore like to propose to deprecate the mini lang implementation >> which means: >> >> 1. there will be no new implementations based on mini lang accepted to go >> into the code base. >> >> 2. mini lang and mini lang code will be maintained with bug and security >> fixes for backwards compatibility and to support existing adopters relying >> on mini lang. >> There will be no new features though. >> >> 3. we will continously replace the mini lang implementations with Java >> and/or Groovy code. This will be another good opportunity for contributors >> to engage in the project. >> >> >> This will certainly be a longer process and we will not stop support for >> mini lang but I think we should avoid to add more mini lang implementations >> to the project. >> >> What do you think? >> >> Regards, >> >> Michael >> >> >> >> > >
