Spring Tool Suite
  1. Spring Tool Suite
  2. STS-1159

In Grails you can overwrite plugin classes, but STS complains about class duplication.

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.3.3.M2
    • Fix Version/s: None
    • Component/s: GRAILS
    • Labels:
    • Environment:

      WinXP SP3, SpringSource STS 2.3.3M2, Grails 1.3.3

      Description

      In my grails project I have overwritten a class of the rich-ui plugin. The class is to be found in the src/groovy folder. STS complains about class duplication. It seems like STS can only handle overwriting of grails artefacts as overwriting a taglib class didn't cause any problems.

        Activity

        Hide
        Andrew Eisenberg (c) added a comment -

        I'm actually quite surprised that you were able to overwrite a grails Taglib. Eclipse generally does not allow having 2 types with the same name and package in the same project. And when I tried it out, I got an error for both situations that you describe.

        This will not be a simple fix inside of STS since we would need to make some fundamental changes to the Java builder.

        However, I can suggest a workaround:

        1. Find the file that contains the class you want overwritten.
        2. You may need to remove the Grails Project Filter to find resources in plugins:
          1. Right-click on the small upside down triangle in the upper right corner of the package explorer/grails explorer.
          2. Select Customize View (in the Grails explorer) or Filters (in the package explorer)
          3. In the list, deselect "Grails Project Filter"
          4. Click OK
        3. Now, find the resource.
        4. Right-click -> Build Path -> Exclude
        5. This file will no longer be sent to the compiler and you should no longer have duplication problems.
        6. To revert, Select file, Right-Click -> Build Path -> Include
        Show
        Andrew Eisenberg (c) added a comment - I'm actually quite surprised that you were able to overwrite a grails Taglib. Eclipse generally does not allow having 2 types with the same name and package in the same project. And when I tried it out, I got an error for both situations that you describe. This will not be a simple fix inside of STS since we would need to make some fundamental changes to the Java builder. However, I can suggest a workaround: Find the file that contains the class you want overwritten. You may need to remove the Grails Project Filter to find resources in plugins: Right-click on the small upside down triangle in the upper right corner of the package explorer/grails explorer. Select Customize View (in the Grails explorer) or Filters (in the package explorer) In the list, deselect "Grails Project Filter" Click OK Now, find the resource. Right-click -> Build Path -> Exclude This file will no longer be sent to the compiler and you should no longer have duplication problems. To revert, Select file, Right-Click -> Build Path -> Include
        Hide
        Andy Clement (c) added a comment -

        we could think about automating the exclude if we see this pattern occurring. We already automatically exclude some that will be known duplicates.

        Show
        Andy Clement (c) added a comment - we could think about automating the exclude if we see this pattern occurring. We already automatically exclude some that will be known duplicates.
        Hide
        Andrew Eisenberg (c) added a comment -

        Yes, but the problem is that we won't know there are any duplicates until after compilation already starts. By this point, it is already too late to exclude resources.

        I can see two possible solutions, neither of which I like:

        1. Create a kind of Grails builder, or maybe just a compilation participant that searches through the indexes and looks for duplicate types. And then tries to resolve which one it should use and which should be excluded before handing control over to the builder. This would be slow and there would be significant duplication of logic in the builder as there would be in the compiler.
        2. Create a callback in the compiler so that when this duplicate type problem is found, an exclusion filter is added. Then abort compilation and restart. This, too will take a long time (essentially compiling twice) and requires a change to the compiler.

        Now that I think about it, there is a third possibility, which is slightly less bad than the other two:

        After compilation is finished, search all problems for duplicate types. If there is one, then try to resolve the problem. Although this too, would require multiple compilation steps, at least we could take full advantage of the incremental compiler here.

        Show
        Andrew Eisenberg (c) added a comment - Yes, but the problem is that we won't know there are any duplicates until after compilation already starts. By this point, it is already too late to exclude resources. I can see two possible solutions, neither of which I like: Create a kind of Grails builder, or maybe just a compilation participant that searches through the indexes and looks for duplicate types. And then tries to resolve which one it should use and which should be excluded before handing control over to the builder. This would be slow and there would be significant duplication of logic in the builder as there would be in the compiler. Create a callback in the compiler so that when this duplicate type problem is found, an exclusion filter is added. Then abort compilation and restart. This, too will take a long time (essentially compiling twice) and requires a change to the compiler. Now that I think about it, there is a third possibility, which is slightly less bad than the other two: After compilation is finished, search all problems for duplicate types. If there is one, then try to resolve the problem. Although this too, would require multiple compilation steps, at least we could take full advantage of the incremental compiler here.
        Hide
        Markus List added a comment -

        Thanks Andrew², for your help. The workaround works fine for me. In my opinion, an automatic exclusion would be a useful feature as I wouldn't need to exclude those files on every STS installation. Don't know how important this is to other people, however.

        Show
        Markus List added a comment - Thanks Andrew², for your help. The workaround works fine for me. In my opinion, an automatic exclusion would be a useful feature as I wouldn't need to exclude those files on every STS installation. Don't know how important this is to other people, however.
        Hide
        Andrew Eisenberg (c) added a comment -

        Won't get to this for 2.5.0.

        Show
        Andrew Eisenberg (c) added a comment - Won't get to this for 2.5.0.

          People

          • Assignee:
            Unassigned
            Reporter:
            Markus List
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              First Response Date: