YourKit IDE Integration too Mac like

[Binyan]

One of my pet peeves with the Mac OS is that in certain cases it thinks its smarter than the person holding the mouse and your IDE integration suffes from ths too. In essense you're making simple things hard when you don't have too.

For instance it is common and recommended practice to install plugins in a separate directory and not in the <eclipse install directory>. This allows the same plugins to be used in multiple installs such as the stabe Eclipse 3.1.2 release and the Eclipse 3.2M5 release. However, this is frakked up with Yourkit, because 1.) you try and validate that there is an eclipse executable in the directory and if you don't find one then you refuse to proceed. Instead you should A.) ask for the "plugins" folder itself because RCP apps don't have to name the folder plugins if they don't want too and B.) if the user still selects to continue then copy the plugin to the location specified and maybe display the full path in a confirmation dialog so that the user knows exactly where you put it.

On the plus side you did create manual instructions, however they only get the plugin installed as YK forgot to document the fact that apparently after installing the plugin the IDE integration code also writes out a 'ide-integration.config" file in the user's home directory. I know this because the only way to get YK working was to actually let it install to my real d:\dev\eclipse\plugins, thus creating the ide-integration.config file and then delete out the YK plugin from the real eclipse plugins directory and use the one I put in my d:\dev\eclipse-plugins\eclipse\plugins folder instead were all 3rd party plugins are kept. Please look into fixing this because it currently stands YK is forcing people do a bad thing by installing all plugins into the eclipse install folder.

[Anton Katilin]

Hi,

I totally agree that simpler is better.

The problem is that it is not possible for the same plugin to work with Eclipse 3.0 and 3.1 and 3.2. The reason is that the necessary support from Eclipse side (API) is different in these versions. In particular, not everything can be made with public API in 3.1, because that API first appeared in 3.2. The situation with 3.0 is even worse.

Of course, using non-public API is bad. But without it was not possible to implement plugin at all for Eclipse 3.0 and 3.1. We decided to have a custom plugin for each Eclipse version in use (3.0, 3.1 and 3.2) rather than force users to use only latest (and not yet released!) 3.2.

Best regards,
Anton

[Binyan]

Hi,

I totally agree that simpler is better.

The problem is that it is not possible for the same plugin to work with Eclipse 3.0 and 3.1 and 3.2. The reason is that the necessary support from Eclipse side (API) is different in these versions. In particular, not everything can be made with public API in 3.1, because that API first appeared in 3.2. The situation with 3.0 is even worse.

Of course, using non-public API is bad. But without it was not possible to implement plugin at all for Eclipse 3.0 and 3.1. We decided to have a custom plugin for each Eclipse version in use (3.0, 3.1 and 3.2) rather than force users to use only latest (and not yet released!) 3.2.

Best regards,
Anton

I'm not going to knock you on the use of "*.internal.*" code since we use some too here. My issue was that the ide integration tries to do too much in validating that the user is installing the YourKit plugin to where you think the correct location should be. If the exact location doesn't meet your exact specifications then you refuse to go forward. Since you all know that you have a plugin for each version an option might be to allow the user to select the version to be installed wtih a note in a bold, flashing neon font that the plugin version is tied to the eclipse version. Also the manual installation steps should document the need for the ide-integration.config file and its contents and location, so end users who don't have the same plugin layout can benefit from YK also.

[Anton Katilin]

I see your point. We'll think about it, thank you very much.