Community
Participate
Working Groups
UI Part of bug 526054: > - JDT/UI's ModuleDialog uses > org.eclipse.jdt.core.provisional.JavaModelAccess.defaultRootModules(Iterable<IPackageFragmentRoot>) > even in a modular project. ... > It could still be interesting to use that default for a modular project, to > test whether clients in an unnamed module would need any --add-module options. > This could, e.g., be achieved by a button: "Use default root modules like for > unnamed modules", which would then populate the Contents sub-lists accordingly. > Note, that also persisting limit-modules must be aware if current project is > modular to compare against the appropriate default.
Stephan, are you still planning to look at it for 4.7.2? Or, we can update the target.
I should probably split into: - correction a la bug 526054 - for 4.7.x - discussion if we want an additional button - later Still, 4.7.2 would be very ambitious even just for the first part. I'll have a quick look into this later today.
This fell through the cracks due to today's mayhem on hudson.
Stephan, is it still in plan for 4.7.3?
(In reply to Noopur Gupta from comment #4) > Stephan, is it still in plan for 4.7.3? Shame on me. I'm looking at it right now, if a simple, low-risk fixed is possible.
New Gerrit change created: https://git.eclipse.org/r/116777
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/116777 The fixed *does* appear to be straight forward: As stated the algorithm from JEP 261 should apply only when looking at an unnamed module. Ergo, two changes are necessary in ModuleDialog: (1) Make initialization conditional, i.e., when the current project defines (or patches) a module, put all found modules into "Explicitly Included". (2) When preparing the result for storing in .classpath, modifiesContents() needs to answer true under a modified condition: when looking at a named module any entry in "Available" or "Implicitly Included" will always be interpreted as a modification. Comparison to the JEP 261 list is *not* relevant in this case. So, with (1) the dialog is correctly populated, and with (2) we ensure that the correct result is stored, which can also be validated by checking that opening and closing the dialog should never change presence/absence of a limit-modules attribute. Relevance of this fix can be checked by the following scenario: In a modular project - make some changes to JRE contents, e.g., exclude all javafx* modules. - in module-info try to complete "requires java.a|" to yield java.activation. In the current implementation, java.activation will not be proposed, which is bad for a modular project, that has not explicitly excluded that module. Ergo: I think it's good to have in 4.7.3 - unless someone objects.
Gerrit change https://git.eclipse.org/r/116777 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=e29dc152e158cd79f23d84733a79358941655537
+1 to include it in 4.7.3.
New Gerrit change created: https://git.eclipse.org/r/116792
(In reply to Noopur Gupta from comment #9) > +1 to include it in 4.7.3. Thanks, here we go: (In reply to Eclipse Genie from comment #10) > New Gerrit change created: https://git.eclipse.org/r/116792
Gerrit change https://git.eclipse.org/r/116792 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=5074fefa0fcfa06d0e96907f8568ff2d9769bc45
(In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/116792 was merged to > [R4_7_maintenance]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/ > ?id=5074fefa0fcfa06d0e96907f8568ff2d9769bc45 Released for 4.7.3
