#1732 Classpath Plugin + jEdit Native2Ascii "ant test" target

None
closed-fixed
None
5
2014-10-16
2013-09-01
Alan Ezust
No

I am trying to build jedit using jEdit's console plugin. So I run "ant" from the "build project" command.

When I do, the native2ascii test fails:
test:
Deleting directory /home/ezust/workspace/jedit/trunk/build/test/raw-reports
Created dir: /home/ezust/workspace/jedit/trunk/build/test/raw-reports
Running org.jedit.io.Native2ASCIIEncodingTest
Tests run: 108, Failures: 0, Errors: 13, Time elapsed: 0.113 sec
Test org.jedit.io.Native2ASCIIEncodingTest FAILED
Processing /home/ezust/workspace/jedit/trunk/build/test/merged-reports/TESTS-TestSuites.xml to /tmp/null1094608422
Loading stylesheet jar:file:/home/ezust/workspace/slackerdoc/lib/ant-junit-1.8.2.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl
Transform time: 637ms
Deleting: /tmp/null1094608422

BUILD FAILED
/home/ezust/workspace/jedit/trunk/build.xml:432: Unit test(s) failed! See reports at /home/ezust/workspace/jedit/trunk/build/test/reports/index.html

Total time: 5 seconds
Process ant exited with code 1

it works fine when I use a regular shell prompt.

Discussion

1 2 > >> (Page 1 of 2)
  • Alan Ezust
    Alan Ezust
    2013-09-01

    changed the "test" from a dependency of build to an <antcall target="test"/> at the end of the target. That's a workaround but not a fix.

     
  • Björn Kautler
    Björn Kautler
    2013-09-01

    Hm, this is really strange.
    The 13 tests that use package private methods of the Test Subject in the Test Class do fail in that case with an IllegalAccessError.
    But why is this the case if called through "Compile Project" or "Run Project"?
    Anyway I think this is more a Console plugin bug than a build system bug, as it works just fine if you run "ant test" from the command line, or also from the Ant Integration of IntelliJ IDEA.
    So I guess this should be moved to plugin bugs for Console plugin.

     
  • Alan Ezust
    Alan Ezust
    2013-09-01

    I don't think it is a bug in the console plugin, because we have the same problem when we tried to automate the build with jenkins.

     
  • Björn Kautler
    Björn Kautler
    2013-09-01

    Acutally Console per-se works if I run "ant test" in the Console System shell.
    If I start jEdit, open the System Console Shell, cd to the jEdit directory and run "ant test" everything works fine. (No PV Project existing)
    As soon as I open the Project Viewer Dockable, still without any existing Project, "ant test" fails with those 13 failing tests.
    According to "Activator" Dockable the "Loaded" / "Activated" state of all plugins does not change during this.
    Jenkins could have the same bug or a similar one.
    But if it works when calling the intended tool directly (Ant) then I don't think it is a bug in the build file that should be fixed or work-arounded in the build file.

     
  • Alan Ezust
    Alan Ezust
    2013-09-01

    I wonder if the Classpath plugin is doing something funky...

     
  • Alan Ezust
    Alan Ezust
    2013-09-01

    I uninstalled the classpath plugin and the problem goes away!

     
  • Alan Ezust
    Alan Ezust
    2013-09-01

    If I have classpath loaded, but un-check "include system classpath" in in the classpath plugin options, the problem goes away.

     
  • Alan Ezust
    Alan Ezust
    2013-09-01

    • summary: Native2Ascii test fails in headless? build --> Classpath Plugin + jEdit Native2Ascii "ant test" target
    • assigned_to: vampire0 --> nobody
     
  • Björn Kautler
    Björn Kautler
    2013-09-01

    Ah, nice pin-down. :-)

     
  • Björn Kautler
    Björn Kautler
    2014-10-16

    Ok, I fixed it by forking the JUnit execution off of the Ant process and adding the needed Ant libraries manually to that process. This way no unwanted entries make it to the test classpath.

    The problem was that the Classpath plugin added the jEdit.jar file to the CLASSPATH environment variable in the Console plugin and the Ant launcher script then considered it and put it early in the classpath. This way the classes from the running jEdit, instead of the correct classes were under test and there the access problem happened when the test classes tried to access package private stuff inside the JAR, even though it is the same packet. Now the tests should work fine, no matter where you execute them from.

     
1 2 > >> (Page 1 of 2)