Apache Maven JDeps Plugin

[Mandy Chung]

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.chung at 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