Community
Participate
Working Groups
Build: M4 When you start a new workspace, by default PDE does not detect any external plugins. This makes most of the PDE UI appear broken... if you create a blank plugin project, and then try to add extensions, there are no available extensions in the list. If you try to add a depedent plugin, there are none found, etc. Basically, you can't do anything until you go to Preferences > Plug-in Development > Target Platform, and click "Not in Workspace". I think preferences should generally have a default value that is usable. In this case, I think a reasonable default would be for PDE to include in the target platform all plugins in the install that are not also in the workspace.
'Reasonable default' is relative and depends on the user group. Most of the Eclipse team self-hosts using binary project and do not use external plug-ins at all. For them, the current default is 'reasonable' :-). Absolute beginners that start by using PDE 'new' wizards are offered help and have the external plug-ins enabled when they try to create a new plug-in. Therefore, they are covered as well. The only group that is not covered are product teams that already have projects (hence are not using the 'New' wizard) but use a mix of external and workspace plug-ins. We consider them advanced enough to know about 'Not in Workspace' and the target platform preference page in general. PDE users are quite diverse and it is hard to find defaults that will make everybody happy.
It was the "Absolute beginner" category I was coming from. I was trying to demonstrate the basic steps to creating your first plugin to our new co-op students. Maybe my downfall was in selecting "Blank plugin project" in the PDE project wizard? I wasn't offered any help and didn't get the external plugins enabled automatically. I didn't want auto-generated content, so "Blank plugin" seemed like the correct choice.
That sounds about right. When you select a template, it generates Java code and it would not compile without external plug-ins. Even 'Default Plug-in Structure' has at least the top-level plug-ins class that requires platform UI in order to compile. You would get a warning for it. In contrast, blank plug-in does not contain any Java code, so strictly speaking you do not require external plug-ins in order to compile it. At that point we don't know if you will import binary projects or enable external to continue your work (either is find by us). We have fequently being criticized for trying to be too helpful and making wrong assumptions in the process, so we are trying to be careful with 'user friendly' code :-).
I don't know what the right answer is... I think the crux of the problem is that the "Target Platform" page has low visibility because it is under preferences. It would be useful to have some cues to either steer people to that page, or to present that page in other contexts when necessary. For example, when the user tries to add an extension or a dependency when there are no plugins in the target environment it could either present that configuration page in a dialog or steer people to the preference page... "You are trying to add a dependency, but there are no plugins in your target platform. Would you like to configure that now? Yes/No...". Or perhaps target platform configuration could appear in the wizard when you create a plug-in project... It's true that a blank plugin doesn't technically need any other plugins to compile, but in order to run it needs at least the basic ones (xerces, runtime, boot). Perhaps at least those should be added to the target platform when a blank plugin is created?
Defer.
Re-opening.
The default should be changed, and has certainly changed in 3.0. By default, all external plug-ins are checked for more than one good reason (some of which are listed above).
