On Sat, Sep 3, 2016 at 4: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. > 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" < > [email protected]> 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 > > >
