Transitive dependencies not resolved correctly?

[bigsur0]

I find that with the Jarfile containing only

Case 1

group :ingest, :cli do jar 'org.apache.flume:flume-ng-core:1.5.0-cdh5.4.5' end

The lock_file generated is <jarfile_case1.lock> jarfile_case1.txt

Case 2

While when the groups are

group :cli do jar 'com.google.guava:guava:jar:15.0' end

group :ingest, :cli do jar 'org.apache.flume:flume-ng-core:1.5.0-cdh5.4.5' end

lock_file generated is <jarfile_case2.lock> jarfile_case2.txt

I find that the dependency "com.google.guava:guava:jar:15.0” is not listed as a dependency for "ingest" group in case two. Is this expected behavior or a bug?

[bigsur0]

@mguymon just wanted to check-in w/ you to see if you've had a chance to read through this.

[bigsur0]

@mguymon just pinging you again on this or should I be filing an issue against a new project now that the buildr integration has moved?

[bigsur0]

Issue here seems to be that a single resolver object is being used for multiple groups within the same lockjar block. If those dependencies/groups are pushed down into lockjar blocks in Buildr sub-projects each gets its own resolver object things work as expected. I guess the key question is whether groups within a single lockjar block merit individual resolver objects.

[mguymon]

@r6p

Wow, this flew under the radar for ~ year. Probably too little too late, but I will schedule some time this week to look at it.