Community
Participate
Working Groups
Since the introduction to modules in Java 9 (JPMS ), we can specify the modular jar version. This can be done using the "--module-version" option describe here: https://docs.oracle.com/javase/9/tools/jar.htm#JSWOR614 However, the JAR export tools do not provide options for defining the version of the exported JAR. The only solution is to do an update such as: "jar --update --file a.jar --module-version 1.0.1" after the creation of the jar by eclipse.
makes sense As of bug 548195, ecj internally has the capability to add the module-version field to the Module attribute. Some things still needed: 1. JDT/Core to provide API for setting the module version 2. JDT/UI to add a field in the wizard where the version can be specified 3. module-info.java must be re-compiled to add the version into .class Perhaps (1) & (3) could be combined into one API. Alternatively, we could make it a property of the project, so that each compilation will add the version to module-info.class, and the jar wizard will simply pick up the class file already containing the desired version. Naively I could think of an attribute in .classpath: <classpathentry kind="src" path="src"> <attributes> <attribute name="module-version" value="3.14.15"/> </attributes> </classpathentry> This would have to be set on the source folder containing module-info.java The Java Build Path UI could then provide a field (e.g., on Module Dependencies tab) where this version can be edited. Question: is the module version a property of the project, or should this be specific to the jar export, allowing, e.g, the same stuff to be exported with different module versions (just asking, not that I would see reasons for the latter).
I think it's specific to the jar export. Otherwise, the version number would be defined directly in the module-info.java. This version number should only appear at the time of export, when the compiled module is created.
(In reply to marc revilloud from comment #2) > I think it's specific to the jar export. Otherwise, the version number would > be defined directly in the module-info.java. This version number should only > appear at the time of export, when the compiled module is created. To be precise: module-info.class is created during each (incremental or full) build in Eclipse. I don't know the exact reasoning, why module-info.java does not define the version, Perhaps, because the Jigsaw EG was not ready to specify the format or such. Module versions are kind of a semi-official feature, with some freedom left to build tools. But I think it's fair to also consider Eclipse as a build tool, so we have this freedom to decide. Meaning: I think Eclipse is free to actually store the current version in some project file, rather than waiting for the export to ask the user. Technically, this would be easier in fact (no recompilation needed during export), but the question is: what is the expected use case? Does it make sense to export the same sources with different versions? Is *.jardesc a suitable location to put module versions into version control or is .classpath a better place? I'd like to hear a few more opinions before making a call.
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.
