Community
Participate
Working Groups
Created attachment 267856 [details] Screenshot Test: Create src-check with module-info.java create src-test with module-info.java -> Project unusable in Package Explorer, e.g., its content cannot be shown anymore, see screenshot.
Jay, can you take an initial look please.
I see the problem. Looks like throwing JavaModelException is not a good idea to report multiple module-info in a project.
Wouldn't it be better if the create source folder action performs the validation and fails instead?
(In reply to Sasikanth Bharadwaj from comment #3) > Wouldn't it be better if the create source folder action performs the > validation and fails instead? Not sure what you mean. In my case, I already had them but put the second module-info outside eclipse and refreshed.
Is that s.t. that should be reported from the builder? OTOH, IProblem.DuplicateTypes is reported right from the compiler, so perhaps we can handle DuplicateModuleDeclaration just like that? (Of course smart wizards could help to *avoid* the situation, but still we must handle it, when it occurs).
(In reply to comment #5) > Is that s.t. that should be reported from the builder? > > OTOH, IProblem.DuplicateTypes is reported right from the compiler, so perhaps we > can handle DuplicateModuleDeclaration just like that? > I feel duplicate types doesn't qualify as a build path error, and it's easier to detect during compilation than initialization of the builder. Duplicate module-info files on the other hand definitely qualifies, similar to a cycle in dependencies, and should be reported by the builder as such. But yeah, there must be a better way to handle this > (Of course smart wizards could help to *avoid* the situation, but still we must > handle it, when it occurs). Ofcourse, I meant the wizard should change too
(In reply to Sasikanth Bharadwaj from comment #6) > (In reply to comment #5) > > Is that s.t. that should be reported from the builder? > > > > OTOH, IProblem.DuplicateTypes is reported right from the compiler, so perhaps we > > can handle DuplicateModuleDeclaration just like that? Sometime back that was the compiler was doing. But looks like that changed in the course of time.
In the compiler it should be simple to detect relative to LookupEnvironment#knownModules. Unfortunately we don't have any stacktrace to tell whether that would fix the original problem.
Bulk move out of 4.9
*** Bug 575098 has been marked as a duplicate of this bug. ***
(In reply to Stephan Herrmann from comment #8) > In the compiler it should be simple to detect relative to > LookupEnvironment#knownModules. > > Unfortunately we don't have any stacktrace to tell whether that would fix > the original problem. Hello, As I've created duplicate 575098, I've attached a trace (and screenshot as well) of the problem. The problem is fairly simple to reproduce in fact: 1. Create a simple Java project using Eclipse wizard with module in standard Eclipse folder; use com.example.eclipse as module name. 2. Add another source folder 3. Create a new module-info.java inside (perhaps from outside Eclipse or with Eclipse closed). In the part (3), I think I add the problem after investigating https://bugs.eclipse.org/bugs/show_bug.cgi?id=574831 using RCP.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
