[PROPOSAL] deprecate mini lang
Locked
12
12
Re: [PROPOSAL] deprecate mini lang
 
|
Good idea, thanks Taher!
Cheers, Michael Am 29.03.17 um 19:47 schrieb Taher Alkhateeb: > +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 <[hidden email]> > 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 >>> >>> >>> >>> >> |
smime.p7s (5K)
Re: [PROPOSAL] deprecate mini lang
|
|
In reply to this post by Jacques Le Roux
Thanks for the reference, Jacques.
Am 29.03.17 um 18:12 schrieb Jacques Le Roux: > +1 > > For those interested, thanks to Jacopo, we have already a beginning of > a Groovy DSL > > https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic > > https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide > > https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions > > Jacques > > > Le 29/03/2017 à 17:12, Michael Brohl a écrit : >> 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 >>> >>> >>> >> >> > |
Re: [PROPOSAL] deprecate mini lang
|
|
In reply to this post by Michael Brohl-3
Dear all,
just an update for this topic. I have created a Jira issue to track the efforts. [1] 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! 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: > 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 >> >> >> > > |
Re: [PROPOSAL] deprecate mini lang
|
|
Re: [PROPOSAL] deprecate mini lang
|
|
Hi James,
thanks for your suggestion. That's exactly what I did in [1], which pops up a warning. Don't you think it is sufficient? Best regards, Michael [1] https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference Am 08.05.17 um 05:34 schrieb James Yong: > Hi all, > > Since this will be an on-going effort, it would be useful to post the links, mentioned below, on the confluence header (together with the notice "Access to add and change pages is restricted"). > Will help to remind both user and developer groups using confluence. > Don't want to see new users spending time contributing minilang patches, and then be told to convert to java code. > My 2 cents opinion. Thanks. > > Regards, > James Yong > > > On 2017-05-08 03:16 (+0800), Michael Brohl <[hidden email]> wrote: >> Dear all, >> >> just an update for this topic. >> >> I have created a Jira issue to track the efforts. [1] >> >> 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! >> >> Thanks and regards, >> >> Michael >> >> >> [1] https://issues.apache.org/jira/browse/OFBIZ-9350 >> >> [2] https://cwiki.apache.org/confluence/display/OFBIZ/Mini+Lang+Deprecation >> |
Re: [PROPOSAL] deprecate mini lang
|
|
| Free forum by Nabble | Edit this page |