Bug 172326 - [api] SystemView should be internal
Summary: [api] SystemView should be internal
Status: RESOLVED DUPLICATE of bug 172468
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 1.0.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 2.0   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks: 170922
  Show dependency tree
 
Reported: 2007-01-31 10:42 EST by Martin Oberhuber CLA
Modified: 2008-08-13 13:16 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-01-31 10:42:26 EST 
The implementation of the SystemView should not be known or accessible to extenders. All kinds of customization to the SystemView should be done by registering systems, subsystems, filters and their adapters.

Availability of methods like SystemView.refresh() is confusing since the recommended way for doing refresh is through the Event firing mechanism in the SystemRegistry.

Therefore, SystemView should be moved to an internal package.
Comment 1 Kushal Munir CLA 2007-02-01 13:00:18 EST 
I agree. I don't think SystemView needs to be public. It would be useful, however, to have something available that would allow extenders to easily embed the RSE tree in dialogs, wizards and views, and for that we already have SystemViewForm. It would be good to ensure that SystemViewForm provides a good set of methods for configuring it.
Comment 2 David McKnight CLA 2007-02-01 15:36:24 EST 
What about the other views?  For example, the monitor view, the table view, the search view and other things like the forms, view parts, label providers, content providers, adapters, sorters, and such?  Looking at the org.eclipse.rse.ui.view directory, there are quite a few classes that may need to go internal.
Comment 3 Martin Oberhuber CLA 2007-02-01 16:38:52 EST 
The more we can have internal, the better.
And the sooner we have it internal, the better.
Adding DaveD on CC for discussion.

Note that we can also have something internal but still export it (marked x-internal). That way, users have access to it "on their own risk", PDE will mark it as "discouraged access". This might be an option for cases where we are not sure (SystemFilter is one example implemented that way right now).
Comment 4 Martin Oberhuber CLA 2007-02-01 16:50:43 EST 
BTW, for creating internal packages and package naming, see
http://wiki.eclipse.org/index.php/Naming_Conventions
Looks like e.g. org.eclipse.rse.internal.ui.views would be right.

I have E-Mailed the Webmaster if we can move stuff in CVS keeping the history intact. It's possible with just a little bit of effort. So if you want to move something with the history let me know. I guess history won't be interesting for in many cases; but in some cases of "hot" classes which received many bugfixes (e.g. SystemView?) the history would probably be helpful.

Can we compile a list of things we want internal for discussion?
Comment 5 David McKnight CLA 2007-02-16 11:36:15 EST 
I've resolved this in the fix for 172468.

*** This bug has been marked as a duplicate of bug 172468 ***
Comment 6 Martin Oberhuber CLA 2008-08-13 13:16:54 EDT 
[target cleanup] 2.0 M5 was the original target milestone for this bug