OFBiz › OFBiz - Dev

[PROPOSAL] deprecate mini lang

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Michael Brohl-3

[PROPOSAL] deprecate mini lang

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) Download Attachment

taher

Re: [PROPOSAL] deprecate mini lang

+1

let's maintain but not add more to the pile, and try to replace everything
written in minilang with other languages over time. I think your arguments
and proposal are well founded and would really improve the health of this
project.

On Feb 18, 2017 12:17 PM, "Michael Brohl" <[hidden email]> wrote:

> 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
>
>
>
>

Jacques Le Roux

Re: [PROPOSAL] deprecate mini lang

Administrator

I agree with both of you.

The recent FinAccount deadlock issue reported on dev ML is one example of the type of issues which would be easier to deal with with a Turing complete
language or at least a better DSL.

My 2 cts

Jacques

Le 18/02/2017 à 10:25, Taher Alkhateeb a écrit :

> +1
>
> let's maintain but not add more to the pile, and try to replace everything
> written in minilang with other languages over time. I think your arguments
> and proposal are well founded and would really improve the health of this
> project.
>
> On Feb 18, 2017 12:17 PM, "Michael Brohl" <[hidden email]> wrote:
>
>> 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
>>
>>
>>
>>

Paul Foxworthy

Re: [PROPOSAL] deprecate mini lang

+1

I have wondered how hard it would be to create an isomorphic conversion
between minilang and a Groovy DSL - bidirectional conversion between the
two. That would mean we could automatically convert the existing minilang
to the DSL, and if there is anyone who prefers minilang, they could convert
in the other direction.

There would even be benefits if we just worked on generating an Abstract
Syntax Tree from minilang, which is then compiled to bytecode. That would
increase the performance of minilang code, and perhaps allow for debugging
it. It might be possible to verify that replacement DSL was doing the same
thing as existing minilang by comparing the ASTs (before we start
refactoring!).

Cheers

Paul Foxworthy

On 18 February 2017 at 21:45, Jacques Le Roux <[hidden email]>
wrote:

> I agree with both of you.
>
> The recent FinAccount deadlock issue reported on dev ML is one example of
> the type of issues which would be easier to deal with with a Turing
> complete language or at least a better DSL.
>
> My 2 cts
>
> Jacques
>
>
>
>
> Le 18/02/2017 à 10:25, Taher Alkhateeb a écrit :
>
>> +1
>>
>> let's maintain but not add more to the pile, and try to replace everything
>> written in minilang with other languages over time. I think your arguments
>> and proposal are well founded and would really improve the health of this
>> project.
>>
>> On Feb 18, 2017 12:17 PM, "Michael Brohl" <[hidden email]>
>> wrote:
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

Pierre Smits

Re: [PROPOSAL] deprecate mini lang

I am inclined to say +1.

But I see some concerns rising (with respect to some suggestions) with new
additions, e.g:

1. No more simple (entity-auto) services, ecas and secas in xml? Or only
no more complex ones? Do we opt for Java, Groovy, or leave that to the
discretion of each contributor?
2. No more screen, form and grid definitions, but instead everything in
Freemarker? Or something else?
3. No more ofbiz-component.xml, *Data.xml and *Label.xml? Into what do
we want these be refactored?

As implied elsewhere in this thread this refactoring will take a serious
amount of effort. Without a plan (probably a SMART one) this can go in any
direction (from just 'it is only a wish' to halted contributions). Clarity
up front will speed up conversion down the line.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Feb 18, 2017 at 12:16 PM, Paul Foxworthy <[hidden email]>
wrote:

> +1
>
> I have wondered how hard it would be to create an isomorphic conversion
> between minilang and a Groovy DSL - bidirectional conversion between the
> two. That would mean we could automatically convert the existing minilang
> to the DSL, and if there is anyone who prefers minilang, they could convert
> in the other direction.
>
> There would even be benefits if we just worked on generating an Abstract
> Syntax Tree from minilang, which is then compiled to bytecode. That would
> increase the performance of minilang code, and perhaps allow for debugging
> it. It might be possible to verify that replacement DSL was doing the same
> thing as existing minilang by comparing the ASTs (before we start
> refactoring!).
>
> Cheers
>
> Paul Foxworthy
>
>
>
> On 18 February 2017 at 21:45, Jacques Le Roux <
> [hidden email]>
> wrote:
>
> > I agree with both of you.
> >
> > The recent FinAccount deadlock issue reported on dev ML is one example of
> > the type of issues which would be easier to deal with with a Turing
> > complete language or at least a better DSL.
> >
> > My 2 cts
> >
> > Jacques
> >
> >
> >
> >
> > Le 18/02/2017 à 10:25, Taher Alkhateeb a écrit :
> >
> >> +1
> >>
> >> let's maintain but not add more to the pile, and try to replace
> everything
> >> written in minilang with other languages over time. I think your
> arguments
> >> and proposal are well founded and would really improve the health of
> this
> >> project.
> >>
> >> On Feb 18, 2017 12:17 PM, "Michael Brohl" <[hidden email]>
> >> wrote:
> >>
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: +61 3 9585 6788
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

Jacques Le Roux

Re: [PROPOSAL] deprecate mini lang

Administrator

Le 18/02/2017 à 13:12, Pierre Smits a écrit :
> I am inclined to say +1.
>
> But I see some concerns rising (with respect to some suggestions) with new
> additions, e.g:
>
> 1. No more simple (entity-auto) services, ecas and secas in xml? Or only
> no more complex ones? Do we opt for Java, Groovy, or leave that to the
> discretion of each contributor?

I did not see anything about (entity-auto) services, ecas and seca, only Minilang

> 2. No more screen, form and grid definitions, but instead everything in
> Freemarker? Or something else?

Surely not, Freemarker should be used only at last resort. We have to think about actions in widgets, but I see no problems with them for now.

> 3. No more ofbiz-component.xml, *Data.xml and *Label.xml? Into what do
> we want these be refactored?

Why would that change? It's not "[PROPOSAL] deprecate XML" only [PROPOSAL] deprecate mini lang

>
> As implied elsewhere in this thread this refactoring will take a serious
> amount of effort. Without a plan (probably a SMART one) this can go in any
> direction (from just 'it is only a wish' to halted contributions). Clarity
> up front will speed up conversion down the line.

Paul's proposition is the ultimate (and would be glorious) one. I guess we can find a way in the middle in the meantime...

Jacques

>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sat, Feb 18, 2017 at 12:16 PM, Paul Foxworthy <[hidden email]>
> wrote:
>
>> +1
>>
>> I have wondered how hard it would be to create an isomorphic conversion
>> between minilang and a Groovy DSL - bidirectional conversion between the
>> two. That would mean we could automatically convert the existing minilang
>> to the DSL, and if there is anyone who prefers minilang, they could convert
>> in the other direction.
>>
>> There would even be benefits if we just worked on generating an Abstract
>> Syntax Tree from minilang, which is then compiled to bytecode. That would
>> increase the performance of minilang code, and perhaps allow for debugging
>> it. It might be possible to verify that replacement DSL was doing the same
>> thing as existing minilang by comparing the ASTs (before we start
>> refactoring!).
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>>
>> On 18 February 2017 at 21:45, Jacques Le Roux <
>> [hidden email]>
>> wrote:
>>
>>> I agree with both of you.
>>>
>>> The recent FinAccount deadlock issue reported on dev ML is one example of
>>> the type of issues which would be easier to deal with with a Turing
>>> complete language or at least a better DSL.
>>>
>>> My 2 cts
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>> Le 18/02/2017 à 10:25, Taher Alkhateeb a écrit :
>>>
>>>> +1
>>>>
>>>> let's maintain but not add more to the pile, and try to replace
>> everything
>>>> written in minilang with other languages over time. I think your
>> arguments
>>>> and proposal are well founded and would really improve the health of
>> this
>>>> project.
>>>>
>>>> On Feb 18, 2017 12:17 PM, "Michael Brohl" <[hidden email]>
>>>> wrote:
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Australia
>>
>> Phone: +61 3 9585 6788
>> Web: http://www.coherentsoftware.com.au/
>> Email: [hidden email]
>>

Michael Brohl-3

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Pierre Smits

Hi Pierre,

my proposal was to deprecate mini lang, not to drop xml based
definitions and configurations as a whole.

Regards,

Michael

Am 18.02.17 um 13:12 schrieb Pierre Smits:

> I am inclined to say +1.
>
> But I see some concerns rising (with respect to some suggestions) with new
> additions, e.g:
>
> 1. No more simple (entity-auto) services, ecas and secas in xml? Or only
> no more complex ones? Do we opt for Java, Groovy, or leave that to the
> discretion of each contributor?
> 2. No more screen, form and grid definitions, but instead everything in
> Freemarker? Or something else?
> 3. No more ofbiz-component.xml, *Data.xml and *Label.xml? Into what do
> we want these be refactored?
>
> As implied elsewhere in this thread this refactoring will take a serious
> amount of effort. Without a plan (probably a SMART one) this can go in any
> direction (from just 'it is only a wish' to halted contributions). Clarity
> up front will speed up conversion down the line.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sat, Feb 18, 2017 at 12:16 PM, Paul Foxworthy <[hidden email]>
> wrote:
>
>> +1
>>
>> I have wondered how hard it would be to create an isomorphic conversion
>> between minilang and a Groovy DSL - bidirectional conversion between the
>> two. That would mean we could automatically convert the existing minilang
>> to the DSL, and if there is anyone who prefers minilang, they could convert
>> in the other direction.
>>
>> There would even be benefits if we just worked on generating an Abstract
>> Syntax Tree from minilang, which is then compiled to bytecode. That would
>> increase the performance of minilang code, and perhaps allow for debugging
>> it. It might be possible to verify that replacement DSL was doing the same
>> thing as existing minilang by comparing the ASTs (before we start
>> refactoring!).
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>>
>> On 18 February 2017 at 21:45, Jacques Le Roux <
>> [hidden email]>
>> wrote:
>>
>>> I agree with both of you.
>>>
>>> The recent FinAccount deadlock issue reported on dev ML is one example of
>>> the type of issues which would be easier to deal with with a Turing
>>> complete language or at least a better DSL.
>>>
>>> My 2 cts
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>> Le 18/02/2017 à 10:25, Taher Alkhateeb a écrit :
>>>
>>>> +1
>>>>
>>>> let's maintain but not add more to the pile, and try to replace
>> everything
>>>> written in minilang with other languages over time. I think your
>> arguments
>>>> and proposal are well founded and would really improve the health of
>> this
>>>> project.
>>>>
>>>> On Feb 18, 2017 12:17 PM, "Michael Brohl" <[hidden email]>
>>>> wrote:
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Australia
>>
>> Phone: +61 3 9585 6788
>> Web: http://www.coherentsoftware.com.au/
>> Email: [hidden email]
>>

smime.p7s (5K) Download Attachment

Vogelsme

Re: [PROPOSAL] deprecate mini lang

+1

I've been waiting for this since about 4 years ;)
Debugging was always a pain and apart from simple "update my entity" services I did never see a big advantage in this. Apart from that it was always a barrier for pleople new to OFBiz.

Jacopo Cappellato-5

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

+1

Thank you Michael for the well thought proposal.

Jacopo

On Sat, Feb 18, 2017 at 10:17 AM, Michael Brohl <[hidden email]>
wrote:

Gil Portenseigne

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

Thanks Michael for the proposal ! I've got nothing to add to your mail ;) !

Gil

On 18/02/2017 10:17, Michael Brohl wrote:

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

Shi Jinghai-3

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

+1.

-----邮件原件-----
发件人: Michael Brohl [mailto:[hidden email]]
发送时间: 2017年2月18日 17:17
收件人: [hidden email]
主题: [PROPOSAL] deprecate mini lang

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

Swapnil Mane

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

+1

- Best Regards,
Swapnil M Mane

On Sat, Feb 18, 2017 at 2:47 PM, Michael Brohl <[hidden email]>
wrote:

Nicolas Malin-2

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

+1

I also agree to replace the minilang by groovy dsl for service.

For screen a prefer wait a good equivalent solution for simple case.

Nicolas

Le 18/02/2017 à 10:17, Michael Brohl a écrit :

> 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
>
>
>

Pranay Pandey-3

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

+1

Thanks for the well thought proposal.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Sat, Feb 18, 2017 at 2:47 PM, Michael Brohl <[hidden email]>
wrote:

Julien NICOLAS

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Nicolas Malin-2

+1

On 27/02/2017 13:44, Nicolas Malin wrote:

> +1
>
> I also agree to replace the minilang by groovy dsl for service.
>
> For screen a prefer wait a good equivalent solution for simple case.
>
> Nicolas
>
>
> Le 18/02/2017 à 10:17, Michael Brohl a écrit :
>> 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
>>
>>
>>
>
>

Rishi Solanki

Re: [PROPOSAL] deprecate mini lang

+1

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Tue, Feb 28, 2017 at 2:53 PM, Julien NICOLAS <[hidden email]>
wrote:

> +1
>
>
>
> On 27/02/2017 13:44, Nicolas Malin wrote:
>
>> +1
>>
>> I also agree to replace the minilang by groovy dsl for service.
>>
>> For screen a prefer wait a good equivalent solution for simple case.
>>
>> Nicolas
>>
>>
>> Le 18/02/2017 à 10:17, Michael Brohl a écrit :
>>
>>> 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
>>>
>>>
>>>
>>>
>>
>>
>

Michael Brohl-3

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

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:

smime.p7s (5K) Download Attachment

Jacopo Cappellato-5

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

On Sat, Feb 18, 2017 at 10:17 AM, Michael Brohl <[hidden email]>
wrote:

> [...]
> 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.
>
>

+1

Jacopo

Jacques Le Roux

Re: [PROPOSAL] deprecate mini lang

Administrator

In reply to this post by Michael Brohl-3

+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
>>
>>
>>
>
>

taher

Re: [PROPOSAL] deprecate mini lang

In reply to this post by Michael Brohl-3

+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
>>
>>
>>
>>
>
>