GRECLIPSE
  1. GRECLIPSE
  2. GRECLIPSE-1118

Better editing support for groovy files that are not on the build path

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5.1Release
    • Fix Version/s: 2.5.2.Release
    • Component/s: Editor
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Currently, we explicitly disable much of the editing support for Groovy files that are not on the build path. This means that editing scripts, gradle files, or anything else not on the build path will not be too easy. Since we are trying to provide better gradle support, we should be doing something about this.

      It would be nice to enable standard editor features like navigation, outline view, content assist, type inferencing, and dsl support.

      I don't remember exactly why we disabled this in the past, but I do know that there were many exceptions being added to the log when editing files not on the build path.

        Activity

        Hide
        Andrew Eisenberg added a comment -

        I have been playing around with this in my local workspace and this is working quite well. By simply removing the guards on GroovyCompilationUnit.buildStructure and elsewhere, I now have navigation, content assist, type inferencing, and mark occurrences working. The caveats are that files outside of the build path cannot be referenced by any other files, search doesn't work inside of these files, and refactoring does not work. These are restrictions that is similar to those for Java files in JDT.

        Show
        Andrew Eisenberg added a comment - I have been playing around with this in my local workspace and this is working quite well. By simply removing the guards on GroovyCompilationUnit.buildStructure and elsewhere, I now have navigation, content assist, type inferencing, and mark occurrences working. The caveats are that files outside of the build path cannot be referenced by any other files, search doesn't work inside of these files, and refactoring does not work. These are restrictions that is similar to those for Java files in JDT.
        Hide
        Andrew Eisenberg added a comment -

        I am considering committing what I have and seeing if other people have problems with editing.

        The next step is to allow the ability to augment (or replace) the lookup path of script files.

        Show
        Andrew Eisenberg added a comment - I am considering committing what I have and seeing if other people have problems with editing. The next step is to allow the ability to augment (or replace) the lookup path of script files.
        Hide
        Andy Clement added a comment -

        So as we discussed, we can choose to not be eclipsey in terms of the extra lookups. Both the ability to use ast transforms that are part of the project and grab support use a classloader to make types available that are not on the classpath. The classpath to be used could be communicated in a similar way in which we currently communicate that the file is a script (see GCUD.tagAsScript() and how that filters through to GCUScope). I think this is worth continuing with once we have a real use case and the gradle support is able to conjure up the classpath to use. I'll check with Kris next week about whether the API can provide it. Where we will have to be careful is that using a classloader kind of just gives us augmentation of the classpath, we'll need to also affect the JDT resolver and prevent it finding things in these situations (if we truly want to use an entirely different classpath for the scripts).

        Now the script support seems to be behaving, perhaps we also need to make the change that will mean the scripts are not passed to the compiler (for a proper build), even if in a source folder (if they match the script patterns). ie. remove our old hacky way of supporting scripts.

        Show
        Andy Clement added a comment - So as we discussed, we can choose to not be eclipsey in terms of the extra lookups. Both the ability to use ast transforms that are part of the project and grab support use a classloader to make types available that are not on the classpath. The classpath to be used could be communicated in a similar way in which we currently communicate that the file is a script (see GCUD.tagAsScript() and how that filters through to GCUScope). I think this is worth continuing with once we have a real use case and the gradle support is able to conjure up the classpath to use. I'll check with Kris next week about whether the API can provide it. Where we will have to be careful is that using a classloader kind of just gives us augmentation of the classpath, we'll need to also affect the JDT resolver and prevent it finding things in these situations (if we truly want to use an entirely different classpath for the scripts). Now the script support seems to be behaving, perhaps we also need to make the change that will mean the scripts are not passed to the compiler (for a proper build), even if in a source folder (if they match the script patterns). ie. remove our old hacky way of supporting scripts.
        Hide
        Andrew Eisenberg added a comment -

        I am resolving this issue as fixed since the main part of this is done. Now, editing groovy files outside the build path is supported much more deeply. It is an entirely different problem to enhance the classpath for reconciling of these files.

        Show
        Andrew Eisenberg added a comment - I am resolving this issue as fixed since the main part of this is done. Now, editing groovy files outside the build path is supported much more deeply. It is an entirely different problem to enhance the classpath for reconciling of these files.

          People

          • Assignee:
            Andrew Eisenberg
            Reporter:
            Andrew Eisenberg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: