This message was deleted.
# community-support
s
This message was deleted.
c
Additionally, adding a full number in front
Copy code
implementation("com.mycompany", "mylib", "1.release-125")
then we can get gradle to throw a resolution error
Copy code
> Could not find com.mycompany:my-lib:1.release-125.
Are there different resolution/failure rules for when an version is number formatted vs alphabetically formatted?
although what you have is an empty base version with a
release-*
qualifier, which is quite confusing
actually I'm not sure if that's how it's parsed, hmm
v
Gradle does not interpret versions as semver. In that version
release
is the "major" version and
125
and
87
are the "minor" versions. It just splits versions at
.
,
-
,
_
, and
+
and additonally at the change between non-numeric and numeric, then the parts are compared. So
release-87
<
release-124
<
release-125
That 87 is picked when 125 is also requested, or that 125 is picked if 124 is requested and 125 not at all both make little sense to me and would need an MCVE
c
I was able to reproduce it.
Copy code
gradle mylib1:pTML mylib2:pTML
will create 2 publications (published to ~/.m2) these will have 2 versions of the same artifact (release-124 and release-87)
run
gradle :myconsumer:run
to see the output
change the dependency version and the other jar will be picked up.
v
If that setup is comparable to your setup, I guess you have other problems. You should not have two projects that produce the same artifact coordinates. And if the consumer is in the same build too, I think the published artifacts are not used anyway, but the project dependencies directly.
c
This in no way mirrors our setup, other than our versions being named
release-<build-number>
And us being confused about the resolution rules wrt
Copy code
// why is release-125 completely ignored
implementation("com.mycompany", "mylib", "release-125")
implementation("com.mycompany", "mylib", "release-87")
Basically
myconsumer
is the only part comparable to our setup. If you change
release-125
to
1.release-125
(for example) it’ll throw a dependency resolution error.
v
Actually, right away this does not make much sense to me and I'd tend to say it is a bug.
It seems, that at least for local directory repositories non-existing versions are ignored which seems to be wrong
c
This is reproducible in remote repositories as well (I’ve verified release-125 is absent in our artifactory instance)
v
Hm, I guess it is too late for me to think properly, maybe @ephemient is fit enough to see more
c
@Vampire I appreciate your insight and help.
👌 1