https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
Untitled.kt
v
Why are you confused? Something is requesting 2.1.1, so conflict resolution uses that one. Your 1.+ is not strict, so if something else wants 2.1.1 that wins. You can use 
dependencyInsight
or build 
--scan
to find out where it comes from if you are curious.
c
so how'm I supposed to override it?
Copy code
karta.annotation:jakarta.annotation-api:2.1.1
  Variant compile:
    | Attribute Name                 | Provided | Requested    |
    |--------------------------------|----------|--------------|
    | org.gradle.status              | release  |              |
    | org.gradle.category            | library  | library      |
    | org.gradle.libraryelements     | jar      | jar          |
    | org.gradle.usage               | java-api | java-api     |
    | org.gradle.dependency.bundling |          | external     |
    | org.gradle.jvm.environment     |          | standard-jvm |
    | org.gradle.jvm.version         |          | 17           |
   Selection reasons:
      - By constraint: dependency was locked to version '2.1.1'
      - By ancestor
      - By constraint: rejected versions 1.3.5, 1.3.4, 1.3.3 because need the 1.0 api
      - By conflict resolution: between versions 2.1.1 and 1.3.5

jakarta.annotation:jakarta.annotation-api:{strictly 2.1.1} -> 2.1.1
\--- compileClasspath

jakarta.annotation:jakarta.annotation-api:2.1.1
\--- org.springframework.boot:spring-boot-starter-parent:3.1.4
     \--- compileClasspath (requested org.springframework.boot:spring-boot-starter-parent:3.+)

jakarta.annotation:jakarta.annotation-api:1.3.4 -> 2.1.1
\--- si.uom:si-units:2.1
     +--- compileClasspath (requested si.uom:si-units:{strictly 2.1})
     \--- systems.uom:systems-common:2.1
          \--- compileClasspath (requested systems.uom:systems-common:2.+)

jakarta.annotation:jakarta.annotation-api:1.+ -> 2.1.1
\--- compileClasspath
got it, I think
Copy code
constraints {
    implementation(libs.javax.annotation) {
      version {
        strictly("1.3.4")
      }
      because("need the 1.0 api")
    }
  }
