Hi all,
I have a general question about transitive dependencies. Here is an example use case: OFBiz depends on 2 external jars: jar1 and jar2 jar1 depends on log4j-version1 jar2 depends on log4j-version2 How should we manage the two versions of the same product (log4j in this exemple), containing most likely the same classes, since they are both in the classpath? Thanks, Jacopo |
Hi Jacopo,
I have to dig some more to confirm but I believe Gradle automatically resolves transitive dependencies and the newer version usually wins. You can confirm that by typing ./gradlew dependencies, and whenever you see an asterisk next to a package you know that this package is overridden elsewhere by another transitive dependency. As I was discussing this with Jacques earlier I think this is a very complex subject because of dependency hell. We really need to cut down on the number of libraries used by OFBiz because each Library pulls too many transitive dependencies. Another thing to note is that the special purpose components especially birt pull a lot of libraries that override some of the libraries in core system. Taher Alkhateeb On Sep 3, 2016 4:57 PM, "Jacopo Cappellato" < [hidden email]> wrote: > Hi all, > > I have a general question about transitive dependencies. > Here is an example use case: > OFBiz depends on 2 external jars: jar1 and jar2 > jar1 depends on log4j-version1 > jar2 depends on log4j-version2 > > How should we manage the two versions of the same product (log4j in this > exemple), containing most likely the same classes, since they are both in > the classpath? > > Thanks, > > Jacopo > |
Hi Jacopo, also adding that you can override any transitive dependencies by
explicitly declaring them (compile, runtime, etc ..) in build.gradle. I'm not sure if this is what you're after but I thought I'd mention it here just in case. On Sat, Sep 3, 2016 at 5:04 PM, Taher Alkhateeb <[hidden email]> wrote: > Hi Jacopo, > > I have to dig some more to confirm but I believe Gradle automatically > resolves transitive dependencies and the newer version usually wins. You > can confirm that by typing ./gradlew dependencies, and whenever you see an > asterisk next to a package you know that this package is overridden > elsewhere by another transitive dependency. > > As I was discussing this with Jacques earlier I think this is a very > complex subject because of dependency hell. We really need to cut down on > the number of libraries used by OFBiz because each Library pulls too many > transitive dependencies. > > Another thing to note is that the special purpose components especially > birt pull a lot of libraries that override some of the libraries in core > system. > > Taher Alkhateeb > > On Sep 3, 2016 4:57 PM, "Jacopo Cappellato" <jacopo.cappellato@ > hotwaxsystems.com> wrote: > >> Hi all, >> >> I have a general question about transitive dependencies. >> Here is an example use case: >> OFBiz depends on 2 external jars: jar1 and jar2 >> jar1 depends on log4j-version1 >> jar2 depends on log4j-version2 >> >> How should we manage the two versions of the same product (log4j in this >> exemple), containing most likely the same classes, since they are both in >> the classpath? >> >> Thanks, >> >> Jacopo >> > |
In reply to this post by taher
On Sat, Sep 3, 2016 at 4:04 PM, Taher Alkhateeb <[hidden email]>
wrote: > Hi Jacopo, > > I have to dig some more to confirm but I believe Gradle automatically > resolves transitive dependencies and the newer version usually wins. You > can confirm that by typing ./gradlew dependencies, and whenever you see an > asterisk next to a package you know that this package is overridden > elsewhere by another transitive dependency. > This is what I was expecting. However it doesn't resolve the problem I have described (two jars that require two different version of the same classes) simply because (I fear) there is not an easy solution for this problem: unless we start messing with the classpaths... but I hope we don't have to go in this direction. Just to clarify: this is *not* a problem introduced by Gradle (in fact the opposite is true because Gradle is alleviating it), it is a problem OFBiz has since too long. > > As I was discussing this with Jacques earlier I think this is a very > complex subject because of dependency hell. We really need to cut down on > the number of libraries used by OFBiz because each Library pulls too many > transitive dependencies. > +1 > > Another thing to note is that the special purpose components especially > birt pull a lot of libraries that override some of the libraries in core > system. > This is a concern I have too and I have repeated myself too many time: it is a wrong approach to embed huge external application in our own because it opens the door to many problems (classpath issues, vulnerabilities, code redundancy, high cost of maintainability etc...). By the way, thank you Taher about your valuable feedback; I am also interested to hear what others think about this topic. Regards, Jacopo > > Taher Alkhateeb > > On Sep 3, 2016 4:57 PM, "Jacopo Cappellato" < > [hidden email]> wrote: > > > Hi all, > > > > I have a general question about transitive dependencies. > > Here is an example use case: > > OFBiz depends on 2 external jars: jar1 and jar2 > > jar1 depends on log4j-version1 > > jar2 depends on log4j-version2 > > > > How should we manage the two versions of the same product (log4j in this > > exemple), containing most likely the same classes, since they are both in > > the classpath? > > > > Thanks, > > > > Jacopo > > > |
I also agree on the transitive dependencies nightmare. By feedback I
would be tried to limit the dependencies and when a conflict on different version are raise, I'm in favor to lost functionality instead of lose on maintainability and stability Finally, I haven't a groovy solution to resolve this problem ;) Nicolas Le 03/09/2016 à 16:38, Jacopo Cappellato a écrit : > This is a concern I have too and I have repeated myself too many time: it > is a wrong approach to embed huge external application in our own because > it opens the door to many problems (classpath issues, vulnerabilities, code > redundancy, high cost of maintainability etc...). > > By the way, thank you Taher about your valuable feedback; I am also > interested to hear what others think about this topic. |
Free forum by Nabble | Edit this page |