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 <[email protected]> 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 >> >
