You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently otel-extension module contains instruments for both Akka and ZIO, this means that users of only Akka or ZIO have unnecessary classes in their classpath, the .jar is larger for no reason. I would propose a more fine grained splitting of agent modules, ideally per instrumented library. The current single module approach will likely become more and more of an issue with increasing number of libraries that we instrument.
We could also instead of splitting into modules split into multiple repositories - core, akka and ZIO. This might ease versioning and maintenance, especially if we want to support multiple conflicting versions of a specific library. This is something that I have seen being done in https://endpoints4s.github.io/, where interpreters for less popular HTTP libraries were split into their own repositories so that we could focus on the more popular ones and keep the core lighter.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently
otel-extension
module contains instruments for both Akka and ZIO, this means that users of only Akka or ZIO have unnecessary classes in their classpath, the.jar
is larger for no reason. I would propose a more fine grained splitting of agent modules, ideally per instrumented library. The current single module approach will likely become more and more of an issue with increasing number of libraries that we instrument.We could also instead of splitting into modules split into multiple repositories - core, akka and ZIO. This might ease versioning and maintenance, especially if we want to support multiple conflicting versions of a specific library. This is something that I have seen being done in https://endpoints4s.github.io/, where interpreters for less popular HTTP libraries were split into their own repositories so that we could focus on the more popular ones and keep the core lighter.
Beta Was this translation helpful? Give feedback.
All reactions