groovy
  1. groovy
  2. GROOVY-3041

Support for adding default imports

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.5.6
    • Fix Version/s: None
    • Component/s: class generator
    • Labels:
      None
    • Number of attachments :
      0

      Description

      It would be nice if users could customize the default imports by adding packages.

        Activity

        Hide
        blackdrag blackdrag added a comment -

        could you explain a little what you suggest?

        Show
        blackdrag blackdrag added a comment - could you explain a little what you suggest?
        Hide
        Alexander Veit added a comment -

        org.codehaus.groovy.control.ResolveVisitor#DEFAULT_IMPORTS defines

        java.lang.*
        java.io.*
        java.net.*
        java.util.*
        groovy.lang.*
        groovy.util.*

        as those packages that need no explicit import statement.

        Applications that embed Groovy in order to get scripting capabilities will often provide packages that are frequently used within scripts. It would be nice if such packages could be added to the default import packages when setting up the Groovy system.

        Show
        Alexander Veit added a comment - org.codehaus.groovy.control.ResolveVisitor#DEFAULT_IMPORTS defines java.lang.* java.io.* java.net.* java.util.* groovy.lang.* groovy.util.* as those packages that need no explicit import statement. Applications that embed Groovy in order to get scripting capabilities will often provide packages that are frequently used within scripts. It would be nice if such packages could be added to the default import packages when setting up the Groovy system.
        Hide
        blackdrag blackdrag added a comment -

        this is possible already if you have control over the compilation process... Because then you can do:

                cu.addPhaseOperation(new SourceUnitOperation() {
                    public void call(SourceUnit source) throws CompilationFailedException {
                        source.getAST().addImport("User",ClassHelper.make("my.company.UserDAO"));
                    }
                },Phases.CONVERSION);

        cu is the CompilationUnit. Is this not enough for you?

        Show
        blackdrag blackdrag added a comment - this is possible already if you have control over the compilation process... Because then you can do: cu.addPhaseOperation( new SourceUnitOperation() { public void call(SourceUnit source) throws CompilationFailedException { source.getAST().addImport( "User" ,ClassHelper.make( "my.company.UserDAO" )); } },Phases.CONVERSION); cu is the CompilationUnit. Is this not enough for you?
        Hide
        Alexander Veit added a comment -

        Your sample works for single classes. I've played around with sth. like

        class DefaultImportSourceUnitOperation extends SourceUnitOperation {
            public void call(SourceUnit source) throws CompilationFailedException {
                source.getAST().addImportPackage("pkg1.pgk2.pkg3");
            }
        }
        
        class DefaultImportClassLoader extends GroovyClassLoader {
            protected CompilationUnit createCompilationUnit(CompilerConfiguration config, CodeSource codeSource) {
                CompilationUnit cu = super.createCompilationUnit(config, codeSource)
        
                cu.addPhaseOperation(new DefaultImportSourceUnitOperation(), Phases.CONVERSION)
        
                return cu
            }
        }
        

        which doesn't work. Probably I'm doing sth. wrong but the documentation is really poor at this time. So I had to dive deeper into this matter.

        However, are there any arguments against letting configure the default import packages instead of writing AST transformation code?

        Show
        Alexander Veit added a comment - Your sample works for single classes. I've played around with sth. like class DefaultImportSourceUnitOperation extends SourceUnitOperation { public void call(SourceUnit source) throws CompilationFailedException { source.getAST().addImportPackage( "pkg1.pgk2.pkg3" ); } } class DefaultImportClassLoader extends GroovyClassLoader { protected CompilationUnit createCompilationUnit(CompilerConfiguration config, CodeSource codeSource) { CompilationUnit cu = super .createCompilationUnit(config, codeSource) cu.addPhaseOperation( new DefaultImportSourceUnitOperation(), Phases.CONVERSION) return cu } } which doesn't work. Probably I'm doing sth. wrong but the documentation is really poor at this time. So I had to dive deeper into this matter. However, are there any arguments against letting configure the default import packages instead of writing AST transformation code?
        Hide
        Arek Stryjski added a comment -

        "Jochen Theodorou added a comment - 17/Sep/08 05:40 PM
        this is possible already if you have control over the compilation process... "

        You mean we should not use GroovyShell but write our own class which will replace it, right?
        In this way we will be able to force it to use our own ClassLoader not default GroovyClassLoader.

        addImport() works but addImportPackage() not
        It is a bit incontinent, but as API will have limited number of classes I can use addImport()

        By the way do you know how to stop users from using some classes?
        In our application we have classes with set and get methods. We would like to give users only read access in scripts, so the public API classes will have only get methods. I would like to prevent users from importing and using classes from some packages. Is it possible in some easy way by extending GroovyClassLoader or other class?

        Show
        Arek Stryjski added a comment - "Jochen Theodorou added a comment - 17/Sep/08 05:40 PM this is possible already if you have control over the compilation process... " You mean we should not use GroovyShell but write our own class which will replace it, right? In this way we will be able to force it to use our own ClassLoader not default GroovyClassLoader. addImport() works but addImportPackage() not It is a bit incontinent, but as API will have limited number of classes I can use addImport() By the way do you know how to stop users from using some classes? In our application we have classes with set and get methods. We would like to give users only read access in scripts, so the public API classes will have only get methods. I would like to prevent users from importing and using classes from some packages. Is it possible in some easy way by extending GroovyClassLoader or other class?
        Hide
        blackdrag blackdrag added a comment -

        Alexander... how would you define the default import packages?

        Arek, if you use a subclass of GroovyClassLoader you can do it like Alexander did.

        As for addImportPackage(), this wants to have the packe plus ".". That is because of historic reasons, so don't ask Anyway, if you want to import foo.bar.*, then you have to call addImportPackage("foo.bar.")

        As for preventing a user to use certain classes. I suggest you add a phase operation that checks each ClassExpression for a usage of that class. In the Groovy ditstribution since 1.6-beta2 and 1.5.7 you should find in the examples directory an example called ArithmeticShell. This shell does for example forbid the usage of certain classes. So look at that example.

        Show
        blackdrag blackdrag added a comment - Alexander... how would you define the default import packages? Arek, if you use a subclass of GroovyClassLoader you can do it like Alexander did. As for addImportPackage(), this wants to have the packe plus ".". That is because of historic reasons, so don't ask Anyway, if you want to import foo.bar.*, then you have to call addImportPackage("foo.bar.") As for preventing a user to use certain classes. I suggest you add a phase operation that checks each ClassExpression for a usage of that class. In the Groovy ditstribution since 1.6-beta2 and 1.5.7 you should find in the examples directory an example called ArithmeticShell. This shell does for example forbid the usage of certain classes. So look at that example.
        Hide
        Arek Stryjski added a comment -

        Great, thanks for a tip with "." Now it works.
        I will also look at this examples.

        Thanks a lot.

        Show
        Arek Stryjski added a comment - Great, thanks for a tip with "." Now it works. I will also look at this examples. Thanks a lot.

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            Alexander Veit
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: