Transitive dependencies not resolved correctly?
bigsur0 opened this issue · comments
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?
@mguymon just wanted to check-in w/ you to see if you've had a chance to read through this.
@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?
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.
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.