runtime scope dep as libraryjar?

[newobj]

Hi,

Not new to proguard, but new to maven. I have a project that I'm trying to run proguard on, and it has some dependencies which are scoped as runtime (I believe this is because they are deployed separately? it's hdfs infra.)

The runtime scope dependencies are not being passed to proguard as libraryjars (nor in any other capacity). Proguard complains vociferously (as it should) and fails.

I'm surprised the maven plugin does not pass the runtime scope deps onto proguard? Is this a conscious design decision or an oversight? Is there any way to get it to?

Thanks!

[lasselindqvist]

This should be straightforward to fix by changing https://github.com/wvengen/proguard-maven-plugin/blob/master/src/main/java/com/github/wvengen/maven/proguard/ProGuardMojo.java#L515 We could just add a call to https://maven.apache.org/ref/3.2.3/apidocs/org/apache/maven/project/MavenProject.html#getRuntimeArtifacts() but both that and the existing getCompileArtifacts have been deprecated a long time. Instead we could use https://maven.apache.org/ref/3.2.3/apidocs/org/apache/maven/project/MavenProject.html#getDependencyArtifacts() and add only those with a proper scope. Test scope can be excluded at least, but seems like system and provided scope should be included.

[lasselindqvist]

@newobj do you have a simple test project for this you could share?

[glebfrank]

Here's a test project. Here, the artifact com.github.jnr:jffi:jar:native is a runtime dependency of jnr-jffi, which is reachable through a chain of compile dependencies. Consequently, the contents of the artifact (a bunch of shared libraries under a folder called jni) don't make it into the assembly. If I uncomment the commented-out dependency in the POM, the jar contents do make it in, because now it is a compile dependency.

proguard-test.zip