Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #187647 +++ The new persistence provider looks great, but there is still a hidden project "RemoteSystemConnections" with an empty "dom.properties" directory when creating a new workspace. When using the metadata persistence provider there should be no information stored in the workspace! Also, there should be no SchedulingRules locking against the Workspace in the Persistence Manager.
This root isn't actually created by the persistence provider and may have some purpose such as indicating initialization. Thus there may be some API hits to removing it. I'll track them down.
FYI, I found this in SystemTeamViewResourceAdapterFactory.getAdapter(): public Object getAdapter(Object adaptableObject, Class adapterType) { Object adapter = null; if (adaptableObject instanceof ISystemRegistry) { //SystemRegistry sr = (SystemRegistry)adaptableObject; adapter = SystemResourceManager.getRemoteSystemsProject(); } Should it still get the RemoteSystemsProject even if we're using a metadata provider?
I believe this is because the team view shows this project as the root of the view. I think we might be able to get rid of this.
Created attachment 69652 [details] Delay the creation of RemoteSystemsConnections until absolutely needed The patch delays the creation of RemoteSystemsConnections project until it is needed for writing by a persistence provider that writes to the workspace instead of the metadata area. Since the team view referenced this project, it was removed from the team view - resulting in a list of profiles in that view. The patch also renames the view from "Team" to "Projects". This affects some help contexts and documentation. The help contexts will be modified when the code patch is accepted. The user documentation will be modified for RC3. This has the (in my opinion, excellent) side effect of removing the "Reload RSE" action from the UI.
Martin - can you please review? This is a good-sized change and I don't want it hanging out too long. There is some API breakage, but it is fairly minor.
Created attachment 69946 [details] Updated patch performing the Team view rename more thoroughly
The main patch itself looks good, I just found the following: SystemTeamViewContentProvider : Organize Imports SystemTeamViewPart: profileAdapter is deprecated --> better get fresh What I'm a bit concerned about is renaming the "Team" view to a "Profiles" view at this time. I invested a bit of time searching for the String "Team" and replaced it in those places of the User's and Reference guide as well as HelpContexts.xml that I found. But I didn't check if the docs are still accurate, i.e. do they refer to selecting the RemoteSystemsProject in the (now) Profiles View asking to perform CVS operations on it? Is it really appropriate to remove the RemoteSystemsProject as the root node in the Profiles view? Perhaps the Persistence Providers should serve as root nodes in the Profiles view? Or we should explicitly allow the RemoteSystemsProject in the Profiles view for the case of having a Workspace Anchor? Dave -- do you have a plan what to do with the Team view vs. Profiles view i.e. how do you want to continue? What's the Story?
What about the id "org.eclipse.rse.ui.view.teamView" it's also referenced in the docs; also think about the screenshot view_Team.gif When searching for the String "Team", found that ACTION_CASCADING_TEAM_LABEL is obsolete, should be removed -- also ACTION_CASCADING_TEAM_TOOLTIP
Here's "The Story" For this release I was going to make only the minimum number of documentation and message changes. Certainly the screen shot would have to be redone. I was also going to leave all the view ids and internal constant names as they are. Cleanup of these items should be done in release 3.0 with additional cut/copy/paste/delete/dnd operations in the "profiles" view, a reasonable sort order for profiles, import/export, perhaps some visual tie with the provider (certainly this should be in the properties), and I think some sort of migration operation. The RSE view should be the view where you work with remote resources. The profiles view should be where you play with the packaging of your definitions so that you can share them with other folks. I find that having a "Team" view is too limiting since it provides only one way of sharing and not a very good one. I think we want to export a profile to a project and allow users to synchronize the project to share that profile with a team - similar to project sets and launch configs. My guess is that we'd want this form to be XML based and to be editable using the forms package in much the same way as plugin.xml files are edited. If we are uncomfortable with the rename of the view for now (and we should be) we can leave it but document in the release notes our intentions for this view.
I have no problems with renaming it now, if the change is well-thought out and planned. You'd probably have more issues with the NLS change than I do... The one thing I am slightly concerned about is that we do document a procedure for sharing connections with a team in the userdocs, which involves doing a "Team Synchronize" operation on the RemoteSystemsProject via the Team view. If we do this away, then we do not have ANY possibility of team-sharing connections in 2.0 -- which is perhaps not a very bad thing since it hasn't been working properly anyways. But it also makes the Profiles view pretty useless, so perhaps we should hide it from 2.0 completely until we have a more complete story for using it in 3.0. I, for one, cannot see what a user should use his profiles for the way it is right now. Or do you see a way for extenders to make use of the Profiles view? On the other hand, if we get rid (aka deactivate, make invisible) the Profiles view new, why can a user select a Profile in the New connection wizard?
Applied the patch minus the rename of the Team view. The following items will be generated for release 3.0 based on discussions of this bug report. Links to the new bugs reports will be posted here as well. Plan item - improve the team/profiles view. 1) rename the view from team to profiles 2) change the view id to reflect the name (api change) 3) Add persistence providers as roots in the view - the new profile action should take the selected persistence provider into context. Add persistence provider as a property in the property sheet and profile properties. Add a persistence provider property sheet. Add a persistence provider property page. 4) Allow copy/cut/paste and drag and drop of profiles between persistence providers. Drag and drop performs a profile migration, as does cut and paste, copy and paste performs a profile copy and eventual scheduling for writing. 5) Provide a resolution mechanism for profile naming conflicts if profiles of the same name should be read from different persistence providers. The name resolution is really for display purposes only and should not affect the stored name. 6) Allow copy/cut/paste/dnd-move of hosts between profiles 7) Allow copy/cut/paste/dnd-move of filter pools between profiles 8) Allow copy/cut/paste/dnd-move of filters between filter pools 9) Use decorators to show if profiles are self contained or have external references, create an operation to import external references to make profiles self contained. 10) import and export profiles to the file system 11) import and export profiles to the workspace (from/to any IContainer) 12) provide a comparison editor for profiles
API Change Summary: RSEUIPlugin - removed getRemoteSystemsProject() SystemResourceManager - renamed createRemoteSystemsProjectInternal to ensureRemoteSystemsProject, made it private
Thanks. I think you still need to "Organize Imports" in SystemTeamViewContentProvider, and create a new bug for removing those pages from the User's guide that refer to sharing profiles through CVS.
Created attachment 70104 [details] Patch for renaming "Team View" to "Profiles View" Attached patch performs most of the renames from "Team View" to "Profiles View". Interesting files touched: HelpContexts.xml plugin.properties cprofile.html cteam.html tteamsup.html tteamsup1.html other.html SystemResources.properties
[target cleanup] 2.0 RC2 was the original target milestone for this bug
