Upgraded AWS SDK to 1.11.817 #100
Conversation
| @@ -27,6 +27,7 @@ configurations.all { | |||
| "com.fasterxml.jackson.core:jackson-core" -> useVersion("2.9.4") | |||
| "org.slf4j:slf4j-api" -> useVersion("1.8.0-alpha2") | |||
| "org.apache.httpcomponents:httpcore" -> useVersion("4.4.9") | |||
| "commons-codec:commons-codec" -> useVersion("1.11") | |||
There was a problem hiding this comment.
A new dependency? What is it for?
There was a problem hiding this comment.
Ok, it's an old one. Just a version bump.
There was a problem hiding this comment.
Old dependency, new version conflict. That's what happens if libs don't use version ranges: uncountable bogus version conflicts.
pbruski
force-pushed
the
Upgraded-AWS-SDK-to-1.11.817
branch
2 times, most recently
from
d257383 to
fd683f0
Compare
There was a problem hiding this comment.
@pbruski, what's the rationale behind the bump? Also, could you please add a CHANGELOG entry?
| architecture | ||
| } | ||
|
|
||
| return "ubuntu-focal-20.04-${imgArchitecture}-server-20200701" |
There was a problem hiding this comment.
The new SDK allows use of new architecture - arm64
There was a problem hiding this comment.
Hmmm. I've just realised that uses of aws-infrastructure will be broken if they use SDK older than the one where they introduced DescribeInstanceTypes. How do we handle that? That means a new major release, right?
There was a problem hiding this comment.
That's the problem with hiding version conflicts by default (damn you Maven). We can express that aws-infra requires at least this version, but it could be ignored.
Gradle consumers are in the clear. They can failOnVersionConflict to detect it early. And they can use dependency locks to control when the bump (and conflict) happens.
I tried to depend on AWS SDK SemVer range, but Maven would download every single POM for every version in the range (hundreds). It increased Maven build times by tens of minutes on cold caches. Gradle did no such thing.
Our examples for vendors use Maven, because the Atlassian ecosystem is built upon it.
So in general, it's not a problem for Gradlers, and it might be a problem for Maveners.
Even the loose Gradle users (without dep locks and strict conflicts) would not be impacted, because Gradle would pick the higher version anyway. Maven will pick the closest dep in the tree.
By accident, jira-performance-tests depends on aws-infrastructure first and then on aws-resources, so aws-infra AWS SDK will win. I confirmed it via ./mvnw -pl reference-jira-app-performance-tests dependency:tree in go/jpt repo. If we ever need to take the control of this, jira-performance-test can resolve this conflict in its POM.
So for now, we can stick to the current POM contracts:
Adding a requirement of a major version of a dependency is breaking a contract. Dropping a requirement of a major version of a dependency is a new contract.
If we ever find a way to (any of the following):
- get
failOnVersionConflictfor Maven - get dependency locks for Maven (this is actually very probable)
- get Maven to stop downloading the entire dependency version range
- avoid Maven as a build tool
... then we can rest easy with the current POM contracts.
A better POM contract could help us too, but I'm out of ideas there.
pbruski
force-pushed
the
Upgraded-AWS-SDK-to-1.11.817
branch
from
fd683f0 to
44ca2c8
Compare
No description provided.