Community
Participate
Working Groups
Detail Description: 1.Go to Window > Preferences > Java > Build Path > Classpath Variables 2.Select a variable and click on edit 3.After making change to the value of a variable, for example ECLIPSE_HOME, Click OK. 4.Restart Eclipse, the modified value get reset back to the default value
Reproduced with N0421-0010.
This seems to be an issue only with ECLIPSE_HOME. In fact the EclipseHomeInitializer resets the values for each session. Moving to PDE/UI for comment. If this value cannot be changed, the variable should be set as reserved and not editable.
See the implementation in org.eclipse.pde.internal.core.EclipseHomeInitializer
It's not just ECLIPSE_HOME that doesn't persist the change but all the default classpath variables. I'm running IBM Rational Application Developer(which is built on top of Eclipse 3.0.2) and there's about 37 default classpath variables. Should the creators of these variables mark them as reserved manually or can Eclipse be smart enough to determine all the default variables and mark them automatically?
JDT/UI currently hardcodes "(reserved)" for the JRE* variables. It should do so generically for all variables contributed via the classpathVariableInitializer extension.
Hm, not sure if that wouldn't be breaking. Maybe some variables with inigtializers can handle or even want to allow user changes. It would be better if jdt.core introduces this concept of non-modifiable variables . Moving to jdt.core for comments.
I'd be fine if a new (optional) attribute was added the classpathVariableInitializer and classpathContainerInitializer schema (e.g. an attribute named 'reserved' with a default value of false). PDE could also benefit from this attribute for the PDE container, since it's a read-only and we don't want people to try to modify it via the UI.
For containers, you mean more than ClasspathContainerInitializer.canUpdateClasspathContainer ?
ClasspathContainerInitializer.canUpdateClasspathContainer is good enough for me, but it does not seem to be good enough for JDT/UI. The Edit... button is enabled when the PDE container is selected in the Java Build path property page (bug 77364). Bottom line is we need a mechanism to not allow anybody to mess with the PDE container via the UI.
Not for 3.2. BTW, pls clarify why the container support doesn't work. We could add similar support for variables.
assuming the question in comment 10 is for me: currently the PDE container returns false for canUpdateClasspathContainer(), however, in the UI, the Edit... button is always enabled and allows the user to attempt to make modificiations to the container. Then when Finish is pressed, PDE ignores all those changes as our container is meant to be read-only. The Edit button should have been disabled in the first place. Additionally, the container could have the word 'reserved' in the label.
(In reply to comment #11) > The Edit button should have been disabled in the first place. Additionally, > the container could have the word 'reserved' in the label. This is exactly what I meant in comment 2. If the Edit button is enabled, then it should be possible to change the value. If the container is meant to be read-only, it must be clear from the UI that this is a read-only container.
The question would be. Why the Edit button state is not consistent with the return value of canUpdateClasspathContainer() call? This looks like a bug.
I think it's ok to show the container configure page so the page can give some explanations about the container. I agree 'Edit..' is not the right term here. But PDE could for example add text (or a link) to say that dependencies are configured in the .manifest file. Can you elaborate about the changes that a user can make and are thrown away? I don't think this is possible. I wouldn't change anything here. Bug 77364 seems unrelated to me.
Very simple. 1. Go to Window > Preferences > Java > Build Path > Classpath Variables 2. Select ECLIPSE_HOME and click on Edit... 3. In my case, it shows: D:/eclipse/N0425/eclipse 4. Now I change it for: D:/eclipse/N0424/eclipse And I click OK. 5. Back to the classpath variable preference page, I can see the new value for the ECLIPSE_HOME entry. 6. At this point if I select it again and click OK, I see the new value in the text field. 7. Click OK to close the classpath variable preference page. 8. Open that preference page again and I can still see the new value. 9. Exit and restart. 10. The old value is back which is consistent with the implementation of this container. I can always reproduce. I am using 0425-0010 build.
Olivier, I meant modifications to a classpath container (not variable) that are thrown away. canUpdateClasspathContainer only releates to the container entries (children). if (canUpdateClasspathContainer is false) we won't let the user configure the children. The container wizard page is under the contributors control. PDE just shows information there, but doesn't allow modifictaion, JUnit (new container, just added) lets you specify the JUnit version, but it is also now allowing any children changes.
#canUpdateClasspathContainer() is meant to control read-only-ness, not just nested entries; i.e. the contract is that if it says it can be updated, then the change will be reflected after a call to #requestClasspathContainerUpdate(). The doc isn't super clear, but this is the idea. We can clarify the doc if needed. * Returns <code>true</code> if this container initializer can be requested to perform updates * on its own container values. If so, then an update request will be performed using * <code>ClasspathContainerInitializer#requestClasspathContainerUpdate</code>/ Currently, it feels the UI is inconsistent and bypasses the contract of #canUpdateClasspathContainer(). Would be a JDT/UI bug to me.
Yes, the API is not very clear. 'container values'... A better, clearer API, more finegrained for example, would be nice to have. Maybe a container wants to allow that the 'javadoc' attribute can be modified, but not the 'source'. In JUnit I want to allow reconfiguring the path, but not the children. The UI has been for that for quite a while now. Interpreting the updating rules stricter will break other containers. There's also no real benefit in that. As mentioned, no harm is done at the moment. I still doubt that there is a scenario where the UI allows the user to make changes on a read-only container.
The reason for #canUpdateClasspathContainer() is precisely to drive UI enablement. The fact you ignore it is your problem. I do not see finer granularity occurring, i.e. you are not going to show me 5 different buttons for each individual property... Anyhow, post 3.2
Again: it is not ignored. We are blocking the editing of all 'values' of the read-only container. But we allow the read-only container to show it's configuration page, where he can completly _replace_ the container. PDE doesn't even want replace, JUnit wants it. We don't need 5 buttons for all the properties, one is enough as we show all properties in the tree: select the one you want to modify and press 'edit'. Now either you can either change all properties of a container child or none. That's something we should improve in 3.3.
Martin, I am afraid I do not understand your idea very well. Could you please give more details about what should be improved?
bug 168077 is the request for an improved #canUpdateClasspathContainer()
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
