Add the usage of waiting for the workspace availablity to N&N

[vogella]

@laeubi I think you added some functionality to Equinox to listen to the workspace location being set.

As we want more people to use this approach, we should document in the N&N. Can you add an example code snippet to N&N new API for developers?

[laeubi]

As we want more people to use this approach

I don't think this is generally useful because most people are not really interested in the workspace location but either on the plugin state area or the workspace

If you are interested in the Workspace then the best is (and was before) to acquire the IWorkspace service, the service for this was introduced in 2009 so its a bit late for a N&N isn't it?

If you want an example CheckMissingNaturesListener use all the new and old ways:

• IWorkspace (old)
• ILog (new)
• IScopeContext (new)

I though describing this in more detail in the Wiki but it was said that wikis are to prone to become outdated here https://github.com/eclipse-platform/.github/issues/4#issuecomment-1112595976

[vogella]

I had in mind that wating for the workspace was not possible before a change you did. Looking like this was wrong. So all the changes you did were "just" because the classes were using getWorkspace() before is was available?

[laeubi]

It depends, the problem that I like to solve (and what was not possible before) is that if the resources plugin gets activated it currently fails because the resources do not has a way to wait for the workspace location to be set (what obviously is a perquisite to open and register the workspace). This is currently tracked at https://github.com/eclipse-platform/eclipse.platform.resources/pull/71 and "all the getWorkspace() before is was available" things are there because we either expose a (not fully initialized) to everyone or some of the init coe fails at the moment... I got quite close fixing this but there is always something popping out e.g. https://github.com/eclipse-platform/eclipse.platform.resources/pull/98

Why is it a problem at all? Because even if I listen to an IWorkspace service I must carefully ensure that may bundle is not activated because otherwise loading the IWorkspace will activate the resource bundle "to early", and consumer of my bundle must take care not to active me and so on.... so everyone is in fear of activation, and when it finally happens ther is an activation rush rather than some bundles just starting e.g. while the workspace selection dialog is shown.

And that's where the workspace location tracking comes into account, because if the resource plugin itself waits before init the workspace and then registered the IWorkspace it doesn't matter at all (for anyone not using getWorkspace() but IWorkspace service), when their bundle is started and that the resources plugin is 'active' earlier.

[vogella]

Thanks for the explanation @laeubi. Sounds to me that once #71 is fixed, we should add this to the N&N. I close this issue therefore.

[laeubi]

One example is the MvnProtocolHandlerService as you can see we currently do not use DS here but the Activator because otherwise M2e would activate "too early" and then resources activates "to early" even though the protocol handler would be never had any use of the resources plugin...