Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #245013 +++ This enhancement tracks implementing a shared view that would allow anyone who has to present servers, services or connections to plug in content.
A lot of interesting discussion about this enhancement can be found on Bug 245013.
I've only been following this bug and it's predecessor (bug 252239) for a short time, but it seems to me that there are at least three design issues: 1) figure out whether people want UIs that put together servers, services, and connections into a single view...and if so/not in what contexts they want them together and/or apart. 2) implement view(s) that expose a single (hopefully simpler) organization of servers, services, and connections via the CNF or whatever. 3) implement framework UI (that reuse the work from 2 presumably) that allows extensions (by subclassing, extension registry, services, etc) to display a certain view and management of a subset of servers, services, connections Also...a view/UI for 2 and 3 that is really intended to interact with arbitrary external processes (e.g. servers, clients, dbs, services, etc., etc) probably should be directly related to/use the E4 work on a common connection framework as described http://wiki.eclipse.org/E4/Connection_Frameworks
Created attachment 116229 [details] How DevStudio currently does it Referencing / reattaching from bug 247934, how devstudio manages a shared view
Created attachment 116230 [details] How Netbeans does it Referencing / reattaching from bug 247934, how netbeans manages a shared view
So I'm not terribly familiar with eclipse processes and how things actually get done around here. I will say that item [1], [2], and [3] in comment 2 are most important. I would not support directly tying this view to the Connections Framework or limiting it to that. I think extenders to this view are more than welcome to have their internal guts related to it and as we start finding commonalities we can put some handy classes in our public packages, but I don't believe this view should require connections framework support... In the Common Navigator Framework, each provider of content is allowed to add as many top level elements (or inner elements) as they want... however the content from each "provider" can be turned off via the CNF's filter / content management. So users will ultimately be very able to turn off specific pieces of content. I would support that the primary extenders of this view make their top-level element something very generic, such as a static "Databases" object which would serve only as the category, and underneath that they can add all of their databases. In this fashion if someone wants to add additional pieces to unsupported databases or databases not configured using DTP, they *should* put it under the "Databases" node which would already be made / provided by DTP. (ideally). If someone made a product that had a second "server" tooling API but also wanted to support WTP's servertools, the same logic would follow. webtools' servertools would provide a root "Servers" node, under which they would list all the servers *they* know about, and another extender can provide, under the same "Servers" node, all of the servers their other plugins know about. Again, since I'm not familiar with WTP too much, the question is do we want to let external adapters pretty much add anything wherever they want, like in the Project Explorer, or do we actually want to constrict where and when they add things? Personally, I'm more of a freedom-loving kinda guy and say its the responsibility of all plugin-makers to make sure their plugin jives with the flow of the view... however I'm sure we can still come up with approved methods for eclipse-internal projects and how they should behave.
(In reply to comment #5) > So I'm not terribly familiar with eclipse processes and how things actually get > done around here. I will say that item [1], [2], and [3] in comment 2 are most > important. > > I would not support directly tying this view to the Connections Framework or > limiting it to that. I think extenders to this view are more than welcome to > have their internal guts related to it and as we start finding commonalities we > can put some handy classes in our public packages, but I don't believe this > view should require connections framework support... Then what should this view require? That is...if it's a view that can be used for servers, services, and connections it will have to require something that is shared across all of those type of external entities...so what would you expect it to require for interaction with all these external processes (i.e. servers, services, dbs, etc?). > > In the Common Navigator Framework, each provider of content is allowed to add > as many top level elements (or inner elements) as they want... however the > content from each "provider" can be turned off via the CNF's filter / content > management. So users will ultimately be very able to turn off specific pieces > of content. I agree filtering is fine/good, but I believe that the CNF is based upon the resources framework (i.e. IResource and sub-interfaces). What would you expect a view for external processes to depend upon (assuming it's not IResource)? > > I would support that the primary extenders of this view make their top-level > element something very generic, such as a static "Databases" object which would > serve only as the category, and underneath that they can add all of their > databases. >In this fashion if someone wants to add additional pieces to > unsupported databases or databases not configured using DTP, they *should* put > it under the "Databases" node which would already be made / provided by DTP. > (ideally). I agree that various types of remote services (e.g. Databases) should serve as categories as you describe. But part of the notion of a common connection framework is that various remote services (like dbs) can/could use a common way of addressing/connecting/disconnecting/managing all types of connections to external processes. > > If someone made a product that had a second "server" tooling API but also > wanted to support WTP's servertools, the same logic would follow. webtools' > servertools would provide a root "Servers" node, under which they would list > all the servers *they* know about, and another extender can provide, under the > same "Servers" node, all of the servers their other plugins know about. Yes, I agree. > > Again, since I'm not familiar with WTP too much, the question is do we want to > let external adapters pretty much add anything wherever they want, like in the > Project Explorer, or do we actually want to constrict where and when they add > things? Good questions. > > Personally, I'm more of a freedom-loving kinda guy and say its the > responsibility of all plugin-makers to make sure their plugin jives with the > flow of the view... however I'm sure we can still come up with approved methods > for eclipse-internal projects and how they should behave. Agreed. If '3' is agreed to be one of the goals for this bug, then the implementation of the 'top-level' view classes will affect to some degree what extenders will/can change about the presentation and behavior.
Well I suppose I just feel the purpose of this bug is to help consolidate "like" objects with each other... and in this case like as in type, not necessarily API. Sure, Package Explorer is based on resources, but Project Explorer is not. I can add absolutely ANYTHING to Project Explorer... anything at all. Anything at the top level or anything under anywhere. Granted the unifying theme is resource / project based (hence Project Explorer), but there are (as far as I know) no true restrictions to adding nodes to it. From the way I've looked at this bug, it is primarily UI-oriented in trying to consolidate into a common view without mandating conformance to any particular core API and only conformance to any UI-APIs we add in which would be primarily around the topic of appearance and organization of the view. Again, while the Connections Framework would probably be used by many of the underlying providers, I'm personally of the opinion that the Connections Framework is a bit broad and that rather than using that as the basis for the view (and perhaps moving forward with "Connections Framework"-oriented assumptions and limitations) we should let the Connections Framework adopters, servertools, dtp, etc, be the providers for this view.
(In reply to comment #7) > Well I suppose I just feel the purpose of this bug is to help consolidate > "like" objects with each other... and in this case like as in type, not > necessarily API. I think in general type does correspond to API (if by type you mean Servers, Services, Databases, other types of interactions with external processes). > > Sure, Package Explorer is based on resources, but Project Explorer is not. I > can add absolutely ANYTHING to Project Explorer... anything at all. Anything at > the top level or anything under anywhere. Granted the unifying theme is > resource / project based (hence Project Explorer), but there are (as far as I > know) no true restrictions to adding nodes to it. I don't know the project explorer internal architecture, so I may be wrong about this, but doesn't it ultimately have to cast the entities it displays to IProject (sub-interface of IResource) and/or specific sub-types of IProject within the view content provider? > > From the way I've looked at this bug, it is primarily UI-oriented in trying to > consolidate into a common view without mandating conformance to any particular > core API and only conformance to any UI-APIs we add in which would be primarily > around the topic of appearance and organization of the view. I do see the issues 1 and 2 listed in comment #2 as basically about design/organization of the UI, but OTOH there is UI infrastructure implied by having something that clients can add to/reuse/extend for their particular purposes (3). > > Again, while the Connections Framework would probably be used by many of the > underlying providers, I'm personally of the opinion that the Connections > Framework is a bit broad and that rather than using that as the basis for the > view (and perhaps moving forward with "Connections Framework"-oriented > assumptions and limitations) we should let the Connections Framework adopters, > servertools, dtp, etc, be the providers for this view. I'm not arguing differently from this. I'm just proposing that if there are some things that are actually shared across providers (e.g. a connection framework, or common presentation, common management conventions, etc), that the 'top-level' ui support classes could/should take advantage of such sharing (e.g. by providing a common UI for the verbs associated with all entries). This would make things more usable, I believe. As having consistent ways of interacting with (e.g.) dbs and external app servers (e.g. same context menu entries/actions) would make things simpler for users.
> I don't know the project explorer internal architecture, so I may be wrong > about this, but doesn't it ultimately have to cast the entities it displays to > IProject (sub-interface of IResource) and/or specific sub-types of IProject > within the view content provider? The Project Explorer is essentially the Reference Implementation of how to make a Common Navigator and has no such restrictions. You can add absolutely anything absolutely anywhere. The additions need not be adaptable to anything.
(In reply to comment #9) > The Project Explorer is essentially the Reference Implementation of how to make > a Common Navigator and has no such restrictions. You can add absolutely > anything absolutely anywhere. > > The additions need not be adaptable to anything. Well, they need to be of type IAdaptable (for no good reason) but that is workaroundable and a topic of another bug ;)
I'm interested in eventually plugging in DSDP-TM / RSE contents (http://www.eclipse.org/dsdp/tm) into this common servers view, and not knowing the proposed framework yet I have 3 questions: (1) If I create a provider for this common servers view inside DSDP-TM, what would my dependencies be? Would I need to depend on something from WTP? (2) The "Systems View" (RSE Tree) which we currently use has a capability of showing the SAME remote object under MULTIPLE nodes in the tree, provided that the object matches multiple filters: Server Foo + Subsystem Files + Filter "My Home" + someFile.txt + Filter "/home/user" + someFile.txt this capability has caused us some headaches in the past, since a Refresh on someFile.txt (e.g. deleting it or renaming it) requires refreshing ALL filters that display it. We've had several issues with that, related to the SWT TreeViewer's elementMap and more. Do you guys think that the Common Navigator Framework will allow us to provide such dupliate contents, or will we likely hit some roadblocks with this? (3) I'm a bit concerned about usability if we just plug-in providers into this which don't know anything about each other. For instance, if WTP references some Application Servers on "Server Foo" and DTP References a database on "Server Foo" and RSE gives access to the remote file system on "Server Foo" -- will we have 3 separate top-level or 2nd-level nodes for "Server Foo" ? This doesn't seem like a good user experience, how do VS / Netbeans deal with that? (4) I like the idea of a single, consolidated servers view for exploring remote resources and drilling into them. I do believe, however, that once some item of interest has been detected in the hierarchy, users may want other means to interact with that element. At least, they will want to find that same element again easily in order to interact with it again. I can imagine a separate "details view" for replicating the same element of interest; or, some "bookmarks" to find the element of interest again easily; perhaps also filters such as working sets. Scrolling around the consolidated servers view again and again does not seem good user experience to me -- I'd rather switch separate views (perspectives) than scroll around all the time. Has anyone thought about this yet?
> I'm interested in eventually plugging in DSDP-TM / RSE contents > (http://www.eclipse.org/dsdp/tm) into this common servers view [snip] Excellent! > (1) If I create a provider for this common servers view inside DSDP-TM, what > would my dependencies be? Would I need to depend on something from WTP? The current plan is to create a separate plugin in WTP to hold the common view and any related API. The plugin would not have any dependencies on anything else in WTP and could be consumed by other projects using the map file trick developed for Orbit. David Williams put together a wiki that describes how that works (http://wiki.eclipse.org/WTP/Build/Consuming_plugins_directly_from_others_builds). The code would have different shut-down rules from the rest of WTP to make it possible for projects to consume it who are on the same release offset as WTP. This is mostly about short-term convenience (we are trying to put the first version of this together in time for 3.5). I don't see this is a viable long-term strategy. > (3) I'm a bit concerned about usability if we just plug-in providers into > this which don't know anything about each other. For instance, if WTP > references some Application Servers on "Server Foo" and DTP References > a database on "Server Foo" and RSE gives access to the remote file > system on "Server Foo" -- will we have 3 separate top-level or 2nd-level > nodes for "Server Foo" ? This doesn't seem like a good user experience, > how do VS / Netbeans deal with that? Icons and category labels should reduce any user confused. Another possibility is to use text decorations on the server node to show server type. The user would be able to turn the decorations on or off. Also, as users start using the common view and see that they have used the same name to represent different things, I imagine that they would do some re-naming if they are getting confused. > (4) I like the idea of a single, consolidated servers view for exploring > remote resources and drilling into them. I do believe, however, that > once some item of interest has been detected in the hierarchy, users > may want other means to interact with that element. At least, they > will want to find that same element again easily in order to interact > with it again. > > I can imagine a separate "details view" for replicating the same element > of interest; or, some "bookmarks" to find the element of interest again > easily; perhaps also filters such as working sets. Scrolling around the > consolidated servers view again and again does not seem good user > experience to me -- I'd rather switch separate views (perspectives) than > scroll around all the time. > > Has anyone thought about this yet? It's an interesting question. I wonder if we could borrow the approach that the platform team just implemented for the properties view. They now allow multiple instances of the view to be opened and have some content pinned in a particular view instance. We could do something similar. If the common server view is configurable (allow filtering by server type and even server instance), then a user should have a lot of flexibility to configure their workbench just the way the want. Another possibility is to support "focus on" semantics (like what the navigator views implement). By focusing on a particular server, all other content would be hidden in the view. Both of these ideas can work together as well.
I'm a fan of having multiple instances of this view. We should be able to pull that off. Another possibility is the "drill in" functionality that exists in the Project Explorer where you can change the top level to only see, for example "Servers" or "Databases" instead of that top level.
As I had a chance to think more about this, I am becoming convinced that we should limit the extent to which people can use CNF to modify the view. I think ability to use CNF beneath a particular server node makes a lot of sense, but above the server node, the view should maintain pretty tight control. This would make the view more consistent and usable without having to police the extenders. Do people who have CNF experience know off-hand if that would be possible? I am thinking we could define pretty minimalistic API which would include things like: server category extension point: * id, label, etc. * factory for producing server nodes * callbacks for add, remove and delete The view would then control top-level organization and behavior. We could let the user choose whether to group by categories or to list everything at the top level (makes sense if you only have a few items). All the top-level actions would be consistent because the view rather than extenders would be responsible for contributing them and then delegating the implementation. This should also make it easier to implement drill-down and multiple view instances ideas that were brought up in last couple of comments. Thoughts?
Ok, for (1) I'm fine with the consuming story for now. Question (2) has not yet been answered, but this is extremely important for us. RSE content won't work in a CN based view if multiple occurrences of the same element are not supported. For (3), my understanding is that no effort will (yet) be made to consolidate multiple providers for a single connection under one node. That's fair enough and perhaps something to consider in the context of E4. One question in this context is whether we'd want to sort Servers View Content alphabetically by connection name, or by category/connection type. Might be a view setting. For (4), RSE currently provides "Go Into" to change the root node, as well as "Open in New Window" to open a whole new Eclipse Window with the same SystemView tree "gone into" the selection. That's similar to multiple instances of the view but (I think) easier to implement... though multiple windows are not as nice as multiple view instances (potentially in multiple perspectives). Bookmarks are nice though I don't use them personally. Drag&Drop of a node onto the Window's border in order to create a new view (focused on the dropped node), stacked with the view next to that border would also be nice. For the "server category extension point", I'm a bit confused... wouldn't the Common Navigator framework already provide the ability for this markup since "server category" should be equivalent to "provider"?
> Question (2) has not yet been answered, but this is extremely important for us. > RSE content won't work in a CN based view if multiple occurrences of the same > element are not supported. I am not an expert on CNF api, so I am hoping that someone with more experience can jump in an answer this question. Even if CNF can't support this, wouldn't it be possible to work-around that by creating separate wrapper objects to hold the real object in different contexts? > For the "server category extension point", I'm a bit confused... wouldn't the > Common Navigator framework already provide the ability for this markup since > "server category" should be equivalent to "provider"? It's certainly an option to not force any structure on the view and just let everyone contribute content anywhere they want in the view. I am not convinced that it's a good idea, though, and I am arguing for limiting access to CNF API to beneath the server instance node. If we do that, we need API to tell the view about the top-level nodes.
> It's certainly an option to not force any structure on the view and just let > everyone contribute content anywhere they want in the view. I am not convinced > that it's a good idea, though, and I am arguing for limiting access to CNF API > to beneath the server instance node. If we do that, we need API to tell the > view about the top-level nodes. > As I mentioned in the predecessor of this bug. I think an approach were we limit the CNF API would make more sense so that we can control the top level node and in the future certainly provide the ability of grouping the resources by servers(similar to what Project set are for the Project Explorer).
(In reply to comment #17) > node and in the future certainly provide the ability of grouping the resources > by servers(similar to what Project set are for the Project Explorer). Seems like you're also talking about the ServerFactory creating nodes that are adaptable to some API like (in the most minimalistic form) interface IServerNode { String getSortKey(); } such that you can compare / sort / group the connection nodes... given that connections are of many different kinds, the semantics of the sort key would need to be defined. Could be the user-defined label of the connection, or something derived from an IP Address, perhaps some canonicalized URI.
> I would not support directly tying this view to the Connections Framework or > limiting it to that. I think extenders to this view are more than welcome to > have their internal guts related to it and as we start finding commonalities we > can put some handy classes in our public packages, but I don't believe this > view should require connections framework support... I tend to agree (at least in the short term). It could be argued that requiring central API for managing "connections" would make the common view implementation simpler (it makes it easier to handle basic add, remove, rename actions and also resolves the potential confusion over identical names contributed by different managers). However, requiring everyone who has content to contribute to first adopt the connections framework would hamper the short-term adoption of the common servers view. If the connections framework takes off and is widely adopted, I can see re-visiting this.
Hi Konstantin, (In reply to comment #12) > > The current plan is to create a separate plugin in WTP to hold the common view > and any related API. The plugin would not have any dependencies on anything > else in WTP So this plugin would contain the Server/Runtime framework?...or would it be new/separate from that? And it would contain UI code (view) also, right? Would it be a brand new plugin (with new package namespace), or an existing WTP plugin? Also...it seems to me that even with the map file trick it would/will be difficult to get cross-project consumption of something like this...which I think is what's desired here. Perhaps this could be in runtime project...or platform UI or...or even part of Nexus (although I don't know what state the project is in) http://wiki.eclipse.org/Nexus_Project
(In reply to comment #11) > (2) The "Systems View" (RSE Tree) which we currently use has a capability of > showing the SAME remote object under MULTIPLE nodes in the tree, provided > that the object matches multiple filters: > Server Foo > + Subsystem Files > + Filter "My Home" > + someFile.txt > + Filter "/home/user" > + someFile.txt > this capability has caused us some headaches in the past, since a Refresh > on someFile.txt (e.g. deleting it or renaming it) requires refreshing > ALL filters that display it. We've had several issues with that, related > to the SWT TreeViewer's elementMap and more. > Do you guys think that the Common Navigator Framework will allow us to > provide such dupliate contents, or will we likely hit some roadblocks > with this? Martin, I don't believe I've ever tried this in the CNF, but that doesn't mean it can't be done, just that I don't think I've ever seen it done. The idea that a downstream object is shared would have to be handled by the content provider through some sort of listener interface I'd guess, but I don't know how that would all work.
> So this plugin would contain the Server/Runtime framework?...or would it be > new/separate from that? And it would contain UI code (view) also, right? It would contain the view as well as the API that goes along with the view. The plugin would not contain any part of WTP Server/Runtime framework. > Would it be a brand new plugin (with new package namespace), or an existing WTP > plugin? A brand new plugin. Name space choice is important as it will either facilitate or make it more difficult to move this code around. Apparently, WTP server tools project has org.eclipse.servertools namespace assigned to it, so it has been suggested that we use something nested beneath that (no references to JST or WST). The problem I see with that approach is that the namespace belongs to WTP. If this plugin later moves, then part of WTP namespace now belongs to another project. Maybe not a problem, but not clean either. My recommendation (based on lessons learned with Faceted Project Framework) is to think about requesting a stand-alone name space right now. That will make it possible to avoid disruption caused by having to change name space later. Maybe org.eclipse.serversview or something like that. All it takes to get a new namespace is a quick note to EMO with proposed namespace and justification. > Also...it seems to me that even with the map file trick it would/will be > difficult to get cross-project consumption of something like this...which I > think is what's desired here. Perhaps this could be in runtime project...or > platform UI or...or even part of Nexus (although I don't know what state the > project is in) > > http://wiki.eclipse.org/Nexus_Project I agree completely. The map file trick is really just a short-term solution to allow progress to be made without waiting for the process to catch up. It is just not feasible to propose a project and graduate it in several months. At the same time, a mature project (such as WTP or DTP) cannot take a dependency on an incubating project. This is partly because incubating label covers both "community is not mature" and "ip is less-than-clean" concepts. I plan to start a separate discussion later on improving this aspect of the development process. Here is what I think should happen when this effort is further along (say when the view exists and both WTP and DTP contribute content to it)... The Eclipse Project team should be approached about incorporating this technology into that project. This can take various forms. It could go directly into platform or it could become a sub-project under Eclipse Project. The 3.x vs E4 is another consideration here. If the Eclipse Project team does not take this, then the next best thing is to go ahead and get a separate project started under Technology. After the project reaches maturity and has to move from Technology, it would likely go to the Tools Project. The assumption here is that Eclipse Project still doesn't want it, but that could change if by then the project has managed to achieve wide adoption. Regarding Nexus. The status of that idea is that I went through a lot of discussions with the Technology Project PMC regarding it. Through those discussions we separated the original Nexus concept into two parts: (a) providing a place for framework-type micro projects that are used by several projects at eclipse, and (b) helping to lower the overhead of starting micro projects. The general agreement is that (b) is covered by Technology Project's charter, which is why I find myself on the Technology Project's PMC. That leaves (a). There are two opinions on this: (x) existing top-level projects such as Eclipse Project, Tools Project and Runtime Project should be able to via generality of their charters provide home for pretty much any project so we don't need another top-level project with it's own PMC, and (y) none of the existing top-level projects have experience containing projects that do not represent significant end-user functionality so it is not clear that they will be willing to accept framework projects. The last question is going to get answered once a few framework micro projects graduate under Technology and start looking for permanent home. How that goes will determine whether or not Nexus project is necessary. I hope that the above made sense. If something is unclear to anyone, please ask.
> Maybe org.eclipse.serversview or something like that. I think that it should at least be in the UI space. In Eclipse Platform, we already have org.eclipse.ui.net which holds the common Proxy Preference page. For me, it looks like the concept of the Servers view is much similar to the common Proxy Preferences. Where the Project Explorer holds anything related to the Workspace, the "Servers View" would really be about holding anything related to the wider (remote) environment around the workspace. This can be seen as a general concept. From that point of view, I could even see the contents merged into the existing org.eclipse.ui.net bundle. Other options are org.eclipse.ui.serversview org.eclipse.ui.net.serversview org.eclipse.ui.remote > All it takes to get a new namespace is a quick note to EMO with proposed > namespace and justification. Right, but I think it might make sense to ask the Architecture Council and/or owners of the current org.eclipse.ui.net namespace for their opinion. The namespace discussion is also related to the "provisional API" discussion we recently had on the E4 mailing list. > http://wiki.eclipse.org/Nexus_Project > Regarding Nexus. The status of that idea is that I went through a lot of > discussions with the Technology Project PMC regarding it. I like the idea of Nexus, and I understand the underlying problem. Isn't this a topic that the Architecture Council should also be working on? The new development process should allow micro-projects with relatively small overhead provided that they find a suitable parent project. > none of the existing top-level projects have experience containing projects > that do not represent significant end-user functionality Isn't this merely a question of infrastructure and community adoption? Microprojects should be capable of managing themselves, without posing overhead to their containers. Web/Mailinglist/etc infrastructure should be simple enough that maintaining a website isn't a lot of effort. I like the Sourceforge pre-canned infrastructure in this respect, SF is a place that fosters microprojects. At Eclipse, the Common Builder Infrastructure is a step in the right direction, but much seems to be missing to make an individual microproject run really well (in terms of continuous builds, testing, integration, projectplan, ...) - for me it looks like we need more such common infrastructure, and that's an effort that goes beyond any individual toplevel project. It's a Community thing. I'm adding the AC on CC to raise awareness of the cross-project architectural nature of this discussion.
In regards to the naming of the org.eclipse.ui.net bundle, the reason the org.eclipse.ui namespace was used is because that namespace is owned by the Eclipse Platform project to which the bundle belonged (and org.eclipse.core.net is also in a namespace owned by the platform). There was discussion about using the org.eclipse.net namespace but this would have required architecture council approval and unfortunately we didn't have time to explore that option. The implication of using the org.eclipse.ui namespace is that the bundle would need to be owned by the Eclipse Platform. I can see arguments for and against this but my personal opinion is that the common servers view should not be part of the Platform. Another option we had discussed for the proxy support but had to abandon due to time constraints was whether the proxy support should be part of ECF. At the time we felt that it should be part of ECF but we didn't have the proper build infrastructure in place to make that work. Since then, the Platform project has started including parts of ECF in the Eclipse Platform. Would ECF be the proper home for a common servers view infrastructure?
What I don't understand is, what common operations would the new shared view support? The Project Explorer, and other IResource-based views, have a common underlying model that allows not only to browse some kind of hierarchy, but also to perform common operations, such as Cut/Copy/Paste, Rename, New, Open, etc. In other words, how does this view support specific tasks? Without an answer to this question, as someone defining a new perspective, how would I know whether to include the view in the perspective? Also, with lots of plug-ins plugging their content into a view like this, wouldn't we end up with a hierarchy like that in the preferences dialog, where it is hard for users to find the node they want? I think it would be useful to document use cases where a common view would help. For example, do users of Eclipse Ganymede end up with several sparsely populated views in their perspectives, between which they have to switch frequently to do their work? Would a single view with a tree be more useful to them?
(In reply to comment #24) <stuff deleted> > Another option we had discussed for the proxy support but had to abandon due to > time constraints was whether the proxy support should be part of ECF. At the > time we felt that it should be part of ECF but we didn't have the proper build > infrastructure in place to make that work. Since then, the Platform project has > started including parts of ECF in the Eclipse Platform. Would ECF be the proper > home for a common servers view infrastructure? > I don't really think so...at least not as it's currently formulated. ECF is (hopefully) participating substantially in the common connection work...and that is a closer fit to what we are now doing in the runtime project than a common servers view. If the common servers view ends up being dependent/using a common connection framework, and ECF plays a substantive role in that, then I could see it being in the o.e.ecf.ui plugin (if desired) but if that doesn't happen it does not seem like a great fit to me...and would be practically difficult (because the number of ECF committers is currently smaller than needed for this...i.e. for initial work, maintenance, build, etc).
> > Maybe org.eclipse.serversview or something like that. > > I think that it should at least be in the UI space. In Eclipse Platform, we > already have org.eclipse.ui.net which holds the common Proxy Preference page. Since the org.eclipse.ui namespace belongs to the Platform project, that would only makes sense if the Platform would be ready to immediately commit to hosting this effort. Based on past experience, this is rather unlikely, so a safer bet would be to use an independent namespace. An independent namespace facilitates mobility. Today WTP, tomorrow Technology, Tools the day after, Eclipse Project next week, etc. > I like the idea of Nexus, and I understand the underlying problem. Isn't this a > topic that the Architecture Council should also be working on? The new > development process should allow micro-projects with relatively small overhead > provided that they find a suitable parent project. Perhaps. It certainly could not hurt to bring this up. However, I think that best progress will be made at this point by observing a few micro-projects go through the startup process, recording the problems and making suggestions for specific process improvements. It's rather difficult to talk about obstacles for micro-projects in abstract sense. There are a lot of people who don't believe there any problems that need addressing. > > none of the existing top-level projects have experience containing > > projects that do not represent significant end-user functionality > > Isn't this merely a question of infrastructure and community adoption? > Microprojects should be capable of managing themselves, without posing > overhead to their containers. I was specifically referring to the management overhead. While projects should largely manage themselves, there are still many responsibilities left exclusively to PMCs. What's not clear is whether PMCs of projects that are used to managing few large sub-projects will be willing to start managing many smaller projects. Perhaps yes, perhaps no. We just can't answer that question until we've tried this with at least a few projects. Once we know the answer to that question we will know whether Nexus is necessary or not. In any case, we probably should avoid hijacking this bug for this more general discussion.
> I can see arguments for and against this but my personal opinion is that the > common servers view should not be part of the Platform. There are actually two separate questions. Should this be part of the platform or should it be a sub-project under Eclipse Project (peer to the Platform)? I tend to favor the second option since is doesn't clutter up Platform with pieces that not everyone might need, is just as good from a positioning perspective, and can be done incrementally (projects can move fairly easily from one top-level project to another).
> What I don't understand is, what common operations would the new shared view > support? The Project Explorer, and other IResource-based views, have a common > underlying model that allows not only to browse some kind of hierarchy, but > also to perform common operations, such as Cut/Copy/Paste, Rename, New, Open, > etc. It is not necessary to have a common model to support common operation. You just need to have some sort of an API to delegate implementation of basic actions. The current trend of the discussion is to have the view manage nodes and actions at the level of server and higher. The contributors will manage nodes and actions beneath the server level. The view will likely support common Add, Rename, Remove, and Open actions for server nodes. The view will likely also manage presentation of server nodes (visibility, ordering, grouping, etc.). > as someone defining a new perspective, how would I know whether to include the > view in the perspective? This question can only be answered by knowing who contributes to the view and whether those specific contributions are relevant to that perspective. For example, if I know that WTP contributes app servers and DTP contributes databases to this view, I know that this view would be useful for the Java EE perspective. > Also, with lots of plug-ins plugging their content into a view like this, > wouldn't we end up with a hierarchy like that in the preferences dialog, > where it is hard for users to find the node they want? The current trending of the discussion is to not just make it a free-for-all CNF tree. That should keep the view better organized. Usability of content beneath a server node is something that each content contributor will have to work out on their own. > I think it would be useful to document use cases where a common view would > help. For example, do users of Eclipse Ganymede end up with several sparsely > populated views in their perspectives, between which they have to switch > frequently to do their work? Would a single view with a tree be more useful > to them? This discussion started from the effort to improve the Java EE perspective. Currently, the Java EE perspective has a separate app servers view and another view for dealing with databases. Developers have to switch back-n-forth between those views regularly or find some way to have both visible at the same time (no very practical for most). In the context of the Java EE perspective, combining those two views into one would be very beneficial from the usability perspective. Also consider that a typical Java EE developer is working in a team environment. That means, there is the team repository view to find place for in the workbench. Even further usability improvements can be attained if team providers plugged into this view as well.
Mark Phippard left the following comment on my blog when I blogged about this effort. Pretty interesting... ========== The Subclipse and Mylyn teams have been asking for this for a while. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=138583 I do not think this general concept can really work unless the Platform itself provides the view and it is adopted by something like the CVS tooling. Not only could a view like this reduce the number of views, it could reduce the number of perspectives. It is good to see someone is putting some work into the idea.
(In reply to comment #29) > Even further usability improvements can be attained if team > providers plugged into this view as well. Are you sure? For me, scrolling around a single view all the time is worse than switching perspectives or switching views. How would you see dealing with "too much for a screenful" contents in the servers view? Repository operations (like exploring a Repository, synchronizing a workspace...) are very different workflows than usual development. I find it just right that these are in their own perspective, not cluttered by contents not relevant for these workflows. Do the Eclipse UI Guidelines have any advice on this?
I wonder if the user can open multiple instances of a common-nav view and configure each one however they want. So if we had 10 extensions in our view (servers, databases, team, etc) a user could open two instances and have one display servers / databases and the other display team. It'd be interesting to look into that.
> > Even further usability improvements can be attained if team providers > > plugged into this view as well. > > Are you sure? For me, scrolling around a single view all the time is worse than > switching perspectives or switching views. How would you see dealing with "too > much for a screenful" contents in the servers view? > > Repository operations (like exploring a Repository, synchronizing a > workspace...) are very different workflows than usual development. I find it > just right that these are in their own perspective, not cluttered by contents > not relevant for these workflows. The idea is to give more options to the user. Some like the separate team perspective. Many don't. Perspectives get a lot less usage in real life than many of us like to admit. I have seen many users add the repositories view to their primary development perspective. If the common servers view is well designed, then I don't think "too much for a screenful" is going to be more of a problem for the common servers view than other views such as Project Explorer. We have also discussed making it possible for the user to create multiple view instances (like what Platform just did with the properties view). Each instance could have different filters configured and would allow user to look at different parts of the content tree concurrently.
Somewhat related is Mylyn's "Task Repositories" view. For the next release, it's likely that we will extend this to support other ALM repositories, such as build servers and calendars, since we have some redundancy in Mylyn extensions that need to support those kinds of repositories. In the Galileo timeframe, I'm not sure if we need to merge these, as I think that we are dealing with three kinds of repositories that are different in terms of what they need to expose to the user: 1) Servers: app servers, etc, used for deployment and introspection of files and modules on a running server (this bug) 2) VCS Repositories: CVS, SVN, provide browsing facilities, I think these would benefit from a unified view (bug 138583) 3) ALM Repositories: tasks, issues, bugs, agile project managers, calendars, maybe build systems (bug 252681). We have deliberately making the TAsk Repositories view a tree viewer (see http://www.ibm.com/developerworks/java/library/j-mylyn1/part1-repository.jpg), in favor of customized views that support the specific ALM artifact (e.g., the Task List for tasks).
Ian just presented interesting data collected by the new Eclipse Usage Collector framework that I think is relevant to this discussion. http://www.eclipse.org/org/foundation/membersminutes/20081028MarketingSymposium/udc%20report.pdf Take a look at page 20 that shows data on perspectives usage. Notice how top 3 (java + java ee + debug) are dominating by a wide margins. Highly specialized perspectives are registering very little usage.
