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 97290 - Unit tests using Retouche not working on Mac OS X
Summary: Unit tests using Retouche not working on Mac OS X
Status: RESOLVED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 6.x
Hardware: Macintosh Mac OS X
: P2 blocker (vote)
Assignee: Max Sauer
URL:
Keywords: T9Y
: 148009 159658 161172 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-03-06 15:34 UTC by Martin Adamek
Modified: 2009-07-09 05:44 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Simple ugly local workaround for test-single target (1.14 KB, text/plain)
2007-03-08 12:13 UTC, Martin Adamek
Details
Refined patch, including debugging support. (3.42 KB, text/plain)
2008-07-04 13:38 UTC, schmidtm
Details
platform-independent fix, including debugging support (14.03 KB, text/plain)
2009-03-21 13:17 UTC, Max Sauer
Details
another patch file (6.74 KB, patch)
2009-03-24 10:35 UTC, Max Sauer
Details | Diff
patch (6.59 KB, patch)
2009-03-25 13:09 UTC, Max Sauer
Details | Diff
patch (5.98 KB, patch)
2009-03-26 11:36 UTC, Max Sauer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Adamek 2007-03-06 15:34:41 UTC
Unit test are not working on Mac OS X. According to Tomas and Honza it is caused
by javac bundled in rt.jar on Mac JDK. Test infrastructure should take care
about this (see also build.xml of java/source module).
Comment 1 Martin Adamek 2007-03-06 15:35:38 UTC
I forgot to mention important thing: it is specially for unit tests using Retouche.
Comment 2 Martin Adamek 2007-03-08 12:13:02 UTC
Created attachment 39302 [details]
Simple ugly local workaround for test-single target
Comment 3 pzajac 2007-03-08 12:40:30 UTC
Thanks a lot for your patch. The boot.classpath initialization can be moved to
test-init target. The changes have to be applied also to ant scripts of xtest. 

Jesse what do you think about modification in common.xml for test run on Mac OS X?

Comment 4 Martin Adamek 2007-03-08 12:47:00 UTC
The patch is very primitive, path to Classes/*.jar is already defined somewhere
probably.
Comment 5 Jesse Glick 2007-03-12 18:29:56 UTC
Maybe there could be a property test.unit.bootcp.extra defined in appropriate
projects. I would prefer to avoid hardcoding JARs as in the current patch.
Comment 6 Martin Adamek 2007-03-12 19:25:49 UTC
> I would prefer to avoid hardcoding JARs as in the current patch.

Definitely. My patch is just simple workaround to get things working quickly.

> Maybe there could be a property test.unit.bootcp.extra defined in appropriate
projects

Problem is related to OS platform, not the project. I don't know what will be
the definite fix, but if there will be somewhere switch 'IF OSX THEN
boot_cp=...', the property should reflect that somehow: test.unit.osx.bootcp.extra ?
Comment 7 pzajac 2007-03-13 10:31:57 UTC
>Problem is related to OS platform, not the project. I don't know what will be
>the definite fix, but if there will be somewhere switch 'IF OSX THEN
>boot_cp=...', the property should reflect that somehow: 
>test.unit.osx.bootcp.extra ?

It becomes to be quite complicated. The same property have to be propagated to 
xtest. It  works on all platforms if you add these items
${nb_all}/java/external/javac-api.jar"
${nb_all}/java/external/javac-impl.jar"

before default boot classpath, isn't it. We can use  test.unit.bootcp.extra 
for all platforms.
 
Comment 8 Martin Adamek 2007-03-13 10:44:04 UTC
Sure. If Tomas and Honza don't have any objections, I am fine with that.
Comment 9 pzajac 2007-06-13 15:10:22 UTC
For example I tried to modify bootclasspath for my Linux.

    <junit showoutput="true" fork="true" failureproperty="tests.failed" errorproperty="tests.failed"
filtertrace="${test.filter.trace}" tempdir="${build.test.unit.results.dir}">
            <batchtest todir="${build.test.unit.results.dir}">
                <fileset dir="${build.test.unit.classes.dir}">
                    <include name="**/*Test.class"/>
                </fileset>
            </batchtest>
            <bootclasspath>
                <pathelement path="${java.home}/jre/lib/rt.jar"/>
                <pathelement path="${nb_all}/java/external/javac-api.jar"/>
                <pathelement path="${nb_all}/java/external/javac-impl.jar"/>
            </bootclasspath>
            <classpath refid="test.unit.run.cp"/>
            <syspropertyset refid="test.unit.properties"/>
            <jvmarg value="-ea"/>
            <formatter type="brief" usefile="false"/>
            <formatter type="xml"/>
        </junit>

It throws NPE :
java/lang/NoClassDefFoundError: java/lang/Object

I am not feeling  comfortable to fix this issue.  
Comment 10 Jesse Glick 2007-06-15 21:49:52 UTC
Since I have no Mac machine to test on, I do not plan to touch this. If someone else wants to propose a patch, I will
review it.
Comment 11 Tomas Zezula 2007-06-18 09:52:41 UTC
I will try to borrow some Mac and create a patch.
Comment 12 Antonin Nebuzelsky 2007-10-30 14:20:06 UTC
P3, future for now.
Comment 13 schmidtm 2008-07-02 17:23:15 UTC
Can't we do something like this:

  <condition property="isMacOX">
    <and>
      <os family="mac"/>
      <os family="unix"/>
    </and>
  </condition>

...

  <path id="additional.mac.cp">
	<pathelement path="${nb_all}/libs.javacapi/external/javac-api-nb-7.0-b07.jar"/>
        <pathelement path="${nb_all}/libs.javacimpl/external/javac-impl-nb-7.0-b07.jar"/>
        <pathelement path="/System/Library/Frameworks/JavaVM.framework/Classes/classes.jar"/>
        <pathelement path="/System/Library/Frameworks/JavaVM.framework/Classes/laf.jar"/>
        <pathelement path="/System/Library/Frameworks/JavaVM.framework/Classes/ui.jar"/>
  </path>

...

And and in the tasks/macros based on the condition:

<bootclasspath refid="additional.mac.cp"/>
Comment 14 schmidtm 2008-07-04 13:37:15 UTC
Here's a new version of the patch - alas it still has to be applied manually, since conditionals are only allowed on targets in ant but not on path's. 
Comment 15 schmidtm 2008-07-04 13:38:33 UTC
Created attachment 63946 [details]
Refined patch, including debugging support.
Comment 16 Martin Schovanek 2008-09-23 14:04:49 UTC
*** Issue 148009 has been marked as a duplicate of this issue. ***
Comment 17 Max Sauer 2009-03-19 10:34:36 UTC
*** Issue 159658 has been marked as a duplicate of this issue. ***
Comment 18 Max Sauer 2009-03-19 10:37:33 UTC
Upgrading to priority of a duplicate. Reassigning to me.
Comment 19 Max Sauer 2009-03-21 13:17:43 UTC
Created attachment 78570 [details]
platform-independent fix, including debugging support
Comment 20 Max Sauer 2009-03-21 13:22:11 UTC
Here's a patch, it's rather complicated because of ant restrictions. In case there will be no objections, I'll do some testing and integrate it next week.
Comment 21 Jesse Glick 2009-03-21 18:57:41 UTC
Do not modify semantics of common.xml for something that is specific to a handful of nb.org modules.

Patch looks much too complicated to me. Would seem to be much easier to always define bootpath.prepend, but
conditionally set it to a real value if=is.mac (otherwise to "").

You can use <pathconvert> to define it as a fileset so you can use wildcards rather than hardcoding version numbers in
JAR names. In fact the <path> named javacimpl in projectized.xml may be all you need (this is OpenJDK 6 but probably fine).

@{disable.apple.ui} is a macro param and will not be propagated thru <antcall> I think.

In sum, I would recommend having common.xml just look for ${bootclasspath.mac} with a fallback value of "", and in
projectized.xml something like:

<condition name="bootclasspath.mac" refid="javacimpl">
  <os family="mac"/>
</>

Richard should approve any patch in this area. I would also be more comfortable with an optional new property that would
be defined only in selected projects which are known to make use of java.source classes, rather than modifying the
behavior of all module projects, including the great majority which are fine as they are.
Comment 22 Max Sauer 2009-03-21 23:57:51 UTC
Thanks for your comments, Jesse. Empty bootclasspath for other platforms sounds as best solution.
Comment 23 Max Sauer 2009-03-24 10:33:01 UTC
I've prepared a new patch (mac-tests-v2.diff).

> In fact the <path> named javacimpl in projectized.xml may be all you need (this is OpenJDK 6 but probably fine).
This does not suffice, a reference to our javac jars has to be created (in projectized.xml, see diff).

Models requiring out javac have to define something like 

<target name="test-preinit" depends="init">
        <property name="requires.nb.javac" value=""/>
</target>

in their build scripts from now on, is that what you mean?

I've tested this on Mac and Linux and haven't encountered any problems.

Jesse or Richard, could you please make another review? Thank you very much.




Comment 24 Max Sauer 2009-03-24 10:35:04 UTC
Created attachment 78723 [details]
another patch file
Comment 25 Jesse Glick 2009-03-24 16:36:09 UTC
bootclasspath.mac has to be defaulted to "" in common.xml or you will cause a mess for external modules.

requires.nb.javac should be set to true or false, not the empty string. (Use <istrue>.) And when set, it should be
defined in project.properties, not the build script.

Delete the extra <echo>.

<path id="retouche.javac">...</><pathconvert property="retouche.javac" refid="retouche.javac"/> could be simplified to
either <pathconvert property="retouche.javac">...</> or <path id="retouche.javac">...</><property name="retouche.javac"
refid="retouche.javac"/>.

I am concerned about the addition of a new <bootclasspath> to <junit>. If ${nbjdk.bootclasspath} was not quite precise,
this could affect test runs for unrelated modules. Would prefer use of -Xbootclasspath/p with just ${bootclasspath.mac}
if that is possible.
Comment 26 Max Sauer 2009-03-25 13:09:56 UTC
Created attachment 78814 [details]
patch
Comment 27 Max Sauer 2009-03-25 13:12:32 UTC
I've made requested changes. -Xbootclasspath/p works OK, thanks for all you hints Jesse.
Comment 28 Jesse Glick 2009-03-25 14:36:24 UTC
bootclasspath.mac may need to be defaulted before test-init, since the <javac> presetdef is used for non-test
compilation too. Otherwise the unevaluated string "${bootclasspath.mac}" will be included in <javac>'s bootcp, which
might cause some kind of issue.

On non-Macs, does passing "-Xbootclasspath/p:" (empty) cause any harm? Doesn't seem to hurt anything on Linux.
Comment 29 Max Sauer 2009-03-26 11:36:05 UTC
Created attachment 78894 [details]
patch
Comment 30 Max Sauer 2009-03-26 11:39:45 UTC
Hopefully final patch version. ${bootclasspath.mac} is initialized in projectized.xml's build-init, with fallback to "" using ant condition "else" parameter.
Comment 31 Rastislav Komara 2009-03-26 15:14:36 UTC
*** Issue 161172 has been marked as a duplicate of this issue. ***
Comment 32 Michal Zlamal 2009-03-26 16:40:07 UTC
Raising to P1 because it was resolved duplicate to #161172
Comment 33 Jesse Glick 2009-03-26 16:58:34 UTC
The last patch will leave the property unset, hence using the literal value "${bootclasspath.mac}", for external
modules. You could default it to "" in apisupport.harness/release/build.xml but this poses potential version skew
issues. I would rather suggest getting rid of the 'else' clause and instead just add

<property name="bootclasspath.mac" value=""/>

to common.xml#-javac-init.
Comment 34 Max Sauer 2009-03-26 19:18:25 UTC
This surely cannot be a P1 if it slipped two releases as a P3...
Comment 35 Max Sauer 2009-03-26 19:28:59 UTC
> I would rather suggest getting rid of the 'else' clause and instead just add
>   <property name="bootclasspath.mac" value=""/>
> to common.xml#-javac-init.

Done, thanks. Will be part of my next push as soon as M3 cloning will be finished.
Comment 37 Quality Engineering 2009-03-28 20:50:11 UTC
Integrated into 'main-golden', will be available in build *200903281400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/db7e8e910073
User: Max Sauer <msauer@netbeans.org>
Log: #97290: Unit tests using Retouche not working on Mac OS X
Comment 38 Quality Engineering 2009-07-09 05:44:44 UTC
Integrated into 'main-golden', will be available in build *200907090200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/0311cf96ed75
User: Jesse Glick <jglick@netbeans.org>
Log: #97290 is already applied.