Bug 196890 - Expose gsf.testrunner API to Android modules
Expose gsf.testrunner API to Android modules
Status: RESOLVED FIXED
Product: utilities
Classification: Unclassified
Component: Test Runner
7.0
All All
: P2 (vote)
: 7.0
Assigned To: issues@utilities
issues@utilities
: 70_HR_FIX
Depends on: 158018
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-20 13:49 UTC by _ rkubacki
Modified: 2011-03-25 07:24 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2011-03-20 13:49:11 UTC
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.
Comment 1 _ rkubacki 2011-03-23 08:22:00 UTC
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.
Comment 2 Jesse Glick 2011-03-23 11:51:11 UTC
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.)
Comment 3 Marian Mirilovic 2011-03-23 12:08:13 UTC
(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.
Comment 4 Jaroslav Tulach 2011-03-23 13:14:43 UTC
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.
Comment 5 _ rkubacki 2011-03-23 13:21:30 UTC
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?
Comment 6 Quality Engineering 2011-03-24 09:48:11 UTC
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.
Comment 7 Jaroslav Tulach 2011-03-24 11:13:30 UTC
(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.
Comment 8 _ rkubacki 2011-03-24 15:03:19 UTC
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?
Comment 9 Jesse Glick 2011-03-24 19:33:28 UTC
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
Comment 10 Jaroslav Tulach 2011-03-25 07:24:40 UTC
(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).


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo