Bugzilla – Full Text Bug Listing
| Summary: | [1.9] module-info.java's "requires" should contribute to the compile-time classpath | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Simon Archer <sja.eclipse> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | stephan.herrmann |
| Version: | 4.8 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| Whiteboard: | stalebug | ||
This had been discussed before, but we decided not to let JDT support this because this would be a crippled solution for most real world scenarios. The reason is: JPMS supports neither versioning nor a strategy from where to fetch missing dependencies. Ergo, people will use a build system like maven or gradle anyway. The corresponding plug-ins connecting to these build systems are in a much better position to wire the buildpath using the information from module-info.java. IOW, the analogy to PDE for OSGi projects is not JDT but m2e or buildship or ... In our experience, the feature you request would come most naturally for toy/learning examples but would fail in real world projects. If you have real-world scenarios in mind, feel free to comment on what relationship you see between JDT and the build system of choice. For the learning example dimension, perhaps the quick fix you mention would be the best middle ground. My scenario is simply using JDT to develop Java modules. This is a fundamental requirement of the JDT. Having to manually maintain both the .classpath and the module-info.java just feels wrong. If my module-info.java says that it 'requires' another module, it seems right that Eclipse would know that the required module should be on the compile time build path. Breaking the D.R.Y principle by having to repeat myself only opens up the opportunity for me to make a mistake. While we use Gradle as our build system, it surprises me that a developer is required to have Gradle plug-ins installed in Eclipse to simply contribute to the Java project based on modules. While I've not yet investigated Gradle's support for Java 9 and the module system, my hope is that it will be able to calculate a module's build path via its module-info.java. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. (In reply to Simon Archer from comment #2) > My scenario is simply using JDT to develop Java modules. This is a > fundamental requirement of the JDT. > > Having to manually maintain both the .classpath and the module-info.java > just feels wrong. > > If my module-info.java says that it 'requires' another module, it seems > right that Eclipse would know that the required module should be on the > compile time build path. Just to close the loop here: yes, JDT knows which modules are required, but it has literally no clue where to find the module. The module name could even be different from the jar file, or the jar file has do be downloaded from some unknown-to-JDT server using some unknown-to-JDT repository format. It was a deliberate choice of JMPS *not* to help in this regard. JDT only propagates that choice to users. Hence WONTFIX is the correct choice, even if made by brain-dead genie ;p Besides, I do hope that buildship mediates in this issue. |
Using Eclipse 4.8M6 With the introduction of Java 9's module-info.java, it would be helpful if the JDT recognized that when a module "requires" another module that it is automatically make part of the Java project's compile-time classpath. Without this, I am forced to add the Java project containing the required module to the project's compile-time classpath. This breaks the D.R.Y principle, hurts the usability of the JDT, and is error prone. An example... 1. Create a Java project called "foo" with the following structure: src/ foo module-info.java module foo { exports foo; } 2. Create a Java project called "bar" with the following structure: src/ bar module-info.java module bar { requires foo; } 3. Notice that bar's module.info.java has the error "foo cannot be resolved". The only fix I have found is to manually add the "foo" project to the "bar" project's compile-time classpath. There's not even a quick fix for this. The JDT should be parsing the module-info.java and composing a compile-time classpath. When working with modules it should not be necessary to manually manage the compile-time classpath of the Java projects since we are already describing module dependencies via module-info.java. The PDE tooling has done exactly this for many years; if you add "Import-Package" or "Require-Bundle" headers to a plug-in project's META-INF/MANIFEST.MF, or if you add a plug-in project to another plug-in project's bundle.properties' additional.bundles property, the plug-in project's compile-time classpath is computed.