Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store dependency versions in MANIFEST.MF file #19

Open
alexander-yevsyukov opened this issue Feb 17, 2022 · 5 comments
Open

Store dependency versions in MANIFEST.MF file #19

alexander-yevsyukov opened this issue Feb 17, 2022 · 5 comments
Assignees

Comments

@alexander-yevsyukov
Copy link
Contributor

alexander-yevsyukov commented Feb 17, 2022

We need a new mechanism for storing and loading the version of a tool and its dependencies.

ProtoData currently uses version.txt(stored in resources) for an artifact version. This approach would not work if components with different versions are merged into a fat JAR.

A better solution would be to use MANIFEST.MF file. The standard tag Implementation-Version tag would be used for keeping a version.

Dependencies could be stored in a custom tag called Depends-On. A value for the tag should be formed after this pattern maven:$group:$artifact:$version. Notice the maven: prefix coming before GAV coordinates. It 1) explains the format of the value 2) allows for extensibility—there could be other formats of values coming with a different prefix.

After this issue is addressed, the io.spine.tools.gradle.DependencyVersions should be deprecated. Version management in ProtoData should be updated too.

References:

@alexander-yevsyukov alexander-yevsyukov self-assigned this Feb 17, 2022
@alexander-yevsyukov
Copy link
Contributor Author

We have a Gradle script plugin which writes version information loaded by DependencyVersions. See the class io.spine.internal.gradle.VersionWriter under buildSrc.

@alexander-yevsyukov
Copy link
Contributor Author

Consider adding the following attributes to the manifest:

  • Name: the package
  • Implementation-Build-Date: the build date for the implementation
  • Implementation-Title: the title of the implementation
  • Implementation-Vendor: the vendor for the implementation

Ref.: https://www.baeldung.com/java-jar-manifest

@alexander-yevsyukov
Copy link
Contributor Author

In addition to version we need to store what's actually in the JAR. That is, somehow reference the artifact for which we store and later obtain the version.

JAR Manifest specification gives the following example of a JAR manifest:

Manifest-Version: 1.0
Created-By: 1.8.0 (Oracle Corporation)
Name: java/util/
Specification-Title: Java Utility Classes
Specification-Version: 1.2
Specification-Vendor: Example Tech, Inc.
Implementation-Title: java.util 
Implementation-Version: build57
Implementation-Vendor: Example Tech, Inc.

What we need to store is a group-artifact pair (in terms of Maven). The version is going to be stored separately, in the Implementation-Version attribute. Such a pair is called module in the Version Catalog feature of Gradle.

I don't think it is safe to use Module or Package in our case because these terms are already used for other manifest attributes (already handled by Gradle plugins) or they mean also something else in a broader Java context.

The candidates for our task are Name and Implementation-Title. The latter is closer to the code and comes together with the -Version sibling. So, if may come like this:

Implementation-Title: io.spine.tools:tool-base
Implementation-Version: 2.0.0-SNAPSHOT.90
Implementation-Vendor: TeamDev

@armiol, please have a look and let me know what you think of this.

@alexander-yevsyukov
Copy link
Contributor Author

Other attributes to consider for manifest: https://andresalmiray.com/customize-jar-manifest-entries-with-maven-gradle/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant