Bug 553385

Summary: Jar export should propose to add version information for modular project
Product: [Eclipse Project] JDT Reporter: marc revilloud <marc.revilloud>
Component: UIAssignee: JDT-UI-Inbox <jdt-ui-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: stephan.herrmann
Version: 4.14Keywords: helpwanted
Target Milestone: ---   
Hardware: PC   
OS: All   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=536330
Whiteboard: stalebug

Description marc revilloud CLA 2019-11-23 15:04:11 EST
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.
Comment 1 Stephan Herrmann CLA 2019-11-23 18:53:05 EST
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).
Comment 2 marc revilloud CLA 2019-11-28 03:52:46 EST
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.
Comment 3 Stephan Herrmann CLA 2019-11-28 08:02:52 EST
(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.
Comment 4 Eclipse Genie CLA 2022-05-30 09:51:55 EDT
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.