> > > > >> I’d really like a dependency system that makes each dep’s transitive >> dependencies only visible to itself, so there would never be any reason to >> resolve dependencies. >> > > You need classloader support for this and indeed this is what OSGi and > some early versions of the Java module system do. Working in that kind of > environment is very constraining. A lot of discipline is required with > respect to your interfaces between loaders and in general I think it's way > too much of a burden to use as the normal operating mode (which is one > reason you don't see it in the Java module system of java 9). It is a good > option for systems where you want users to plug in functionality and the > scope of those interface points is small and highly controlled. >
I have run into incompatible transitive dependencies a lot throughout my career. In many cases its not that big a deal but for cross cutting libraries such as data serialization etc it can be hard to get all of your dependencies to agree on a common version. Here is a concrete example I ran into just today: https://github.com/thheller/shadow-cljs/issues/177 and the library that caused the issue is non-other than core.async! I second the idea of private dependencies. I have had the displeasure of working with OSGI and I think the reason its complex is not so much because the required metadata is hard to figure out... the complexity mostly comes from the starting, stopping and restarting bundles within a running jvm in non deterministic order. Another issue is that the dependency metadata needs to be included within each jar and since most library authors don't see the value of OSGI they don't provide it to users to rebundle the jar with the required metatata. This problem is similar to that of cljsjs, most javascript devs do not see any value in any significant value is using closure compile over uglyify (myself included as externs are a pain to maintain, minified stacktraces are useless, and errors are subtle and hard to debug), but the clojurescript community does see value in this so they do their best to maintain this metadata even if it means rebuilding projects. So what is the alternatives: 1. Don't upgrade (common solution when there are breaking changes) 2. Try to get upstream maintainer to upgrade (most common when changes are not breaking and/or maintainer willing to do the work) 3. Fork the upstream project and maintain your own release using the desired version 4. Split your app into multiple pieces so they can run in different JVM instances (enter the microservice) I think the idea that everything can use the same version is oversimplified and creating microservice shouldn't be necessary just because you can't get all your dependencies to agree. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
