Include implementation and specification version info in MANIFEST.MF file in outputted JARs (#476)

[veita]

Manifest files were added to the RichTextFX libraries. Implementation and specification version were set to 0.7.0-M6 and 0.7.0 respectively. See http://semver.org.

Note that the version information must be updated manually. They also might be derived from Git tags
using Gradle plugins like https://github.com/palantir/gradle-git-version.

[JordanMartinez]

Thanks for the PR. I asked you to do this because I use Gradle and have never had to deal with the Manifest file. So, I figured you would know what was needed more than I, and your PR would include the needed information for your particular situation.

That being said, I'm cautious about merging this for three two reasons:

1. The version was changed from 1.0.0-SNAPSHOT to an actual version:

version = '0.7.0-M6'
ext.specificationVersion = '0.7.0'

@TomasMikula seems to leave the project version as is so he can make snapshot releases very quickly. He only overrides that variable temporarily when he makes a new release. Personally, I'm fine with what you've done, but he's the one who owns the project. I also like the idea of using that plugin, but that choice is up to Tomas.

2. You include both a project version and implementation version. Could you explain why? Due to the above issue, you can see why that might be an issue. (Again, this is personally unfamiliar territory for me). I initially guessed that one specifies the major release whereas another specifies the specific version. However, that doesn't make sense because one could infer that from the project version alone.

3. The Travis build failed. Your changes are obviously not at fault here (or at least shouldn't be since I can't understand how they could be the issue). However, I am adding the debug flags to gradle check again in #518 and ask you to rebase this commit on top of that commit. Edit: I've confirmed in #518 that the issue is unrelated to your code.

[veita]

1. That's ok for me. The values version = '0.7.0-M6' and ext.specificationVersion = '0.7.0' are only a suggestion since I don't know what the actual release planning and version naming schema for this project is. However, since the semantic versioning spec says that a normal version number MUST take the form X.Y.Z, I've chosen three digits.

If the values are set temporarily or not shouldn't matter. I've tried to use the https://github.com/palantir/gradle-git-version plugin, but it could not get the version string from the Git tags. The printVersion task always returned unspecified. Maybe I did something wrong.

2. Specification and implementation version could be the same. Many projects, e.g. Ant, Maven, seem to do so. It's probably the easiest way to follow this pattern if there is no specification. Or leave out the specification version. In my opinion the first three digits of the implementation version should be the release version (plus optional suffixes as described in the semver spec).

For more information about package versioning see Java™ Product Versioning.

[JordanMartinez]

That's ok for me. The values version = '0.7.0-M6' and ext.specificationVersion = '0.7.0' are only a suggestion since I don't know what the actual release planning and version naming schema for this project is. However, since the semantic versioning spec says that a normal version number MUST take the form X.Y.Z, I've chosen three digits.

Aye, the X.Y.Z is what we've typically been following. However, we stopped the base area from extending Control and instead extend Region, so that one could have access to more view-related API (hence the 0.7.Z releases). Since the API isn't yet stable enough for a stable release, these have been milestone releases (hence the M-# suffix). The issue tracker shows what bugs still remain, but I'm not sure what else we should do to stabilize the API. Tomas hasn't answered when I asked about it earlier.

I think the plugin only works if you first tag the commit and then run that command. If you did that and it still didn't work, then I have no idea! 😄

Specification and implementation version could be the same. Many projects, e.g. Ant, Maven, seem to do so. [the rest of your comment and that link]

Ahh... ok. That clarifies why the two values are necessary. For right now, let's leave the project version as is, but keep the specification version as 0.7.0. When Tomas makes a new release, he'll do his typical routine and the resulting JAR file will have the same manifest file as what this commit currently has. Does that sound good to you? If you are fine with that and update your commit to do that, I'll merge this.

[veita]

That's fine. Done.

[JordanMartinez]

Thanks.
As stated before, the builds' pass/fail don't matter in this case.