This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 208032 - Unable to test Project
Summary: Unable to test Project
Status: RESOLVED WORKSFORME
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 7.1
Hardware: PC Windows 7
: P2 normal (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-02 19:48 UTC by javydreamercsw
Modified: 2012-03-30 14:10 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description javydreamercsw 2012-02-02 19:48:47 UTC
Product Version = NetBeans IDE 7.1 (Build 201112071828)
Operating System = Windows 7 version 6.1 running on x86
Java; VM; Vendor = 1.7.0_02
Runtime = Java HotSpot(TM) Client VM 22.0-b10

I have a web project I've been developing for a while. I started it on NetBeans 6.9.1. I started adding unit tests to it and suddenly it stopped working. (the unit tests) with this error:

Z:\NetBeans\Xinco\xinco\XincoWebApp\nbproject\build-impl.xml:1092: The following error occurred while executing this line:
Z:\NetBeans\Xinco\xinco\XincoWebApp\nbproject\build-impl.xml:356: The <classpath> for <junit> must include junit.jar if not in Ant's own classpath

After lots of debugging I noticed that for some reason the libraries are not resolved on the ant task. I added an echo with this result:

${libs.metro.classpath}:../XincoLibs/gsp.jar:../XincoLibs/log4j-1.2.16.jar:../XincoLibs/lucene-core-3.4.0.jar:../Xinco/dist/Xinco.jar:../XincoExplorer/dist/XincoExplorer.jar:${libs.MySQLDriver.classpath}:../XincoLibs/h2-1.3.161.jar:../XincoLibs/Vaadin Addons/easyuploads-0.4.9.jar:../XincoLibs/Vaadin Compilation/gwt-dev.jar:../XincoLibs/Vaadin Compilation/validation-api-1.0.0.GA.jar:../XincoLibs/lucene-demos-3.0.3.jar:../XincoLibs/Vaadin Compilation/gwt-user.jar:../XincoLibs/vaadin-6.7.3.jar:../XincoLibs/tika-app-1.0.jar:../XincoLibs/tm-extractors-1.0.jar:../XincoLibs/commons-codec-1.5.jar:../XincoLibs/commons-dbcp-1.4.jar:../XincoLibs/jodconverter/commons-cli-1.1.jar:../XincoLibs/jodconverter/commons-io-1.4.jar:../XincoLibs/jodconverter/jodconverter-core-3.0-beta-4.jar:../XincoLibs/jodconverter/json-20090211.jar:../XincoLibs/jodconverter/juh-3.2.1.jar:../XincoLibs/jodconverter/jurt-3.2.1.jar:../XincoLibs/jodconverter/ridl-3.2.1.jar:../XincoLibs/jodconverter/unoil-3.2.1.jar:../XincoLibs/commons-collections-3.2.1.jar:../XincoLibs/commons-pool-1.5.6.jar:../XincoLibs/Base64-0.91.jar:../XincoLibs/org-openide-util-lookup.jar:../XincoLibs/Vaadin Addons/stepper-1.1.0.jar:${libs.javaee-endorsed-api-6.0.classpath}:../XincoLibs/Vaadin Addons/expandingtextarea-0.1.jar:../XincoLibs/vaadin-chameleon-theme-1.1.0.jar:${libs.eclipselink.classpath}:../XincoLibs/Vaadin Addons/lucenecontainer-1.0.2.jar:../XincoLibs/Vaadin Addons/JPA Container/vaadin-jpacontainer-agpl-3.0-2.0.0-RC1.jar:../XincoLibs/Vaadin Compilation/validation-api-1.0.0.GA-sources.jar:${libs.CopyLibs.classpath}:build/web/WEB-INF/classes:${libs.junit_4.classpath}:build/test/classes:../Xinco/dist/Xinco.jar:../XincoLibs/h2-1.3.161.jar:${libs.junit_4.classpath}

As you can see from the output above, for some reason the ant target is not seeing the library variables. That explains the error but why is this? I tried deleting the build.xml file to have it regenerated without luck. If I add a jar dependency in compile tests to the same jar referenced by the library it does work (test fails but do to the other libraries needing the same workaround)

The project compiles and has no red badges. The source can be found here: https://xinco.svn.sourceforge.net/svnroot/xinco/trunk.

I was unable to create a simple test case as this issue doesn't happen with projects created from scratch.
Comment 1 javydreamercsw 2012-02-07 21:02:51 UTC
I got the same issue on a Java project, so it seems to be a more generic issue.

The project compiles and has no red badges. The source can be found here:
https://bitbucket.org/javydreamercsw/jwrestling.
Comment 2 javydreamercsw 2012-02-08 13:25:25 UTC
This is the change set that broke the build: https://bitbucket.org/javydreamercsw/jwrestling/changeset/28dbc438a052

I believe is the fact that the definitions within the nblibraries.properties file are not injected into the system so the libraries are found. I tried adding the properties file but had no luck.
Comment 3 Petr Hejl 2012-03-29 14:57:13 UTC
User reports it is happening for J2SE project as well. Might be a problem with sharable libs.
Comment 4 Jesse Glick 2012-03-29 18:27:23 UTC
${libs.junit_4.classpath} is unevaluated, meaning that the lib definition is not working.

I checked out the provided repo and ran tests on the j2seproject:

ant -f /tmp/jwrestling/jWrestling -Dignore.failing.tests=true test

Seemed to work fine. So maybe some bad definitions in your environment, etc. Try to work out a minimal test case.
Comment 5 javydreamercsw 2012-03-29 19:19:54 UTC
In which version of the IDE did you try it? I just tried it on 7.2 (Daily builds) and it worked. Will switch to 7.1.1 and report back.
Comment 6 javydreamercsw 2012-03-29 19:23:44 UTC
It working on 7.1.1. I reported against 7.1 but it seems to work now.
Comment 7 David Konecny 2012-03-29 20:44:22 UTC
(In reply to comment #2)
> https://bitbucket.org/javydreamercsw/jwrestling/changeset/28dbc438a052

Looking at the changeset I noticed there are two references to value "../jWrestlingLibs\nblibraries.properties" - maybe backslash is causing the problem??
Comment 8 javydreamercsw 2012-03-29 22:10:52 UTC
I gave it a try and seems to be working fine, but again, it was working fine without that change. That should be checked/fixed sine that's an IDE generated file.
Comment 9 Jesse Glick 2012-03-30 14:10:57 UTC
(In reply to comment #7)
> maybe backslash is causing the problem?

I think this should be OK even on Unix, at least for the Ant build aspect, since Ant permits both / and \ as path separators on all platforms. Nonetheless it is poor style to be mixing these, of course; conventionally we use / for relative path fragments regardless of platform. If it is reproducible that \ gets used in relative paths (I guess when edited on Windows) then that would be a separate P4 bug, but I doubt that is the cause of the reported problem.