Trying to use a release-independent repository for CDT (#1522)

This is some rather ugly workaround in our ivy repository layout, but it should work for all future releases.

README.md

@@ -33,21 +33,9 @@ In order to get familiar with the graph itself, you can use the subproject [cpg-
 
 ### As Library
 
-The most recent version is being published to Maven central and can be used as a simple dependency, either using Maven or Gradle. Since Eclipse CDT is not published on maven central, it is necessary to add a repository with a custom layout to find the released CDT files. For example, using Gradle's Kotlin syntax:
+The most recent version is being published to Maven central and can be used as a simple dependency, either using Maven or Gradle.
 
 ```kotlin
-repositories {
-    ivy {
-        setUrl("https://download.eclipse.org/tools/cdt/releases/11.3/cdt-11.3.1/plugins")
-        metadataSources {
-            artifact()
-        }
-        patternLayout {
-            artifact("/[organisation].[module]_[revision].[ext]")
-        }
-    }
-}
-
 dependencies {
     val cpgVersion = "8.0.0"
 
@@ -63,6 +51,23 @@ dependencies {
 }
 ```
 
+There are some extra steps necessary for the `cpg-language-cxx` module. Since Eclipse CDT is not published on maven central, it is necessary to add a repository with a custom layout to find the released CDT files. For example, using Gradle's Kotlin syntax:
+```kotlin
+repositories {
+    // This is only needed for the C++ language frontend
+    ivy {
+        setUrl("https://download.eclipse.org/tools/cdt/releases/")
+        metadataSources {
+            artifact()
+        }
+
+        patternLayout {
+            artifact("[organisation].[module]_[revision].[ext]")
+        }
+    }
+}
+```
+
 Beware, that the `cpg` module includes all optional features and might potentially be HUGE (especially because of the LLVM support). If you do not need LLVM, we suggest just using the `cpg-core` module with the needed extra modules like `cpg-language-go`. In the future we are working on extracting more optional modules into separate modules.
 
 #### Development Builds

buildSrc/src/main/kotlin/cpg.common-conventions.gradle.kts

@@ -27,12 +27,13 @@ repositories {
     mavenCentral()
 
     ivy {
-        setUrl("https://download.eclipse.org/tools/cdt/releases/11.3/cdt-11.3.1/plugins")
+        setUrl("https://download.eclipse.org/tools/cdt/releases/")
         metadataSources {
             artifact()
         }
+
         patternLayout {
-            artifact("/[organisation].[module]_[revision].[ext]")
+            artifact("[organisation].[module]_[revision].[ext]")
         }
     }
 }

gradle/libs.versions.toml

@@ -31,7 +31,9 @@ jacksonyml = { module = "com.fasterxml.jackson.dataformat:jackson-dataformat-yam
 eclipse-runtime = { module = "org.eclipse.platform:org.eclipse.core.runtime", version = "3.31.0"}
 osgi-service = { module = "org.osgi:org.osgi.service.prefs", version = "1.1.2"}
 icu4j = { module = "com.ibm.icu:icu4j", version = "75.1"}
-eclipse-cdt-core = { module = "org.eclipse.cdt:core", version = "8.3.1.202309150117"}
+# Note: This "module" intentionally looks very weird, because the CDT version is actually part of the path of the CDT external
+# repository. In order to avoid updating the repository URL everytime a new CDT version comes out, we need to do this weird hack.
+eclipse-cdt-core = { module = "11.5/cdt-11.5.0/plugins/org.eclipse.cdt:core", version = "8.4.0.202402110645"}
 picocli = { module = "info.picocli:picocli", version = "4.7.0"}
 picocli-codegen = { module = "info.picocli:picocli-codegen", version = "4.7.0"}
 jep = { module = "black.ninia:jep", version = "4.2.0" }  # build.yml uses grep to extract the jep verison number for CI/CD purposes