Update PMD to 7.0.0

[zod]

PMD has finally released version 7.0.0 which offers better analysis and new rules.

It required a gradle update but Android Studio kept nagging me to upgrade gradle & AGP (Android Gradle Plugin) anyway...

[devemux86]

Note that many developers use IDEA instead of Android Studio.

Latest IDEA does not still support the Android Gradle plugin 8.3.X.
IDEA works fine with Android Gradle plugin 8.2.X (currently 8.2.2).

[zod]

I guess we don't use any features from 8.3.x, so switching back to 8.2.2 shoudn't cause any issues.

[afischerdev]

One remark only, the BRouter server still uses JDK 11.
Therefore, the output lib cannot be used directly.

[zod]

If we want to compile for older Java releases we should target a specific java version. It seems reasonable to target Java 11 but use JDK 17 to build.

[devemux86]

For maximum compatibility with old Android versions (that do not contain newer Java API),
in the open source libraries I maintain, we may use Java 17 to compile,
but have sourceCompatibility and targetCompatibility with JavaVersion.VERSION_1_8.

For example:
https://github.com/mapsforge/mapsforge/blob/master/build.gradle#L32-L33
https://github.com/mapsforge/vtm/blob/master/build.gradle#L34-L35

[afischerdev]

Fine, I could try sourceCompatibility and targetCompatibility next week with the test server.

[zod]

I've implemented targeting a specific Java version using conventions plugins because the gradle documentation suggested to avoid cross configuration using allprojects/subprojects

Currently it targets Java 11 because we already use some functionality from Java 9. It's mostly in test code but the new Hgt processing also uses it. This code won't be run on Android so it should not cause any issues. Going forward we should pick a Java version we really want to target and adopt the build configuration to treat using newer code as error.

I'd also like to add a dependency from distZip target to :brouter-routing-app:packageRelease to ensure it's built before distZip, but unfortunately adding this dependency won't work if the android SDK isn't present because the target isn't defined. If you have any suggestions I would be very happy :)

[afischerdev]

I made some tests:

• export repository as zip and run Android Studio / gradle command line
• export repo as git export and run Android Studio ( gradle command line
• use the generated lib as test-server lib
  All tests passed ok.
  So I would like to merge after version 1.7.4

[afischerdev]

I'd also like to add a dependency from distZip ...

As you see in the current release, the distribution file is not produced.
I used

distZip {
    dependsOn fatJar
    dependsOn (':brouter-routing-app:assemble')
    archiveFileName = 'brouter-' + project.version + '.zip'
}

[zod]

Your suggestion would break builds without android SDK because the :brouter-routing-app:assemble wouldn't exist. The docker build doesn't add the android SDK and therefore would fail.

[afischerdev]

Yes, you are right. This is only a temporary solution to get an apk inside the zip when Android tasks are present.
My attempts with doLast or Exception were unsuccessful. So no idea at the moment.

[afischerdev]

I've masked the dependencies now, that should do the job.

if (file('../local.properties').exists()) dependsOn (':brouter-routing-app:assemble')

[zod]

I'm not to happy with this check because not we check for local.properties in multiple locations instead of detecting if the target was added, but let's just use it for now and perhaps I'll come up with a different check in a future PR.

[afischerdev]

@zod
I understand that, but we already use this way in settings.gradle.
My tests with hasProperty('sdk.dir') or similar were not successful. My be there are other ideas?