Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340597

Summary:	Allow users to interact with on-disk JRE update changes
Product:	[Eclipse Project] JDT	Reporter:	Michael Rennie <Michael_Rennie>
Component:	Debug	Assignee:	JDT-Debug-Inbox <jdt-debug-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	digulla, eclipse, linux.news
Version:	3.7
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Michael Rennie

2011-03-21 14:40:18 EDT

FUP to bug 266651

With support to detect on-disk JRE changes, we should also provide some mechanism for users to interact with the update process to decide what happens to the changed JRE (if anything).

I would envision something along the lines of a refactoring or compare dialog that would show the current state and the proposed changes and allow users to pick and choose what gets changed.

Comment 1 Aaron Digulla

2011-03-22 06:20:50 EDT

Most of the time, the change of the symlink will be to upgrade from 1.6.23 to 1.6.24.

So the rest is either unusual or an error (like using /etc/alternatives on Linux, upgrading the whole system and not noticing that Java was replaced with a successor).

Suggestion: If the user makes manual changes to the result of the LibraryDetector class, mark the VM config as "modified by user".

If the link changes && ( "was modified by user" or "the major Java version changes" ), open a dialog with the prefs settings for the VM, saying "Major version of the JVM changed" or "VM changed; unable to merge your modifications"

so users a) get immediate feedback that Eclipse detected the change and b) they know why it happens and what they have to do now.

Comment 2 Ben Bucksch

2011-03-22 08:47:26 EDT

"was modified by user" (or even using different storage fields for each, the automatic detection being just a cache) is a very good idea. If the original value was set automatically, you should not ask (bother) the user, only for user-modified ones.