Community
Participate
Working Groups
3.3 N0510 I find it surprising that Target Platforms are squirreled away in the preferences. For an RCP developer, a target platform is a real, first class thing. I may have several, and require tools for managing them, sharing them, etc. I think of preferences as "user tweaks to the IDE", a way I happen to like to work, and should be able to get all my tasks done without ever going into the preferences. Target Platforms are part of the output of (or input to) the development effort. For RCP development they really aught to be central to the task (rather than say managing required plugin lists). They deserve their own view.
you are so retro. All the cool kids use Target Definition **files**. that's where the real power is. The target platform in the prefs is for old guys.
Since I still believe Jeff is the only one outside the PDE team that uses target definitions, maybe this is an education issue. How do we educate people about target definitions and their benefits?
take away the preferences page :-) Hey, does this make me the coolest kid outside the PDE team?
Actually its not that I am retro, its that I followed the freekin doc! There's too many ways to do things in PDE. I understand that its because PDE has grown and we are always reluctant to remove old features. I think though that it would be a good time to step back and look at the workflows we want people to follow, and ensure the UI guides them in that direction. As one who is new to building RCP apps (and stepping out of the simple pattern of workspace self hosting), I have to say, the path is not very clear for the user, and the experience can be frustrating.
With respect to my last comment and the bug in general, the fact that "target files" are the in way, and I didn't discover them, is a problem. The general sense of the bug remains: to me, targets aught to be a first class entity. They may be backed by files, whatever, but in the UI they should be pervasive when creating a PDE application/product, managing its dependencies, and running it. There could be a special Target called, "The IDE I am running in" for the non-PDE eclipse self hosting development. Once I have compile errors/warnings out, then I should never get a runtime error because of a missing plugin, and exporting as a standalone should also be guaranteed to have all you require. Ok well that's the ideal. If I do something special/off the track then ok I need to do more to manage the dependencies and run configurations. At present I find it somewhat hit and miss.
+1 for all of Kevin's comments... cool kid notwithstanding. This new target file is a huge leap forward in supporting multiple configurations, but is far from ideal. I note that the Plug-in Development > Target Platform preference page now allow you to browse the workspace for *.target files. (But of course if you don't have any you just get a mostly empty dialog.) The only way I see to create a new target file from the preference page is to leave the pre-defined target combo box empty and click on the underlined Target label on the left. This does create and save a new target, but the available options are limited and this new target is not applied... leaving you to browse for it. So the UI is there, but not at all intuitive, especially if you're not a cool as Jeff. (Which would be most of us.) I guess what I'd like to see here is a "New Target" button that launches the Target Definition wizard. This wizard should do far more than simply create a new target file, it should allow me to walk through the configuration steps that are currently available in the preference page and the target file editor. I'd also like to see the ability to SAVE the current target configuration as a target file.
(In reply to comment #3) > take away the preferences page :-) so when? :) Looking at WTP they're smarter to require (in 90% cases) to first create a server, before creating any project. PDE should work like that as well. Of course default could be always the "IDE I'm running in", or last one created. After all, most WTP users only have one/two servers, more than 5 indicates a maniac.
ya... this is like a 3.5/4.0 idea... we need to really re-think the way we work with target platforms... and how we define them... target definitions were a start in the right direction...
(In reply to comment #6) > I guess what I'd like to see here is a "New Target" button that launches the > Target Definition wizard. This wizard should do far more than simply create a > new target file, it should allow me to walk through the configuration steps > that are currently available in the preference page and the target file editor. I like this approach. So a first step to encouraging the use of target files, so we can all be as cool as Jeff (I never thought I'd say that, wow) is to restrict the actions in the preference page to something like: 1) select an existing target as the current (same as "Set as Target Platform" in the target editor) 2) launch the wizard to create a new one, dropping the person into the target editor so they know that's where they go in the future Thus the *only* preference is to identify which target you're using. >>I'd also like to see the ability to SAVE the current target configuration as >>a target file. Backwards compatibility is an issue if I have actually modified the target info in the preference but such a "Save as target file" would help move people forward. The only unfortunate part is that (2) requires a project for the file to live in which makes it much heavier weight than just editing some preferences. Mind you, at least it doesn't disappear when I nuke my workspace .metadata. While we're future gazing, I aught to be able to see the target in the package explorer since again they should be more first class and deserve more lovin' than a list in an editor. I think my ideal would be a split pane explorer, with my source projects in one, and the target in the other. That way I can easily browse the target API's I'm writing against, its always clear what I'm working on vs. what I'm using. As a bonus it'd be a step to getting rid of the rather awkward "External Plug-in Libraries". All of this assumes that "The IDE I am running in" is always presented as just another target, which you happened to get preloaded and happens to be the default.
*** Bug 111404 has been marked as a duplicate of this bug. ***
This has been addressed in 3.5 M5/M6. The new target platform preference shows target definitions as first class entities. Definitions can be created/edited and the user can easily switch between them by setting the active definition. We could add a link/action to make it more obvious that a target editor exists. New bugs should be opened as required. *** This bug has been marked as a duplicate of bug 256910 ***
