Question about transitive dependencies on different version of the same library

[Jacopo Cappellato-5]

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

[taher]

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
>

[taher]

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
>>
>

[Jacopo Cappellato-5]

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
> >
>

[Nicolas Malin-2]

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.