Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle consumers issue #81

Open
elect86 opened this issue Jan 30, 2025 · 3 comments
Open

Gradle consumers issue #81

elect86 opened this issue Jan 30, 2025 · 3 comments

Comments

@elect86
Copy link

elect86 commented Jan 30, 2025

Gradle has a known issue when it comes to bom, it can't properly resolve dependency versions which have more than one layer of indirection

In my case, that is jackson.version.module.kotlin in jackson-bom-2.16.1

<jackson.version>2.16.1</jackson.version>
<jackson.version.module>${jackson.version}</jackson.version.module>
<jackson.version.module.kotlin>${jackson.version.module}</jackson.version.module.kotlin>

Could not resolve all dependencies for configuration ':webstartRes'.
Could not find com.fasterxml.jackson.module:jackson-module-kotlin:.

If jackson.version.module.kotlin had ${jackson.version}, then it'd work fine instead

How to fix this?

  1. Switch to Gradle Platform, this will generate .pom for Maven users and .module for Gradle ones
  2. Leave the current Maven implementation as it is and simply inject within it a Gradle .module file generation and include that in the publication, as I did with pom-Scijava, where you have platform (and catalog, if you want) published altogether at the very same coordinates.

I can provide a PR for either of them

@cowtowncoder
Copy link
Member

First of all, thank you for reporting this @elect86.

Ideally, of course, Gradle tooling didn't have this limitation. But it sounds like that this is not going to happen?

Now... I have no plans to move to Gradle so (1) won't work.

(2) might work, but depends a bit on complexity of the approach. If it's easy to show in form of PR I'd be interested.

But... alternatively maybe just going with the simplest (in some sense) choice of just flattening versions to remove use of intermediate jackson.version.module.kotlin -- we probably still need to leave that property available (if some Maven users did use it), but not use it.
So changing things to:

<jackson.version>2.16.1</jackson.version>
<jackson.version.module>${jackson.version}</jackson.version.module>
<jackson.version.module.kotlin>${jackson.version}</jackson.version.module.kotlin>

Note, too, that the oldest branch from which full releases are likely is 2.17 (full patch release takes 2.5 - 3 hours to make so I have to choose where to spend my time for maximum benefit). So PR probably should be against 2.17

@elect86
Copy link
Author

elect86 commented Jan 30, 2025

That's actually the simplest solution, yes

I'll craft one with that then

@cowtowncoder
Copy link
Member

Great! Also please add an XML comment or two to indicate reasoning (and if there's a link to Gradle platform limitation, that'd be great)

elect86 pushed a commit to elect86/jackson-bom that referenced this issue Jan 31, 2025
elect86 pushed a commit to elect86/jackson-bom that referenced this issue Feb 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants