Community
Participate
Working Groups
There are 3 stages. Stage 1: (API) add a properties API to persistence providers that allows them to receive properties from their defining extension points. Add new "property" elements that can be attached to each persistence provider declaration. To be done prior to M7 build. Stage 2: (non-API) move the location and anchor interfaces/classes from the PropertyFileProvider, leave them in the internal package so they remain non-api. Add a new anchor and location for storing in the metatdata area - also in the internal package. Stage 3: (non-API) Modify the PropertyFileProvider to accept a location property that determines if profiles should be storeed in metadata or workspace. Define two autostart providers - both of class PropertyFileProvider for the metadata and workspace areas. They will have different ids. The default will remain the workspace provider.
Stage 1 has been committed for M7. The rest should be committed for RC1.
I'd prefer having the metadata provider the default, because: 1. The auto-created connection ("Local") will always be handled by the default provider. But it makes sense on the local system only, there is no point in sharing it so it should be stored in metadata. 2. Metadata is less problematic because it does not interfere with Workspace locks. For instance, if you have a long-running build going on, it locks the workspace. With a workspace provider you cannot use your connections during that time. 3. By default, all connections created go into the default profile, which is the "local" profile by the name of the IP address a user is working on. Sharing this profile makes no sense. 4. Connections should be user-private by default; team-sharing them may be extra effort (that can be explained in the user's guide). 5. I'm not sure how well the Team Sharing functionality of RSE will work for 2.0 -- last times I tested it by importing a Team profile through CVS I got into really weird situations pretty much messing up my workspace. I think the right solution is to associate the default profile (by the name of the IP address of the local machine) with the metadata provider, ant the default created "Team" profile with the Workspace provider.
The profiles stored in the metadata area will be in the state location of the core plugin in the "profiles" subdirectory. Comments?
As stated above profiles are stored in the state location of "org.eclipse.rse.core" in the "profiles" directory. Profiles are written using the property file provider so their format is identical to those in the workspace. The provider is instantiated twice, each with a different set of properties and a different id. Both providers are autostart. The default provider has been changed to be the one for the metadata area. Implementation consisted of moving the new anchor and location types out of the PropertyFileProvider and providing an implementation of them that dealt with the metadata area. The PropertyFileProvider is now completely free of the org.eclipse.core.resources dependencies. These are now encapsulated in the workspace anchor and location classes. Those profiles that are in the workspace will continue to reside in the workspace but new profiles will be created in the metadata area. Both types of profiles will load on startup. There is no UI for moving profiles from one location to the other, but you should be able to move them manually by copying the PRF.<profile> directories. In addition I've cleaned up the SystemProfileManager a bit with respect to creating profiles and managing active profiles. The duplicate Team profile was a result of creating profiles on reference and having the Team profile be in the active profiles list. This bug has now been fixed as well. I've done preliminary testing on this and it seems solid. I am attaching a patch for review, but this needs to be committed soon. Please review.
Created attachment 68488 [details] implement a persistence provider for the metadata area The patch implementing the provider and making it the default
I really don't like the idea of sharing profiles through a team provider. There is too much that changes in them that is beyond the control of users. I would prefer, rather, to be able to import and export whole profiles the way eclipse does preferences. The import export format should be an XML document rather than the property file format. This, with beefed up abilities to move, copy, and delete connections, filter pools, and filters between profiles on the profiles view would be a big step in the right direction.
Patch looks good to me. If you tested and it works, please go for it. Only the copyright comments on the new files look odd. - Some have a copyright year 2006 (should be 2007?) - Some are missing (PFConstants) - Multiple contributors on "Initial API and Implementation" -- most of Eclipse just writes "IBM Corporation - initial API and implementation I recommend using the releng.tools "Fix Copyrights" action, perhaps after you checked in the initial contribution.
One thing that we might need to be cautious about is: what happens if profile "Team" was created in .metadata after RSE startup, but then a RemoteSystemsConnections project is being brought in (e.g. by CVS) which also contains a profile named "Team"? Who would win? Would we show an error dialog? Rename the profile in metadata?
Thanks for the review Martin. There is one item hanging out that I'm currently investigating, but I should be able to check it in today.
(In reply to comment #8) > One thing that we might need to be cautious about is: what happens if profile > "Team" was created in .metadata after RSE startup, but then a > RemoteSystemsConnections project is being brought in (e.g. by CVS) which also > contains a profile named "Team"? > > Who would win? Would we show an error dialog? Rename the profile in metadata? > That's a problem for more than the Team profile. Now that we can have multiple providers profiles can always be named the same from different sources. I think what I'd like to do is just arbitrarily rename any duplicates as they are restored. MacOS does this for files that have colliding names during a copy. As long as the user can rename them later, its not a problem. So if we have Team come in from another provider we'd rename it to Team.1, or Team.2, ...
The changes have been committed. I'm going to leave this open for a bit, since there is some future work in the discussion we probably want to capture in another report as soon as that's done, I'll close this report.
I've captured the relevant discussion in the following bug reports: Bug 189273, Bug 189274, and Bug 189275.
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!
[target cleanup] 2.0 RC1 was the original target milestone for this bug
