Re: Apache Maven JDeps Plugin

2015-02-15 Thread Hervé BOUTEMY
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-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Archetype in git

2015-02-15 Thread Hervé BOUTEMY
perhaps adding instruction on the git migration Wiki page [1] would help 
having easier and consistent work done on every migration

Regards,

Hervé

[1] 
https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration#GitMigration-KeepingtrackofauthorativeSCMforeachplugin

Le lundi 9 février 2015 12:08:43 Benson Margulies a écrit :
 https://git-wip-us.apache.org/repos/asf/maven-archetype.git
 
 Momentarily it will be R/W and have a github mirror.
 
 I'll be making the pom scm updates.
 
 How ruthlessly do I prune svn?
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [VOTE] Release Apache Maven PDF Plugin version 1.3

2015-02-15 Thread Hervé BOUTEMY
+1

Regards,

Hervé

Le mercredi 11 février 2015 19:43:58 Karl Heinz Marbaise a écrit :
 Hi,
 
 We solved 9 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932version=189
 50
 
 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/issues/?jql=project%20%3D%20MPDF%20AND%20status%20%
 3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1137/
 
 https://repository.apache.org/content/repositories/maven-1137/org/apache/mav
 en/plugins/maven-pdf-plugin/1.3/maven-pdf-plugin-1.3-source-release.zip
 
 Source release checksum(s):
 maven-pdf-plugin-source-release.zip sha1:
 1e8df80049a3c61d2b899120d700b52670181745
 
 Staging site:
 http://maven.apache.org/plugins-archives/maven-pdf-plugin-LATEST/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Kind regards
 Karl Heinz Marbaise
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Build failed in Jenkins: maven-plugins » Apache Maven RAR Plugin #2651

2015-02-15 Thread Robert Scholte

Just checked on my system, it had that folder as well.
Removing it and rebuilding it again didn't make it appear again.
So I guess there was a configuration-issue in the past, but because it is  
next to the target-directory it won't be cleaned up with the 'mvn clean'.


thanks,
Robert

Op Sun, 15 Feb 2015 04:54:23 +0100 schreef Hervé BOUTEMY  
herve.bout...@free.fr:



a maven-archiver directory appears on Jenkins [1] but not on my machine

Does anybody know why?

Regards,

Hervé

[1] https://builds.apache.org/job/maven-plugins/ws/maven-rar-plugin/

Le samedi 14 février 2015 12:36:56 Apache Jenkins Server a écrit :

See
https://builds.apache.org/job/maven-plugins/org.apache.maven.plugins$maven
-rar-plugin/2651/

--
[INFO]
[INFO]

[INFO] Building Apache Maven RAR Plugin 2.5-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @  
maven-rar-plugin

