Community
Participate
Working Groups
One more option to support: when Jrt container specifies limit-modules only the transitive closure of the mentioned modules should be observable. I don't see use for other classpath entries.
New Gerrit change created: https://git.eclipse.org/r/104815
Gerrit change https://git.eclipse.org/r/104815 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9b8300bd40097f83910af2d40fdc1cb6ee0c88af
(In reply to Eclipse Genie from comment #2) > Gerrit change https://git.eclipse.org/r/104815 was merged to [BETA_JAVA9]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9b8300bd40097f83910af2d40fdc1cb6ee0c88af > Released for BETA_JAVA9.
.
Once limit-modules has been defined, removing the limitation doesn't restore the original set of modules (need to close the project). Additionally, in a project with --limit-modules, UI (bug 521666) has no means to retrieve the list of available modules. This may actually require new API.
New Gerrit change created: https://git.eclipse.org/r/105257
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/105257 Fixes for both issues in comment 5: - Don't persist the filtered set of roots in PerProjectInfo#jrtRoots (we don't have the updating mechanism in place to update this list), instead consistently apply limit-modules filtering on every access. - I added provisional API, exported only to JDT/UI to allow access to the unfiltered list or roots corresponding to a given raw IClasspathEntry. For the API I'd be happy to merge this back into IJavaProject, if people like it, but since I didn't want to block necessary work by this API discussion I opted for the provisional API approach.
@Jay, I noticed no-one was subscribed to this bug, so repeating my last comment to keep you in the loop: (In reply to Stephan Herrmann from comment #7) > [...] > - I added provisional API, exported only to JDT/UI to allow access to the > unfiltered list or roots corresponding to a given raw IClasspathEntry. > > For the API I'd be happy to merge this back into IJavaProject, if people > like it, but since I didn't want to block necessary work by this API > discussion I opted for the provisional API approach. See also https://git.eclipse.org/r/plugins/gitiles/jdt/eclipse.jdt.core/+/refs/changes/57/105257/1/org.eclipse.jdt.core/model/org/eclipse/jdt/core/provisional/JavaModelAccess.java
Gerrit change https://git.eclipse.org/r/105257 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=54049bd43ee6ccfbd3f1b67192d2ed3baee764e3
(In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/105257 was merged to [BETA_JAVA9]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=54049bd43ee6ccfbd3f1b67192d2ed3baee764e3 > Both fixes mentioned in comment 7 released for BETA_JAVA9
Provisional API to be finalized in the 4.8 frame via bug 522391