fasterxml / jackson-parent Goto Github PK

The maven-enforcer-plugin version in oss-parent:30 (3.0.0-M1) is compatible with Java-9, but the version is overridden here in jackson-parent to an older version.

jackson-core has had a release of 2.6.3 but there is no corresponding release of jackson-parent. If we want to build jackson in a repeatable build system and the versions are not correctly aligned (i.e. everything using 2.6.3) then we would end up having to build 2.6.3, 2.6.2, etc etc.

This is the part of FasterXML/jackson-databind#2434 that relates to changes to the jackson-parent project.

For example https://github.com/FasterXML/jackson-parent/releases/tag/jackson-parent-2.15.

The assets for that release are:
https://github.com/FasterXML/jackson-parent/archive/refs/tags/jackson-parent-2.15.zip
https://github.com/FasterXML/jackson-parent/archive/refs/tags/jackson-parent-2.15.tar.gz

...which looks fine, but if you download those archives you get:

jackson-parent-jackson-parent-2.15.tar.gz
jackson-parent-jackson-parent-2.15.zip

...with the name in twice. The same is true for the other Jackson packages.

This has been like this for as long as I have been packaging Jackson packages in Fedora, I have just been ignoring it so far as it has been a minor inconvenience I didn't think worth the time to try resolve. However, I am now trying to simplify my life by using Packit to automate away some of the manual grunt work involved in package maintenance. There is an assumption in-built there that the source archive has the same name as the project, which the double-naming breaks.

It is probably possible for me to hack around this on my end, but before I do I wondered if this was a simple thing to correct? Or if it is like this by design, what is the reason for that?

Thanks for all your work maintaining these packages!

Cheers,

Chris

Not available LICENSE file in source directory structure
Please. Added license and copyright notice.
the fedora pakaging guideline is very strictly precise about this problem
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Text
thanks
regards

Jackson is a great library, but its frustrating that we can't use it with the Java Module System. Yes, jackson does have automatic module names, but you cannot build a minimal application image (jlink) or installer (jpackage) without explicit module-infos.

I tried forking jackson databind and its dependent projects, generating module-infos with jdeps, and then using javac --patch-module to repackage, but jlink still fails because it sees the Automatic Module Name field.

Although maintaining another branch may be require extra work, I think its worth considering to get the performance and size benefits of Java 11's defining feature. And since Java 11 is LTS, I expect the 4.0.0 branch would be created eventually.

Hi,

It's possible to find SNASHOT versions of jackson-databing in sonatype snapshot repo, but it's a but hard for some other components, even for a core.
This is how repo for databind looks like: https://oss.sonatype.org/content/repositories/snapshots/com/fasterxml/jackson/core/jackson-databind/
And this is how repo for datatype components looks like:
https://oss.sonatype.org/content/repositories/snapshots/com/fasterxml/jackson/dataformat/jackson-dataformat-csv/
So, it's empty or pretty outdates. Would be great to fix publishing of all modules.

Jackson parent uses the version 2.10, whereas jackson-core, jackson-annotations, jackson-databinding and so on all use version 2.10.0. This difference causes fun with things like gradle version resolution strategies.

For example, when bumping jackson versions to avoid recent CVEs, this is the difference between:

Closure versionStrategy = {
    eachDependency { details ->
        if (details.requested.group.startsWith("com.fasterxml.jackson")) {
                details.useVersion '2.10.0'
                details.because "spring boot 2.1.7 uses the wrong version: https://app.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-469676"
        }
    }
}

which is what I would use in the perfect world, and:

Closure versionStrategy = {
    eachDependency { details ->
        if (details.requested.group.startsWith("com.fasterxml.jackson")) {
            if (details.requested.name == 'jackson-parent') {
                //jackson uses the version 2.10 for some things and 2.10.0 for others
                details.useVersion '2.10'
            }
            else {
                details.useVersion '2.10.0'
            }
            details.because "spring boot 2.1.7 uses the wrong version: https://app.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-469676"
        }
    }
}

There was a version 2.9.0 of jackson-parent, so I'm not sure what the criteria is for any particular version number, which makes it difficult to predict ahead of time when upgrading.

Currently junit is declared with test scope in the <dependencyManagement> section.

Sincejackson-bom is a child of jackson-parent users of jackson-bom will, without further intervention, have their junit dependency forced to be test scoped, which is not always desirable.

I think jackson-all is more intuitive.