If you received inactive project deletion emails on 4/30/25, you can ignore them. The projects named in those emails will NOT be deleted on 7/30/25. Some type of inactive project deletion will be implemented later this year, but you'll receive further communications before any deletions are scheduled.
feat: always populate MANIFEST with project.name and .version
This pull request directs the plugin to configure the jar task (if present, provided by the java plugin) and/or the war task (if present, provided by the war plugin) to set the Implementation-Version and Implementation-Title attributes in the MANIFEST.MF file included in the result.
The end result is that issue #1 (closed) can be satisfied by pulling out Implementation-Version from the MANIFEST. By using MANIFEST, we use a file in Java specifications and we don't have to pollute the build of downstream projects with our own custom properties file.
If a commit lands on master, and `cpublish.skip` is false, you can have confidence that the gradle `project.version` includes a new value. Running `gradle uploadArchives` to publish a new release will work.
TODO: currently depend on Jenkins to tag the release, provide a task to do this from Gradle
After the `uploadArchives` task completes, you can have Jenkins tag the release and push the tag to the repository.
1. In your Jenkins build job, in the **Build** section, add a `Execute system Groovy script` step, and have it run a copy of the provided [artifact-version.groovy](artifact-version.groovy).
2. In the same job, in the **Post-build actions** section, add a `Git Publisher` step, and configure it:
