Re: [PROPOSAL] deprecate mini lang

[James Yong]

Hi Michael,

Okay, I didn't look at that page. Yes, it should be sufficient. Thanks.

Sincerely,
James

On 2017-05-08 16:54 (+0800), Michael Brohl  wrote: 
> 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  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

[Michael Brohl]

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






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] deprecate mini lang

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

[Michael Brohl]

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











smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] deprecate mini lang

[Michael Brohl]

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













smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] deprecate mini lang

[Michael Brohl]

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 
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
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] deprecate mini lang

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

Re: [PROPOSAL] deprecate mini lang

[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

[Jacopo Cappellato]

On Sat, Feb 18, 2017 at 10:17 AM, Michael Brohl 
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

Re: [PROPOSAL] deprecate mini lang

[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








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] deprecate mini lang

[Rishi Solanki]

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

Re: [PROPOSAL] deprecate mini lang

[Julien NICOLAS]

+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

Re: [PROPOSAL] deprecate mini lang

[Pranay Pandey]

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

Re: [PROPOSAL] deprecate mini lang

[Nicolas Malin]

+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

Re: [PROPOSAL] deprecate mini lang

[Swapnil Mane]

+1


- Best Regards,
Swapnil M Mane

On Sat, Feb 18, 2017 at 2:47 PM, 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
>
>
>
>

Re: [PROPOSAL] deprecate mini lang

[Shi Jinghai]

+1.


-邮件原件-
发件人: Michael Brohl [mailto:michael.br...@ecomify.de] 
发送时间: 2017年2月18日 17:17
收件人: dev@ofbiz.apache.org
主题: [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

Re: [PROPOSAL] deprecate mini lang

[gil portenseigne]

+1

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

Re: [PROPOSAL] deprecate mini lang

[Jacopo Cappellato]

+1

Thank you Michael for the well thought proposal.

Jacopo

On Sat, Feb 18, 2017 at 10:17 AM, 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
>
>
>
>

Re: [PROPOSAL] deprecate mini lang

[Vogelsme]

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



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/PROPOSAL-deprecate-mini-lang-tp4702545p4702632.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: [PROPOSAL] deprecate mini lang

[Michael Brohl]

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 
OFBiz based solutions & services

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

On Sat, Feb 18, 2017 at 12:16 PM, Paul Foxworthy 
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 <
jacques.le.r...@les7arts.com>
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" 
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 

Re: [PROPOSAL] deprecate mini lang

[Jacques Le Roux]

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 
OFBiz based solutions & services

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

On Sat, Feb 18, 2017 at 12:16 PM, Paul Foxworthy 
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 <
jacques.le.r...@les7arts.com>
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" 
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 

Re: [PROPOSAL] deprecate mini lang

[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 
OFBiz based solutions & services

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

On Sat, Feb 18, 2017 at 12:16 PM, Paul Foxworthy 
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 <
> jacques.le.r...@les7arts.com>
> 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" 
> >> 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 

Re: [PROPOSAL] deprecate mini lang

[Paul Foxworthy]

+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 
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" 
>> 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: i...@coherentsoftware.com.au

Re: [PROPOSAL] deprecate mini lang

[Jacques Le Roux]

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

Re: [PROPOSAL] deprecate mini lang

[Taher Alkhateeb]

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