Community
Participate
Working Groups
The Java Build Path properties page should refresh when it is opened and should also have an apply button. We are running into problems because we also contribute a properties page to Java projects that edits the build properties and it is unclear what the current state of the build path is. There are two main problems. First, the user opens our page, modifies and applies the change and then goes to the Java Build Path page where the change is not available because it is not refreshed. At this point if the user modifies the Java Build Path page and exits. The changes he first made are wiped out and replaced with current state of the Java Build Path page. Second, the user opens the Java Build Path page and modifies some information and then goes to our page; these changes are unavaible. It would be nice if the user could have applied the changes from the Java Build Path page to make them avaible to our page. We are able to handle this state (in English at least) because our page comes after the Java Build path page and is saved last. Ultimatly, the best solution would be to create an in memory copy of the Build Properties that both pages could use without these synchronization issues.
Why is it necessary that you provide your own page to edit Java build path properties ?
Our J2EE tools plugin provides a "Java JAR Dependencies" property page. This page is used to modify the runtime classpath, aka in the MANIFEST.MF file, AND the Java build path in a one-stop-shopping approach. In our project structure, each module in an EAR is mapped to a project or JAR file in an EAR. We try to steer our customers to use our page instead of the Java build path page, when they are modifying the build path to set up project-to-project dependencies when the projects represent modules or JARs in an EAR. However, we can't stop them from using the Java build path page as well and therefore it would be nice if we can have better syncronization to mitigate the update anomolies that users often encounter. The web tools plugin contains a similar page for "web library projects", which allows you to treat a Java project as a "virtual" JAR under the WEB-INF/lib directory. At a minimum, the Java build path page could listen for updates to the classpath and refresh accordingly when it is focused. More advanced would be for us to work together and figure out a way for the Java build path page to be extended, where other plugins can contribute pages that would be synchronized with the other pages.
The same problem exists with other perference/properties pages as well. Given the current schedule (we have passed RC1 and only consider critical bugs) there is little we can do since opening the build path dialog or listening to class path changes envolves recoding. A "low risk" solution would be to commit the changes on page flip instead of dialog closing. But to do so, platform support is needed. Postponing > 2.1. But we should look into this for 2.2
Users are still having difficulty with this. Will it be resolved for 3.0?
Is this going to be addressed for Eclipse 3.0?
Martin, can you please comment on possible solutions to solve this problem.
We should discuss this also with the core. The 'project capability' proposal was the solution for that (depending on the nature a project can decide which property pages are there)
I've discovered a partial workaround for this problem. It seems to force a refresh of the classpath settings if one changes the order of the JAR or project that satisfies the dependency using the Order and Export tab of the Java Build Path page. This doesn't always work, but I've been able to save a little frustration by resorting to it.
proposed for 3.0
Is there a design doc available?
CC'ing Dan as we discussed this at length recently.
Sorry about the multiple updates, having some problems with bugzilla: As we discussed recently, there are a few approaches to solve this: 1) Add exclusion filters which would allow us to replace the Java build path page with our own, based on the nature. There are some limitations to this. -A. We don't want to copy all the code in the Java build path page and reference internal code. There is some function in Java build path that we still want to keep, e.g., source folders, classes folders, libraries. -B. We actually have 3 different property pages that can modify the build path 2) Change the build path page to use a notification based working copy of the Java build path. The all our pages can use this as well. When the working copy is changed, the property pages can refresh accordingly. 3) Change the behavior of preferences such that changing the page will apply the changes. Then all build path related pages need to refresh when they are re-focused. Pages that force an autobuild would indicate this but the autobuild would not fire until the dialog is closed. This issue is very important to our product, and we'd like to see some resolution in the 3.0 timeframe.
Regarding the proposed solution: 3.) this requires lots of work since we have to do it for "all" preference pages to be consistent. Another solution is: 4.) pages that manipulate the Java build path create a "copy" of the build path when they first open. If the loose and gain focus the compare the current setting with the stored copy. If they differ, some other page has changed the build path and they could be adjusted. This solution doesn't require additional API nor new concepts (overriding of preference pages).
In option 4, what would happen if the user modified one page but did not hit "Apply", then flipped to another page? How would the changes be kept in sync? Options 2 or 3 would address this.
This is correct. But the case gets detected when the users presses apply on the second page. So it handles the "last save wins" case which I thought causes the most trouble.
Getting the Java build path page to refresh after one of our pages has been applied is certainly an improvement. Synchronization even when changes are not applied would be even better. I think the right solution should take that into consideration, but would settle for option 4 only if the "right" solution cannot be contained.
We decided to implement solution 4. It will also work if we get 3.) from the platform (I'm not conviced they will like that idea). In fact all preference and property pages should to implement 4: Our preference keys are API so for any kind of setting conflicts are possible. Summary of solution 4: Whenever a page becomes visible, it has to read the options it configures from the store and compare them with it's working values. If different, a dialog is opened to ask which if you want to update the working values with the stored changes. Open point is how to react if the conflict is discovered on finish. Cascaded dialogs could be the result.
Solution 3 is the preferred solution but we will take solution 4 in the Eclipse 3.0 timeframe if 3 cannot be contained. A reasonable solution is better than no solution at all. ;-)
I implemented solution 3 for the Java Build path page. When leaving the page with unapplied changes, a dialog asks the user to apply the changes so that other build path related pages can update. When becoming visible, the page always refreshes with the settings from the build path. Other options are 'dicard and keep unapplied'. This is implemented in 'setVisible' which has some limitations, e.g. I can't e.g. prevent that the page switch. Have a look and let me know what you think. > 20040218 (for M8)
Verified by Jialin Chen
