Skip to content
This repository has been archived by the owner on Nov 30, 2017. It is now read-only.

Gradle plugin does not see jars in the libs/ folder #30

Open
imbeyondboredom opened this issue Jul 13, 2017 · 7 comments
Open

Gradle plugin does not see jars in the libs/ folder #30

imbeyondboredom opened this issue Jul 13, 2017 · 7 comments

Comments

@imbeyondboredom
Copy link

When scanning a project and it has a libs folder then those jars are ignored (Or seem to be ignored) by the gradle plugin.

Ideally these would be scanned (Although understandably accuracy would be low) but if these cannot be scanned then IMO it would be ideal if the plugin failed by default and one had to set an override variable or something.

@stavvy-akamen
Copy link

@imbeyondboredom The gradle plugin never scans anything, it is a purely package manager implementation. The CLI does scanning of the /lib/ directory. THis is why we built detect which does both PM and CLI discovery approaches. We are deprecating this plugin eventually and encourage you to use detect which is a one stop shop.

@imbeyondboredom
Copy link
Author

So I understand your eventual goals but this means that until hub-detect is done this plugin is missing dependencies. Is hub-detect close enough to done that we should rely on it completely?

If not then I'd like to again suggest a flag that fails the scan if it detects libs folders/jar files and then an override variable or something where you could provide jar names that bypass the failure. That way we can set this up for our internal projects and be sure that we're not missing components.

@jamesrichard91
Copy link

I'm not sure I understand your request? You want to fail what scan? There is no scan in the Gradle plugin. You want the Gradle plugin to fail if it finds jar files in the Build output directory that aren't included in a white list of file names?
Would you be willing to set up a policy, in the Hub, to reject components you dont want? and then set a flag in the Gradle plugin to fail on policy violations?

@imbeyondboredom
Copy link
Author

I want the plugin to fail if it detects dependencies that it can't get an identifier to send up to the hub. As it is now, it looks like all dependencies are being reported when in fact some could be missing if developers include them as jar files.

I do understand that this might not be desired default behavior though so I'd be happy if there were a flag that turns this functionality on

@stavvy-akamen stavvy-akamen reopened this Jul 20, 2017
@stavvy-akamen
Copy link

stavvy-akamen commented Jul 20, 2017

Hmmm....this is an interesting request.

Are you asking for a delta between the build.gradle declared/transitive and actual binaries in the /lib directory?

If so, then certainly hub-detect performing a signature scan will give you that information - even if it won't fail the build.

@imbeyondboredom
Copy link
Author

Yep exactly. I'm currently setting that on a few projects but I'm finding that developers don't realize that the libs directory isn't being picked up. So I want a flag that will fail this scan so that the developers realize that jars they are adding are not picked up with the gradle plugin and that they need to set up an additional scan OR explicitly tell the plugin not to fail on certain proprietary jars.

I'll have to try out hub-detect again on Android builds. We had tested it on iOS Projects but we were waiting on it to stabilize before relying on it exclusively.

@stavvy-akamen
Copy link

Interesting feature request, we definitely have not considered making that explicit. Here is what I can offer for now.

We definitely want to deprecate this plugin.

Hub-Detect will, in the case of gradle/maven/sbt/nuget perform a signature scan on top of the package manager analysis. You can then, in the BOM, easily determine what is missing by simply sorting match counts. For anything that matched only once, you know immediately whether you have a discrepancy. Then the match type will indicate what kind of match it is: Dependency = Package Manager, Exact= Signature.

Android projects have always been tricky, but I urge you to try it with out latest SNAPSHOT.

We are planning a 1.0.0 release in a week, so we are quite close to complete.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants