Details

      Description

      According to the proposal thread in [1] we decided to deprecate mini lang.

      This issue tracks the next steps proposed in the aformentioned thread, namely:

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

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

      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. A good starting point can be [4][5][6].

      [1] https://lists.apache.org/thread.html/253b41060a295b8ab68bc78763cc129fc74b712cf776f8716022097f@%3Cdev.ofbiz.apache.org%3E
      [2] https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference
      [3] does anyone know a way to batch comment Jira issues like it is possible in Redmine?
      [4] https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic
      [5] https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide
      [6] https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions

        Issue Links

          Activity

          Hide
          mbrohl Michael Brohl added a comment -

          2. is done for [2]. Any other places where we should put it?

          Show
          mbrohl Michael Brohl added a comment - 2. is done for [2] . Any other places where we should put it?
          Show
          mbrohl Michael Brohl added a comment - - edited Wiki page: https://cwiki.apache.org/confluence/display/OFBIZ/Mini+Lang+Deprecation
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          We have also wiki pages for the older versions of the minilang page. We can put it there too, but not sure it's needed, older versions are already deprecated by the last minilang version.

          Show
          jacques.le.roux Jacques Le Roux added a comment - We have also wiki pages for the older versions of the minilang page. We can put it there too, but not sure it's needed, older versions are already deprecated by the last minilang version.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          One important thing we should not forget when replacing minilang is its ability to not need to compile. So for instance when replacing minilang services, and in general when writing small services, it's better to use Groovy (than eg Java) which as the same no compile needed ability. Of course when the service definition change this does not apply. At large it makes quite a difference when you want to develop fast. I did not say it's more reliable and easier to refactor (obviously it's not, Groovy is optionnaly typed, contrary to Java which is type safe)

          Show
          jacques.le.roux Jacques Le Roux added a comment - One important thing we should not forget when replacing minilang is its ability to not need to compile. So for instance when replacing minilang services, and in general when writing small services, it's better to use Groovy (than eg Java) which as the same no compile needed ability. Of course when the service definition change this does not apply. At large it makes quite a difference when you want to develop fast. I did not say it's more reliable and easier to refactor (obviously it's not, Groovy is optionnaly typed, contrary to Java which is type safe)
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I will somehow add my last comment in the Mini+Lang+Deprecation wiki page...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I will somehow add my last comment in the Mini+Lang+Deprecation wiki page...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Done

          Show
          jacques.le.roux Jacques Le Roux added a comment - Done
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          BTW, I don't recall we discussed about a replacement of "Simple Map Processor", did we?

          Show
          jacques.le.roux Jacques Le Roux added a comment - BTW, I don't recall we discussed about a replacement of "Simple Map Processor", did we?
          Hide
          rishisolankii Rishi Solanki added a comment -

          Review comments from Scott Gray on dev list to follow in upcoming conversion:

          1. It would be good if the services were converted one per commit, with the
          empty minilang file removed at the end with a separate commit. That would
          allow reviewers to compare the removed XML code with the new groovy code.
          2. Defaults should (where possible) be moved to the service definition
          3. I could be wrong about this but I don't think it is a good practice to
          assign/change values in the parameters map, I think callers would not
          expect their inputs to be changed by the service. But I'm not sure if that
          is actually happening or if groovy has copied the map beforehand, I'm also
          unsure of how minilang used to handle the same.
          4. Because groovy has "Groovy Truth", UtilValidate.isEmpty/isNotEmpty isn't
          required, you can simply do "if (parameters.ratesList)". An empty list or
          null would return false.
          5. I think it would be better to add the service documentation to the
          service definition instead of a comment inline with the code.
          6. I'm curious about the getRateAmount() "level" variable, I see it is only
          defined within the local scope of the if/else blocks whereas "serviceName"
          was defined at the method scope. Does groovy allow "level" to take on the
          method scope or is it an error?

          Show
          rishisolankii Rishi Solanki added a comment - Review comments from Scott Gray on dev list to follow in upcoming conversion: 1. It would be good if the services were converted one per commit, with the empty minilang file removed at the end with a separate commit. That would allow reviewers to compare the removed XML code with the new groovy code. 2. Defaults should (where possible) be moved to the service definition 3. I could be wrong about this but I don't think it is a good practice to assign/change values in the parameters map, I think callers would not expect their inputs to be changed by the service. But I'm not sure if that is actually happening or if groovy has copied the map beforehand, I'm also unsure of how minilang used to handle the same. 4. Because groovy has "Groovy Truth", UtilValidate.isEmpty/isNotEmpty isn't required, you can simply do "if (parameters.ratesList)". An empty list or null would return false. 5. I think it would be better to add the service documentation to the service definition instead of a comment inline with the code. 6. I'm curious about the getRateAmount() "level" variable, I see it is only defined within the local scope of the if/else blocks whereas "serviceName" was defined at the method scope. Does groovy allow "level" to take on the method scope or is it an error?
          Hide
          mbrohl Michael Brohl added a comment -

          Hi devs,

          there seems to me more action in this task recently, which is great!

          To prevent working on the same services from different sides I strongly recommend to file a Jira BEFORE starting the work.

          Regards,
          Michael

          Show
          mbrohl Michael Brohl added a comment - Hi devs, there seems to me more action in this task recently, which is great! To prevent working on the same services from different sides I strongly recommend to file a Jira BEFORE starting the work. Regards, Michael

            People

            • Assignee:
              mbrohl Michael Brohl
              Reporter:
              mbrohl Michael Brohl
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development