Community
Participate
Working Groups
Should consider options for running without a workspace (instance data). Since the configuration info has been moved out of the workspace, the only thing that is left there is: .log .lock .keyring version.ini .plugins The proposal is to have Platform have new api as follows - getInstanceDataLocation (or the current getLocation()) - setInstanceDataLocation = set the data location only if it is not already set. - hasInstanceData = whether or not an instance data location is available. This could be replaced by getInstanceDataLocation returning null or some such - lockInstanceData(boolean) = lock/unlock the instance data location (if any). This fails if the locaiton is already locked/unlocked. Related, a new command line arg -noInstanceData disables the computation/use of a default data location (the default workspace). Going down this path allows the application more control over how it runs. For example, it would come up and request a lock on the instance data location. If it cannot lock, then it is in use by another Eclipse and the app can notify the user. (currently I believe we do this via a special return code that eclipse.exe notices and opens the dialog). similarly, the version checking and conflict reporting can be in the applicaiton (or not). But wait, there's more! For years now people have wanted to start eclipse and choose a workspace. Since the config data has been moved out of the workspace, and assuming the above changes, the application is in a position to prompt the user to select a workspace. It would then Platofrm.setInstanceDataLocation() Platform.lockInstanceData() <check instance datalocation> All of these together remove UI code and NL messages from eclipse.exe, reduce the number of special return codes, special case applications, gives more control to the application (i.e., enables more scenarios) and enables workspace selection. Wins all around. (can you tell I am keen on this one?)
This is an interesting proposal. Having a workspace directory structure seems like an artificial requirement, at least for simple RCP apps (e.g. the browser example). It seems like these are pretty fundamental APIs that we probably only want to allow the primary application to tweak, not regular plug-ins. This is similar to some of the privileged APIs we have that only the app can gain access to, like IWorkbenchConfigurer and IWorkbenchWindowConfigurer.
Seems that only the set methods are sensitive. Question: If we did this, would you (UI and others) leverage it and change the way you lock, discover, ... the instance area (aka workspace)? I would like to get a sense that this is the direction we will actually do. Otherwise there is not much motivation for the runtime to restructure.
Yes, the UI team is willing to make the necessary changes to the IDE to allow the workspace location to be chosen, and to get the version check logic out of the runtime. We should sit down together and work through the control flow. Note that currently the IDE activates the Resources plugin implicitly due to class references in the primary structure of IDEWorkbenchAdvisor, but I'm sure this could be refactored to give us more explicit control over plugin activation.
Great. Bumping the priority up so we ensure the necessary runtime work is done for M7. May be interesting for EclipseCon since it is a visible/interesting change but that does not give the UI team much time. some notes on core implementation: - consider cases where two plugins in the same session try to lock the instance data area. Should there be a token of some sort that they pass in such that if the same token is used, the lock succeeds? - where should messages be logged before the instance data area is known? Perhaps the config area since we know that is writable? - will need a commmandline arg/property to disable prompting for the workspace location (this allows the default to be used with out asking the user anything) - also need a command line arg/property to say -noData. This disables the use of a default and thus, if -data is not spec'd, there will be no instance data area. - handle the cases where there is no instance data area. ==> - no lock - no log (put it in the config area) - no keyring
Just did a quick check in the UI code. It will be straightforward for us to defer activating the resources plugin, and therefore get in and prompt for the workspace location before we force it to the default.
What should happen to the preferences in case where there is no workspace? I would propose to save them in the .config area? Other pb: When I'm starting with -noDefaultData (which means that the instance data can be specified programmaticaly), the .log file is created in the .config area. Once the instance data has been specified, should we recreate a new .log file or let the .log file in the .config?
A first version of this support has been released in HEAD. New APIs are available on Platform, please review it. Note that it does not cover the version.ini file as the support will totally change. The APIs allow to programmatically set the instance data location and even to unset it. Unset APIs are just to try and see. For now they are unguarded and anyone can unset it. A token could be introduced if we wanted to keep these APIs. In complement of the -data command line option that was supported, two new command line options are now supported: -noData (system property eclipse.noData=true) which prevents creation of instance data and therefore metadata. In this case the .log is stored into the .config area. -noDefaultData (system property eclipse.noDefaultData=true) this forces instance data location to be set programmatically. Until a location is specified programmatically, the API behaves like if -noData has been specified. Note that from now on, the keyring will always be stored in the .config area.
Someone needs to lock the workspace. It can either be the workspace chooser, or the resource plugin since he is one of the main plugin requiring this.
A proposed solution for the locking problem: Platform#lockInstanceData can be specified such that it obtains a lock on the instance location for the caller's VM. I.e., it is not a mutex for multiple callers within the VM, but a single mutex that only one VM can own at a given time. Multiple calls to #lockInstanceData from the same VM would all succeed once the VM owns the lock. Every plug-in that cannot tolerate multiple instances on the same location will call lockInstanceData in their Plugin.startup(), and unlockInstanceData in their Plugin.shutdown() (or BundleActivator.start/stop) for pure OSGi bundles). org.eclipse.core.resources would do this, and so would org.eclipse.ui. Their Plugin.startup() would fail if the lock cannot be obtained. That way the decision is being made by the plug-ins that depend on it, rather than leaving it up to the runtime or the application, which may not need exclusive access.
Good observation on the locking per VM. One issue that comes up is who unlocks the instance data? Currently it would be implied by exiting eclipse but that is somewhat limiting. Lockers can be required to unlock in their stop() method but this requires reference counting. Not hard to implement but more than we were thinking to date. Bascially I was thinking that it would be the plugin which set the instance location or was in "overall control" (typcially the application). The curent usecase is that we want to bail at the beginning when we discover that someone is already using the specified instance location. The UI would report to the user and perhaps allow them to choose an alternative or just exit. Side note: since setInstanceLocation() can only be called/succeed once, choosing another location is not an option unless they lock first. But then you have to manage locking but failing to set etc etc. Perhaps a viable option here is to have a "lock" boolean on setInstanceLocation(). If you spec lock = true then the method only succeeds if the location was not set and was not locked. We would still need a lockInstanceData() method. Allowing individual plugins to lock defers the failure case perhaps into a situation from which the user cannot recover. It may be an over engineered solution.
Reference counting is fairly easy, but I suspect freeing on VM exit (as we currently do) is probably sufficient. This isn't a *real* lock that multiple VMs can share by taking turns on the data area. First one in gets it, and all other VMs fail. However, I think your idea of making locking an atomic part of setInstanceLocation() makes sense. It's not exactly clear to me why you need the lockInstanceLocation API at all if it's assumed to be a part of setInstanceLocation.
Not all clients need to call setInstanceLocation(). The runtime will compute a default if one has not been set. Looking forward there may be scenarios where we want to be able to switch instance locations without exiting. If we start now and have the appropriate API then we can lay the ground work.
We've just had a discussion about our friend the keyring file. We're thinking while we're in the process of exposing API to set the location, we should also expose API to set the keyring encryption password. That way the UI can also prompt the user to supply a password (for example in the same dialog where they chose the workspace location), and maybe even (gasp!) allow them to change an existing password!
Excellent idea!
Bob suggested to always put the .keyring file into the user.home. Why do you think about that?
combine -noData and -noDefaultData with -data as follows -data <location> {osgi.instance.area} sets the instance data location for this session. Plug-ins use this location to store their data. For example, the Resources plug-in uses this as the default location for projects (aka the workspace). If the location is "<NONE>" then no instance data location is created/used. If the location is "<NO_DEFAULT>" then the platform runs only with an explicitly defined instance data location. That is, a default data location is not computed or used. note that the osgi.instance.area property should not have the value <NONE> or <NO_DEFAULT> after main() has been run.
The documentation regarding all the new options must be updated.
Due to some problems in PDE, new values have been defined to replace the <...> ones. We have: @none @defaultData Note that two other generic values have been defined: @user.home @user.dire
I'm curious, where did this "@" notation come from? On Windows, "command @something" usually means read the rest of the command line arguments from the file "something" (for example, the C/C++ linker command does that). At SAS we have a long standing tradition for case insensitive keywords that can go where names can go: put underscores before and after them. For example, "-data _none_". It's a trivial thing but you might want to consider it if you think you'll ever have to implement "@"-style indirect option files in the future. BTW I'm almost afraid to ask what the user.dire location is. :)
command @somefile can still be used as you describe. The @none etc come only after location command line args like -data. @ was chosen because it is simple, can be used in a file name in all known filesystems (needed by PDE) and it reads well. To catch up on some other commnets and summary of where we are: - we have decided against adding more keyring file support for the time being. We are hoping to get to a good spot on user permissions/roles in Eclipse post 3.0 and do not want to add API now that we will regret later. - locking of locations is a separate operation (Location.lock()) from setting the value of a location (Location.setURL()). This enables scenarios where locking is not needed or is independent of the setting of the locaiton value. - We may do the refernece counting for locks though I am not sure we really want to get all plugins using the instance location (for example) to start locking it. The reference counting proposal would be simply to count the number of times that lock() and release() are called. When the count gets back to 0 we actually release. The area will be released automagically by the OS when the VM process exits. - UI team has an initial implementation of a workspace chooser dialog. Looks good. - logging before the instance location is known goes into the configuration area in a file <timestamp>.log. When/if the instance location is known, the contents of the config log (if any) are appended to the instance log and the config log is deleted. Logging done by Main in startup.jar is always done in the config area. The cases where this happens are very few. - We are investigating ways of returning the actual log location to Eclipse.exe for use in its error dialogs.
In the workspace prompt (dialog) for IDEs I do something close to the following: Location loc = Platform.getInstanceLocation(); while(true) { loc.setURL(promptForWorkspace()); // *** if(loc.lock()) break; } This way I can continue to prompt for a workspace until a valid one is selected. However, the second time through this loop, *** throws an IllegalStateException. What can I do? Perhaps there should be a #setUrlAndLock?
> Logging done by Main in startup.jar is always done in > the config area. The cases where this happens are very few. I just wanted to point out a fairly common case where logging occurs in Main. If the Eclipse application throws any exception, it is currently only logged from Main. From the perspective of a lowly RCP application writer (or Workbench team member), this is really unfriendly... when launched using PDE the config area is buried deep in a metadata directory, which is immediately deleted on shutdown. I think we could improve this by logging and swallowing at least Exceptions and LinkageErrors from somewhere that has access to the real log location (EclipseStarter.run?) to prevent these more common errors from being logged by Main.
Using contribution items instead of a StatusLine makes sense. I think the real problem is that you may want to allow client contributions to get placed relative to the message control, progress control and cancel control independently (they don't need to be grouped together). I don't think SubContributionItem is the right approach though. That is a goofy interface intended to be used with SubContributionManagers for virtualizing contribution managers between the workbench and regular plugins. Perhaps the way the Workbench does it would work, where the app gets to contribute items first, then regular plugins get to contribution items relative to those. Except in this case, this would be done in StatusLineManager itself, but in a way that's subclassable.
Nick, I think that last comment was pasted into the wrong PR
Indeed. It was intended for bug 53748. Sorry for the confusion, and thanks for letting me know.
Closing since all the support is available in runtime and used by the UI with the workspace chooser.
