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.
The current changes to junit contain some assumptions and designs that are not matched by all project types, eg. maven based ones. 1. SourceLevelQuery doesn't have to return a value (as stated in javadoc) which is contrary to the assetions in current junit codebase 2. juit support assumes Junit library is in test classpath and doesn't update it if user picks a given junit version 3. the Junit library as currently defined (both versions of junit in one library definition) is not compatible with the way maven operates, there always just one version per artifact is allowed. 2+3 can be solved together by having 2 distinct libraries and adding/removing them according to the user preferences (via the ClassPatchModifier or ClassPathExtender interfaces). On top of that the JUnit support would not require any persistent data in the project.xml, but could just consult the classpath of the project and look for a class from the given version of the junit library and handle accordingly. That way even maven or freeform projects could be easily supported out of the box (without persisting any settings)
Issue 2. and 3. were solved by changes made to fix issue #101499 ("Do not store http://www.netbeans.org/ns/junit/1 fragment"). I am going to fix the remaining issue with SourceLevelQuery.
Fixed in the trunk. Modified files: junit/src/org/netbeans/modules/junit/: DefaultPlugin.java (1.17) Bundle.properties (1.90) Diffs: http://junit.netbeans.org/source/browse/junit/src/org/netbeans/modules/junit/DefaultPlugin.java?r1=1.16&r2=1.17&diff_format=u http://junit.netbeans.org/source/browse/junit/src/org/netbeans/modules/junit/Bundle.properties?r1=1.89&r2=1.90&diff_format=u
*** Issue 118997 has been marked as a duplicate of this issue. ***