Realistic lean Roadmap [was Ofbiz Cookbook]

[Jacques Le Roux]

Hi All,

I move and replace the "Ofbiz Cookbook" thread from the user ML since it concerns more developers

We need to have a very realistic lean Roadmap to agree on, follow and progress.

We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document by simply prioritize the goals, then pick up
them as they come and prioritize again now and then when needed.

We don't need to prioritize all tasks. Simply few that we put at top to really work on them as a team and then sort again once they are done.
For that I have already added in this order "Introduce a plugin system" and "Replace Minilang and widgets actions by a Groovy DSL"

Also I don't think we need to maintain lists of "interested" and "willing to help" people by goal. So I have removed this information. It's about
having a lean roadmap here, anybody can join at any moment. Rather links to Jira can help to find people interested.

I just removed the achieved or abandoned goals there:
Abandoned: Ivy integration (because of Gradle integration), Complete the support for VAT(WIP was removed)
Achieved: Solr integration

It simple and lean, what do you think?

Jacques


Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit :

> +1
>
> On Aug 13, 2016 10:18 AM, "gil portenseigne" <[hidden email]>
> wrote:
>
>> Yes i like this plan :)
>>
>> Gil
>>
>> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>>
>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>> finishing it, adding plugins, correctly documenting the whole) we should
>>> gather to work on this and slowly replace/improve the old good Minilang
>>>
>>> Could be the R17 main task?
>>>
>>> Jacques
>>>
>>>
>>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>>
>>>> +1
>>>>
>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>> configuration in IDE Integration part.
>>>>
>>>> Thanks
>>>>
>>>> Gil
>>>>
>>>>
>>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>>
>>>>> +1
>>>>>
>>>>> I think Jacopo has more to say about that :)
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>> DSL+for+OFBiz+business+logic
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>>
>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>> not
>>>>>> only difficult to debug but also overly verbose.
>>>>>>
>>>>>> However, minilang exists and continues to be used I think because of
>>>>>> the
>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>> statements.
>>>>>> This makes it a DSL (not too pretty) and this is something that we did
>>>>>> not
>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>> for an
>>>>>> alternative DSL but we don't have something yet which is
>>>>>> comprehensively
>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>> for
>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>
>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> I'm certainly no fan of minilang. I prefer something I can step through
>>>>>>> with a debugger.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> On 9/08/2016 20:55, "Paul Piper" <[hidden email]> wrote:
>>>>>>>
>>>>>>> Skip,
>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>> community,
>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>> standards. I
>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>
>>>>>>> though
>>>>>>>
>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>> entity-auto
>>>>>>>>
>>>>>>> for
>>>>>>>
>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>
>>>>>>> invest
>>>>>>>
>>>>>>>> the time into proper java or groovy code.
>>>>>>>>
>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>> we
>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>> of
>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>> are
>>>>>>>> defined by your theme. So if people prefer to use widgets, they can.
>>>>>>>> We
>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>> as not
>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>
>>>>>>>> That being said, our goal is to further replace widgets by ftl logic
>>>>>>>> as
>>>>>>>>
>>>>>>> we
>>>>>>>
>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>> that
>>>>>>>> neither technology is used anywhere outside of the ofbiz project and
>>>>>>>> thus
>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>> rely on
>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>

[taher]

Hi Jacques,

Would you kindly clarify the objective of the roadmap? What is the desired
goal and how does it help? I think it is important to understand that to
see if I would invest time and effort towards authoring the work.

Taher Alkhatteb

On Aug 17, 2016 6:48 PM, "Jacques Le Roux" <[hidden email]>
wrote:

> Hi All,
>
> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
> concerns more developers
>
> We need to have a very realistic lean Roadmap to agree on, follow and
> progress.
>
> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
> pick up them as they come and prioritize again now and then when needed.
>
> We don't need to prioritize all tasks. Simply few that we put at top to
> really work on them as a team and then sort again once they are done.
> For that I have already added in this order "Introduce a plugin system"
> and "Replace Minilang and widgets actions by a Groovy DSL"
>
> Also I don't think we need to maintain lists of "interested" and "willing
> to help" people by goal. So I have removed this information. It's about
> having a lean roadmap here, anybody can join at any moment. Rather links to
> Jira can help to find people interested.
>
> I just removed the achieved or abandoned goals there:
> Abandoned: Ivy integration (because of Gradle integration), Complete the
> support for VAT(WIP was removed)
> Achieved: Solr integration
>
> It simple and lean, what do you think?
>
> Jacques
>
>
> Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit :
>
>> +1
>>
>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <[hidden email]
>> >
>> wrote:
>>
>> Yes i like this plan :)
>>>
>>> Gil
>>>
>>> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>>>
>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>
>>>> Could be the R17 main task?
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>>>
>>>> +1
>>>>>
>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>> configuration in IDE Integration part.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Gil
>>>>>
>>>>>
>>>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>>>
>>>>> +1
>>>>>>
>>>>>> I think Jacopo has more to say about that :)
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>> DSL+for+OFBiz+business+logic
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>>>
>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>> not
>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>
>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>> the
>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>> statements.
>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>> did
>>>>>>> not
>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>> for an
>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>> comprehensively
>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>> for
>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>
>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>> [hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>> through
>>>>>>>
>>>>>>>> with a debugger.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Skip,
>>>>>>>>
>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>> community,
>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>> standards. I
>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>
>>>>>>>>> though
>>>>>>>>
>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>> entity-auto
>>>>>>>>>
>>>>>>>>> for
>>>>>>>>
>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>
>>>>>>>>> invest
>>>>>>>>
>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>
>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>> we
>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>> of
>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>> are
>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>> can.
>>>>>>>>> We
>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>> as not
>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>
>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>> logic
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>> we
>>>>>>>>
>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>> that
>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>> and
>>>>>>>>> thus
>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>> rely on
>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>

[Pierre Smits]

Is it in the right space? Where it is now, I would say it is a fest of
privileged contributors.

Best regards,

Pierre

On Wednesday, August 17, 2016, Jacques Le Roux <[hidden email]>
wrote:

> Hi All,
>
> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
> concerns more developers
>
> We need to have a very realistic lean Roadmap to agree on, follow and
> progress.
>
> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
> pick up them as they come and prioritize again now and then when needed.
>
> We don't need to prioritize all tasks. Simply few that we put at top to
> really work on them as a team and then sort again once they are done.
> For that I have already added in this order "Introduce a plugin system"
> and "Replace Minilang and widgets actions by a Groovy DSL"
>
> Also I don't think we need to maintain lists of "interested" and "willing
> to help" people by goal. So I have removed this information. It's about
> having a lean roadmap here, anybody can join at any moment. Rather links to
> Jira can help to find people interested.
>
> I just removed the achieved or abandoned goals there:
> Abandoned: Ivy integration (because of Gradle integration), Complete the
> support for VAT(WIP was removed)
> Achieved: Solr integration
>
> It simple and lean, what do you think?
>
> Jacques
>
>
> Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit :
>
>> +1
>>
>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <[hidden email]
>> >
>> wrote:
>>
>> Yes i like this plan :)
>>>
>>> Gil
>>>
>>> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>>>
>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>
>>>> Could be the R17 main task?
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>>>
>>>> +1
>>>>>
>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>> configuration in IDE Integration part.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Gil
>>>>>
>>>>>
>>>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>>>
>>>>> +1
>>>>>>
>>>>>> I think Jacopo has more to say about that :)
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>> DSL+for+OFBiz+business+logic
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>>>
>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>> not
>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>
>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>> the
>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>> statements.
>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>> did
>>>>>>> not
>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>> for an
>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>> comprehensively
>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>> for
>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>
>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>> [hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>> through
>>>>>>>
>>>>>>>> with a debugger.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Skip,
>>>>>>>>
>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>> community,
>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>> standards. I
>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>
>>>>>>>>> though
>>>>>>>>
>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>> entity-auto
>>>>>>>>>
>>>>>>>>> for
>>>>>>>>
>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>
>>>>>>>>> invest
>>>>>>>>
>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>
>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>> we
>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>> of
>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>> are
>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>> can.
>>>>>>>>> We
>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>> as not
>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>
>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>> logic
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>> we
>>>>>>>>
>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>> that
>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>> and
>>>>>>>>> thus
>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>> rely on
>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>

--
Pierre Smits

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

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

[Jacques Le Roux]

The idea is to focus team efforts on a small number of important goals rather than scatter energies on a lot of small goals

To stay focused we need a Roadmap, a simple and realistic one.

Jacques


Le 17/08/2016 à 19:05, Taher Alkhateeb a écrit :

> Hi Jacques,
>
> Would you kindly clarify the objective of the roadmap? What is the desired
> goal and how does it help? I think it is important to understand that to
> see if I would invest time and effort towards authoring the work.
>
> Taher Alkhatteb
>
> On Aug 17, 2016 6:48 PM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
>> Hi All,
>>
>> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
>> concerns more developers
>>
>> We need to have a very realistic lean Roadmap to agree on, follow and
>> progress.
>>
>> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
>> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
>> pick up them as they come and prioritize again now and then when needed.
>>
>> We don't need to prioritize all tasks. Simply few that we put at top to
>> really work on them as a team and then sort again once they are done.
>> For that I have already added in this order "Introduce a plugin system"
>> and "Replace Minilang and widgets actions by a Groovy DSL"
>>
>> Also I don't think we need to maintain lists of "interested" and "willing
>> to help" people by goal. So I have removed this information. It's about
>> having a lean roadmap here, anybody can join at any moment. Rather links to
>> Jira can help to find people interested.
>>
>> I just removed the achieved or abandoned goals there:
>> Abandoned: Ivy integration (because of Gradle integration), Complete the
>> support for VAT(WIP was removed)
>> Achieved: Solr integration
>>
>> It simple and lean, what do you think?
>>
>> Jacques
>>
>>
>> Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit :
>>
>>> +1
>>>
>>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <[hidden email]
>>> wrote:
>>>
>>> Yes i like this plan :)
>>>> Gil
>>>>
>>>> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>>>>
>>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>>
>>>>> Could be the R17 main task?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>>>>
>>>>> +1
>>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>>> configuration in IDE Integration part.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>>
>>>>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>>>>
>>>>>> +1
>>>>>>> I think Jacopo has more to say about that :)
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>>> DSL+for+OFBiz+business+logic
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>>>>
>>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>>> not
>>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>>
>>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>>> the
>>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>>> statements.
>>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>>> did
>>>>>>>> not
>>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>>> for an
>>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>>> comprehensively
>>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>>> for
>>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>>
>>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>>> [hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>>> through
>>>>>>>>
>>>>>>>>> with a debugger.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Skip,
>>>>>>>>>
>>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>>> community,
>>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>>> standards. I
>>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>>
>>>>>>>>>> though
>>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>>> entity-auto
>>>>>>>>>>
>>>>>>>>>> for
>>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>> invest
>>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>>> we
>>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>>> of
>>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>>> are
>>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>>> can.
>>>>>>>>>> We
>>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>>> as not
>>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>>
>>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>>> logic
>>>>>>>>>> as
>>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>>> that
>>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>>> and
>>>>>>>>>> thus
>>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>>> rely on
>>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

[Jacques Le Roux]

You are right, it should be moved to the open space. I'll wait a consensus before engaging more effort on this. Not only on the page itself but also
on the prioritized goals.

Jacques


Le 17/08/2016 à 20:01, Pierre Smits a écrit :

> Is it in the right space? Where it is now, I would say it is a fest of
> privileged contributors.
>
> Best regards,
>
> Pierre
>
> On Wednesday, August 17, 2016, Jacques Le Roux <[hidden email]>
> wrote:
>
>> Hi All,
>>
>> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
>> concerns more developers
>>
>> We need to have a very realistic lean Roadmap to agree on, follow and
>> progress.
>>
>> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
>> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
>> pick up them as they come and prioritize again now and then when needed.
>>
>> We don't need to prioritize all tasks. Simply few that we put at top to
>> really work on them as a team and then sort again once they are done.
>> For that I have already added in this order "Introduce a plugin system"
>> and "Replace Minilang and widgets actions by a Groovy DSL"
>>
>> Also I don't think we need to maintain lists of "interested" and "willing
>> to help" people by goal. So I have removed this information. It's about
>> having a lean roadmap here, anybody can join at any moment. Rather links to
>> Jira can help to find people interested.
>>
>> I just removed the achieved or abandoned goals there:
>> Abandoned: Ivy integration (because of Gradle integration), Complete the
>> support for VAT(WIP was removed)
>> Achieved: Solr integration
>>
>> It simple and lean, what do you think?
>>
>> Jacques
>>
>>
>> Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit :
>>
>>> +1
>>>
>>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <[hidden email]
>>> wrote:
>>>
>>> Yes i like this plan :)
>>>> Gil
>>>>
>>>> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>>>>
>>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>>
>>>>> Could be the R17 main task?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>>>>
>>>>> +1
>>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>>> configuration in IDE Integration part.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>>
>>>>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>>>>
>>>>>> +1
>>>>>>> I think Jacopo has more to say about that :)
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>>> DSL+for+OFBiz+business+logic
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>>>>
>>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>>> not
>>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>>
>>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>>> the
>>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>>> statements.
>>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>>> did
>>>>>>>> not
>>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>>> for an
>>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>>> comprehensively
>>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>>> for
>>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>>
>>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>>> [hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>>> through
>>>>>>>>
>>>>>>>>> with a debugger.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Skip,
>>>>>>>>>
>>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>>> community,
>>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>>> standards. I
>>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>>
>>>>>>>>>> though
>>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>>> entity-auto
>>>>>>>>>>
>>>>>>>>>> for
>>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>> invest
>>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>>> we
>>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>>> of
>>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>>> are
>>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>>> can.
>>>>>>>>>> We
>>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>>> as not
>>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>>
>>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>>> logic
>>>>>>>>>> as
>>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>>> that
>>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>>> and
>>>>>>>>>> thus
>>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>>> rely on
>>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>