Include dependencies in events

[smeubank]

investigate if possible and "costs" associated

Java Dependency Insights

Approaches

1. LibraryDetector that calls Class.forName at runtime
   • might not be able to get version information
   • only detects libraries we actively try to detect
   • will not work if proguard or similar is active
   • 137 625
     μs ns
     • for a single dependency (Spring) detecting + reading version number
2. LibraryDetector that reads Manifest files at runtime
   • might be slow
     • 12 339 709
       ms μs ns
     • on our Spring Boot 3 Sample
   • could take up a lot of payload limit if there’s many libs
   • not possible on Android? → backend only?
   • there doesn’t seem to be a standard around manifest property names (can scan a bunch of fields)
3. Gradle Plugin
   • already works using sentry-android-gradle-plugin which could also be used by backend developers
   • why would people use it for backend if it doesn’t offer any other benefit; would need to do more to be attractive
   • could make SAGP more generic and also apply to non Android Plugins (for features applicable)
4. Maven Plugin
   • why would people use it if it doesn’t offer any other benefit; would need to do more to be attractive
5. Linked repo in Sentry that can read dependencies?
   • not sure if possible
   • how to resolve transitive dependencies?
   • needs extra config for multi module repos where only one is deployed

Which one?

• Android: Option 3 (already working)
• Java (Backend): Option 2 and at some point also Option 3 by making it more attractive for backend developers

[romtsn]

@smeubank @adinauer option 3 is already working both for Android and Java btw https://docs.sentry.io/platforms/java/gradle/

[adinauer]

Thanks @romtsn, updated the issue to make it more clear, this already works when using SAGP. So we could also make our gradle plugin more attractive for backend developers.

[adinauer]

While it's already possible to use SAGP for backend. It's not common. As a quick way for us to get info about backend applications, option 2 could serve until we provide enough features for people to actually use the gradle plugin. Also we could get info from applications built using Maven.

On startup, in the background, we could look for all META-INF/MANIFEST.MF files and capture the names of the JAR files from the URLs returned by getResources(). Needs some more testing, whether this also works for WAR files deployed to e.g. Tomcat. Looking at the URLs is 10x faster (1-2ms) than actually parsing the manifest files (10-20ms) that don't have a common set of properties. While it's possible to get the version using "Implementation-Version" in many cases, the name of the library varies in terms of what property and also whether it's similar to the name of the dependency. JAR name also isn't exactly the same as what we'd get from the gradle plugin but it can still be valuable. For Android this background collection will be turned off as it wouldn't work anyways.

[romtsn]

@adinauer I've closed this since we have a dedicated plugin for backend now + you've made something to fetch them at runtime. Feel free to reopen if we still should do something else here