Results 1 to 6 of 6

Thread: spurious compiler errors

  1. #1

    Default spurious compiler errors

    I am using STS 2.3.3.M2; I am building a grails application.

    All of a sudden I have started seeing compiler errors in my domain classes in a large project that has no problems up to now.

    The project compiles just fine from the shell, but the IDE is unable to resolve a class reference to one of my classes. This application was converted from an old grails 1.0.x version; its domain classes are in the default namespace.

    It's hard to see how to build a small test application from this, given that the code has over a dozen domain classes.

    Is there anything obvious I should try to test?

    Gene

  2. #2

    Default

    Followup:

    The compiler complains about the following lines:

    Code:
    class User {
    	String name
    ...
    	Camera defaultCamera()
    	{
    		return Camera.findByOwner(this)
    	}
    }
    
    class Camera {
    	
    	String name
    	User owner
    ...
    	
    	static belongsTo=[User]
    }
    The compiler indicates an error in the belongsTo line in the Camera class, and in the defaultCamera() method of the User class.

    When I created a test project with just the code shown above, I got no compiler errors. As noted in my previous message, the full code also compiles and runs from the commandline with no issues. (yes, I've cleaned the project before compiling.)

    Thoughts?

    Gene

  3. #3

    Default

    more info:

    When I removed the defaultCamera() method, the compiler error switched to a new domain class, Role. If I remove all references to Role, the User code compilers (but of course won't run). When I put the defaultCamera() method back, it was not flagged as an error any more, but the Role errors remained. Here is the stack trace from the associated 'Groovy bug when compiling' error in the log:

    Code:
    BUG! exception in phase 'semantic analysis' in source unit '/ReBoard-1.2/grails-app/domain/User.groovy'
    at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:944)
    at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:574)
    at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:550)
    at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:527)
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:162)
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.resolve(GroovyCompilationUnitDeclaration.java:1692)
    at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:961)
    at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1006)
    at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:201)
    at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:262)
    at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190)
    at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
    at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
    at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
    at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:432)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
    at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
    at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
    at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102)
    at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
    at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
    Caused by: org.eclipse.jdt.internal.compiler.problem.AbortCompilation:
    at org.eclipse.jdt.internal.core.CancelableNameEnvironment.checkCanceled(CancelableNameEnvironment.java:34)
    at org.eclipse.jdt.internal.core.CancelableNameEnvironment.findType(CancelableNameEnvironment.java:44)
    at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:130)
    at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2616)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2375)
    at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitScope.lookupClassNodeForSource(GroovyCompilationUnitScope.java:172)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolveFromCompileUnit(JDTResolver.java:145)
    at org.codehaus.groovy.control.ResolveVisitor.resolveNestedClass(ResolveVisitor.java:304)
    at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:276)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.resolve(JDTResolver.java:260)
    at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:243)
    at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:226)
    at org.codehaus.groovy.control.ResolveVisitor.resolveOrFail(ResolveVisitor.java:238)
    at org.codehaus.groovy.control.ResolveVisitor.visitProperty(ResolveVisitor.java:189)
    at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1080)
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
    at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1304)
    at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:150)
    at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.startResolving(JDTResolver.java:571)
    at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:680)
    at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:935)
    ... 24 more

  4. #4
    Join Date
    May 2009
    Location
    Vancouver
    Posts
    274

    Default

    Any errors that contain the bit:

    Caused by: org.eclipse.jdt.internal.compiler.problem.AbortCom pilation:
    at org.eclipse.jdt.internal.core.CancelableNameEnviro nment.checkCanceled(CancelableNameEnvironment.java :34)
    at org.eclipse.jdt.internal.core.CancelableNameEnviro nment.findType(CancelableNameEnvironment.java:44)
    you can usually ignore. Abort happens because something was happening that is no longer relevant so Eclipse cancelled the activity.

    I presume this isn't the error you are actually getting against the domain class - what is the actual text of the error you see in the problems view for this?

    I would recommend updating to the latest groovy eclipse dev build which has specific changes in the areas relating to AbortCompilation logging and 'unable to resolve a class reference'. 90% of the time when I've seen 'unable to resolve a class reference' it means there is a real problem with the project, but it is being hidden by that invalid error.

    Dev build update site is:
    http://dist.codehaus.org/groovy/dist...snapshot/e3.6/

    Andy

  5. #5

    Default

    Thanks! When I ran updates, the problem went away. How often do you recommend to check for updates, given that it takes some time to run then?

  6. #6
    Join Date
    May 2009
    Location
    Vancouver
    Posts
    274

    Default

    We usually put up quite a few releases a week on the snapshot site. Finding and updating shouldn't take that long, unless you happen to be using the 'check all update sites' (something like that) option on the update page, uncheck that if just going after a groovy eclipse update.

    If there are major fixes that we really want people to use then we'd probably post a note on the groovy eclipse mailing list, and possibly here.

    Andy

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •