You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2015/02/14 16:32:23 UTC
Apache Maven JDeps Plugin
Hi,
during FOSDEM 2015 a few members of the Apache Maven team visited a talk
of Oracle, presented by Rory O'Donnell and Dalibor Topic.
Their talk ended with encouraging everybody to use the JDeps tool to
analyze your dependencies in preparation of JDK9s jigsaw.
On behalf of the Maven team I've picked up the task to develop a plugin
which can do the analysis during the build of a Java project. Call it a
thin Maven wrapper around the JDeps tool.
The sources can be found here:
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
The documentation can be found here:
http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jdeps-plugin/
http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jdeps-plugin/usage.html
There's a SNAPSHOT version availabe at
https://repository.apache.org/content/repositories/snapshots/
The plugin is still in development, but now would be an appropriate moment
to share your thoughts on what this plugin should do. For instance: break
the build if the project depends on JDK internal APIs (already
implemented).
So please, share your ideas.
thanks,
Robert Scholte
ps. Quite a lot of users relate the plugin version to the Maven version.
For that reason the maven-jdeps-plugin version starts with 3.0, indicating
you need to use at least Maven-3.
ps2. Documentation already refers to Apache Maven 3.2.6, even though it is
not released yet. Chances are that Maven 3.2.6 will be released before
Maven JDeps Plugin 3.0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
Op Fri, 20 Feb 2015 04:48:54 +0100 schreef Hervé BOUTEMY
<he...@free.fr>:
> ok, I just updated the index page to try to improve explanations about
> this
> unusual/new toolchains use case (ie not trying to be consistent across
> plugins)
>
> notice that if you use ToolchainManagerPrivate like
> maven-toolchains-plugin
> does, you even don't require Maven 3.2.6 to do that
>
You need to do a bit more: up until Maven 3.2.5 it was the
maven-toolchain-plugin which triggered the reading of the toolchains.xml.
So you have to add that part of the code as well to this plugin. And you
have to copy the business logic to select the proper toolchain too.
I'd prefer to keep it as it is, so this kind of logic doesn't get spread
over all kinds of plugins.
best,
Robert
> Regards,
>
> Hervé
>
> Le dimanche 15 février 2015 12:16:14 Robert Scholte a écrit :
>> Op Sun, 15 Feb 2015 07:09:37 +0100 schreef Hervé BOUTEMY
>>
>> <he...@free.fr>:
>> > another topic:
>> > "When using Apache Maven 3.2.6 you don't need to include the <<<maven-
>> > toolchain-plugin>>>; the <<<maven-jdeps-plugin>>>
>> >
>> > can pick up..."
>> >
>> > looking at the code, IIUC: the plugin doesn't use the jdk toolchain
>> > configured
>> > (or not) for the whole build with maven-toolchain-plugin but will
>> select
>> > a jdk
>> > toolchain based on its own preference
>> >
>> > isn't it?
>>
>> yes. Up until Maven 3.2.5 the maven-toolchain-plugin was responsible for
>> reading the toolchains.xml, so in a multimodule project the same file
>> was
>> read over and over again.
>> This has been rewritten. Now it is read only once on startup. This also
>> made it possible to read it without the maven-toolchain-plugin, which
>> makes sense in this case. You probably want to verify if your current
>> (older JDK) code is ready according to jdeps (newer JDK, i.e. 8 and
>> above).
>>
>> This is the magic line:
>> List<Toolchain> tcs =
>> (List<Toolchain>) getToolchainsMethod.invoke( toolchainManager,
>> session,
>> "jdk",
>> Collections.singletonMap( "version", "[1.8,)" ) );
>> The final arguments defines the restriction.
>> We could make a mojo parameter for this, so users can lock it to a
>> specific tool.
>>
>> thanks,
>> Robert
>>
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
>> >> Hi,
>> >>
>> >> during FOSDEM 2015 a few members of the Apache Maven team visited a
>> talk
>> >> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
>> >> Their talk ended with encouraging everybody to use the JDeps tool to
>> >> analyze your dependencies in preparation of JDK9s jigsaw.
>> >> On behalf of the Maven team I've picked up the task to develop a
>> plugin
>> >> which can do the analysis during the build of a Java project. Call
>> it a
>> >> thin Maven wrapper around the JDeps tool.
>> >>
>> >> The sources can be found here:
>> >>
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>> >>
>> >> The documentation can be found here:
>> >>
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven->
>> >> jde ps-plugin/
>> >>
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven->
>> >> jd
>> >> eps-plugin/usage.html
>> >>
>> >> There's a SNAPSHOT version availabe at
>> >> https://repository.apache.org/content/repositories/snapshots/
>> >>
>> >> The plugin is still in development, but now would be an appropriate
>> >> moment
>> >> to share your thoughts on what this plugin should do. For instance:
>> >> break
>> >> the build if the project depends on JDK internal APIs (already
>> >> implemented).
>> >> So please, share your ideas.
>> >>
>> >> thanks,
>> >> Robert Scholte
>> >>
>> >> ps. Quite a lot of users relate the plugin version to the Maven
>> version.
>> >> For that reason the maven-jdeps-plugin version starts with 3.0,
>> >> indicating
>> >> you need to use at least Maven-3.
>> >> ps2. Documentation already refers to Apache Maven 3.2.6, even though
>> it
>> >> is
>> >> not released yet. Chances are that Maven 3.2.6 will be released
>> before
>> >> Maven JDeps Plugin 3.0
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
ok, I just updated the index page to try to improve explanations about this
unusual/new toolchains use case (ie not trying to be consistent across
plugins)
notice that if you use ToolchainManagerPrivate like maven-toolchains-plugin
does, you even don't require Maven 3.2.6 to do that
Regards,
Hervé
Le dimanche 15 février 2015 12:16:14 Robert Scholte a écrit :
> Op Sun, 15 Feb 2015 07:09:37 +0100 schreef Hervé BOUTEMY
>
> <he...@free.fr>:
> > another topic:
> > "When using Apache Maven 3.2.6 you don't need to include the <<<maven-
> > toolchain-plugin>>>; the <<<maven-jdeps-plugin>>>
> >
> > can pick up..."
> >
> > looking at the code, IIUC: the plugin doesn't use the jdk toolchain
> > configured
> > (or not) for the whole build with maven-toolchain-plugin but will select
> > a jdk
> > toolchain based on its own preference
> >
> > isn't it?
>
> yes. Up until Maven 3.2.5 the maven-toolchain-plugin was responsible for
> reading the toolchains.xml, so in a multimodule project the same file was
> read over and over again.
> This has been rewritten. Now it is read only once on startup. This also
> made it possible to read it without the maven-toolchain-plugin, which
> makes sense in this case. You probably want to verify if your current
> (older JDK) code is ready according to jdeps (newer JDK, i.e. 8 and above).
>
> This is the magic line:
> List<Toolchain> tcs =
> (List<Toolchain>) getToolchainsMethod.invoke( toolchainManager, session,
> "jdk",
> Collections.singletonMap( "version", "[1.8,)" ) );
> The final arguments defines the restriction.
> We could make a mojo parameter for this, so users can lock it to a
> specific tool.
>
> thanks,
> Robert
>
> > Regards,
> >
> > Hervé
> >
> > Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
> >> Hi,
> >>
> >> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
> >> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
> >> Their talk ended with encouraging everybody to use the JDeps tool to
> >> analyze your dependencies in preparation of JDK9s jigsaw.
> >> On behalf of the Maven team I've picked up the task to develop a plugin
> >> which can do the analysis during the build of a Java project. Call it a
> >> thin Maven wrapper around the JDeps tool.
> >>
> >> The sources can be found here:
> >> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
> >>
> >> The documentation can be found here:
> >> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-> >> jde ps-plugin/
> >> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-> >> jd
> >> eps-plugin/usage.html
> >>
> >> There's a SNAPSHOT version availabe at
> >> https://repository.apache.org/content/repositories/snapshots/
> >>
> >> The plugin is still in development, but now would be an appropriate
> >> moment
> >> to share your thoughts on what this plugin should do. For instance:
> >> break
> >> the build if the project depends on JDK internal APIs (already
> >> implemented).
> >> So please, share your ideas.
> >>
> >> thanks,
> >> Robert Scholte
> >>
> >> ps. Quite a lot of users relate the plugin version to the Maven version.
> >> For that reason the maven-jdeps-plugin version starts with 3.0,
> >> indicating
> >> you need to use at least Maven-3.
> >> ps2. Documentation already refers to Apache Maven 3.2.6, even though it
> >> is
> >> not released yet. Chances are that Maven 3.2.6 will be released before
> >> Maven JDeps Plugin 3.0
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
Op Sun, 15 Feb 2015 07:09:37 +0100 schreef Hervé BOUTEMY
<he...@free.fr>:
> another topic:
> "When using Apache Maven 3.2.6 you don't need to include the <<<maven-
> toolchain-plugin>>>; the <<<maven-jdeps-plugin>>>
> can pick up..."
>
> looking at the code, IIUC: the plugin doesn't use the jdk toolchain
> configured
> (or not) for the whole build with maven-toolchain-plugin but will select
> a jdk
> toolchain based on its own preference
>
> isn't it?
yes. Up until Maven 3.2.5 the maven-toolchain-plugin was responsible for
reading the toolchains.xml, so in a multimodule project the same file was
read over and over again.
This has been rewritten. Now it is read only once on startup. This also
made it possible to read it without the maven-toolchain-plugin, which
makes sense in this case. You probably want to verify if your current
(older JDK) code is ready according to jdeps (newer JDK, i.e. 8 and above).
This is the magic line:
List<Toolchain> tcs =
(List<Toolchain>) getToolchainsMethod.invoke( toolchainManager, session,
"jdk",
Collections.singletonMap( "version", "[1.8,)" ) );
The final arguments defines the restriction.
We could make a mojo parameter for this, so users can lock it to a
specific tool.
thanks,
Robert
>
> Regards,
>
> Hervé
>
> Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
>> Hi,
>>
>> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
>> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
>> Their talk ended with encouraging everybody to use the JDeps tool to
>> analyze your dependencies in preparation of JDK9s jigsaw.
>> On behalf of the Maven team I've picked up the task to develop a plugin
>> which can do the analysis during the build of a Java project. Call it a
>> thin Maven wrapper around the JDeps tool.
>>
>> The sources can be found here:
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>>
>> The documentation can be found here:
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jde
>> ps-plugin/
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jd
>> eps-plugin/usage.html
>>
>> There's a SNAPSHOT version availabe at
>> https://repository.apache.org/content/repositories/snapshots/
>>
>> The plugin is still in development, but now would be an appropriate
>> moment
>> to share your thoughts on what this plugin should do. For instance:
>> break
>> the build if the project depends on JDK internal APIs (already
>> implemented).
>> So please, share your ideas.
>>
>> thanks,
>> Robert Scholte
>>
>> ps. Quite a lot of users relate the plugin version to the Maven version.
>> For that reason the maven-jdeps-plugin version starts with 3.0,
>> indicating
>> you need to use at least Maven-3.
>> ps2. Documentation already refers to Apache Maven 3.2.6, even though it
>> is
>> not released yet. Chances are that Maven 3.2.6 will be released before
>> Maven JDeps Plugin 3.0
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
another topic:
"When using Apache Maven 3.2.6 you don't need to include the <<<maven-
toolchain-plugin>>>; the <<<maven-jdeps-plugin>>>
can pick up..."
looking at the code, IIUC: the plugin doesn't use the jdk toolchain configured
(or not) for the whole build with maven-toolchain-plugin but will select a jdk
toolchain based on its own preference
isn't it?
Regards,
Hervé
Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
> Hi,
>
> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
> Their talk ended with encouraging everybody to use the JDeps tool to
> analyze your dependencies in preparation of JDK9s jigsaw.
> On behalf of the Maven team I've picked up the task to develop a plugin
> which can do the analysis during the build of a Java project. Call it a
> thin Maven wrapper around the JDeps tool.
>
> The sources can be found here:
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>
> The documentation can be found here:
> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jde
> ps-plugin/
> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jd
> eps-plugin/usage.html
>
> There's a SNAPSHOT version availabe at
> https://repository.apache.org/content/repositories/snapshots/
>
> The plugin is still in development, but now would be an appropriate moment
> to share your thoughts on what this plugin should do. For instance: break
> the build if the project depends on JDK internal APIs (already
> implemented).
> So please, share your ideas.
>
> thanks,
> Robert Scholte
>
> ps. Quite a lot of users relate the plugin version to the Maven version.
> For that reason the maven-jdeps-plugin version starts with 3.0, indicating
> you need to use at least Maven-3.
> ps2. Documentation already refers to Apache Maven 3.2.6, even though it is
> not released yet. Chances are that Maven 3.2.6 will be released before
> Maven JDeps Plugin 3.0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
That's exactly the reason why I hadn't started it. Ordering based on
version is simple, but you probably need to respect the other requirements
as well.
I see some challenges here: how to switch between the two without changing
the pom.xml or toolchains.xml?
I have some ideas: let me work on a solid solution for this.
thanks,
Robert
Op Sun, 15 Feb 2015 16:48:01 +0100 schreef Hervé BOUTEMY
<he...@free.fr>:
> generic toolchain ordering doesn't seem feasible
>
> jdk toolchain ordering, since we know fields, can be done: version is the
> easiest one to order. But then there are other properties: how to order
> them,
> since they are full open?
>
> it will be the same if you implement order in jdeps plugin: how to order
> Oracle JDK 1.8 with OpenJDK 1.8 and IBM JDK 1.8?
>
> the question of ordering isn't as trivial as expected: sometimes, some
> user
> may want not only the latest but another condition
>
> Regards,
>
> Hervé
>
> Le dimanche 15 février 2015 11:59:11 Robert Scholte a écrit :
>> Hi Hervé,
>>
>> yes, you are right, it is indeed the last one specified in the
>> toolchains
>> with type 'jdk'.
>> I'm still wondering if I should make Toolchains Comparable, so we can
>> indeed order them.
>> In that case it would really be the latest.
>>
>> thanks,
>> Robert
>>
>> Op Sun, 15 Feb 2015 07:05:05 +0100 schreef Hervé BOUTEMY
>>
>> <he...@free.fr>:
>> > Hi Robert,
>> >
>> > I just had a look at jdeps doc, and was suprosed by "the
>> > maven-jdeps-plugin
>> > can pick up the latest jdk toolchain": latest, really?
>> >
>> > Then I had a look at the code: IIUC, it uses *the last one* declared
>> in
>> > toolchains.xml, but not really the latest since there is no sort on
>> > version in
>> > code, isn't it?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
>> >> Hi,
>> >>
>> >> during FOSDEM 2015 a few members of the Apache Maven team visited a
>> talk
>> >> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
>> >> Their talk ended with encouraging everybody to use the JDeps tool to
>> >> analyze your dependencies in preparation of JDK9s jigsaw.
>> >> On behalf of the Maven team I've picked up the task to develop a
>> plugin
>> >> which can do the analysis during the build of a Java project. Call
>> it a
>> >> thin Maven wrapper around the JDeps tool.
>> >>
>> >> The sources can be found here:
>> >>
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>> >>
>> >> The documentation can be found here:
>> >>
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven->
>> >> jde ps-plugin/
>> >>
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven->
>> >> jd
>> >> eps-plugin/usage.html
>> >>
>> >> There's a SNAPSHOT version availabe at
>> >> https://repository.apache.org/content/repositories/snapshots/
>> >>
>> >> The plugin is still in development, but now would be an appropriate
>> >> moment
>> >> to share your thoughts on what this plugin should do. For instance:
>> >> break
>> >> the build if the project depends on JDK internal APIs (already
>> >> implemented).
>> >> So please, share your ideas.
>> >>
>> >> thanks,
>> >> Robert Scholte
>> >>
>> >> ps. Quite a lot of users relate the plugin version to the Maven
>> version.
>> >> For that reason the maven-jdeps-plugin version starts with 3.0,
>> >> indicating
>> >> you need to use at least Maven-3.
>> >> ps2. Documentation already refers to Apache Maven 3.2.6, even though
>> it
>> >> is
>> >> not released yet. Chances are that Maven 3.2.6 will be released
>> before
>> >> Maven JDeps Plugin 3.0
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
generic toolchain ordering doesn't seem feasible
jdk toolchain ordering, since we know fields, can be done: version is the
easiest one to order. But then there are other properties: how to order them,
since they are full open?
it will be the same if you implement order in jdeps plugin: how to order
Oracle JDK 1.8 with OpenJDK 1.8 and IBM JDK 1.8?
the question of ordering isn't as trivial as expected: sometimes, some user
may want not only the latest but another condition
Regards,
Hervé
Le dimanche 15 février 2015 11:59:11 Robert Scholte a écrit :
> Hi Hervé,
>
> yes, you are right, it is indeed the last one specified in the toolchains
> with type 'jdk'.
> I'm still wondering if I should make Toolchains Comparable, so we can
> indeed order them.
> In that case it would really be the latest.
>
> thanks,
> Robert
>
> Op Sun, 15 Feb 2015 07:05:05 +0100 schreef Hervé BOUTEMY
>
> <he...@free.fr>:
> > Hi Robert,
> >
> > I just had a look at jdeps doc, and was suprosed by "the
> > maven-jdeps-plugin
> > can pick up the latest jdk toolchain": latest, really?
> >
> > Then I had a look at the code: IIUC, it uses *the last one* declared in
> > toolchains.xml, but not really the latest since there is no sort on
> > version in
> > code, isn't it?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
> >> Hi,
> >>
> >> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
> >> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
> >> Their talk ended with encouraging everybody to use the JDeps tool to
> >> analyze your dependencies in preparation of JDK9s jigsaw.
> >> On behalf of the Maven team I've picked up the task to develop a plugin
> >> which can do the analysis during the build of a Java project. Call it a
> >> thin Maven wrapper around the JDeps tool.
> >>
> >> The sources can be found here:
> >> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
> >>
> >> The documentation can be found here:
> >> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-> >> jde ps-plugin/
> >> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-> >> jd
> >> eps-plugin/usage.html
> >>
> >> There's a SNAPSHOT version availabe at
> >> https://repository.apache.org/content/repositories/snapshots/
> >>
> >> The plugin is still in development, but now would be an appropriate
> >> moment
> >> to share your thoughts on what this plugin should do. For instance:
> >> break
> >> the build if the project depends on JDK internal APIs (already
> >> implemented).
> >> So please, share your ideas.
> >>
> >> thanks,
> >> Robert Scholte
> >>
> >> ps. Quite a lot of users relate the plugin version to the Maven version.
> >> For that reason the maven-jdeps-plugin version starts with 3.0,
> >> indicating
> >> you need to use at least Maven-3.
> >> ps2. Documentation already refers to Apache Maven 3.2.6, even though it
> >> is
> >> not released yet. Chances are that Maven 3.2.6 will be released before
> >> Maven JDeps Plugin 3.0
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
Hi Hervé,
yes, you are right, it is indeed the last one specified in the toolchains
with type 'jdk'.
I'm still wondering if I should make Toolchains Comparable, so we can
indeed order them.
In that case it would really be the latest.
thanks,
Robert
Op Sun, 15 Feb 2015 07:05:05 +0100 schreef Hervé BOUTEMY
<he...@free.fr>:
> Hi Robert,
>
> I just had a look at jdeps doc, and was suprosed by "the
> maven-jdeps-plugin
> can pick up the latest jdk toolchain": latest, really?
>
> Then I had a look at the code: IIUC, it uses *the last one* declared in
> toolchains.xml, but not really the latest since there is no sort on
> version in
> code, isn't it?
>
> Regards,
>
> Hervé
>
> Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
>> Hi,
>>
>> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
>> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
>> Their talk ended with encouraging everybody to use the JDeps tool to
>> analyze your dependencies in preparation of JDK9s jigsaw.
>> On behalf of the Maven team I've picked up the task to develop a plugin
>> which can do the analysis during the build of a Java project. Call it a
>> thin Maven wrapper around the JDeps tool.
>>
>> The sources can be found here:
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>>
>> The documentation can be found here:
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jde
>> ps-plugin/
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jd
>> eps-plugin/usage.html
>>
>> There's a SNAPSHOT version availabe at
>> https://repository.apache.org/content/repositories/snapshots/
>>
>> The plugin is still in development, but now would be an appropriate
>> moment
>> to share your thoughts on what this plugin should do. For instance:
>> break
>> the build if the project depends on JDK internal APIs (already
>> implemented).
>> So please, share your ideas.
>>
>> thanks,
>> Robert Scholte
>>
>> ps. Quite a lot of users relate the plugin version to the Maven version.
>> For that reason the maven-jdeps-plugin version starts with 3.0,
>> indicating
>> you need to use at least Maven-3.
>> ps2. Documentation already refers to Apache Maven 3.2.6, even though it
>> is
>> not released yet. Chances are that Maven 3.2.6 will be released before
>> Maven JDeps Plugin 3.0
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
Hi Robert,
I just had a look at jdeps doc, and was suprosed by "the maven-jdeps-plugin
can pick up the latest jdk toolchain": latest, really?
Then I had a look at the code: IIUC, it uses *the last one* declared in
toolchains.xml, but not really the latest since there is no sort on version in
code, isn't it?
Regards,
Hervé
Le samedi 14 février 2015 16:32:23 Robert Scholte a écrit :
> Hi,
>
> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
> Their talk ended with encouraging everybody to use the JDeps tool to
> analyze your dependencies in preparation of JDK9s jigsaw.
> On behalf of the Maven team I've picked up the task to develop a plugin
> which can do the analysis during the build of a Java project. Call it a
> thin Maven wrapper around the JDeps tool.
>
> The sources can be found here:
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>
> The documentation can be found here:
> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jde
> ps-plugin/
> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jd
> eps-plugin/usage.html
>
> There's a SNAPSHOT version availabe at
> https://repository.apache.org/content/repositories/snapshots/
>
> The plugin is still in development, but now would be an appropriate moment
> to share your thoughts on what this plugin should do. For instance: break
> the build if the project depends on JDK internal APIs (already
> implemented).
> So please, share your ideas.
>
> thanks,
> Robert Scholte
>
> ps. Quite a lot of users relate the plugin version to the Maven version.
> For that reason the maven-jdeps-plugin version starts with 3.0, indicating
> you need to use at least Maven-3.
> ps2. Documentation already refers to Apache Maven 3.2.6, even though it is
> not released yet. Chances are that Maven 3.2.6 will be released before
> Maven JDeps Plugin 3.0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
Hi Anders,
AFAIK the majority of goals is dash-based and not camelCaseBased.
I'd prefer not to guess the name of the goal, so I'd like to follow the
dash-based goal convention.
Maybe we should add/rename the goals for the m-compiler-p and
m-resources-p.
thanks,
Robert
Op Wed, 18 Feb 2015 09:04:02 +0100 schreef Anders Hammar
<an...@hammar.net>:
> Robert,
>
> Wrt to the goal names, do we want the "test-xxx" syntax instead of
> "testXxx" (used in m-compiler-p and m-resources-p)? "test-xxx" is used in
> some other core plugins as well.
>
> /Anders
>
> On Sat, Feb 14, 2015 at 4:32 PM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> Hi,
>>
>> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
>> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
>> Their talk ended with encouraging everybody to use the JDeps tool to
>> analyze your dependencies in preparation of JDK9s jigsaw.
>> On behalf of the Maven team I've picked up the task to develop a plugin
>> which can do the analysis during the build of a Java project. Call it a
>> thin Maven wrapper around the JDeps tool.
>>
>> The sources can be found here:
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>>
>> The documentation can be found here:
>> http://maven.apache.org/plugins-archives/maven-jdeps-
>> plugin-LATEST/maven-jdeps-plugin/
>> http://maven.apache.org/plugins-archives/maven-jdeps-
>> plugin-LATEST/maven-jdeps-plugin/usage.html
>>
>> There's a SNAPSHOT version availabe at
>> https://repository.apache.org/content/repositories/snapshots/
>>
>> The plugin is still in development, but now would be an appropriate
>> moment
>> to share your thoughts on what this plugin should do. For instance:
>> break
>> the build if the project depends on JDK internal APIs (already
>> implemented).
>> So please, share your ideas.
>>
>> thanks,
>> Robert Scholte
>>
>> ps. Quite a lot of users relate the plugin version to the Maven version.
>> For that reason the maven-jdeps-plugin version starts with 3.0,
>> indicating
>> you need to use at least Maven-3.
>> ps2. Documentation already refers to Apache Maven 3.2.6, even though it
>> is
>> not released yet. Chances are that Maven 3.2.6 will be released before
>> Maven JDeps Plugin 3.0
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Anders Hammar <an...@hammar.net>.
Robert,
Wrt to the goal names, do we want the "test-xxx" syntax instead of
"testXxx" (used in m-compiler-p and m-resources-p)? "test-xxx" is used in
some other core plugins as well.
/Anders
On Sat, Feb 14, 2015 at 4:32 PM, Robert Scholte <rf...@apache.org>
wrote:
> Hi,
>
> during FOSDEM 2015 a few members of the Apache Maven team visited a talk
> of Oracle, presented by Rory O'Donnell and Dalibor Topic.
> Their talk ended with encouraging everybody to use the JDeps tool to
> analyze your dependencies in preparation of JDK9s jigsaw.
> On behalf of the Maven team I've picked up the task to develop a plugin
> which can do the analysis during the build of a Java project. Call it a
> thin Maven wrapper around the JDeps tool.
>
> The sources can be found here:
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>
> The documentation can be found here:
> http://maven.apache.org/plugins-archives/maven-jdeps-
> plugin-LATEST/maven-jdeps-plugin/
> http://maven.apache.org/plugins-archives/maven-jdeps-
> plugin-LATEST/maven-jdeps-plugin/usage.html
>
> There's a SNAPSHOT version availabe at
> https://repository.apache.org/content/repositories/snapshots/
>
> The plugin is still in development, but now would be an appropriate moment
> to share your thoughts on what this plugin should do. For instance: break
> the build if the project depends on JDK internal APIs (already implemented).
> So please, share your ideas.
>
> thanks,
> Robert Scholte
>
> ps. Quite a lot of users relate the plugin version to the Maven version.
> For that reason the maven-jdeps-plugin version starts with 3.0, indicating
> you need to use at least Maven-3.
> ps2. Documentation already refers to Apache Maven 3.2.6, even though it is
> not released yet. Chances are that Maven 3.2.6 will be released before
> Maven JDeps Plugin 3.0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
Hi Tibor,
the plugin is just a thin wrapper around the jdeps executable to make it
easier to integrate it with your Maven project. So for the Apache Maven
JDeps plugin it is out of scope. However, you could share your idea with
the jigsaw project[1]
thanks,
Robert
[1] http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev
Op Tue, 17 Feb 2015 09:15:21 +0100 schreef Tibor Digana
<ti...@apache.org>:
> Hi Robert,
>
> It would be great to launch the JDeps within Javac compiler. Do you
> think it
> would be possible for JDeps?
> I like the way how my annotation processor (AP) is wired with the
> compiler.
> I don't think that JDeps use annotations. I am not sure if compiler has
> other kinds of processor interfaces, but my point is to fail the build as
> soon as possible right within compiler, that's why I like the idea of AP
> running in compiler.
>
> Cheers
> Tibor
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Apache-Maven-JDeps-Plugin-tp5826470p5826639.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Tibor Digana <ti...@apache.org>.
Hi Robert,
It would be great to launch the JDeps within Javac compiler. Do you think it
would be possible for JDeps?
I like the way how my annotation processor (AP) is wired with the compiler.
I don't think that JDeps use annotations. I am not sure if compiler has
other kinds of processor interfaces, but my point is to fail the build as
soon as possible right within compiler, that's why I like the idea of AP
running in compiler.
Cheers
Tibor
--
View this message in context: http://maven.40175.n5.nabble.com/Apache-Maven-JDeps-Plugin-tp5826470p5826639.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
notice: I made some tests, and animal-sniffer detects internals API use
then failOnWarning will not be useful for people already using animal sniffer
Regards,
Hervé
Le mardi 17 février 2015 00:04:37 Robert Scholte a écrit :
> Hi Alan,
>
> I've added a flag called failOnWarning (default:true), assuming that the
> usage of jdkinternals is considered a warning and not an error.
> With the following configuration you'll be able to run jdeps multiple
> times within the same build.
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jdeps-plugin</artifactId>
> <version>3.0-SNAPSHOT</version>
> <executions>
> <execution>
> <id>classes</id>
> <goals>
> <goal>jdkinternals</goal>
> <goal>test-jdkinternals</goal>
> </goals>
> </execution>
> <execution>
> <id>dependencies</id>
> <goals>
> <goal>jdkinternals</goal>
> <goal>test-jdkinternals</goal>
> </goals>
> <configuration>
> <recursive>true</recursive>
> <failOnWarning>false</failOnWarning>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> This should match your requirements.
>
> Robert
>
>
> Op Mon, 16 Feb 2015 19:45:16 +0100 schreef Alan Bateman
>
> <Al...@oracle.com>:
> > 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.
> >
> > -Alan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Stephen Connolly <st...@gmail.com>.
Or maybe just integrate http://www.graphdracula.net/showcase/ into the html
report and let people drag the graph to their needs. Note that the site
also lists similar projects providing similar functionality, so worth
checking out either way
On 13 April 2015 at 08:59, Alan Bateman <Al...@oracle.com> wrote:
> On 13/04/2015 03:46, Hervé BOUTEMY wrote:
>
>> last week, during DevoxxFR, Arnaud and I showed maven-jdeps-plugin: as
>> expected, a lot of users didn't know about this tool
>> So for sure, having this plugin and a report would help
>>
>> Then there is the question of: what should the report look like?
>> Should it be a simple stdout dump of command line result? ugly...
>>
>> During DevoxxFR, I saw a graph of Java modules dependencies: having a
>> report
>> putting info on this graph could really be more expressive than console.
>>
>> Is there an html report available for jdeps?
>> Should we parse text output to work on a graphic report? (seems hard...)
>>
>> jdeps can produce .dot files when you use -dotoutput. You can then you
> use Graphviz layout or other tools to draw graphs. Would that help?
>
> -Alan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Apache Maven JDeps Plugin
Posted by Alan Bateman <Al...@oracle.com>.
On 13/04/2015 03:46, Hervé BOUTEMY wrote:
> last week, during DevoxxFR, Arnaud and I showed maven-jdeps-plugin: as
> expected, a lot of users didn't know about this tool
> So for sure, having this plugin and a report would help
>
> Then there is the question of: what should the report look like?
> Should it be a simple stdout dump of command line result? ugly...
>
> During DevoxxFR, I saw a graph of Java modules dependencies: having a report
> putting info on this graph could really be more expressive than console.
>
> Is there an html report available for jdeps?
> Should we parse text output to work on a graphic report? (seems hard...)
>
jdeps can produce .dot files when you use -dotoutput. You can then you
use Graphviz layout or other tools to draw graphs. Would that help?
-Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
last week, during DevoxxFR, Arnaud and I showed maven-jdeps-plugin: as
expected, a lot of users didn't know about this tool
So for sure, having this plugin and a report would help
Then there is the question of: what should the report look like?
Should it be a simple stdout dump of command line result? ugly...
During DevoxxFR, I saw a graph of Java modules dependencies: having a report
putting info on this graph could really be more expressive than console.
Is there an html report available for jdeps?
Should we parse text output to work on a graphic report? (seems hard...)
Regards,
Hervé
Le vendredi 20 février 2015 13:08:16 Martijn Verburg a écrit :
> From my standpoint that would be amazing - we'd always struggled with how
> we're going to try and educate millions of developers about running this on
> their code base. Having it as a core report is a great start!
>
> Cheers,
> Martijn
>
> On 20 February 2015 at 03:55, Hervé BOUTEMY <he...@free.fr> wrote:
> > regarding failing or not failing (that's the question):
> >
> > IMHO, it would be useful to create Maven reports: as a first step, adding
> > maven-jdeps-report as report will help people be aware of the state of
> > their
> > code and publishing it inside their site without taking any fix action at
> > the
> > moment
> >
> > concrete use case: I'd like to add this to the Maven parent pom to have
> > jdeps
> > report for every future release
> >
> > And I can even dream one step beyond: then add a dist-tool-plugin report
> > to
> > get an overview of the state of our full codebase, like [1] :)
> >
> > this dream should not be that hard to happen
> >
> > Regards,
> >
> > Hervé
> >
> > [1]
> > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/di
> > st-tool-prerequisites.html>
> > Le mardi 17 février 2015 00:04:37 Robert Scholte a écrit :
> > > Hi Alan,
> > >
> > > I've added a flag called failOnWarning (default:true), assuming that the
> > > usage of jdkinternals is considered a warning and not an error.
> > > With the following configuration you'll be able to run jdeps multiple
> > > times within the same build.
> > >
> > > <plugin>
> > >
> > > <groupId>org.apache.maven.plugins</groupId>
> > > <artifactId>maven-jdeps-plugin</artifactId>
> > > <version>3.0-SNAPSHOT</version>
> > > <executions>
> > >
> > > <execution>
> > >
> > > <id>classes</id>
> > > <goals>
> > >
> > > <goal>jdkinternals</goal>
> > > <goal>test-jdkinternals</goal>
> > >
> > > </goals>
> > >
> > > </execution>
> > > <execution>
> > >
> > > <id>dependencies</id>
> > > <goals>
> > >
> > > <goal>jdkinternals</goal>
> > > <goal>test-jdkinternals</goal>
> > >
> > > </goals>
> > > <configuration>
> > >
> > > <recursive>true</recursive>
> > > <failOnWarning>false</failOnWarning>
> > >
> > > </configuration>
> > >
> > > </execution>
> > >
> > > </executions>
> > >
> > > </plugin>
> > >
> > > This should match your requirements.
> > >
> > > Robert
> > >
> > >
> > > Op Mon, 16 Feb 2015 19:45:16 +0100 schreef Alan Bateman
> > >
> > > <Al...@oracle.com>:
> > > > 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.
> > > >
> > > > -Alan
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Martijn Verburg <ma...@gmail.com>.
>From my standpoint that would be amazing - we'd always struggled with how
we're going to try and educate millions of developers about running this on
their code base. Having it as a core report is a great start!
Cheers,
Martijn
On 20 February 2015 at 03:55, Hervé BOUTEMY <he...@free.fr> wrote:
> regarding failing or not failing (that's the question):
>
> IMHO, it would be useful to create Maven reports: as a first step, adding
> maven-jdeps-report as report will help people be aware of the state of
> their
> code and publishing it inside their site without taking any fix action at
> the
> moment
>
> concrete use case: I'd like to add this to the Maven parent pom to have
> jdeps
> report for every future release
>
> And I can even dream one step beyond: then add a dist-tool-plugin report to
> get an overview of the state of our full codebase, like [1] :)
>
> this dream should not be that hard to happen
>
> Regards,
>
> Hervé
>
> [1]
> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html
>
> Le mardi 17 février 2015 00:04:37 Robert Scholte a écrit :
> > Hi Alan,
> >
> > I've added a flag called failOnWarning (default:true), assuming that the
> > usage of jdkinternals is considered a warning and not an error.
> > With the following configuration you'll be able to run jdeps multiple
> > times within the same build.
> >
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-jdeps-plugin</artifactId>
> > <version>3.0-SNAPSHOT</version>
> > <executions>
> > <execution>
> > <id>classes</id>
> > <goals>
> > <goal>jdkinternals</goal>
> > <goal>test-jdkinternals</goal>
> > </goals>
> > </execution>
> > <execution>
> > <id>dependencies</id>
> > <goals>
> > <goal>jdkinternals</goal>
> > <goal>test-jdkinternals</goal>
> > </goals>
> > <configuration>
> > <recursive>true</recursive>
> > <failOnWarning>false</failOnWarning>
> > </configuration>
> > </execution>
> > </executions>
> > </plugin>
> >
> > This should match your requirements.
> >
> > Robert
> >
> >
> > Op Mon, 16 Feb 2015 19:45:16 +0100 schreef Alan Bateman
> >
> > <Al...@oracle.com>:
> > > 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.
> > >
> > > -Alan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Apache Maven JDeps Plugin
Posted by Hervé BOUTEMY <he...@free.fr>.
regarding failing or not failing (that's the question):
IMHO, it would be useful to create Maven reports: as a first step, adding
maven-jdeps-report as report will help people be aware of the state of their
code and publishing it inside their site without taking any fix action at the
moment
concrete use case: I'd like to add this to the Maven parent pom to have jdeps
report for every future release
And I can even dream one step beyond: then add a dist-tool-plugin report to
get an overview of the state of our full codebase, like [1] :)
this dream should not be that hard to happen
Regards,
Hervé
[1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html
Le mardi 17 février 2015 00:04:37 Robert Scholte a écrit :
> Hi Alan,
>
> I've added a flag called failOnWarning (default:true), assuming that the
> usage of jdkinternals is considered a warning and not an error.
> With the following configuration you'll be able to run jdeps multiple
> times within the same build.
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jdeps-plugin</artifactId>
> <version>3.0-SNAPSHOT</version>
> <executions>
> <execution>
> <id>classes</id>
> <goals>
> <goal>jdkinternals</goal>
> <goal>test-jdkinternals</goal>
> </goals>
> </execution>
> <execution>
> <id>dependencies</id>
> <goals>
> <goal>jdkinternals</goal>
> <goal>test-jdkinternals</goal>
> </goals>
> <configuration>
> <recursive>true</recursive>
> <failOnWarning>false</failOnWarning>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> This should match your requirements.
>
> Robert
>
>
> Op Mon, 16 Feb 2015 19:45:16 +0100 schreef Alan Bateman
>
> <Al...@oracle.com>:
> > 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.
> >
> > -Alan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
Hi Alan,
I've added a flag called failOnWarning (default:true), assuming that the
usage of jdkinternals is considered a warning and not an error.
With the following configuration you'll be able to run jdeps multiple
times within the same build.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jdeps-plugin</artifactId>
<version>3.0-SNAPSHOT</version>
<executions>
<execution>
<id>classes</id>
<goals>
<goal>jdkinternals</goal>
<goal>test-jdkinternals</goal>
</goals>
</execution>
<execution>
<id>dependencies</id>
<goals>
<goal>jdkinternals</goal>
<goal>test-jdkinternals</goal>
</goals>
<configuration>
<recursive>true</recursive>
<failOnWarning>false</failOnWarning>
</configuration>
</execution>
</executions>
</plugin>
This should match your requirements.
Robert
Op Mon, 16 Feb 2015 19:45:16 +0100 schreef Alan Bateman
<Al...@oracle.com>:
> 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.
>
> -Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Mandy Chung <ma...@oracle.com>.
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
> <ma...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
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
<ma...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Maven JDeps Plugin
Posted by Robert Scholte <rf...@apache.org>.
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.
thanks,
Robert
Op Mon, 16 Feb 2015 19:16:52 +0100 schreef Alan Bateman
<Al...@oracle.com>:
> On 14/02/2015 15:32, Robert Scholte wrote:
>> Hi,
>>
>> during FOSDEM 2015 a few members of the Apache Maven team visited a
>> talk of Oracle, presented by Rory O'Donnell and Dalibor Topic.
>> Their talk ended with encouraging everybody to use the JDeps tool to
>> analyze your dependencies in preparation of JDK9s jigsaw.
>> On behalf of the Maven team I've picked up the task to develop a plugin
>> which can do the analysis during the build of a Java project. Call it a
>> thin Maven wrapper around the JDeps tool.
>>
>> The sources can be found here:
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-jdeps-plugin/
>>
>> The documentation can be found here:
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jdeps-plugin/
>> http://maven.apache.org/plugins-archives/maven-jdeps-plugin-LATEST/maven-jdeps-plugin/usage.html
>> There's a SNAPSHOT version availabe at
>> https://repository.apache.org/content/repositories/snapshots/
>>
>> The plugin is still in development, but now would be an appropriate
>> moment to share your thoughts on what this plugin should do. For
>> instance: break the build if the project depends on JDK internal APIs
>> (already implemented).
>> So please, share your ideas.
> This looks very useful. If I read the documentation pages correctly then
> it checks the project main and test classes which makes me curious about
> dependences. Does it run jdeps on those too?
>
> -Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org