v
As you see, spring boot requests that version. So you could for example exclude it from boot, out you could just a strict version
c
right, not sure why boot is doing that
v
You can use a strict version in the version catalog too
Both, with using a verbose version declaration of with the 
!!
shortcut suffix
c
? what's that look like?
1.+!!
?
👌 1
t
You could use another artifact providing 
javax.annotation
classes that won't conflict with Jakarta EE 9+ artifact coordinates. E.g. 
org.apache.tomcat:tomcat-annotations-api
(according to https://github.com/gradlex-org/java-ecosystem-capabilities)
c
Yeah, but I'm guessing that one is just as likely to end up on my classpath... At least if I ended up using tomcat
Thanks to all those involved in this mess
I wonder if there's a way to fetch and then rename the coordinates before adding/ resolving the dependency
v
Not fully sure what you mean, but it sounds like a bad idea. :-) Just use a strict version and you should probably be fine.
c
Heh, the problem with this jar hell is the bad idea... Why on earth none of these providers thought to rename the coordinates when changing the API I'll never know... Of course then we can also refer to all of the other people who created this mess.
v
It's "just" a breaking change that was done in a major version. If they would have renamed coordinates you would get both versions on your classpath and some parts in your system will use the old ones, some the new ones. That would even be worse most probably. Better it clearly fails when some parts you use support the old ones and some parts you use support the new ones. Then you at least know instantly that something is incompatible and can try to find a combination that works instead
c
It's actually a completely new API, arguably. No package preservation done at all. There's also the split package problem with this one... 😔 Normally I'd agree with you but all of these javax packages were kind of important and so doing this with those created kind of a problem
t
@Vampire I disagree. Because of the package renaming, there should be very few (if any) reason that having both the 
javax
and 
jakarta
version at the same time in the classpath would break. If things can cohabit, then there's no reason they share the same Maven coordinates. Some people go as far as changing their Java package and Maven coordinates whenever they ship a breaking change (https://jakewharton.com/java-interoperability-policy-for-major-version-updates/)
v
That's the point, it would not break. It would silently work, or rather not work.
If you for example have a Weld version that uses 
javax
CDI, and some library that provides beans with 
javax
CDI.
Then you update one of the two to a new version that uses 
jakarta
CDI, then the beans are not found anymore as they use the wrong annotations.
This can lead to a big break, or it can just cause some things not behaving as expected silently
Imho it is better that there is a clear conflict, as it is extremely unlikely that it is a good idea to have both of these APIs on the classpath
t
Mixing 
javax
and 
jakarta
packages in the same app still is possible if "upgrading" from 
javax
to 
jakarta
coordinates. Also, there's a difference between "it's not what you'd want" vs. "it's impossible". Choosing the "it's impossible" path when technically they can coexist was a bad idea. Anyway, that ship has sailed, Jakarta EE 8 was among the dumbest idea on earth (partly due to Oracle being a d*ck, partly due Jakarta not understanding dependency resolvers and usage of their technologies outside of "big-ass application servers") and we now have to live with it (until, one day, all those 
javax
will be buried for good).
v
🤷‍♂️
c
I don't see why a good CDI system wouldn't be able to recognize both JavaX and Jakarta annotations at the same time. The weld example you're describing would simply be a flaw in weld not allowing it to continue to recognize Javax annotations.
t
like… Guice 6? https://github.com/google/guice/wiki/Guice600#jee-jakarta-transition 😎 (with a small limitation, and note that they fully transitioned in version 7 released at the same time; unfortunately there's not only annotations, but also 
Provider
implementations and injected values, so it added complexity) Wrt Weld, and "Jakarta EE application servers", it was envisioned that the application server could rewrite the bytecode on-the-fly. No idea if it actually happened.
c
🤷‍♂️ If spring can do it...
v
would simply be a flaw in weld not allowing it to continue to recognize Javax annotations
No, a given Weld major version is about a given CDI version. CDI 2 hast javax. CDI 3 has jakarta.
c
Design flaw. Imagine upgrading and some code you're importing from third party jar doesn't work 🤣. Like you've literally just described the exact scenario you were saying would be a problem earlier...
The problem apparently already exists
v
That's not a design flaw, it is a design decision. If the 3rd party jar is not compatible with CDI 3, it is not compatible with CDi 3. The same as when you use version 5 of some library and have another 3rd party jar that is only compatible up to version 2 of that library.
c
Right so wouldn't have mattered at all if they had renamed the artifact coordinates. They would still just be ignoring the Java X ones
v
Exactly, they would ignore them and you wouldn't notice, hence it is imho good they didn't as you then see the conflict and can take care
It is not different than any other situation where you compose multiple modules that depend on common dependencies which might have breaking changes over time.
c
I mean depending on how I'm deploying the server I still might not notice... That said this library I'm using I'm not even sure what they're using it for. Pretty sure that Java measure doesn't use CDI
Also when you're doing a major upgrade you should always pay attention and test everything
If you don't then it bites you that's on you
v
For some libraries like the Apache commons ones that are more or less stanalone utility libraries that can well coexist, it is fine to have different artifacts for major breaking changes. For other things like CDI this does not make too much sense imho
Also when you're doing a major upgrade you should always pay attention and test everything
In an optimal worlds, yes. In reality, impossible. And besides that, fail-fast is imho always better than only finding things at runtime.
But well, let's just agree to disagree here, we will not come to a different concensus
👍 1
c
Well let me ask you this. The last time I checked in An EE environment, You could have a single server with many apps embedded in it. The problem of course is that those apps might have the same library but on a different version. That still a problem?
v
That never was a problem, as the apps have separate class loaders for the libs they ship.
Given a proper application server implementation of course.
4 Views
Open in Slack
PreviousNext
Powered by