Community
Participate
Working Groups
With extracting the modularity configuration into its own tab via bug 546352, data entered on one tab can affect validity of data entered on another tab. Specifically when changing the "module" attribute of any classpath entry, the Module Dependencies tab will have to react, or may even want to veto. Conversely, due to patch-module, some entries may change their module-ness, to be reflected in the Project & Libraries tabs. At an upper level, property pages already suggest to Apply changes before switching to another property page. Different tabs *within* Java Build Path have no such protocol, but share data via BuildPathBlock#fClassPathList, so that some changes done on one page are immediately available in the other. Still, while changes have not been Applied, additional coordination is necessary. I believe, that BuildPathsBlock.buildPathDialogFieldChanged() should be a suitable location for coordinating between different tabs, but we should check in detail how exactly this coordination should happen.
Also introducing a protocol BuildPathsBlock.pageSelected(BuildPathBasePage) would allow things like showing a page-specific status (e.g., on Module Dependencies we could spell out an Info "This project is not modular, module dependencies are not applicable".) See also BuildPathsBlock.tabChanged().
(In reply to Stephan Herrmann from comment #0) > At an upper level, property pages already suggest to Apply changes before > switching to another property page. In this regard the new UI is already clean: by directly operating on the list of CPListElements shared among tabs, changes made on tab Module Dependencies already trigger the question (Apply / Discard / Apply Later) when trying to select another property page.
- Add a library (e.g. external JAR) on Libraries tab, click Apply, go to Module Dependencies tab, the new library is not shown in the list of modules. - Close and reopen the dialog. The added library is now shown in the list. The same is applicable when removing the library from the Libraries tab, clicking Apply, and going to the new tab. The old library is still visible in the list and clicking on that gives the following exception in error log: Java Model Exception: Java Model Status [C:\Eclipse\Builds\eclipse-SDK-I20190506-1800\eclipse\plugins\com.ibm.icu_63.1.0.v20181030-1705.jar is not on its project's build path] at org.eclipse.jdt.internal.core.JavaElement.newJavaModelException(JavaElement.java:583) at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:256) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:596) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:326) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:312) at org.eclipse.jdt.internal.core.JavaElement.getChildren(JavaElement.java:267) at org.eclipse.jdt.internal.ui.wizards.buildpaths.ModuleDependenciesAdapter$DeclaredDetails.getPackages(ModuleDependenciesAdapter.java:172) ...
> (In reply to Stephan Herrmann from comment #43) > > From above we already have bug 546790. > Something similar is done in Launch configuration tabs when making a change > in the JRE tab and moving to Classpath/Dependencies tab without clicking > Apply.
Thanks, Noopur, for fixing the target milestone. That drop down is just too long for my screen :-/
(In reply to Stephan Herrmann from comment #5) > Thanks, Noopur, for fixing the target milestone. > That drop down is just too long for my screen :-/ You can try the Bugzilla script which provides links/shortcuts for many common tasks: https://www.eclipse.org/jdt/ui/dev.php#scripts.
New Gerrit change created: https://git.eclipse.org/r/142980
(In reply to Eclipse Genie from comment #7) > New Gerrit change created: https://git.eclipse.org/r/142980 This may not be perfect, but it's the best (and last code change) I can offer for RC1. Strategy: Mainly rely on the shared List<CPListElement> to synchronize with other tabs. Only change here: when switching to the new tab, re-scan all modules. I was afraid this could cause a performance issue, but in my toy workspace, such scan was a matter of ~10 ms. Until we have data from huge workspaces, I hope this is good enough. Re-scan includes clearing all cached data in ModuleDependenciesPage and ModuleDependenciesList. Next, I noticed that a jar freshly added to the module path still doesn't show up, because for this we need an IPackageFragmentRoot, which hasn't been created yet. Current solution: raise a warning: Not all modules could be found. Please consider pressing Apply to synchronize. Finally, I needed to re-scan modules also on Apply, which I achieved by letting BuildPathsBlock.doUpdateUI() unconditionally initialized ModuleDependenciesPage (not just when switching between 8- and 9+). @Noopur, unfortunately I won't have time for follow-up during office hours tomorrow. I'm fine with any of: submit, submit only part of the change, or defer to 4.13 - I'll have to let you decide which you prefer.
Gerrit change https://git.eclipse.org/r/142980 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=7bac3c186d92b7885ccc834b271de73c51e8d1ef
The current state of the patch looks good for RC1. I have released the patch. Please open a new bug to improve on this in 4.13 e.g. to synchronize automatically instead of the warning.
(In reply to Noopur Gupta from comment #10) > The current state of the patch looks good for RC1. I have released the patch. Thanks! > Please open a new bug to improve on this in 4.13 e.g. to synchronize > automatically instead of the warning. Sure, it's bug 547772. Suggestions welcome.
Verified in I20190529-2005.
