Remove VERSION.txt files from Jackson JARs about jackson-core HOT 12 CLOSED

Hmmh. Unfortunately, there is a good reason for them being there especailly for product versions -- that is how version discovery works, using Class.getResourceAsStream(...).

But if you can figure out how to change "src/main/java/com/fasterxml/jackson/core/util/VersionUtil.java" to do this reliably, this could be done. Initially I thought it important to allow multiple versions per jar, but I don't think that makes sense, given how jar itself has a single version. But there is still the question of how to find out metadata for just the jar. On plus side, VersionUtil does also have 'mavenVersionFor' function so perhaps that could be a replacement.

Note that there are unit tests for verifying that version is correctly detected. Maybe those could help here.

from jackson-core.

Btw, on jackson-annotations... this is due to technical limitation that jackson-annotations is the only jar that does not depend on jackson-core, so it does not have functionality to read the information. It also does not have any obvious object that would expose version (i.e. any implementation of Versioned -- they are just annotations).

Although come to think of it, ability to verify version of annotations package is actually something that should be valuable. So maybe best way to think of that is to consider it an omission, gap in functionality. Every other jar should have it however. VERSION.txt itself is filtered during Maven build, to inject Maven version info in. So it may well be duplicated in pom.xml; and if so, pulling it dynamically from there would be just fine.

from jackson-core.

I'm not using Maven as my build tool, nor do I have any experience with it. That said, I currently do not fully understand who generates VERSION.txt and why it is needed, esp. since
jackson-core.jar/META-INF/maven/com.fasterxml.jackson.core/jackson-core/pom.properties
already seems to contain the required information. So, your suggestion to simply use mavenVersionFor instead of versionFor sounds very reasonable to me. I also agree that supporting multiple versions per JAR is probably not a good thing, mostly because the JAR file also contains the version as part of its file name e.g. when downloaded from Maven Central.

Given my limited knowledge about Maven and your build / packaging process I hesitate to come up with a pull request for this. I'd highly appreciate if you could give me a hand here.

from jackson-core.

As I explained, VERSION.txt is there so that code can read version information via standard Java resource loading mechanism. This will not work if file is not visible from same location as class files themselves. Version access is a runtime feature, meant to be used by extensions that need version-specific features (like work-arounds for known bugs in old versions). Alternative approach could have been generation of class files or such; this was the easiest and simplest way I could think of.

Maven properties are added by Maven, and was added later on (for 2.0). VERSION.txt predates this.

from jackson-core.

FWIW, it is likely I will not have time to work on this in very near future. Hopefully someone else has. As usual I can assist & track bugs, but for coding time will be limited until early next year.

from jackson-core.

I can make the change, presuming I understand the implications, to pull
version from the pom.properties in the META-INF area. As Tatu has said,
the version information is used programmatically within Jackson, so you
risk breaking things if you remove it completely.

Are you just looking to save space, or does the .txt file (versus a
.properties files) cause you a particular headache?

On Wed, Dec 5, 2012 at 9:40 AM, Tatu Saloranta [email protected]:

FWIW, it is likely I will not have time to work on this in very near
future. Hopefully someone else has. As usual I can assist & track bugs, but
for coding time will be limited until early next year.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-11051753.

from jackson-core.

From original description, there is apparently a real problem, so not just space savings.

from jackson-core.

@prb Yes, there's a real problem in the sense that the VERSION.txt files are cluttering up the APK. Thanks for taking a look at this!

from jackson-core.

Actually, now that issue #49 supports alternate method that can replace this method, we could drop VERSION.txt.

Although I guess I still do not quite understand (after re-reading report) what the actual problem is, beyond being noisy. I mean, is there an error of some sort, or failure to load?

from jackson-core.

No, there's no error, it's really "just" about the noise. In any case I'd be grateful if VERSION.txt could be dropped in favor of a solution that does not rely on any extra files (outside of META-INF).

from jackson-core.

Fair enough -- I really just wanted to know nature of the problem. We don't want unnecessary stuff to be included either.
Since the better system is included in 2.2, we can start removing these over time (as soon as module has been converted, VERSION.txt can be dropped).

from jackson-core.

Just removed VERSION.txt from core, and over time will remove from other jars as well, when converting version detection.

from jackson-core.