groovy

Joint Compilation fails on the command line

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.5.4, 1.5.5, 1.6-beta-1
  • Fix Version/s: 1.5.6, 1.6-beta-1
  • Component/s: None
  • Labels:
    None
  • Environment:
    cartesian join of [1.5.4, svn trunk] [windows, ubuntu]
  • Number of attachments :
    1

Description

The -j option on the command line for groovy fails.

The attached patch fixes it in svn trunk. I'll let this bug set a few days for comments and then commit the patch to trunk and branches/GROOVY_1_5_X unless there is objection.

C:\temp>groovyc -j Foo.java Bar.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, Compile error during compilation with javac.
C:\DOCUME~1\DANNO~1.FER\LOCALS~1\Temp\groovy-generated-46386-java-source\joint\Bar.java:3: package groovy.util does not exist
import groovy.util.*;
^
C:\DOCUME~1\DANNO~1.FER\LOCALS~1\Temp\groovy-generated-46386-java-source\joint\Bar.java:7: package groovy.lang does not exist
import groovy.lang.*;
^
C:\DOCUME~1\DANNO~1.FER\LOCALS~1\Temp\groovy-generated-46386-java-source\joint\Bar.java:12: package groovy.lang does not exist
    groovy.lang.GroovyObject {
               ^
C:\DOCUME~1\DANNO~1.FER\LOCALS~1\Temp\groovy-generated-46386-java-source\joint\Bar.java:13: package groovy.lang does not exist
groovy.lang.MetaClass metaClass;
           ^
C:\DOCUME~1\DANNO~1.FER\LOCALS~1\Temp\groovy-generated-46386-java-source\joint\Bar.java:15: package groovy.lang does not exist
public groovy.lang.MetaClass getMetaClass() { return (groovy.lang.MetaClass)null;}
                  ^
C:\DOCUME~1\DANNO~1.FER\LOCALS~1\Temp\groovy-generated-46386-java-source\joint\Bar.java:21: package groovy.lang does not exist
public void setMetaClass(groovy.lang.MetaClass value) { }
                                    ^
C:\DOCUME~1\DANNO~1.FER\LOCALS~1\Temp\groovy-generated-46386-java-source\joint\Bar.java:15: package groovy.lang does not exist
public groovy.lang.MetaClass getMetaClass() { return (groovy.lang.MetaClass)null;}
                                                                 ^
7 errors


1 error
Foo.java
package joint;

class Foo {
  Bar baz;
}
Bar.groovy
package joint

class Bar {
  String s
}

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

if this is a general problem, then why does it work one time and the other time it does not? I think it is interesting to note, that if Foo is an empty class, that the compilation will not fail then.

Show
blackdrag blackdrag added a comment - if this is a general problem, then why does it work one time and the other time it does not? I think it is interesting to note, that if Foo is an empty class, that the compilation will not fail then.
Hide
Permalink
Danno Ferrin added a comment -

The reason it works in ant is because the groovy runtime is explicitly added to the groovyc invocation, which is passed onto the javac process. The command line in this bug passes in no classpath.
As to why it works when the java classes have no dependency on the groovy classes has to do with how javac works. Only the native java classes needing compilation are passed into the javac call, so whether or not foo is empty only Foo.java is passed in as an argument, not the Bar.groovy stub. When compiling an empty or non-dependent foo javac never needs to look at any of the stubs, so it doesn't try. But when we reference a stub class javac then trys to resolve the class or compile the stub. Since the stubed Bar.java is in the sourcepath passed into javac in the expected palace, javac then tries to compile it. Javac, however, only looks to the command line classpath to get classes. Even though groovy is in the system classpath javac won't look there (unlike groovyc). Hence the jar containing the groovy classes needs to be passed in the javac -classpath argument.

We could require the user to do this, but this seems surprising to the user. This is also difficult because the name of the groovy jar always changes between versions (unlike java's rt.jar), and the location may be quite inconvenient, depending on where you installed groovy. Even worse, it may need to be the same version jar that groovyc is compiling against to insure API compatibility, since we don't support cross-version compilation..

Show
Danno Ferrin added a comment - The reason it works in ant is because the groovy runtime is explicitly added to the groovyc invocation, which is passed onto the javac process. The command line in this bug passes in no classpath. As to why it works when the java classes have no dependency on the groovy classes has to do with how javac works. Only the native java classes needing compilation are passed into the javac call, so whether or not foo is empty only Foo.java is passed in as an argument, not the Bar.groovy stub. When compiling an empty or non-dependent foo javac never needs to look at any of the stubs, so it doesn't try. But when we reference a stub class javac then trys to resolve the class or compile the stub. Since the stubed Bar.java is in the sourcepath passed into javac in the expected palace, javac then tries to compile it. Javac, however, only looks to the command line classpath to get classes. Even though groovy is in the system classpath javac won't look there (unlike groovyc). Hence the jar containing the groovy classes needs to be passed in the javac -classpath argument. We could require the user to do this, but this seems surprising to the user. This is also difficult because the name of the groovy jar always changes between versions (unlike java's rt.jar), and the location may be quite inconvenient, depending on where you installed groovy. Even worse, it may need to be the same version jar that groovyc is compiling against to insure API compatibility, since we don't support cross-version compilation..
Hide
Permalink
Paul King added a comment -

Danno, saw your commited (commented out) test case. Does your patch fix that test case?

Show
Paul King added a comment - Danno, saw your commited (commented out) test case. Does your patch fix that test case?
Hide
Permalink
Danno Ferrin added a comment -

yes, but I got another patch that I think is better, let me spend some time writing a post to the dev list. This test was submitted to get feedback to see if it fails elsewhere, such as on any g2one machine

Show
Danno Ferrin added a comment - yes, but I got another patch that I think is better, let me spend some time writing a post to the dev list. This test was submitted to get feedback to see if it fails elsewhere, such as on any g2one machine
Hide
Permalink
Paul King added a comment -

add code tags

Show
Paul King added a comment - add code tags
Hide
Permalink
Paul King added a comment -

Confirming that I have the problem locally as mentioned here and the patches/commits fix this issue. I must admit though that I haven't had time to investigate further regarding the impact of the fix.

Show
Paul King added a comment - Confirming that I have the problem locally as mentioned here and the patches/commits fix this issue. I must admit though that I haven't had time to investigate further regarding the impact of the fix.

People

  • Assignee:
    Unassigned
    Reporter:
    Danno Ferrin
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: