mguymon / lock_jar

LockJar manages Java Jars for Ruby
http://mguymon.github.io/lock_jar/
Apache License 2.0
46 stars 9 forks source link

Transitive dependencies not resolved correctly? #38

Open bigsur0 opened 7 years ago

bigsur0 commented 7 years ago

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.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.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 commented 7 years ago

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

bigsur0 commented 7 years ago

@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 commented 7 years ago

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 commented 6 years ago

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