--- [INFO] Deleting
https://builds.apache.org/job/maven-plugins/org.apache.maven.plugins$maven
-rar-plugin/ws/target [INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce  
(enforce-bytecode-version) @

maven-rar-plugin --- [INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce
(ban-known-bad-maven-versions) @ maven-rar-plugin --- [INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce  
(ensure-no-container-api) @

maven-rar-plugin --- [INFO]
[INFO] --- apache-rat-plugin:0.11:check (rat-check) @ maven-rar-plugin  
---

[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude:
src/test/resources/unit/basic-rar-with-manifest/src/main/rar/META-INF/MANIF
EST.MF [INFO] Exclude: DEPENDENCIES
[INFO] 41 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 1 unknown: 1 generated:  
0

approved: 37 licence.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Apache Maven JDeps Plugin

2015-02-15 Thread Robert Scholte
Op Sun, 15 Feb 2015 07:09:37 +0100 schreef Hervé BOUTEMY  
herve.bout...@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:
ListToolchain tcs =
	(ListToolchain) 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Archetype in git

2015-02-15 Thread Benson Margulies
Infra turns out to have a strong preference for leaving SVN 'as is'. I
got a dispensation to add a readme pointing across to git. So we might
want to plan to follow that pattern.


On Sun, Feb 15, 2015 at 12:45 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 perhaps adding instruction on the git migration Wiki page [1] would help
 having easier and consistent work done on every migration

 Regards,

 Hervé

 [1]
 https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration#GitMigration-KeepingtrackofauthorativeSCMforeachplugin

 Le lundi 9 février 2015 12:08:43 Benson Margulies a écrit :
 https://git-wip-us.apache.org/repos/asf/maven-archetype.git

 Momentarily it will be R/W and have a github mirror.

 I'll be making the pom scm updates.

 How ruthlessly do I prune svn?

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Apache Maven JDeps Plugin

2015-02-15 Thread Hervé BOUTEMY
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
 
 herve.bout...@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-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
  
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Build failed in Jenkins: maven-plugins » Apache Maven RAR Plugin #2651

2015-02-15 Thread Karl Heinz Marbaise

Hi,

there problem seemed to be caused by that not all jenkins nodes have 
been updated correctly...which means there are some folders left over 
and haven't been removedwhich i don't understand...


If you had the folder on your system as well that sounds like a problem 
with SVN..


I had informed INFRA for that and requested to clean the nodes manually 
...but there seemed to be some noded left or oversight...


Kind regards
Karl Heinz Marbaise

On 2/15/15 12:44 PM, Robert Scholte wrote:

Just checked on my system, it had that folder as well.
Removing it and rebuilding it again didn't make it appear again.
So I guess there was a configuration-issue in the past, but because it
is next to the target-directory it won't be cleaned up with the 'mvn
clean'.

thanks,
Robert

Op Sun, 15 Feb 2015 04:54:23 +0100 schreef Hervé BOUTEMY
herve.bout...@free.fr:


a maven-archiver directory appears on Jenkins [1] but not on my machine

Does anybody know why?

Regards,

Hervé

[1] https://builds.apache.org/job/maven-plugins/ws/maven-rar-plugin/

Le samedi 14 février 2015 12:36:56 Apache Jenkins Server a écrit :

See
https://builds.apache.org/job/maven-plugins/org.apache.maven.plugins$maven

-rar-plugin/2651/

--
[INFO]
[INFO]

[INFO] Building Apache Maven RAR Plugin 2.5-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
maven-rar-plugin
--- [INFO] Deleting
https://builds.apache.org/job/maven-plugins/org.apache.maven.plugins$maven

-rar-plugin/ws/target [INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce
(enforce-bytecode-version) @
maven-rar-plugin --- [INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce
(ban-known-bad-maven-versions) @ maven-rar-plugin --- [INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce
(ensure-no-container-api) @
maven-rar-plugin --- [INFO]
[INFO] --- apache-rat-plugin:0.11:check (rat-check) @
maven-rar-plugin ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude:
src/test/resources/unit/basic-rar-with-manifest/src/main/rar/META-INF/MANIF

EST.MF [INFO] Exclude: DEPENDENCIES
[INFO] 41 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 1 unknown: 1
generated: 0
approved: 37 licence.





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [VOTE] Release Apache Maven PDF Plugin version 1.3

2015-02-15 Thread Robert Scholte

+1, although the logs of the ITs are not clean.

[INFO] Ignoring api call removed in maven 3, no reports are generated!
[DEBUG]
java.lang.NoSuchMethodError:  
org.apache.maven.plugin.PluginManager.verifyReportPlugin(Lorg/apache/maven/model/ReportPlugin;Lorg/apache/maven/project/MavenProject;Lorg/apache/maven/execution/MavenSession;)Lorg/apache/maven/plugin/descriptor/PluginDescriptor;


Needs to be investigated, there was actually a pdf generated.

thanks,
Robert

Op Wed, 11 Feb 2015 19:43:58 +0100 schreef Karl Heinz Marbaise  
khmarba...@gmx.de:



Hi,

We solved 9 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932version=18950

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MPDF%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1137/

https://repository.apache.org/content/repositories/maven-1137/org/apache/maven/plugins/maven-pdf-plugin/1.3/maven-pdf-plugin-1.3-source-release.zip

Source release checksum(s):
maven-pdf-plugin-source-release.zip sha1:  
1e8df80049a3c61d2b899120d700b52670181745


Staging site:
http://maven.apache.org/plugins-archives/maven-pdf-plugin-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [VOTE] Release Apache Maven PDF Plugin version 1.3

2015-02-15 Thread Karl Heinz Marbaise

Hi Robert,

you were faster with creating the appropriate JIRA ;-)..

Thanks for finding it...

On 2/15/15 4:39 PM, Robert Scholte wrote:

+1, although the logs of the ITs are not clean.

[INFO] Ignoring api call removed in maven 3, no reports are generated!
[DEBUG]
java.lang.NoSuchMethodError:
org.apache.maven.plugin.PluginManager.verifyReportPlugin(Lorg/apache/maven/model/ReportPlugin;Lorg/apache/maven/project/MavenProject;Lorg/apache/maven/execution/MavenSession;)Lorg/apache/maven/plugin/descriptor/PluginDescriptor;


Needs to be investigated, there was actually a pdf generated.

thanks,
Robert

Op Wed, 11 Feb 2015 19:43:58 +0100 schreef Karl Heinz Marbaise
khmarba...@gmx.de:


Hi,

We solved 9 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11932version=18950


There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MPDF%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1137/

https://repository.apache.org/content/repositories/maven-1137/org/apache/maven/plugins/maven-pdf-plugin/1.3/maven-pdf-plugin-1.3-source-release.zip


Source release checksum(s):
maven-pdf-plugin-source-release.zip sha1:
1e8df80049a3c61d2b899120d700b52670181745

Staging site:
http://maven.apache.org/plugins-archives/maven-pdf-plugin-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Apache Maven JDeps Plugin

2015-02-15 Thread Robert Scholte
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  
herve.bout...@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

herve.bout...@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-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Apache Maven JDeps Plugin

2015-02-15 Thread Hervé BOUTEMY
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-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Apache Maven JDeps Plugin

2015-02-15 Thread Robert Scholte

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  
herve.bout...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Build failed in Jenkins: maven-plugins » Apache Maven RAR Plugin #2651

2015-02-15 Thread Hervé BOUTEMY
a maven-archiver directory appears on Jenkins [1] but not on my machine

Does anybody know why?

Regards,

Hervé

[1] https://builds.apache.org/job/maven-plugins/ws/maven-rar-plugin/

Le samedi 14 février 2015 12:36:56 Apache Jenkins Server a écrit :
 See
 https://builds.apache.org/job/maven-plugins/org.apache.maven.plugins$maven
 -rar-plugin/2651/
 
 --
 [INFO]
 [INFO]
 
 [INFO] Building Apache Maven RAR Plugin 2.5-SNAPSHOT
 [INFO]
 
 [INFO]
 [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ maven-rar-plugin
 --- [INFO] Deleting
 https://builds.apache.org/job/maven-plugins/org.apache.maven.plugins$maven
 -rar-plugin/ws/target [INFO]
 [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-bytecode-version) @
 maven-rar-plugin --- [INFO]
 [INFO] --- maven-enforcer-plugin:1.3.1:enforce
 (ban-known-bad-maven-versions) @ maven-rar-plugin --- [INFO]
 [INFO] --- maven-enforcer-plugin:1.3.1:enforce (ensure-no-container-api) @
 maven-rar-plugin --- [INFO]
 [INFO] --- apache-rat-plugin:0.11:check (rat-check) @ maven-rar-plugin ---
 [INFO] 51 implicit excludes (use -debug for more details).
 [INFO] Exclude:
 src/test/resources/unit/basic-rar-with-manifest/src/main/rar/META-INF/MANIF
 EST.MF [INFO] Exclude: DEPENDENCIES
 [INFO] 41 resources included (use -debug for more details)
 [INFO] Rat check: Summary of files. Unapproved: 1 unknown: 1 generated: 0
 approved: 37 licence.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Version ranges and snapshots

2015-02-15 Thread Jon Harper
Hi,
since there were no answers, I'm not sure I wrote to the correct mailing
list for this problem. Can anyone direct me to someone who is interested in
working on this issue ?

For info, the docs have been saying the following for 7+ years:
groupId, artifactId, version:
These elements are self-explanatory

The version element is *not* self-explanatory, especially regarding
interactions between version ranges and *-SNAPSHOTs artifacts.

Any thoughts on this matter would be appreciated.
Regards,
Jon

On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper jon.harpe...@gmail.com wrote:

 Hi,
 I'm resurrecting this old thread to ask if it's possible to change
 http://maven.apache.org/pom.html to document the current implementation
 behavior (7+ years old).

 Please see my comment on MNG-3092:
 http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362616

 Jon

 Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700

  Hi,
 
  Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
  contrary to the 2.0 design docs:
 
  http://jira.codehaus.org/browse/MNG-3092
 
  Brett, Kenney and myself had a brief discussion on IRC about this:
  Kenney says that the behaviour is theoretically correct (which it is),
  although I feel it goes against the practical usage described in the
  docs.  The two main choices I can see are:
 
  1) We stick to the design docs and disallow snapshots in ranges when
  they aren't an explicit boundary, as per the MNG-3092 patch.
 
  2) We reconsider the design docs and leave range resolution behaving
  as it is, then use profiles to enable or disable snapshot repositories
  at build time.
 
  Any thoughts?
 
  Mark




Re: Version ranges and snapshots

2015-02-15 Thread Hervé BOUTEMY
Hi Jon,

Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit :
 Hi,
 since there were no answers, I'm not sure I wrote to the correct mailing
 list for this problem.
good mailing list, but can of worm :)

 Can anyone direct me to someone who is interested in
 working on this issue ?
I can try to work on this once more: perhaps we'll manage to improve something

 
 For info, the docs have been saying the following for 7+ years:
 groupId, artifactId, version:
 These elements are self-explanatory
 
 The version element is *not* self-explanatory, especially regarding
 interactions between version ranges and *-SNAPSHOTs artifacts.
you're right: version *in dependencies* is not self explanatory (version in 
Maven coordinates is self explanatory)
It has a lot of subtle features: preferred vs exact match, version range, then 
the question of SNAPSHOTS

 
 Any thoughts on this matter would be appreciated.
if you have little patches for the source of the page [1], I can review and we 
can work and discuss on it step by step

Regards,

Hervé

[1] https://svn.apache.org/repos/asf/maven/site/trunk/content/apt/pom.apt

 Regards,
 Jon
 
 On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper jon.harpe...@gmail.com wrote:
  Hi,
  I'm resurrecting this old thread to ask if it's possible to change
  http://maven.apache.org/pom.html to document the current implementation
  behavior (7+ years old).
  
  Please see my comment on MNG-3092:
  http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616page=com.
  atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36261
  6
  
  Jon
  
  Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700
  
   Hi,
   
   Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
   contrary to the 2.0 design docs:
   
   http://jira.codehaus.org/browse/MNG-3092
   
   Brett, Kenney and myself had a brief discussion on IRC about this:
   Kenney says that the behaviour is theoretically correct (which it is),
   although I feel it goes against the practical usage described in the
   docs.  The two main choices I can see are:
   
   1) We stick to the design docs and disallow snapshots in ranges when
   they aren't an explicit boundary, as per the MNG-3092 patch.
   
   2) We reconsider the design docs and leave range resolution behaving
   as it is, then use profiles to enable or disable snapshot repositories
   at build time.
   
   Any thoughts?
   
   Mark


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org