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 only current option how to display UI from a test run for custom project is to rely on Ant logger in JUnit module. This is not sufficient for Android module - it can run all project tests with Ant but it needs to communicate with test process in a different way if one test is executed. I suggest to add org.netbeans.modules.android.testrunner as a friend of gsf.testrunner or make gsf.testrunner API public. There are already 8 friends so the API seems good enough for Java projects of different types as well as for other languages.
Can anyone take a look at this? 7.0 release seems imminent and missing this opportunity means another months before we will be able to provide reasonable integration.
Fixed for dev in core-main f67c366e98ac and will see if it can be put in 7.0 even though it is not technically a defect. (There are a number of known flaws in the API - bug #158018 and bug #159570 at least - so I would recommend a review before trying to make it public. Would be a separate issue for 7.1.)
(In reply to comment #2) > Fixed for dev in core-main f67c366e98ac and will see if it can be put in 7.0 > even though it is not technically a defect. I agree with integration into release70.
I'd like to see a plan to eliminate the friend restriction and expose the API to public. When such plan exist, I am OK with adding new friend one release before the API becomes public and stable.
To Jarda: bug #158018 tracks stable API for contributions to test result window. Adding friend now will help me to give you feedback for this stabilization in next release cycle. Does it sound acceptable for you now?
Integrated into 'main-golden', will be available in build *201103240400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f67c366e98ac User: Jesse Glick <jglick@netbeans.org> Log: #196890: add android.testrunner as a friend.
(In reply to comment #5) > To Jarda: bug #158018 tracks stable API for contributions > friend now will help me to give you feedback for this To translate: #158018 is not a bug, but enhancement. It is not assigned to anybody. Therefore there is nobody to give feedback to. Not mentioning that as soon as friends get their privildges they loose all their motivation to do anything else. What should happen is to find someone to go through the API, move all useless classes outside of the API package or make them package private. Describe what the API is supposed to do and publish it. I don't believe adding more friends will help with the above at all. Quite contrary.
To Jarda's comment #7: Bug vs. enhancement I am not willing to comment except that the whole policy that prevents me to reuse existing code is a bug (or problem) for me as a developer of an extension for this IDE. Assigned to nobody: RFEs were not assigned until someone started to work on them. How does it apply? Anyway it sounds like internal decision within Oracle that I cannot change. Or should I assign it to myself? I promised to help you with stabilization. But I won't commit my time into this if I cannot see any results in foreseeable future. Going through API review for 7.0 is not realistic at this moment. So what do you suggest? Are you going to block the integration?
Discussions of API status post-7.0 are out of place in this issue; a basic piece of 7.0 IDE functionality is inaccessible to the Android support, and that is trivial to fix in the short term: releases #53c0f522d7c2
(In reply to comment #8) > Anyway it sounds like internal decision within Oracle > that I cannot change. Or should I assign it to myself? Yes, that would be the most productive way to get this functionality exposed to Android and other potential users in a standard way. > I promised to help you > with stabilization. But I won't commit my time into this if I cannot see any > results in foreseeable future. Whether you can see results in foreseeable future depends mostly on your commitment. Sounds like catch 22. > Going through API review for 7.0 is not realistic at this moment. No. > So what do you suggest? I'd suggest to prepare the API changes on a branch. When it is clear that there is a long term proper fix, applying short term hacks like > trivial to fix in the short term: releases #53c0f522d7c2 would worry me less because I can hope that such hacks will be replaced when development is open to new features (especially if the API would have been made available on a branch already).