build.gradle: set miniDnsVersion version to the latest 1.0.x

[stokito]

The minidns dependency use the range to pick the latest version in range of 1.0.x.
This caused some problems in the Spark that I fixed igniterealtime/Spark#866
Anyway, the minidns now released an alpha version of the 1.1 so it shouldn't be any new versions in the 1.0.x series. So here I changed the range to the latest 1.0.5.

[Flowdalic]

Thanks for your contribution.

However, I wonder if the real problem isn't Maven bailing out. I've looked at igniterealtime/Spark#866 (comment) where you write

The Maven goes into the maven-snapshots-repo and tries to resolve the 1.0.3-SNAPSHOT which is not exists there but it was referenced from some other dependency.

So this issue seems to be that something is referencing 1.0.3-SNAPSHOT.

Wouldn't identifying the causing dependency and fixing it be the real fix?

Smack (and all my other Java projects) use ranged dependencies, if the dependency I guranteed to not break API withing the ranged version specification. This is true for MiniDNS, and, fwiw, JXMPP. This always to consume patch-level releases which often carry important fixes.

If you want to pin a dependency to a certain version, then this is usually possible with the help of the build system. I know that Gradle supports this and would be surprised if Maven did not.

With the information I have at the moment, I am unfortunately inclined to reject this change.

But thanks again for submitting it!

[stokito]

I tried to see maven dependency tree but it didn't show who referenced which version.
In the Spark removing of snaphots repo solved the issue.
Still, for a library it would be more stable to specify a version preciselly. In the same time the 1.0.x versions are finished for the minidns.
So the pr should just make the build more stable. This is kind of cleanup but also should increase build speed a little bit

[stokito]

I tried to gradle build again and get a similar problem:

Execution failed for task ':smack-core:compileTestFixturesJava'.
> Could not resolve all files for configuration ':smack-core:testFixturesCompileClasspath'.
   > Could not find jxmpp-jid-1.0.3-tests.jar (org.jxmpp:jxmpp-jid:1.0.3).
     Searched in the following locations:
         file:~/.m2/repository/org/jxmpp/jxmpp-jid/1.0.3/jxmpp-jid-1.0.3-tests.jar

The jxmppVersion = '[1.0.0, 1.0.999]' is also use a range. In the maven central the latest version is 1.0.3 https://central.sonatype.com/artifact/org.jxmpp/jxmpp-jid/versions that has the artifact jxmpp-jid-1.0.3-tests.jar https://repo1.maven.org/maven2/org/jxmpp/jxmpp-jid/1.0.3/.
There is also a newer version 1.1.0-alpha2.

I replaced range and with both version the build was successful. But I tried a second time and build failed. I removed the ~/.m2/repository/org/jxmpp/jxmpp-jid/ and the build was successful again but the ~/.m2/repository/org/jxmpp/jxmpp-jid/ wasn't created again. This is insane, maybe some gradle cache issue. I removed the ~/.gradle/caches and the build was successful but again the artifact didn't appeared in the local maven repo.

The gradle dependencies didn't shown the dependency at all. Not sure why.
I'm not sure if the issue is related to the version range but anyway it's confusing. Maybe by replacing the range with 1.0.3 this issue will newer appear again.

Other problems:

In the DEVELOPING.md said "Smack requires a case-sensitive file system in order to build".
Is this still required? Maybe we can get rid off the case sensitive file names?

I had to comment out the android modules because I'm not interested in it. In order to work on the library I don't want to install the AndroidSDK. Maybe it's possible to add some option for this?

[guusdk]

For what it's worth, I'm frequently hit by this issue (unable to download version 1.0.3-SNAPSHOT of minidns) outside of Spark. Just refreshing the Intellij workspace of a project that uses Smack can trigger it. It's a major pain.

[guusdk]

I suspect that contributing factors include:

• the Sonatype repository metadata referencing the version 1.0.3-SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots/org/minidns/minidns-core/maven-metadata.xml while it does not actually provide any content for that version (note that it's missing in the directory listing of https://oss.sonatype.org/content/repositories/snapshots/org/minidns/minidns-core/
• the IDE trying to loading many/all (?) poms for versions that match the range as defined in Smack (see screenshot)

[guusdk]

A complicating factor is that the repository that is misbehaving (Sonatype's snapshots repo) is the same one as where Smack publishes its snapshots. If we want to consume Smack's snapshots, you will want to enable the repository (which is likely why this was in Spark's POM).

[stokito]

Oh, right, the Intellij also tries to resolve deps. This may explain why the build is blinking. I'm not sure how to better to fix this, just hope my solution will be enough

[guusdk]

I have been talking to Sonatype's support engineers. Per my request, they have modified the repository to remove the faulty reference to the non-existing 1.0.3-SNAPSHOT artifact. Hopefully, this once and for all resolves this problem.

I'm not sure if this faulty metadata gets cached in your local .m2 repository, or, if it does, if the changes from upstream automatically bubble down to your local copy. It may be needed to manually remove org/minidns/ from your local repository for the fix to become available to you.

[stokito]

Great, thank you Guus! I hope they'll do something to avoid such problems in the future. And still, I believe it would be more stable to not use ranges and always upgrade deps manually with separate minor version increase. The PR can be closed or merged, anyway the specific issue was solved.

[guusdk]

I'm not a fan of ranged versions either, but I'll leave that up to @Flowdalic

[Flowdalic]

I'm not a fan of ranged versions either, but I'll leave that up to @Flowdalic

Another advantage of ranged version is that dependent releases do not require a Smack release. For example, Smack uses two libraries I also maintain, jxmpp and MiniDNS. Not using ranged dependencies would mean that for every patch-level release of those libraries I would need to create a Smack release for Smack to benefit from the patch-level release.

So, yeah, I am really sold on ranged versions.

This PR is also just an indirect solution for the problem the PR tries to solve. It seems now that the right solution was deployed, thanks to Guus.