Thanks I'll check it out.
Mandy

On 2/19/2015 12:10 PM, Robert Scholte wrote:
Hi Mandy,

based on your proposal I've added 2 parameters: dependenciesToAnalyzeIncludes and dependenciesToAnalyzeExcludes This way it's not an All-Or-Nothing option, but instead you have full control over the dependencies to include. You can select the dependencies by using the pattern groupId:artifactId in combination with '*'.

Some configuration examples:
This will select all dependencies for the specified scope (compile or test, depending on the goal)
  <dependenciesToAnalyzeIncludes>
     <include>*:*</include>
  </dependenciesToAnalyzeIncludes>

Here are some other patterns, which are allowed
  <dependenciesToAnalyzeIncludes>
     <include>org.foo.*:*</include>
     <include>com.foo.bar:*</include>
     <include>dot.foo.bar:utilities</include>
   </dependenciesToAnalyzeIncludes>

With dependenciesToAnalyzeExcludes you can exclude a subset of dependenciesToAnalyzeIncludes.

  <dependenciesToAnalyzeExcludes>
     <exclude>org.foo.test:*</exclude>
  </dependenciesToAnalyzeExcludes>

This should match your requirements.

Regards,
Robert Scholte


Op Wed, 18 Feb 2015 05:46:37 +0100 schreef Mandy Chung
<mandy.ch...@oracle.com>:

Hi Robert,

Indeed this looks very useful.

On 2/16/2015 10:45 AM, Alan Bateman wrote:
On 16/02/2015 18:28, Robert Scholte wrote:
Hi Alan,

if you are referring to the -R / -recursive option of the jdeps tool, then yes you can. See http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jdeps-plugin/jdkinternals-mojo.html#recursive I think jdeps is first of all interesting for the classes of the current Java project, so I've set the default of this parameter to 'false'. However, if the majority thinks it is better to activate this by default, we will consider to change this value.
I could imagine wanting to run it twice: once for the current project where I want the build to fail if it makes direct use of JDK-internal APIs, and a second time to run with -R and emit warnings if any of the transitive dependences (that I don't control) are using JDK internal APIs.

Another alternative to running jdeps -R, the plugin can run jdeps on all of the transitive dependences of the current project (all JAR files can be put in one jdeps command) that will find out if any of its dependences (analyze all classes) is using JDK internal API.

jdeps -R will only analyze classes that are referenced from the root set (i.e. the arguments passed to jdeps that I assume be the current project) and doesn't analyze any class in the dependences that is not referenced transitively.

The default is to run jdeps on the current project sounds reasonable to me.

Mandy

Reply via email to