Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-6810

Refactor components regarding freemarker file locations

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Trunk, Release Branch 15.12
    • Fix Version/s: 16.11.01
    • Component/s: ALL COMPONENTS
    • Labels:
      None
    • Sprint:
      Community Day 1 - 2016

      Description

      This is a placeholder issue to capture all tasks and related issues regarding the refactoring of the directory structure with respect to the location of .groovy and .ftl (freemarker templates) files.

      See related discussion: http://ofbiz.markmail.org/message/25dse4jke2fp64mx

        Issue Links

        1.
        relocate .ftl files in the specialpurpose/assetmaint component Sub-task Closed Jacques Le Roux
         
        2.
        relocate .ftl files in the specialpurpose/oagis component Sub-task Closed Jacques Le Roux
         
        3.
        relocate .ftl files in the framework/webtools component Sub-task Closed Deepak Dixit
         
        4.
        relocate .ftl files in the accounting component Sub-task Closed Deepak Dixit
         
        5.
        relocate .ftl files in the specialpurpose/ecommerce component Sub-task Closed Deepak Dixit
         
        6.
        relocate .ftl files in the commonext component Sub-task Closed Deepak Dixit
         
        7.
        relocate .ftl files in the content component Sub-task Closed Deepak Dixit
         
        8.
        relocate .ftl files in the framework/common component Sub-task Closed Deepak Dixit
         
        9.
        relocate .ftl files in the party component Sub-task Closed Deepak Dixit
         
        10.
        relocate .ftl files in the product component Sub-task Closed Deepak Dixit
         
        11.
        relocate .ftl files in the specialpurpose/ebay Sub-task Closed Deepak Dixit
         
        12.
        relocate .ftl files in the specialpurpose/ebaystore component Sub-task Closed Deepak Dixit
         
        13.
        relocate .ftl files in the specialpurpose/exampleext component Sub-task Closed Deepak Dixit
         
        14.
        relocate .ftl files in the specialpurpose/exampleext component Sub-task Closed Unassigned
         
        15.
        relocate .ftl files in the specialpurpose/googlebase component Sub-task Closed Deepak Dixit
         
        16.
        relocate .ftl files in the specialpurpose/googlecheckout component Sub-task Closed Deepak Dixit
         
        17.
        relocate .ftl files in the specialpurpose/scrum Sub-task Closed Deepak Dixit
         
        18.
        relocate .ftl files in the specialpurpose/passport component Sub-task Closed Deepak Dixit
         
        19.
        relocate .ftl files in the specialpurpose/lucene component Sub-task Closed Deepak Dixit
         
        20.
        relocate .ftl files in the specialpurpose/bi component Sub-task Closed Deepak Dixit
         
        21.
        relocate .ftl files in the marketing component Sub-task Closed Deepak Dixit
         
        22.
        relocate .ftl files in the securityext component Sub-task Closed Deepak Dixit
         
        23.
        relocate .ftl files in the specialpurpose/birt component Sub-task Closed Deepak Dixit
         
        24.
        relocate .ftl files in the specialpurpose/hhfacility component Sub-task Closed Jacques Le Roux
         
        25.
        relocate .ftl files in the specialpurpose/cmssite component Sub-task Closed Jacques Le Roux
         
        26.
        relocate .ftl files in the workeffort component Sub-task Closed Deepak Dixit
         
        27.
        relocate .ftl files in the humanres component Sub-task Closed Jacques Le Roux
         
        28.
        relocate .ftl files in the specialpurpose/projectmgr component Sub-task Closed Jacques Le Roux
         
        29.
        relocate .ftl files in the manufacturing component Sub-task Closed Jacques Le Roux
         
        30.
        relocate .ftl files in the order component Sub-task Closed Jacques Le Roux
         
        31.
        relocate .ftl files in the specialpurpose/webpos component Sub-task Closed Jacques Le Roux
         
        32.
        relocate .ftl files in the specialpurpose/myportal component Sub-task Closed Jacques Le Roux
         
        33.
        Rename .ftl file as per best practises Sub-task Closed Deepak Dixit
         
        34.
        relocate .ftl files in the theme components Sub-task Closed Deepak Dixit
         
        35.
        Move all Groovy scripts in components WEB-INF/actions sub-folders Sub-task Closed Deepak Dixit
         

          Activity

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

          I don't clearly remember, this has been discussed on the dev ML right?

          Note that we don't backport improvements to freezed branches but in exceptional cases with a consensus (not a lazy one)

          Show
          jacques.le.roux Jacques Le Roux added a comment - I don't clearly remember, this has been discussed on the dev ML right? Note that we don't backport improvements to freezed branches but in exceptional cases with a consensus (not a lazy one)
          Hide
          pfm.smits Pierre Smits added a comment -

          My apologies. I forgot to include the link to the related discusion in the description. I will do so accordingly.

          With respects to backporting to freezed branches: there have been precedents.

          Show
          pfm.smits Pierre Smits added a comment - My apologies. I forgot to include the link to the related discusion in the description. I will do so accordingly. With respects to backporting to freezed branches: there have been precedents.
          Hide
          soledad Nicolas Malin added a comment -

          Thanks pierre for up this subject and works on it.

          Given the dev ML thread, they are a consensus to realize the reallocation. However I prefer keep it on only on trunk.
          I wait one week and if ok I propage your works

          Show
          soledad Nicolas Malin added a comment - Thanks pierre for up this subject and works on it. Given the dev ML thread, they are a consensus to realize the reallocation. However I prefer keep it on only on trunk. I wait one week and if ok I propage your works
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Thanks Pierre, I just re-read it all, interesting topic.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Thanks Pierre, I just re-read it all, interesting topic.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Before engaging more efforts, did we agree about the folders structures for groovy and freemarker? I remember there was a whish to separate pure groovy scripts from groovy files possibly compiled: http://markmail.org/message/swzttrevkn3uofbq

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Before engaging more efforts, did we agree about the folders structures for groovy and freemarker? I remember there was a whish to separate pure groovy scripts from groovy files possibly compiled: http://markmail.org/message/swzttrevkn3uofbq
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Actually it was suggested R15 could be a "major rewrite that will not be backward compatible" http://markmail.org/message/pcnbni33w5qddwev
          So it seems I had not all the context in mind when I wrote my 1st comment in this issue. We still need to agree on this, it's a tremendous change! I guess we will not get a consensus, so a vote might be needed.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Actually it was suggested R15 could be a "major rewrite that will not be backward compatible" http://markmail.org/message/pcnbni33w5qddwev So it seems I had not all the context in mind when I wrote my 1st comment in this issue. We still need to agree on this, it's a tremendous change! I guess we will not get a consensus, so a vote might be needed.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          +1 Jacques,
          IMO first we need to conclude the thread, we can add finalize pattern in ticket and then put effort on this.

          Show
          deepak.dixit Deepak Dixit added a comment - +1 Jacques, IMO first we need to conclude the thread, we can add finalize pattern in ticket and then put effort on this.
          Hide
          soledad Nicolas Malin added a comment -

          Yeah clearly

          My preference gone to have all script related to screen/widget under
          component/script/language
          and all script or compilate code related to event / service or API under
          component/src/language

          Show
          soledad Nicolas Malin added a comment - Yeah clearly My preference gone to have all script related to screen/widget under component/script/language and all script or compilate code related to event / service or API under component/src/language
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Jacopo's initial proposal was (slightly modified by me for component_name generalisation)

          src/main/java/org/ofbiz/component_name/...
          src/test/java/org/ofbiz/component_name/...
          src/main/minilang/org/ofbiz/component_name/...
          src/main/groovy/...
          

          Adam's suggested a change to differentiate between pre-compiled vs parsed Groovy scripts and then Jacopo proposed

          src/main/java/org/ofbiz/component_name/...
          src/test/java/org/ofbiz/component_name/...
          src/main/minilang/org/ofbiz/component_name/...
          src/main/groovy/... (pre-compiled Groovy)
          src/main/scripts/... (parsed Groovy scripts)
          

          I personnaly wonder why we should carry the Java package name way for other languages. So I'd suggest

          src/main/java/org/ofbiz/component_name/...
          src/test/java/org/ofbiz/component_name/...
          minilang/...
          groovy/... (pre-compiled Groovy)
          /groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future)
          

          As Nicolas suggested we could differentiate under minilang, groovy and groovyScripts folders by using sub-folders like screen, event and service (better to separate those 2 last). We anyway need to keep the Java package name way for Java classes.

          Sincerely I did not put much thoughts on this and I could have missed something... Notably how much changes this entails for the "component://" notation

          Show
          jacques.le.roux Jacques Le Roux added a comment - Jacopo's initial proposal was (slightly modified by me for component_name generalisation) src/main/java/org/ofbiz/component_name/... src/test/java/org/ofbiz/component_name/... src/main/minilang/org/ofbiz/component_name/... src/main/groovy/... Adam's suggested a change to differentiate between pre-compiled vs parsed Groovy scripts and then Jacopo proposed src/main/java/org/ofbiz/component_name/... src/test/java/org/ofbiz/component_name/... src/main/minilang/org/ofbiz/component_name/... src/main/groovy/... (pre-compiled Groovy) src/main/scripts/... (parsed Groovy scripts) I personnaly wonder why we should carry the Java package name way for other languages. So I'd suggest src/main/java/org/ofbiz/component_name/... src/test/java/org/ofbiz/component_name/... minilang/... groovy/... (pre-compiled Groovy) /groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future) As Nicolas suggested we could differentiate under minilang, groovy and groovyScripts folders by using sub-folders like screen, event and service (better to separate those 2 last). We anyway need to keep the Java package name way for Java classes. Sincerely I did not put much thoughts on this and I could have missed something... Notably how much changes this entails for the "component://" notation
          Hide
          pfm.smits Pierre Smits added a comment -

          We have to keep in mind that groovy code can also be compiled. Having it in the same src structure as java code can have advantages.

          Show
          pfm.smits Pierre Smits added a comment - We have to keep in mind that groovy code can also be compiled. Having it in the same src structure as java code can have advantages.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Also I just rethought about it, anyway the Java package name way is required to avoid filenames collisions, so not only for Java classes but all languages.

          I mean when using the "component://" notation you could else have files with same names in different components, languages, etc.

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Also I just rethought about it, anyway the Java package name way is required to avoid filenames collisions, so not only for Java classes but all languages. I mean when using the "component://" notation you could else have files with same names in different components, languages, etc.
          Hide
          soledad Nicolas Malin added a comment -

          We are ok for java and minilang, so for the groovy we open a vote ?

          Show
          soledad Nicolas Malin added a comment - We are ok for java and minilang, so for the groovy we open a vote ?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          This would maybe have the effect of getting more attention. A reference to http://markmail.org/message/swzttrevkn3uofbq would be needed

          Show
          jacques.le.roux Jacques Le Roux added a comment - This would maybe have the effect of getting more attention. A reference to http://markmail.org/message/swzttrevkn3uofbq would be needed
          Hide
          soledad Nicolas Malin added a comment -

          The vote is done http://markmail.org/thread/kyhgfykfiwhzllll, now you can continue with the community approbation on your proposal Jacques.

          groovy/... (pre-compiled Groovy)
          groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future)

          Show
          soledad Nicolas Malin added a comment - The vote is done http://markmail.org/thread/kyhgfykfiwhzllll , now you can continue with the community approbation on your proposal Jacques. groovy/... (pre-compiled Groovy) groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future)
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Sorry, where is the official result ?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Sorry, where is the official result ?
          Hide
          soledad Nicolas Malin added a comment -

          http://markmail.org/thread/kyhgfykfiwhzllll#query:+page:1+mid:hemokyhcnpe4w5rn+state:results

          At the question :

          Regard to the issue, we have no problem for the java and minilang files but the groovy need a community decision.
          A) All groovy script under the same path src/main/groovy/...
          B) Separate Groovy compiled and scripted like this src/main/groovy/... (pre-compiled Groovy) src/main/scripts/... (parsed Groovy scripts)
          C) Separate Groovy compiled and scripted like this groovy/... (pre-compiled Groovy) groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future)
          D) other if you have an ingenious idea

          the result is :

          Total are :
          A) -5
          B) 0
          C) +7
          D) No other proposal

          Now we can move all groovy script present on component://componentname/webapp/componentname/WEB-INF/actions/script.groovy to component://componentname/groovyscript/script.groovy

          Show
          soledad Nicolas Malin added a comment - http://markmail.org/thread/kyhgfykfiwhzllll#query:+page:1+mid:hemokyhcnpe4w5rn+state:results At the question : Regard to the issue, we have no problem for the java and minilang files but the groovy need a community decision. A) All groovy script under the same path src/main/groovy/... B) Separate Groovy compiled and scripted like this src/main/groovy/... (pre-compiled Groovy) src/main/scripts/... (parsed Groovy scripts) C) Separate Groovy compiled and scripted like this groovy/... (pre-compiled Groovy) groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future) D) other if you have an ingenious idea the result is : Total are : A) -5 B) 0 C) +7 D) No other proposal Now we can move all groovy script present on component://componentname/webapp/componentname/WEB-INF/actions/script.groovy to component://componentname/groovyscript/script.groovy
          Hide
          pfm.smits Pierre Smits added a comment -

          Why create a new folder in the root of the component. We already have a folder called script. Having groovy script files there fits the naming convention and meaning.

          Show
          pfm.smits Pierre Smits added a comment - Why create a new folder in the root of the component. We already have a folder called script. Having groovy script files there fits the naming convention and meaning.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Good point. You certainly noticed that I suggested

          minilang/...
          groovy/... (pre-compiled Groovy)
          /groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future)
          

          and that all (disclaimer: I did not check that) scripts under the currently folders called script are all Minilang scripts (map_procs or services implementations). You maybe also noticed that using the component:// notation we don't need to use a "java package like" path, any path is OK. So what we could also do is renaming all
          component://componentname/script/java_package_path/possible_sub_folder_name/services_implementation_name.xml
          to
          component://componentname/minilang/possible_sub_folder_name/services_implementations_name.xml

          I'm not sure about keeping the possible_sub_folder_name but it seems reasonnable to not remove this part of the structure.
          Using minilang for component sub_folder name is enough because so far (and I guess in future) Minilang is only used for map_proc and services_implementations (including tests services), so there are no ambiguities

          Show
          jacques.le.roux Jacques Le Roux added a comment - Good point. You certainly noticed that I suggested minilang/... groovy/... (pre-compiled Groovy) /groovyScripts/... (parsed Groovy scripts, groovyScripts rather that script because other script languages could be used in the future ) and that all (disclaimer: I did not check that) scripts under the currently folders called script are all Minilang scripts (map_procs or services implementations). You maybe also noticed that using the component:// notation we don't need to use a "java package like" path, any path is OK. So what we could also do is renaming all component://componentname/script/java_package_path/possible_sub_folder_name/services_implementation_name.xml to component://componentname/minilang/possible_sub_folder_name/services_implementations_name.xml I'm not sure about keeping the possible_sub_folder_name but it seems reasonnable to not remove this part of the structure. Using minilang for component sub_folder name is enough because so far (and I guess in future) Minilang is only used for map_proc and services_implementations (including tests services), so there are no ambiguities
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi Pierre, I was looking at your patches for moving FTL templates from widget to template component direct sub-folder. That seems OK with me, but I could find where this has been discussed. I tried a Nabble search http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=4662062&query=template&n=4662062 nothing about this topic.

          So it seems an unilateral decision of yours? Anyway if nobody complains I'll commit your patches in few days. Thanks!

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi Pierre, I was looking at your patches for moving FTL templates from widget to template component direct sub-folder. That seems OK with me, but I could find where this has been discussed. I tried a Nabble search http://ofbiz.135035.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=4662062&query=template&n=4662062 nothing about this topic. So it seems an unilateral decision of yours? Anyway if nobody complains I'll commit your patches in few days. Thanks!
          Hide
          pfm.smits Pierre Smits added a comment -

          Unilateral? That seems like a rhetorical question...

          Show
          pfm.smits Pierre Smits added a comment - Unilateral? That seems like a rhetorical question...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Show
          jacques.le.roux Jacques Le Roux added a comment -
          Hide
          deepak.dixit Deepak Dixit added a comment - - edited

          we can define FTL file naming convention and can rename ftl as per naming convention.
          IMO we have to use Upper camel case pattern for file naming.

          Show
          deepak.dixit Deepak Dixit added a comment - - edited we can define FTL file naming convention and can rename ftl as per naming convention. IMO we have to use Upper camel case pattern for file naming.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          +1! long awaited here

          Actually I'd like to have the same for every source files (ie not files like LICENSE, etc.)

          I don't see the point of inconsistency in filenames, shoud be a no brainner!

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited +1! long awaited here Actually I'd like to have the same for every source files (ie not files like LICENSE, etc.) I don't see the point of inconsistency in filenames, shoud be a no brainner!
          Hide
          pfm.smits Pierre Smits added a comment -

          Unfortunately the naming convention for Freemarker template files didn't get persisted in the minds of the various contributors. Hence the variations we have in current code bases.

          Show
          pfm.smits Pierre Smits added a comment - Unfortunately the naming convention for Freemarker template files didn't get persisted in the minds of the various contributors. Hence the variations we have in current code bases.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          It needs maybe some work, but it's worth it!

          Show
          jacques.le.roux Jacques Le Roux added a comment - It needs maybe some work, but it's worth it!
          Hide
          pfm.smits Pierre Smits added a comment -

          Of course. But IMO and the likes doesn't work always. It is better to have it somewhere in the pages.

          Show
          pfm.smits Pierre Smits added a comment - Of course. But IMO and the likes doesn't work always. It is better to have it somewhere in the pages.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          somewhere in the pages.

          ?

          Show
          jacques.le.roux Jacques Le Roux added a comment - somewhere in the pages. ?
          Hide
          pfm.smits Pierre Smits added a comment -

          Yes, the wiki (or somewhere else).

          I feel confident a placeholder can be found.

          Show
          pfm.smits Pierre Smits added a comment - Yes, the wiki (or somewhere else). I feel confident a placeholder can be found.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          I think we can add best practice here https://cwiki.apache.org/confluence/x/C4B2

          Show
          deepak.dixit Deepak Dixit added a comment - I think we can add best practice here https://cwiki.apache.org/confluence/x/C4B2
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Yes, right place indeed

          Show
          jacques.le.roux Jacques Le Roux added a comment - Yes, right place indeed
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Please use svn mv command to move files from old location to new location, else svn history will be lost.

          Show
          deepak.dixit Deepak Dixit added a comment - Please use svn mv command to move files from old location to new location, else svn history will be lost.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Can we create patches using mv command? I mean will they have the same impact?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Can we create patches using mv command? I mean will they have the same impact?
          Hide
          pfm.smits Pierre Smits added a comment -

          My IDE doesn't have a function for that.

          Show
          pfm.smits Pierre Smits added a comment - My IDE doesn't have a function for that.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Yes that's the problem, when you move things you can't create patches with history in them it seems.
          It has to be done by the committers directly. I will double-check that though...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Yes that's the problem, when you move things you can't create patches with history in them it seems. It has to be done by the committers directly. I will double-check that though...
          Hide
          pfm.smits Pierre Smits added a comment -

          For current patch files in the subtasks (and of course future submissions) I will provide new submissions. These submissions will:

          • have a patch file regarding the changed ftl locations in the widgets of the component, and
          • have a text file providing insights of the actual ftl relocation (this text file will contain the changes as an svn patch, but should not be applied as such as a svn mv must be executed).
          Show
          pfm.smits Pierre Smits added a comment - For current patch files in the subtasks (and of course future submissions) I will provide new submissions. These submissions will: have a patch file regarding the changed ftl locations in the widgets of the component, and have a text file providing insights of the actual ftl relocation (this text file will contain the changes as an svn patch, but should not be applied as such as a svn mv must be executed).
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I confirm patches must not be used when moving files!

          Show
          jacques.le.roux Jacques Le Roux added a comment - I confirm patches must not be used when moving files!
          Hide
          soledad Nicolas Malin added a comment -

          Pierre it's ok for you or you want explain an other idea. If it's the case sharing it.

          Show
          soledad Nicolas Malin added a comment - Pierre it's ok for you or you want explain an other idea. If it's the case sharing it.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Nothing was yet done for R15.12 branch and I'm now not sure we really want to do that...

          Show
          jacques.le.roux Jacques Le Roux added a comment - Nothing was yet done for R15.12 branch and I'm now not sure we really want to do that...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Before moving Groovy scripts we need to do OFBIZ-6981

          Show
          jacques.le.roux Jacques Le Roux added a comment - Before moving Groovy scripts we need to do OFBIZ-6981
          Hide
          pfm.smits Pierre Smits added a comment -

          Thanks guys for the assistance in such short time frame to get the patches in the code base.

          Best regards,

          Pierre

          Show
          pfm.smits Pierre Smits added a comment - Thanks guys for the assistance in such short time frame to get the patches in the code base. Best regards, Pierre
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          I will create a new issue for the Groovy moving, after OFBIZ-6981 will be done, and will close this one...

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited I will create a new issue for the Groovy moving, after OFBIZ-6981 will be done, and will close this one...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I will rather create as a subtask and will close here when all subtasks will be done...

          Show
          jacques.le.roux Jacques Le Roux added a comment - I will rather create as a subtask and will close here when all subtasks will be done...
          Hide
          deepak.dixit Deepak Dixit added a comment -

          I think as all task has been closed so we can close parent ticket as well.

          Show
          deepak.dixit Deepak Dixit added a comment - I think as all task has been closed so we can close parent ticket as well.
          Hide
          deepak.dixit Deepak Dixit added a comment - - edited

          Here is the parent ticket for groovy files OFBIZ-7218

          Show
          deepak.dixit Deepak Dixit added a comment - - edited Here is the parent ticket for groovy files OFBIZ-7218

            People

            • Assignee:
              jacques.le.roux Jacques Le Roux
              Reporter:
              pfm.smits Pierre Smits
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development

                  Agile