Re: [PROPOSAL] deprecate mini lang

[Michael Brohl]

Dear all,

just an update for this topic.

I have created a Jira issue to track the efforts. [1]





Thanks and regards,

Michael


[1] https://issues.apache.org/jira/browse/OFBIZ-9350

[2] https://cwiki.apache.org/confluence/display/OFBIZ/Mini+Lang+Deprecation

Am 29.03.17 um 17:12 schrieb Michael Brohl:

A first version of the corresponding wiki page to document the rationale and next steps is now in Confluence. [2] If you want to contribute, please drop me a line. Any help for the next steps is appreciated!

Hi all,











3. put deprecation tags in the corresponding code







Thanks and regards,

Michael

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] 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. [1] https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference

Am 18.02.17 um 10:17 schrieb Michael Brohl:

[2] does anyone know a way to batch comment Jira issues like it is possible in Redmine?

Hi everyone,





- 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 highly verbose, even so more than Java!







- The code is not reusable (limitation of the DSL)

- The code is not composable (limitation of the DSL)













   There will be no new features though.






What do you think?

Regards,

Michael

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: - It is slower because of the overhead of parsing and processing XML documents - 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. - 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. 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.

smime.p7s
Description: S/MIME Cryptographic Signature