Include version information in manifest about metadata-extractor

[RicardoBochnia]

Done in RicardoBochnia@e17d91c Not tested if ant build needs adjusting.

[drewnoakes]

Thanks for picking this up. I'm not sure we should be creating the file explicitly in the repo. In both the Ant and Maven builds, the file is created as part of the JAR creation. It looks like this was happening in the pom.xml, but you removed it.

Also, could you apply this and future fixes on top of the project's current master and submit as new pull requests? There's no easy way to merge this from your fork at the moment as it's stacked on top of all your other changes, some of which cannot be merged.

[RicardoBochnia]

The problem is you can't run junit tests on a non-existing file. Thus you would the manifest in the repository to test it. Otherwise you would have to do a full build each time just to run the manifest unit test. An existing manifest is used by maven and ant. They both will just apprehend entries to an existing manifest file. So instead of writing the same stuff in the pom.xml and the build.xml it easier to just write it into the manifest file.

[drewnoakes]

The version number will still need to be in pom.xml and build.xml. Creating a new file means it'll be in a third place too.

[RicardoBochnia]

Yeah to set the version number in four different files kinda sucks.

The original manifest is just a template for the maven and ant build process. It's the only way to implement a unit test which validates that the generated manifest.mf in the jar will contain the entries from the original manifest file.

[rgauss]

You could create a multi-module project with something like a distribution-test as the last module that verifies the artifacts built by the previous modules.

[drewnoakes]

Hey Ray. That does sound like a sensible way to do it. What else might we include in that test? Is it really worth it?

[rgauss]

Tools like Maven are pretty well tested already so when building with best practices there's probably no need to test the manifest info.

Things like the Maven release plugin help automate and regulate things even further.

Off hand I'm not sure what else you'd need in a distribution test. You'd usually only need that if you were putting things in your final artifacts in non-standard ways.

[drewnoakes]

I believe this is now complete and will verify when completing #1. Closing for now.

[OlivierJaquemet]

Thank you Drew !

[RicardoBochnia]

The version info for the jar plugin is missing. By default it uses 2.1 if I run the maven build, however the current version is 2.5.