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