from:"Guillaume Boué"

Re: [VOTE] Release Maven Help Plugin version 3.0.0

2018-03-09 Thread Guillaume Boué


+1


Le 07/03/2018 à 22:37, Michael Osipov a écrit :

Hi,

We solved 34 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317522=12330788 



There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPH%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC 



Staging repo:
https://repository.apache.org/content/repositories/maven-1403/
https://repository.apache.org/content/repositories/maven-1403/org/apache/maven/plugins/maven-help-plugin/3.0.0/maven-help-plugin-3.0.0-source-release.zip 



Source release checksum(s):
maven-help-plugin-3.0.0-source-release.zip sha1: 
2dbd3dc017f246817de288c5962615cfd5cac18d


Staging site:
http://maven.apache.org/plugins-archives/maven-help-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

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Release Apache Maven 3.5.3

2018-02-27 Thread Guillaume Boué


+1

Can make a JIRA for this after the release.


Le 27/02/2018 à 19:21, Guillaume Boué a écrit :

(Made a mistake and only sent this to Stephen... sorry)

I've found a very small regression, but definitely not a blocker for 
the release I think. When the following is ran:


mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate

There is a spurious "[0m[0m" at the very last line (note: there are 
escape characters before the two square brackets). Doesn't happen with 
3.5.2, the line is empty. (Only tested on Windows).


Also, I didn't reproduce Dan's issue on Windows with the Takari smart 
builder on a single sample project. Maybe the number of modules?


Guillaume


Le 27/02/2018 à 19:01, Dan Tran a écrit :

Hi all,

I believe my usage of antrun is legit to make sure user who is using  
mvn

install ( without clean) has a proper clean up before another plugin
execution

   
 org.apache.maven.plugins
maven-antrun-plugin
 
   
work.around.to.clean.up.classes.before.jsonschema.start
 generate-sources
 
   run
 
 
   
 
   
 
   
 
   


here is the command to reproduce the antrun issue


   mvn clean install --builder smart -T1.0C -DskipTests


Add  -B to remove the issue but it is not ideal

Only only happens on windows ( i only test with windows and linux)

-D



On Tue, Feb 27, 2018 at 7:44 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

On 27 February 2018 at 14:46, Mirko Friedenhagen 
<mfriedenha...@gmail.com>

wrote:


+1 from my side, tested with 10 inhouse projects. Or is this vote

canceled?
Not cancelled yet. Unclear if Dan's issue is something forking maven 
and

parsing the output... the task name
"work.around.to.clean.up.classes.before.jsonschema.start" sounds 
like it
could be doing something crazy like that, in which case it is not 
using -B

when forking maven in Dan's codebase that could be the root cause.



Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Sun, Feb 25, 2018 at 10:14 AM, Dan Tran <dant...@gmail.com> wrote:

   correction

found this reference, found on 3.5.2 but I only encounter this on 
3.5.3

RC

https://stackoverflow.com/questions/48723899/maven-
numberformatexception-when-packaging


On Sun, Feb 25, 2018 at 1:13 AM, Dan Tran <dant...@gmail.com> wrote:


found this reference, found on 3.5.2 but I only encounter this on

3.5.2

RC

https://stackoverflow.com/questions/48723899/maven-
numberformatexception-when-packaging

On Sun, Feb 25, 2018 at 12:53 AM, Dan Tran <dant...@gmail.com> 
wrote:



my build contains 270+ modules using java 8.  The failure found on
windows. Have not tested on Linux  yet

-D

On Sun, Feb 25, 2018 at 12:23 AM, Dan Tran <dant...@gmail.com>

wrote:

Encounter random failure at antrun MOJO + smart builder

here is the error message

[ERROR] Failed to execute goal org.apache.maven.plugins:

maven-antrun-plugin:1.8:run

(work.around.to.clean.up.classes.before.jsonschema.start) on

project

adm-schema: Error executing Ant tasks: For input string: "1;" ->

[Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run
(work.around.to.clean.up.classes.before.jsonschema.start) on

project

adm-schema: Error executing Ant tasks: For input string: "1;"
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.

buildProject

(LifecycleModuleBuilder.java:117)
 at 
io.takari.maven.builder.smart.SmartBuilderImpl.buildProject

(SmartBuilderImpl.java:205)
 at io.takari.maven.builder.smart.SmartBuilderImpl$

ProjectBuildTask.run

(SmartBuilderImpl.java:77)
 at java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:511)
 at java.util.concurrent.FutureTask.run (FutureTask.java:266)
 at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run (Thread.java:748)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error
executing Ant tasks: For input string: "1;"
 at org.apache.maven.plugin.antrun.AntRunMojo.execute
(AntRunMojo.java:347)
 at org.apache.maven.plugin.DefaultBuildPluginManager.

executeMojo

(DefaultBuildPluginManager.java:137)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208

Re: [VOTE] Release Apache Maven 3.5.3

2018-02-27 Thread Guillaume Boué


(Made a mistake and only sent this to Stephen... sorry)

I've found a very small regression, but definitely not a blocker for the 
release I think. When the following is ran:


mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate

There is a spurious "[0m[0m" at the very last line (note: there are 
escape characters before the two square brackets). Doesn't happen with 
3.5.2, the line is empty. (Only tested on Windows).


Also, I didn't reproduce Dan's issue on Windows with the Takari smart 
builder on a single sample project. Maybe the number of modules?


Guillaume


Le 27/02/2018 à 19:01, Dan Tran a écrit :

Hi all,

I believe my usage of antrun is legit to make sure user who is using  mvn
install ( without clean) has a proper clean up before another plugin
execution

   
 org.apache.maven.plugins
 maven-antrun-plugin
 
   
 work.around.to.clean.up.classes.before.jsonschema.start
 generate-sources
 
   run
 
 
   
 
   
 
   
 
   


here is the command to reproduce the antrun issue


   mvn clean install --builder smart -T1.0C -DskipTests


Add  -B to remove the issue but it is not ideal

Only only happens on windows ( i only test with windows and linux)

-D



On Tue, Feb 27, 2018 at 7:44 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


On 27 February 2018 at 14:46, Mirko Friedenhagen 
wrote:


+1 from my side, tested with 10 inhouse projects. Or is this vote

canceled?
Not cancelled yet. Unclear if Dan's issue is something forking maven and
parsing the output... the task name
"work.around.to.clean.up.classes.before.jsonschema.start" sounds like it
could be doing something crazy like that, in which case it is not using -B
when forking maven in Dan's codebase that could be the root cause.



Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Sun, Feb 25, 2018 at 10:14 AM, Dan Tran  wrote:

   correction

found this reference, found on 3.5.2 but I only encounter this on 3.5.3

RC

https://stackoverflow.com/questions/48723899/maven-
numberformatexception-when-packaging


On Sun, Feb 25, 2018 at 1:13 AM, Dan Tran  wrote:


found this reference, found on 3.5.2 but I only encounter this on

3.5.2

RC

https://stackoverflow.com/questions/48723899/maven-
numberformatexception-when-packaging

On Sun, Feb 25, 2018 at 12:53 AM, Dan Tran  wrote:


my build contains 270+ modules using java 8.  The failure found on
windows. Have not tested on Linux  yet

-D

On Sun, Feb 25, 2018 at 12:23 AM, Dan Tran 

wrote:

Encounter random failure at antrun MOJO + smart builder

here is the error message

[ERROR] Failed to execute goal org.apache.maven.plugins:

maven-antrun-plugin:1.8:run

(work.around.to.clean.up.classes.before.jsonschema.start) on

project

adm-schema: Error executing Ant tasks: For input string: "1;" ->

[Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run
(work.around.to.clean.up.classes.before.jsonschema.start) on

project

adm-schema: Error executing Ant tasks: For input string: "1;"
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.

buildProject

(LifecycleModuleBuilder.java:117)
 at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
(SmartBuilderImpl.java:205)
 at io.takari.maven.builder.smart.SmartBuilderImpl$

ProjectBuildTask.run

(SmartBuilderImpl.java:77)
 at java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:511)
 at java.util.concurrent.FutureTask.run (FutureTask.java:266)
 at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run (Thread.java:748)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error
executing Ant tasks: For input string: "1;"
 at org.apache.maven.plugin.antrun.AntRunMojo.execute
(AntRunMojo.java:347)
 at org.apache.maven.plugin.DefaultBuildPluginManager.

executeMojo

(DefaultBuildPluginManager.java:137)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
 at

Re: Question concerning Maven Core

2018-02-16 Thread Guillaume Boué


Hi Karl Heinz,

I may be reading this wrong, but it looks like the class intends to 
print the logs of a concurrent Maven build grouped by segments. That is, 
instead of having interleaved logs of all the plugin executions when 
building with multiple threads, they would be printed in full, logically 
grouped together waiting for the task to complete, until moving to the 
next task and doing the same (which may already have completed by then).


Guillaume


Le 16/02/2018 à 22:09, Karl Heinz Marbaise a écrit :

Hi,

I've stumbled over the following code line in Maven Core:

Class MultiThreadedBuilder:

Line: 94...

    // Currently disabled
    ThreadOutputMuxer muxer = null; // new ThreadOutputMuxer( 
analyzer.getProjectBuilds(), System.out );


Does someone know what intention/idea/purpose is behind 
ThreadOutputMuxer ?


Kind regards
Karl Heinz Marbaise




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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Release Apache Maven Resolver version 1.1.1

2018-02-16 Thread Guillaume Boué


Hi,

+1 tested on multiple projects, and build is OK with JDK 8/9 on 
Windows/Ubuntu.


By the way, I noticed this includes commits for MRESOLVER-9 (db4003a) 
and MNG-6141 (9dbbd06) but both aren't resolved on JIRA. How come? Also, 
perhaps MRESOLVER-28 should be added in the release notes.


Guillaume


Le 15/02/2018 à 20:25, Robert Scholte a écrit :

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12341378=Text 



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



Staging repo:
https://repository.apache.org/content/repositories/maven-1395/
https://repository.apache.org/content/repositories/maven-1395/org/apache/maven/resolver/maven-resolver/1.1.1/maven-resolver-1.1.1-source-release.zip 

https://repository.apache.org/content/repositories/maven-1395/org/apache/maven/resolver/maven-resolver-ant-tasks/1.1.1/maven-resolver-ant-tasks-1.1.1-source-release.zip 



Source release checksum(s):
maven-resolver-1.1.1-source-release.zip   sha1: 
8e98446e93e2810c84257194c67568e069765602
maven-resolver-ant-tasks-1.1.1-source-release.zip sha1: 
5953defeb41258eb47a1d10ce534e9b4bc5b74c4


Staging site:
https://maven.apache.org/resolver-archives/resolver-LATEST/
https://maven.apache.org/resolver-archives/resolver-ant-tasks-LATEST/

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

Vote open for at least 72 hours.

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

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Need for code review and test of branch SUREFIRE-1400 (see Jira ticket)

2017-08-04 Thread Guillaume Boué

This is very nice Tibor! All the ITs of maven-assembly-plugin that were 
failing on my Windows set-up are now running fine. I tested this branch 
both with JDK 7 and 8 on Windows 10.


I also checked that the temporary "surefire" directories located 
in %TEMP% were correctly deleted at the end of the tests. Small note: 
they aren't deleted when Maven is run in debug mode with -X, I think it 
should be noted in "tempDir" javadoc.


Guillaume


Le 03/08/2017 à 15:32, Tibor Digana a écrit :

Hi devs,
Hi Guillaume Boué,

Can you please test this branch on Maven Assembly build and make a code
review? On Windows.

Here we have a commit in branch SUREFIRE-1400, see [1].

The point of this fix is to start Surefire Booter JAR from
${java.io.tmpdir}/surefire-***/surefire*.jar
instead of target/surefire/surefire*.jar

The base dir ${user.dir} in urser's tests did not change.

[1]:
https://git1-us-west.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=7a6f3e6c829e86aba663de4f90963070666d2654

Thx.




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Release Apache Maven Invoker Plugin version 3.0.1 / Apache Maven Script Interpreter 1.2 (take 2)

2017-07-19 Thread Guillaume Boué


+1 from me too (non-binding)


Le 17/07/2017 à 13:08, Olivier Lamy a écrit :

Hi,
I'd like to release Apache Maven Invoker Plugin version 3.0.1 and Apache
Maven Script Interpreter 1.2.

We fixed 2 issues for Script interpreter:
https://s.apache.org/MSCRIPT-INTERPRETER-JIRA-1.2
We fixed 4 issues for Invoker plugin:
https://s.apache.org/MINVOKER-JIRA-3.0.1

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

Source releases:
*
https://repository.apache.org/content/repositories/maven-1346/org/apache/maven/plugins/maven-invoker-plugin/3.0.1/maven-invoker-plugin-3.0.1-source-release.zip
*
https://repository.apache.org/content/repositories/maven-1346/org/apache/maven/shared/maven-script-interpreter/1.2/maven-script-interpreter-1.2-source-release.zip

Staging sites:
http://maven.apache.org/components/plugins-archives/maven-invoker-plugin-LATEST/
http://maven.apache.org/components/shared-archives/maven-script-interpreter-LATEST/

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

Vote open for at least 72 hours.

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

My +1

Cheers



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Release Apache Maven Invoker Plugin version 3.0.1 / Apache Maven Script Interpreter 1.2

2017-07-15 Thread Guillaume Boué


Hi,

I have a question about the post-build invocation change in 
MINVOKER-223. With 3.0.0, the post-build script is executed only once, 
after all Maven invocations (defined for example with invoker.goals.1, 
invoker.goals.2, etc.) are performed successfully. Now, with the fix 
made in MINVOKER-223, the post-build script is executed after each Maven 
invocation, whether it resulted in a success or a failure. As a 
consequence, the post-build script will be ran multiple times, after 
each successful build, instead of after all successful builds.


The fact that the post-build script is executed in case of some 
invocation failure is OK. But I wonder if the behavioral change 
concerning successful builds was also intended. It is contrary to the 
pre-build script, which is ran only once, before all invocations. I 
think the post-build script should be executed after either a failed 
build, or all successful builds.


An example of ITs which rely on the previous behavior are 
"dependencySource-2" and "dependencySource-4" of maven-javadoc-plugin: 
they pass with 3.0.0, but fail with staged 3.0.1.


Guillaume


Le 13/07/2017 à 08:43, Olivier Lamy a écrit :

Hi,
I'd like to release Apache Maven Invoker Plugin version 3.0.1 and Apache
Maven Script Interpreter 1.2.

We fixed 2 issues for Script interpreter:
https://s.apache.org/MSCRIPT-INTERPRETER-JIRA-1.2
We fixed 4 issues for Invoker plugin:
https://s.apache.org/MINVOKER-JIRA-3.0.1

Staging repo: https://repository.apache.org/content/repositories/maven-1345/
Source releases:
*
https://repository.apache.org/content/repositories/maven-1345/org/apache/maven/plugins/maven-invoker-plugin/3.0.1/maven-invoker-plugin-3.0.1-source-release.zip
*
https://repository.apache.org/content/repositories/maven-1345/org/apache/maven/shared/maven-script-interpreter/1.2/maven-script-interpreter-1.2-source-release.zip

Staging sites:
http://maven.apache.org/components/plugins-archives/maven-invoker-plugin-LATEST/
http://maven.apache.org/components/shared-archives/maven-script-interpreter-LATEST/

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

Vote open for at least 72 hours.

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

My +1

Cheers



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [RESULT] [VOTE] Release Apache Maven Enforcer version 1.4.2

2017-06-26 Thread Guillaume Boué

Yes, it should work with Java 9, I ran all the integration tests of the 
plugin with 9ea175 without any issues. This error is already solved for 
3.0.0 by upgrading to commons-lang3.


Guillaume


Le 26/06/2017 à 13:53, Mark Derricutt a écrit :


On 23 Jun 2017, at 7:48, Stephen Connolly wrote:

Ok, I'm dropping this and respinning as 3.0.0

Does 1.4.2/3.0.0 work with Java 9?

I was just testing a build and hit:

Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
com.smxemail.tiles:com.smxemail.tiles.enforcements:3.0.64::enforce-versions 
of goal org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce 
failed: An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce: 
java.lang.ExceptionInInitializerError: null




|at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:181) 
... 21 more |


Caused by: java.lang.ExceptionInInitializerError
at 
org.apache.maven.plugins.enforcer.RequireJavaVersion.execute(RequireJavaVersion.java:52)
at 
org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:193)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

... 21 more
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, 
length 1

at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3116)
at java.base/java.lang.String.substring(String.java:1885)
at 
org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1122)

at org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
... 24 more

I guess the version of commons-lang used doesn't like the new Java 9 
version string.




"The ease with which a change can be implemented has no relevance at 
all to whether it is the right change for the (Java) Platform for all 
time." — Mark Reinhold.


Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-26 Thread Guillaume Boué

From what I tested, ServiceLoader doesn't allow a custom classloading 
scheme for named modules (step 1 of 
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-). 
Its own scheme relies on checking modules loaded by the given 
classloader, then its parents (with a particular rule with regard to 
module layers), and it doesn't look like customizable. It also seems 
that existing META-INF/services declarations, but located in named 
modules, are ignored. For unnamed modules, or when something other than 
ServiceLoader is used, everything is apparently the same as before in 
Java 9.


This is why I think a plugin wouldn't be able to locate providers in a 
module loaded by Maven core extension classloader: parent of the plugin 
realm is bootstrap classloader directly.


Guillaume


Le 26/06/2017 à 01:45, Igor Fedorenko a écrit :

Can you explain little more why plugins won't see classes loaded by
maven core or maven core extensions classloaders? This is implemented in
classwords and I was under impression that java9 still allowed custom
classloading schemes like what we do or like what OSGi does.




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-25 Thread Guillaume Boué



Le 25/06/2017 à 22:03, Chas Honton a écrit :

Under what circumstances would a plugin not want the platform classloader?

Chas


Thinking about this more, with the current situation, it actually means 
that potential providers, located in named modules loaded for example by 
Maven core classloader or extension classloader, will not be available 
to plugins using ServiceLoader. So this is bigger than platform 
classloader. As Robert said, I think there needs to be a way for plugins 
to know about modules.


Reading more into the docs, this may be possible using a ModuleLayer. 
Each plugin would have its own module layer composed of modules found in 
its dependencies. Their parent would be a module layer associated to 
Maven core, and its parent would be the boot layer. This would solve the 
ServiceLoader issue for named modules in a plugin realm, since it would 
locate providers in all modules in the module layer of the plugin, and 
then do the same for their parents, up to the boot layer. However, for 
it to work, I'm not sure if this implies that everything be made modular 
(plugins and Maven itself). I will try to do some testing on this.


Guillaume




On Jun 25, 2017, at 12:40 PM, Robert Scholte <rfscho...@apache.org> wrote:

Hi Guillaume,

I don't know all the details about the Platform classloader, but it has been 
introduced with a reason.
So I don't think we should switch to it by default. I think the plugin is well 
aware which classloaders / modules it wants to use (it should be), so I think 
we need to find a mechanism for plugins to select their classloaders and 
modules.

thanks,
Robert


On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué <gb...@apache.org> wrote:

Hi,

With the introduction of modules in JDK 9, there were changes with
regard to how classloading works, and this impacts class realms created
in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
realm is null, which represents the bootstrap classloader. In JDK 9, the
change is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


-
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

Loading providers in named modules with ServiceLoader using a plugin class realm

2017-06-25 Thread Guillaume Boué


Hi,

With the introduction of modules in JDK 9, there were changes with
regard to how classloading works, and this impacts class realms created
in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
realm is null, which represents the bootstrap classloader. In JDK 9, the
change is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Aw: Re: svn commit: r1799189 - /maven/plugins/trunk/maven-assembly-plugin/pom.xml

2017-06-20 Thread Guillaume Boué

Yes, 3.0.0 is selected during conflict resolution. And this is part of 
the issue: some classes of plexus-io 2.7.1, on which plexus-archiver 3.4 
depends on, were removed in 3.0.0. So they are not present within the 
resolved dependencies because 2.7.1 was (rightfully) omitted.


Did you run them on a Linux platform? I couldn't reproduce it from Windows.

Guillaume


Le 20/06/2017 à 13:46, Michael Osipov a écrit :

How is this possible? I ran the UTs twice. Did you check the dep tree? 3.0.0 
should have been mediated.


Gesendet: Montag, 19. Juni 2017 um 22:13 Uhr
Von: "Guillaume Boué" <gb...@apache.org>
An: dev@maven.apache.org, "Michael Osipov" <micha...@apache.org>
Betreff: Re: svn commit: r1799189 - 
/maven/plugins/trunk/maven-assembly-plugin/pom.xml

Hi,

The unit test
AssemblyProxyArchiverTest#addDirectory_NoPerms_CallAcceptFilesOnlyOnce
is failing with this commit, and I can reproduce the failure on Ubuntu
with OpenJDK 7. It turns out to be coming from conflicting plexus-io
dependencies:

- The plugin now depends on a JDK 7 version of plexus-io (3.0.0).
- But the plugin also depends on plexus-archiver 3.4, which depends on a
JDK 6 version plexus-io (2.7.1).

Some plexus-io classes that were used reflectively in plexus-archiver
(when JDK 7 is used), like Java7Reflector, are thus missing now, since
they were removed in plexus-io 3.0.0. This explains the
NoClassDefFoundError in the unit test. I noticed Plexus Archiver trunk
has moved to JDK 7 also, so we'll need to upgrade to plexus-archiver 3.5
as soon as possible.

Guillaume


Le 19/06/2017 à 14:18, micha...@apache.org a écrit :

Author: michaelo
Date: Mon Jun 19 12:18:42 2017
New Revision: 1799189

URL: http://svn.apache.org/viewvc?rev=1799189=rev
Log:
[MASSEMBLY-859] Upgrade to Plexus IO 3.0.0

This closes #117

Modified:
  maven/plugins/trunk/maven-assembly-plugin/pom.xml

Modified: maven/plugins/trunk/maven-assembly-plugin/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/pom.xml?rev=1799189=1799188=1799189=diff
==
--- maven/plugins/trunk/maven-assembly-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-assembly-plugin/pom.xml Mon Jun 19 12:18:42 2017
@@ -157,7 +157,7 @@ under the License.
   
 org.codehaus.plexus
 plexus-io
-  2.7.1
+  3.0.0
   
   
 org.apache.maven




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


-
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: svn commit: r1799189 - /maven/plugins/trunk/maven-assembly-plugin/pom.xml

2017-06-19 Thread Guillaume Boué


Hi,

The unit test 
AssemblyProxyArchiverTest#addDirectory_NoPerms_CallAcceptFilesOnlyOnce 
is failing with this commit, and I can reproduce the failure on Ubuntu 
with OpenJDK 7. It turns out to be coming from conflicting plexus-io 
dependencies:


- The plugin now depends on a JDK 7 version of plexus-io (3.0.0).
- But the plugin also depends on plexus-archiver 3.4, which depends on a 
JDK 6 version plexus-io (2.7.1).


Some plexus-io classes that were used reflectively in plexus-archiver 
(when JDK 7 is used), like Java7Reflector, are thus missing now, since 
they were removed in plexus-io 3.0.0. This explains the 
NoClassDefFoundError in the unit test. I noticed Plexus Archiver trunk 
has moved to JDK 7 also, so we'll need to upgrade to plexus-archiver 3.5 
as soon as possible.


Guillaume


Le 19/06/2017 à 14:18, micha...@apache.org a écrit :

Author: michaelo
Date: Mon Jun 19 12:18:42 2017
New Revision: 1799189

URL: http://svn.apache.org/viewvc?rev=1799189=rev
Log:
[MASSEMBLY-859] Upgrade to Plexus IO 3.0.0

This closes #117

Modified:
 maven/plugins/trunk/maven-assembly-plugin/pom.xml

Modified: maven/plugins/trunk/maven-assembly-plugin/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-assembly-plugin/pom.xml?rev=1799189=1799188=1799189=diff
==
--- maven/plugins/trunk/maven-assembly-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-assembly-plugin/pom.xml Mon Jun 19 12:18:42 2017
@@ -157,7 +157,7 @@ under the License.
  
org.codehaus.plexus
plexus-io
-  2.7.1
+  3.0.0
  
  
org.apache.maven





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

2017-06-17 Thread Guillaume Boué


Hi,

There was a link to Stephen Colebourne's blog about naming modules: 
http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html. So what 
about "org.apache.maven.plugins.site" for the module name?


But I don't think it is necessary to make the plugin modular. The error 
means that code launched by the Site plugin is trying to access the 
private "File(String,File)" constructor. Can you turn on stacktraces to 
see what part of the code is doing that? We can perhaps fix the deep 
reflection usage and only rely on public API.


I've also noticed MSITE-789 about a similar error but it was in Findbugs 
code.


Guillaume

Le 17/06/2017 à 15:54, Karl Heinz Marbaise a écrit :

Hi,
currently I'm a bit on testing JDK 9 EA+174..and found the following 
issue:


[INFO]
[INFO] <<< maven-plugin-plugin:3.4:report < process-classes @ 
maven-install-plugin <<<

[INFO]
[INFO] 'process-classes' forked phase execution for 
maven-plugin-plugin:report report preparation done
[INFO] configuring report plugin 
org.apache.maven.plugins:maven-invoker-plugin:2.0.0
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 14.810 s
[INFO] Finished at: 2017-06-17T15:47:38+02:00
[INFO] Final Memory: 57M/256M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on 
project maven-install-plugin: Execution default-site of goal 
org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to 
make private java.io.File(java.lang.String,java.io.File) accessible: 
module java.base does not "opens java.io" to unnamed module @44b002c9 
-> [Help 1]

[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with 
the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]

So based on what I understood at the moment is that the 
maven-site-plugin needs to have a module-info.java file


The first thing which came into my mind was how-to name the module?

module org.apache.maven.plugins.maven.site.plugin {
  requires java.io;
  requires java.base;
}

Do we have any kind of general naming convention for the plugins?

Kind regards
Karl Heinz Marbaise

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [ANN] First call to round up issues for 3.5.1

2017-06-10 Thread Guillaume Boué


Hi,

I'd like to propose MNG-6240 to be added in 3.5.1.

Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/e76e217a
IT:
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/commit/a162291e
Successful Jenkins build:
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6240/

It fixes a regression introduced in the renaming of
maven-aether-provider to maven-resolver-provider in 3.5.0. Maven Core
only exports the org.apache.maven:maven-resolver-provider artifact for
plugins, while it should also export
org.apache.maven:maven-aether-provider for compatibility with plugins
depending on older Maven versions.

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: maven-compiler-plugin + default-value for illegal-access

2017-06-10 Thread Guillaume Boué

Wouldn't illegal-access be a run-time 'java' flag only, and not a 
compile-time 'javac' one?


Le 10/06/2017 à 19:46, Robert Scholte a écrit :

Hi all,

below is the proposal for the flag "illegal-access" in Java 9.
TLDR; it controls if the compiler should break the build when making 
illegal usage of internal APIs.


With Java 9 its default value will be 'permit' (not as strict as the 
original proposal), but its default value WILL change in a future 
version.


IMHO from a Maven point of view the result of the compiled code should 
always be the same no matter the JDK version. For the same reason we 
gave source/target a default value. However, there's a small 
difference: in case of a stricter value with a next JDK, there won't 
be any result at all so you would notice the difference immediately.


The compiler does display a warning in case it detects illegal-access.

We have a couple of options:
- do nothing
- give illegal-access a default value in case source/target/release >= 9
- introduce failOnIllegalAccess with a default value (true?false?)
- ...

WDYT?

Robert

--- Forwarded message ---
From: mark.reinh...@oracle.com
To: jigsaw-...@openjdk.java.net
Cc:
Subject: Proposal (revised): Allow illegal access to internal APIs by 
default in JDK 9

Date: Mon, 05 Jun 2017 20:45:27 +0200

(Thanks for all the feedback on the initial proposal [1].  Here's a
  revised version, which incorporates some of the suggestions received 
and

  includes a bit more advice.  An implementation is already available for
  testing in the Jigsaw EA builds [2].  Further comments welcome!)

Over time, as we've gotten closer and closer to the JDK 9 GA date, more
and more developers have begun paying attention to the actual changes in
this release.  The strong encapsulation of JDK-internal APIs has, in
particular, triggered many worried expressions of concern that code that
works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
warning of this change was given at run time in JDK 8.

To help the entire ecosystem migrate to the modular Java platform at a
more relaxed pace I hereby propose to allow illegal-access operations to
internal APIs from code on the class path by default in JDK 9, and to
disallow them in a future release.  This will enable smoother application
migration in the near term, yet still enable and motivate the maintainers
of libraries and frameworks that use JDK-internal APIs to fix their code
to use proper exported APIs.

New command-line option: `--illegal-access`
---

The recently-introduced `--permit-illegal-access` option [3] will be
replaced by a more-general option, `--illegal-access`.  This option takes
a single keyword parameter to specify a mode of operation, as follows:

   `--illegal-access=permit`

 This mode opens each package in each module in the run-time image to
 code in all unnamed modules, i.e., code on the class path, if that
 package existed in JDK 8.  This enables both static access, i.e., by
 compiled bytecode, and deep reflective access, via the platform's
 various reflection APIs.

 The first reflective-access operation to any such package causes a
 warning to be issued, but no warnings are issued after that point.
 This single warning describes how to enable further warnings.

 This mode will be the default for JDK 9.  It will be removed in a
 future release.

   `--illegal-access=warn`

 This mode is identical to `permit` except that a warning message is
 issued for each illegal reflective-access operation.  This is 
roughly

 equivalent to the current `--permit-illegal-access` option.

   `--illegal-access=debug`

 This mode is identical to `warn` except both a warning message and a
 stack trace are issued for each illegal reflective-access operation.
 This is roughly equivalent to combining `--permit-illegal-access`
 with `-Dsun.reflect.debugModuleAccessChecks`.

   `--illegal-access=deny`

 This mode disables all illegal-access operations except for those
 enabled by other command-line options, e.g., `--add-opens`.

 This mode will become the default in a future release.

When `deny` becomes the default mode then `permit` will likely remain
supported for at least one release, so that developers can continue to
migrate their code.  The `permit`, `warn`, and `debug` modes will, over
time, be removed, as will the `--illegal-access` option itself. (For
launch-script compatibility the unsupported modes will most likely just
be ignored, after issuing a warning to that effect.)

How to prepare for the future
-

The default mode, `--illegal-access=permit`, is intended to make you
aware when you have code on the class path that reflectively accesses
some JDK-internal API at least once.  To learn about all such accesses
you can use the `warn` or `debug` modes.  For each library or framework
on the class path that requires

Wrong library.jansi.path in master 3.5.1 startup scripts

2017-06-09 Thread Guillaume Boué


Hi,

The current mvn startup script sets the "library.jansi.path" system
property to "${MAVEN_HOME}/jansi-native". But instead, as said in
MNG-6186, this should be "${MAVEN_HOME}/lib/jansi-native". This also
affects the Windows script. The result is that JAnsi is creating a
jansi-native directory in Maven home and adding new so/dll files in it
for every mvn invocation. 3.5.0 is correct, this is a small in-version
regression.

Should this fix be committed to a new branch, or maybe directly to
master? I wonder if it's feasible to add an integration test that checks
that Maven home is the same before and after some build.

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Artifact "has been attached with deprecated code" warning

2017-06-06 Thread Guillaume Boué

Thanks for confirming this Karl. So in this case, I think that part of 
the code in maven-artifact-transfer can be safely deleted (calling 
setRepository and catching an exception). The repository to deploy to is 
set on the main artifact and, even if it didn't throw an exception, 
there would be no need to set the same again for its attached artifacts, 
right?


What do you think?

Guillaume


Le 06/06/2017 à 22:53, Karl Heinz Marbaise a écrit :

Hi,

On 06/06/17 22:38, Guillaume Boué wrote:
In the new API ProjectDeployer (in maven-artifact-transfer), I 
noticed the default implementation raises a warning in the case that 
it cannot set the repository to an attached artifact:


Yes this code has been "stolen" from the maven-deploy-plugin which 
means we need to adapt the implementation to get it correctly working...


We don't have reached 1.0.0 release so we can change it ...and fix the 
other plugins which already used the maven-artifact-transfer...


So first changing the maven-artifact-transfer component..and 
afterwards going forward for maven-deploy-plugin and 
maven-install-plugin...


Kind regards
Karl Heinz Marbaise



https://github.com/apache/maven-shared/blob/f45e7ad855acfb5d29e7c2b79c6ae57729602133/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/deploy/internal/DefaultProjectDeployer.java#L129-L138 



I'm not sure I understand this warning correctly. It seems to come 
from the fact that an attached artifact is represented by an instance 
of the AttachArtifact class, that is deprecated with Maven 3, and 
this class always throws an exception when trying to set a repository 
to it. But with all current Maven 3 versions, the MavenProjectHelper, 
which is used to attach artifact to a project, relies on this class 
(https://github.com/apache/maven/blob/maven-3.5.0/maven-core/src/main/java/org/apache/maven/project/DefaultMavenProjectHelper.java#L60), 
and so this warning looks inevitable.


If so, why is the warning pointing to "responsible plugin" when this 
comes from maven-core itself? And, if I'm not mistaken, should this 
really be a warning when the user doesn't seem to be able to do 
anything about it?


I noticed it when using latest 3.0.0-SNAPSHOT of the Deploy Plugin: 
the warning is raised for every attach artifact that is deployed.


Thanks,
Guillaume


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Artifact "has been attached with deprecated code" warning

2017-06-06 Thread Guillaume Boué


In the new API ProjectDeployer (in maven-artifact-transfer), I noticed
the default implementation raises a warning in the case that it cannot
set the repository to an attached artifact:

https://github.com/apache/maven-shared/blob/f45e7ad855acfb5d29e7c2b79c6ae57729602133/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/deploy/internal/DefaultProjectDeployer.java#L129-L138

I'm not sure I understand this warning correctly. It seems to come from
the fact that an attached artifact is represented by an instance of the
AttachArtifact class, that is deprecated with Maven 3, and this class
always throws an exception when trying to set a repository to it. But
with all current Maven 3 versions, the MavenProjectHelper, which is used
to attach artifact to a project, relies on this class
(https://github.com/apache/maven/blob/maven-3.5.0/maven-core/src/main/java/org/apache/maven/project/DefaultMavenProjectHelper.java#L60),
and so this warning looks inevitable.

If so, why is the warning pointing to "responsible plugin" when this
comes from maven-core itself? And, if I'm not mistaken, should this
really be a warning when the user doesn't seem to be able to do anything
about it?

I noticed it when using latest 3.0.0-SNAPSHOT of the Deploy Plugin: the
warning is raised for every attach artifact that is deployed.

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Version 3.0.0 on JIRA for MANTRUN

2017-06-06 Thread Guillaume Boué


Hi guys,

The AntRun plugin was migrated to Maven 3 in svn.apache.org/r1796930.
Can someone rename the 3.0 version that currently exists on JIRA to
3.0.0? I can then start closing a bunch of issues with this fix version.

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Code review. Please approve new branches.

2017-06-03 Thread Guillaume Boué

I've ran successfully the ITs on FreeBSD under JDK 7 and 8, so +1 from me.

Would it make sense to add an IT for SUREFIRE-1376?

Guillaume

Le 03/06/2017 à 13:53, Tibor Digana a écrit :

Hi Michael,

I have pushed branch SUREFIRE-1380_2, see [1], and separated the previous
ticket SUREFIRE-1380 to two: SUREFIRE-1380 and SUREFIRE-1381.

The branch SUREFIRE-1380_2 is for Jira SUREFIRE-1380.
[1]:
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=shortlog;h=refs/heads/SUREFIRE-1380_2

On Sat, Jun 3, 2017 at 12:54 PM, Michael Osipov wrote:

Am 2017-06-03 um 12:36 schrieb Tibor Digana:

Michael, I will split SUREFIRE-1380 in two tickets on tomorrow evening.
Another flush is necessary because the method InputStream.read() is called
in a loop and the flush should be called after last byte. If another
thread
marks the stream to be closed asynchronously, then the bytes can be lost.
Therefore flushing if stream has been closed in the intermediate time
between these two threads. Maybe not clear to understand, we can have a
look deeper.

Please add this profound description to the ticket itself. It will help to
understand the motivation.

On Sat, Jun 3, 2017 at 12:31 PM, Tibor Digana
wrote:

Am 2017-06-03 um 10:56 schrieb Tibor Digana:

I have added a new branch with small change only, SUREFIRE-1380.

https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git
;a=shortlog;h=refs/heads/SUREFIRE-1380

I am not happy with this: you mix two different taks in one issue,
refactoring and flush. There is no explanation why another flush is
necessary or what the benefit will be, i.e., don't fix things which
aren't
broken.

WDYT?

Michael

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

--
Cheers
Tibor

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

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

Re: New Branch SUREFIRE-1342

2017-03-18 Thread Guillaume Boué

This is probably the problem, I don't have any dump files. I've attached 
the log.txt files for both tests.


It doesn't seem to be related to the branch though. They work fine in 
2.19.1 and also fail with current master.



Le 18/03/2017 à 21:57, Tibor Digana a écrit :

Please send the dump files from
surefire-integration-tests/target/Surefire141PluggableProvidersIT_invokeRuntimeException
surefire-integration-tests/target/Surefire141PluggableProvidersIT_
invokeReporterException

They must exist in both.

This issue is also concurrency issue but since JVM exit code  is 1, the ACK
is not applicable.

I am thinking about two assertions statements instead of current one.

On Sat, Mar 18, 2017 at 8:49 PM, Guillaume Boué <gb...@apache.org> wrote:


So with JDK 8 (64 bit where possible), the tests are all passing on the
systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64), and Windows
10 x64.

I have two tests consistently in error with OpenJDK 7 (and Maven
3.5.0-alpha-1), at least on Ubuntu:

Failed tests:
invokeRuntimeException(org.apache.maven.surefire.its.jiras.S
urefire141PluggableProvidersIT): expecting non-empty, but it was empty
invokeReporterException(org.apache.maven.surefire.its.jiras.
Surefire141PluggableProvidersIT): expecting non-empty, but it was empty

They are also failing when ran individually if passing
-Dit.test=Surefire141PluggableProvidersIT to the Maven command.

I will test with a JDK 6 right now.


Le 17/03/2017 à 06:12, Tibor Digana a écrit :


Yes, there are a lot of tests 1200 altogether. For instance I have 4 Cores
of CPU and the build takes 45 minutes. In your case 1 Core of Virtual CPU
which makes the difference. Tuning of JVM is also important. Not too much
and not too less of Xmx cca 700 MB and the same or more for permanent part
of memory. I think JVM does not run in server mode if RAM < 2GiB even if
you have x64.

On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué <gb...@apache.org>
wrote:

Yes, I finished running the tests multiple times on FreeBSD with Maven

3.5.0-alpha-1, and they are all passing! The tests were however painfully
slow (more than 4 hours), it might be an issue with my VM (64 bits, only
has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
same characteristics, but on Ubuntu.

I will be running them again on Windows and Ubuntu with JDK 7 and 8 over
the next few days.

Guillaume



Le 15/03/2017 à 21:40, Tibor Digana a écrit :

Hi Guillaume Boué,

Have you found a spare time to test the branch?

Cheers
Tibor

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué <gb...@apache.org>
wrote:

Hi,


I finished setting up a FreeBSD VM with a couple of Maven and JDK
versions, so I'll be testing this extensively (on Ubuntu as well).
Thanks
for the work!

Guillaume



Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,


The new branch SUREFIRE-1342 solves an issue when entire testset
completed
however the surefire's forked JVM  finished printing serious issue. We
know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent
"bye"
event to the Maven process via stdout but Maven process has not
drained
shared memory yet and Maven process was therefore slower to receive
the
event than the forked process which exited. Due to the "bye" event was
not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received
by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor


---


L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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



---

L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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








---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] 
[INFO] -

Re: New Branch SUREFIRE-1342

2017-03-18 Thread Guillaume Boué

Le 18/03/2017 à 20:49, Guillaume Boué a écrit :
So with JDK 8 (64 bit where possible), the tests are all passing on
the systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64),
and Windows 10 x64.

I have two tests consistently in error with OpenJDK 7 (and Maven
3.5.0-alpha-1), at least on Ubuntu:

Failed tests:
invokeRuntimeException(org.apache.maven.surefire.its.jiras.Surefire141PluggableProvidersIT):
expecting non-empty, but it was empty
invokeReporterException(org.apache.maven.surefire.its.jiras.Surefire141PluggableProvidersIT):
expecting non-empty, but it was empty

They are also failing when ran individually if passing
-Dit.test=Surefire141PluggableProvidersIT to the Maven command.

I will test with a JDK 6 right now.

Same errors with Oracle JDK 6, and Maven 3.2.5.

Le 17/03/2017 à 06:12, Tibor Digana a écrit :
Yes, there are a lot of tests 1200 altogether. For instance I have 4
Cores
of CPU and the build takes 45 minutes. In your case 1 Core of Virtual
CPU
which makes the difference. Tuning of JVM is also important. Not too
much
and not too less of Xmx cca 700 MB and the same or more for permanent
part

of memory. I think JVM does not run in server mode if RAM < 2GiB even if
you have x64.

On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué <gb...@apache.org>
wrote:

has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
same characteristics, but on Ubuntu.

I will be running them again on Windows and Ubuntu with JDK 7 and 8
over

the next few days.

Guillaume

Le 15/03/2017 à 21:40, Tibor Digana a écrit :

Hi Guillaume Boué,

Have you found a spare time to test the branch?

Cheers
Tibor

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué <gb...@apache.org>
wrote:

Hi,

I finished setting up a FreeBSD VM with a couple of Maven and JDK
versions, so I'll be testing this extensively (on Ubuntu as well).
Thanks

for the work!

Guillaume

Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset
completed
however the surefire's forked JVM finished printing serious
issue. We

know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM
crash or

System.exit called ?

The problem is solved in the branch and ready to be tested.

not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been
received

by
Maven process. The shared memory is drained directly by Maven
process.

Cheers
Tibor

---
L'absence de virus dans ce courrier électronique a été vérifiée
par le

logiciel antivirus Avast.
https://www.avast.com/antivirus

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.

https://www.avast.com/antivirus

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

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

Re: New Branch SUREFIRE-1342

2017-03-18 Thread Guillaume Boué

So with JDK 8 (64 bit where possible), the tests are all passing on the
systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64), and
Windows 10 x64.

I have two tests consistently in error with OpenJDK 7 (and Maven
3.5.0-alpha-1), at least on Ubuntu:

They are also failing when ran individually if passing
-Dit.test=Surefire141PluggableProvidersIT to the Maven command.

I will test with a JDK 6 right now.

Le 17/03/2017 à 06:12, Tibor Digana a écrit :

Yes, there are a lot of tests 1200 altogether. For instance I have 4 Cores
of CPU and the build takes 45 minutes. In your case 1 Core of Virtual CPU
which makes the difference. Tuning of JVM is also important. Not too much
and not too less of Xmx cca 700 MB and the same or more for permanent part
of memory. I think JVM does not run in server mode if RAM < 2GiB even if
you have x64.

On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué <gb...@apache.org> wrote:

Yes, I finished running the tests multiple times on FreeBSD with Maven
3.5.0-alpha-1, and they are all passing! The tests were however painfully
slow (more than 4 hours), it might be an issue with my VM (64 bits, only
has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
same characteristics, but on Ubuntu.

I will be running them again on Windows and Ubuntu with JDK 7 and 8 over
the next few days.

Guillaume

Le 15/03/2017 à 21:40, Tibor Digana a écrit :

Hi Guillaume Boué,

Have you found a spare time to test the branch?

Cheers
Tibor

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué <gb...@apache.org>
wrote:

Hi,

I finished setting up a FreeBSD VM with a couple of Maven and JDK
versions, so I'll be testing this extensively (on Ubuntu as well). Thanks
for the work!

Guillaume

Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset
completed
however the surefire's forked JVM finished printing serious issue. We
know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?

The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent "bye"
event to the Maven process via stdout but Maven process has not drained
shared memory yet and Maven process was therefore slower to receive the
event than the forked process which exited. Due to the "bye" event was
not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received
by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor

---

L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

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

Re: New Branch SUREFIRE-1342

2017-03-16 Thread Guillaume Boué

Yes, I finished running the tests multiple times on FreeBSD with Maven 
3.5.0-alpha-1, and they are all passing! The tests were however 
painfully slow (more than 4 hours), it might be an issue with my VM (64 
bits, only has 1 Go of RAM and 1 vCPU), I'll see how much time it takes 
with those same characteristics, but on Ubuntu.


I will be running them again on Windows and Ubuntu with JDK 7 and 8 over 
the next few days.


Guillaume


Le 15/03/2017 à 21:40, Tibor Digana a écrit :

Hi Guillaume Boué,

Have you found a spare time to test the branch?

Cheers
Tibor

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué <gb...@apache.org> wrote:


Hi,

I finished setting up a FreeBSD VM with a couple of Maven and JDK
versions, so I'll be testing this extensively (on Ubuntu as well). Thanks
for the work!

Guillaume



Le 13/03/2017 à 10:46, Tibor Digana a écrit :


Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset completed
however the surefire's forked JVM  finished printing serious issue. We
know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent "bye"
event to the Maven process via stdout but Maven process has not drained
shared memory yet and Maven process was therefore slower to receive the
event than the forked process which exited. Due to the "bye" event was not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor



---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [ANN] GitPubSub multi-branch notification now working on builds.apache.org

2017-03-13 Thread Guillaume Boué


How does this play with pull requests on GitHub?

Guillaume


Le 12/03/2017 à 09:59, Stephen Connolly a écrit :

My weekend project: https://github.com/stephenc/asf-gitpubsub-jenkins-plugin
was a success

(Need to find a home for it at the ASF (as it doesn't make sense at Jenkins
/ outside of ASF)

Now when you push a change to maven.git the branch / commit should trigger
a build within seconds.

There are still some fine-tunings to further optimize the process, but that
should shave off the average 7.5 minutes / max 15 minutes we had to wait as
well as significantly reducing the load on the ASF infra.

This same GitPubSub is available to any multibranch based project running
off Git hosted on ASF hardware, so if we add Jenkinsfile to surefire, etc
they will get it too

(Next project is getting better email notification and JIRA integration for
pipeline jobs)

-Stephen




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: New Branch SUREFIRE-1342

2017-03-13 Thread Guillaume Boué


Hi,

I finished setting up a FreeBSD VM with a couple of Maven and JDK 
versions, so I'll be testing this extensively (on Ubuntu as well). 
Thanks for the work!


Guillaume


Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset completed
however the surefire's forked JVM  finished printing serious issue. We know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent "bye"
event to the Maven process via stdout but Maven process has not drained
shared memory yet and Maven process was therefore slower to receive the
event than the forked process which exited. Due to the "bye" event was not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [DISCUSS] Retrospective on Maven 3.5.0-alpha-1

2017-03-13 Thread Guillaume Boué


What is working well:

1. Despite the mess that resulted in the birth of 3.5.0, the project was 
set back on track successfully.
2. There is good feedback on the version, which sets up solid grounds 
for the future.

3. Not the only one for this point but... colorized logging is truly great!

What is not working well:

1. We don't have a proper testing protocol (locally before Jenkins, 
which OS, which JDK versions...)
2. Still lacking some discussions, notably on the issues that sparked 
the reset.
3. There are still a lot of untriaged JIRA issues, for the core, the 
plugins or other components. We might need a plan on how to handle them.


Guillaume


Le 11/03/2017 à 22:56, Stephen Connolly a écrit :

Hi all,

I think it is a good thing if we take stock of where we are and how we are
doing. I would really appreciate if everyone could take a few minutes to
respond with their top three of two areas:

* What is working well

* What is not working well

I'll consolidate the responses after 72h and see if there are any themes
that can be identified

On the stuff that is not working well, I'll try and pick the three most
popular themes, we can then have a round of discussion on those three
themes to see if anyone has any ideas to improve those aspects of how we
work and hopefully we can have some votes to change things for the better.

By the way, this is open to anyone in any way what so ever involved with
the Maven 3.5.0-alpha-1 effort (assuming you are paying attention to the
dev list ;-) )

Thanks in advance for your time,

-Stephen

P.S. As alpha-2 is near, I'll probably wait until after 3.5.0 before I try
this again (assuming people like this idea)




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

2017-02-27 Thread Guillaume Boué


+1 from me too

Tested with some Tycho builds of Spring and it worked fine. Also tested 
on FreeBSD / Ubuntu / Windows without issues.


Le 27/02/2017 à 19:11, Hervé BOUTEMY a écrit :

I already voted, but I'll redo:

+1

tested with many builds: it works as well as I expected (near a RC confidence)
Let's fix the identified little glitches, and we'll have our 3.5.0 final :)

Regards,

Hervé

Le lundi 27 février 2017, 14:42:12 CET Stephen Connolly a écrit :

Hervé, Robert you have commented but I do not see a vote cast. I believe I
have 3 binding votes, but as one of those is mine I would be more
comfortable with some more

On 23 February 2017 at 16:10, Stephen Connolly <

stephen.alan.conno...@gmail.com> wrote:

Hi,

We solved 65 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12316922=12339664=Text

There are still a couple of issues left in JIRA for 3.5.0, but I do not
think any of those are blocking an alpha release:
https://issues.apache.org/jira/issues/?jql=project%20%
3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%
20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%
20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

In addition there are 315 issues left in JIRA for Maven core:
https://issues.apache.org/jira/issues/?jql=project%20%
3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

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

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-> > 
1324/org/apache/maven/apache-maven/3.5.0-alpha-1/

Specifically the zip, tarball, and source archives can be found here:
https://repository.apache.org/content/repositories/maven-> > 
1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
maven-3.5.0-alpha-1-bin.zip
https://repository.apache.org/content/repositories/maven-> > 
1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
maven-3.5.0-alpha-1-bin.tar.gz
https://repository.apache.org/content/repositories/maven-> > 
1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
maven-3.5.0-alpha-1-src.zip
https://repository.apache.org/content/repositories/maven-> > 
1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
maven-3.5.0-alpha-1-src.tar.gz

Source release checksum(s):
apache-maven-3.5.0-alpha-1-src.tar.gz sha1: 6055696aece5b0bfdd0308dae60838
b37e218aba
apache-maven-3.5.0-alpha-1-src.zip sha1: 7d6adcdf8929205bf20399c71c6a2b
db9ee4f6dd

Git tag:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
8e6bbc4d4aa7cdc837625a05358c98ca15f72698

Staging site:
https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/

Vote open for 72 hours.

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


Thanks,
-Stephen



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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Passing a system property already defined on CLI to Failsafe Plugin

2017-02-26 Thread Guillaume Boué

"maven.repo.local" is used automatically by maven-verifier to set-up the
local repository (see
https://github.com/apache/maven-shared/blob/trunk/maven-verifier/src/main/java/org/apache/maven/it/Verifier.java#L1732),
so it would have been nice to refer directly to it in the
systemPropertyVariables... But otherwise, yes, setting another system
property does the job, until someone decides to set that one also on the
CLI, which would break the test again...

With regard to the user properties, since is
"closer" to the IT than the user properties, I'd expect those to win
conflicts. However, if it is really intended not to do it, I'll see
about adding a note in the doc
http://maven.apache.org/components/surefire/maven-failsafe-plugin/examples/system-properties.html.
It doesn't mention this use-case.

Thanks,
Guillaume

Le 26/02/2017 à 23:56, Tibor Digana a écrit :

Perhaps the user properties should be set first, and then any

systemPropertyVariables?
I don't think so. User's properties should be finally preferable however I
understand that you do not want to have so hard restriction.
The solution would be the idiom I mentioned before where
systemPropertyVariable refers to Maven property which refers to user's
system property - all with same key name. Not following the idiom would
break the restriction and property in remains unchanged.

But this is not so easy because this may break the current user's and our
internal integration tests.
As a solution would be to introduce a config parameter to alter this
behavior in Surefire 3.0.

Our internal system property key "localRepository" set initially in forked
jvm refers to Maven Local Repo.
I think you cannot override it, see AbstractSurefireMojo.java L984, however
it is different property key.

Do you definitely want to use "maven.repo.local"?
It looks to me that Arquillian uses "localRepository".

your m2 local repository

On Sun, Feb 26, 2017 at 11:29 PM, Guillaume Boué-2 [via Maven] <
ml-node+s40175n5900380...@n5.nabble.com> wrote:

I just tried it, and it's the same issue.

Digging further into the code, it looks like the issue is here
https://github.com/apache/maven-surefire/blob/master/
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/
SurefireProperties.java#L140-L159.
User properties are set unconditionally after setting the configured
system properties in . Perhaps the user
properties should be set first, and then any systemPropertyVariables?

I found SUREFIRE-491 about this also.

Guillaume

Le 26/02/2017 à 23:03, Tibor Digana a écrit :

Have you tried this?

${project.build.directory}/it-repo

...
maven-failsafe-plugin:

${maven.repo.local}

On Sun, Feb 26, 2017 at 10:01 PM, Guillaume Boué <[hidden email]

<http:///user/SendEmail.jtp?type=node=5900380=0>> wrote:

Hi,

When a system property is passed on the CLI by the user, with
-Dprop=value, it seems that it is always preferred in the ITs of the
Failsafe Plugin, even when setting it to a different value in the
configuration. I think this is due to
SUREFIRE-121, but is there a good way around that? I would like the

system

property defined in to override the one

defined

on the CLI during IT execution.

As an example, consider the build of the maven-remote-resources-plugin.
When trying to run the ITs with a custom local repo set on the CLI

(with

-Dmaven.repo.local=...), they all fail because they can't resolve the
plugin in the version being built. What happens is that, even though

there

${project.build.directory}/it-repo

in the POM, to force the local repository to point to a location where

the

plugin was installed before-hand, it is getting ignored because
-Dmaven.repo.local was also set on the CLI (and to a location where the
plugin is rightly not installed). The current workaround I have is to

set a

different system property, like , and then use

verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );

in each IT code. But this sounds very brittle since the same issue

could

happen again if someone were to define -DlocalRepositoryPath for any

reason

on the CLI...

Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

-
To unsubscribe, e-mail: [hidden email]

<http:///user/SendEmail.jtp?type=node=5900380=1>

For additional commands, e-mail: [hidden email]

<http:///user/SendEmail.jtp?type=node=5900380=2>

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

--
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/Passing-a-system-property-
already

Re: Passing a system property already defined on CLI to Failsafe Plugin

2017-02-26 Thread Guillaume Boué

I just tried it, and it's the same issue.

Digging further into the code, it looks like the issue is here
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireProperties.java#L140-L159.
User properties are set unconditionally after setting the configured
system properties in . Perhaps the user
properties should be set first, and then any systemPropertyVariables?

I found SUREFIRE-491 about this also.

Guillaume

Le 26/02/2017 à 23:03, Tibor Digana a écrit :

Have you tried this?

${project.build.directory}/it-repo

...
maven-failsafe-plugin:

${maven.repo.local}

On Sun, Feb 26, 2017 at 10:01 PM, Guillaume Boué <gb...@apache.org> wrote:

Hi,

As an example, consider the build of the maven-remote-resources-plugin.
When trying to run the ITs with a custom local repo set on the CLI (with
-Dmaven.repo.local=...), they all fail because they can't resolve the
plugin in the version being built. What happens is that, even though there
is

${project.build.directory}/it-repo

in the POM, to force the local repository to point to a location where the
plugin was installed before-hand, it is getting ignored because
-Dmaven.repo.local was also set on the CLI (and to a location where the
plugin is rightly not installed). The current workaround I have is to set a
different system property, like , and then use

verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );

in each IT code. But this sounds very brittle since the same issue could
happen again if someone were to define -DlocalRepositoryPath for any reason
on the CLI...

Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

Passing a system property already defined on CLI to Failsafe Plugin

2017-02-26 Thread Guillaume Boué


Hi,

When a system property is passed on the CLI by the user, with
-Dprop=value, it seems that it is always preferred in the ITs of the
Failsafe Plugin, even when setting it to a different value in the
 configuration. I think this is due to
SUREFIRE-121, but is there a good way around that? I would like the
system property defined in  to override the one
defined on the CLI during IT execution.

As an example, consider the build of the maven-remote-resources-plugin.
When trying to run the ITs with a custom local repo set on the CLI (with
-Dmaven.repo.local=...), they all fail because they can't resolve the
plugin in the version being built. What happens is that, even though
there is

  

${project.build.directory}/it-repo
   

in the POM, to force the local repository to point to a location where
the plugin was installed before-hand, it is getting ignored because
-Dmaven.repo.local was also set on the CLI (and to a location where the
plugin is rightly not installed). The current workaround I have is to
set a different system property, like , and then use

verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );

in each IT code. But this sounds very brittle since the same issue could
happen again if someone were to define -DlocalRepositoryPath for any
reason on the CLI...

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

2017-02-25 Thread Guillaume Boué

I don't see a reason not to push 3.5.0-alpha-1 to Central. It has been 
done this way for previous versions, and makes it more broadly 
applicable for all users.


Guillaume


Le 25/02/2017 à 22:55, Karl Heinz Marbaise a écrit :

Hi,

based on the started discussion about either to bring 3.5.0-alpha-1 to 
Central or not I would suggest to discuss in a separate thread and 
prevent using the VOTE's threads for that (as Stephen already mentioned).


Using Central:
 o Everybody can use it and make tests on it.

Using an other repository:
 o Which one?

Using only dist area? Or something different?

WDY?

Based on earlier releases which had been in Central with alpha's:

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22apache-maven%22 



Kind regards
Karl Heinz Marbaise

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

2017-02-24 Thread Guillaume Boué

I also ran the ITs on a Windows machine, hitting the same error in the 
tests as mentioned by Robert. Additionally, I had the following errors:


Failed tests:
MavenITmng2199ParentVersionRangeTest>AbstractMavenIntegrationTestCase.runTest:244 
Expected failure when with Maven version 3.5.0-alpha-1
MavenITmng2199ParentVersionRangeTest>AbstractMavenIntegrationTestCase.runTest:244 
Expected failure when with Maven version 3.5.0-alpha-1
MavenITmng2199ParentVersionRangeTest>AbstractMavenIntegrationTestCase.runTest:244 
Expected failure when with Maven version 3.5.0-alpha-1
MavenITmng2199ParentVersionRangeTest>AbstractMavenIntegrationTestCase.runTest:244 
Expected failure when with Maven version 3.5.0-alpha-1
MavenITmng2199ParentVersionRangeTest>AbstractMavenIntegrationTestCase.runTest:244 
Expected failure when with Maven version 3.5.0-alpha-1


The command used to ran the ITs was:

mvn clean install -Prun-its -Dmaven.repo.local=`pwd`/repo

Le 24/02/2017 à 18:34, Robert Scholte a écrit :
When running the maven-its, I get this failing test. I think the cause 
is an invalid version range, right?


Robert

Tests in error:
MavenITmng5805PkgTypeMojoConfiguration>AbstractMavenIntegrationTestCase.runTest:222->testPkgTypeMojoConfiguration:27 
╗ Verification




On Thu, 23 Feb 2017 17:10:18 +0100, Stephen Connolly 
 wrote:



Hi,

We solved 65 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12339664=Text 



There are still a couple of issues left in JIRA for 3.5.0, but I do not
think any of those are blocking an alpha release:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC 



In addition there are 315 issues left in JIRA for Maven core:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC 



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

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/ 



Specifically the zip, tarball, and source archives can be found here:
https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.zip 

https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.tar.gz 

https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.zip 

https://repository.apache.org/content/repositories/maven-1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.tar.gz 



Source release checksum(s):
apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
6055696aece5b0bfdd0308dae60838b37e218aba
apache-maven-3.5.0-alpha-1-src.zip sha1:
7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd

Git tag:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8e6bbc4d4aa7cdc837625a05358c98ca15f72698 



Staging site:
https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/

Vote open for 72 hours.

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


Thanks,
-Stephen


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Reviewing MNG-6105

2017-01-25 Thread Guillaume Boué


Hi,

MNG-6105 was committed to a branch and there is a clean build of the IT
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6105/. I
will merge this into master Saturday if there are no objections. The
related issues (MNG-5670 and MNG-6053) were superseded by that one.

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: svn commit: r1779527 - in /maven/plugins/trunk/maven-checkstyle-plugin: ./ src/main/java/org/apache/maven/plugin/ src/main/java/org/apache/maven/plugins/ src/main/java/org/apache/maven/plugins/che

2017-01-24 Thread Guillaume Boué

Could the 2.18 version on JIRA be renamed to 3.0.0? I'll close the issue 
and start looking at all the others we can fix with this upgrade (like 
MCHECKSTYLE-275 for a start).


Guillaume


Le 20/01/2017 à 16:37, Robert Scholte a écrit :

Very nice, another plugin moving forward

Robert

On Thu, 19 Jan 2017 22:06:24 +0100,  wrote:


Author: gboue
Date: Thu Jan 19 21:06:23 2017
New Revision: 1779527

URL: http://svn.apache.org/viewvc?rev=1779527=rev
Log:
[MCHECKSTYLE-335] Migrate plugin to Maven 3.0

Upgrading the Maven version to 3.0 in the POM:
 - Passing version to 3.0.0-SNAPSHOT to mark the upgrade
 - Renaming the packages to org.apache.maven.plugins
 - Removing Maven 2 specific quirks



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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Update Cwiki Roadmap 2017

2017-01-24 Thread Guillaume Boué


Hi Michael,

When you do, can you ask edit privileges for me as well? That would 
avoid creating another one.


Thanks,
Guillaume

Le 24/01/2017 à 20:01, Michael Osipov a écrit :
No, I don't. Read-only. I will create an INFRA ticket. Can you 
meanwhile update the page?


Thank you!

Am 2017-01-24 um 19:45 schrieb Hervé BOUTEMY:

you don't have edit karma on Confluence?
if you need it, please open a Jira issue for INFRA like I did for 
Christian
[1]: we learned that Confluence is not tied to LDAP yet, then require 
manual

addition of account into maven-committers group.

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/INFRA-13311

Le mardi 24 janvier 2017, 18:39:17 CET Michael Osipov a écrit :

Hi Hervé, Stephen,

another bus load of candidates have been seconded/blessed for FIX-3.5.0
recently by Karl Heinz, me, Christian and you two. Can you update the
wiki page accordingly?

I'd like to continue to work on agreed changes.

Michael


-
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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: MNG-5629 and MNG-6117 look good

2017-01-16 Thread Guillaume Boué


And MNG-6117 is also merged to master.


Le 16/01/2017 à 03:19, Christian Schulte a écrit :

Am 01/13/17 um 14:48 schrieb Stephen Connolly:

I think we are ready to push these two branches to master


MNG-5629 merged to master.


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Next version for MPLUGIN in JIRA

2017-01-11 Thread Guillaume Boué


Hi,

For MPLUGIN, the only unreleased version in JIRA is currently 3.5.1, but
the version in the POM themselves is 3.6-SNAPSHOT. Should the version in
JIRA be changed, or can I update the POM versions? I'd lean on updating
JIRA based on the current version history (and maybe even to 3.6.0 to
align with 3 digits versions?).

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Moving forward on 3.5.0

2017-01-10 Thread Guillaume Boué

Yes, was following as well. Looks like the test 
MavenITmng3599useHttpProxyForWebDAVTest 
<https://builds.apache.org/job/maven-jenkinsfile/job/MNG-6117/1/testReport/junit/org.apache.maven.it/MavenITmng3599useHttpProxyForWebDAVTest/testitUseHttpProxyForWebDAV/> 
didn't pass. Weird because it passed when I tested locally, both on 
Window and Ubuntu (with Java 8)... Although it also failed on the 
post-reset-master branch 
https://builds.apache.org/job/maven-jenkinsfile/job/post-reset-master/6/#showFailuresLink 
and also for the MNG-5629 and MNG-5958 branches, looks like a flaky test.


Guillaume


Le 11/01/2017 à 00:01, Stephen Connolly a écrit :

https://builds.apache.org/job/maven-jenkinsfile/job/MNG-6117/ build in
progress... let's see how it does

On 10 January 2017 at 22:01, Guillaume Boué <gb...@apache.org> wrote:


I created the branch for MNG-6117 with commit:
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=comm
it;h=bd98ae6a3de8d443f5b3d2f895f2348c2912ae05

I will merge the branch into master on Monday the 16th if there are no
objections.

Thanks,
Guillaume


Le 09/01/2017 à 12:06, Stephen Connolly a écrit :


OK, I have updated the versions in JIRA.

Issues which have been agreed in the Big Scrub thread as being accepted
for
3.5.0 are all now marked with FixVersion = 3.5.0

Issues which have been proposed for 3.5.0 but have not yet been agreed for
3.5.0 are now all marked with FixVersion = 3.5.0-candidate

Please do not mark any issue with a FixVersion of 3.5.0 until we have had
agreement to put it in scope. It is ok to move things to 3.5.0-candidate

We need to start closing out the decisions on the 3.5.0-candidates.

Also as release manager for 3.5.0 I am requesting that all changes for
master must have a clean build on the full test suite before being merged
to master (I would appreciate a heads up too)

My expectation is that if you committed the changes towards 3.4.0, then
you
are responsible for tidying up the commits and preparing a branch for
merging.

-Stephen



---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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






---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: Moving forward on 3.5.0

2017-01-10 Thread Guillaume Boué

I created the branch for MNG-6117 with commit: 
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=bd98ae6a3de8d443f5b3d2f895f2348c2912ae05


I will merge the branch into master on Monday the 16th if there are no 
objections.


Thanks,
Guillaume

Le 09/01/2017 à 12:06, Stephen Connolly a écrit :

OK, I have updated the versions in JIRA.

Issues which have been agreed in the Big Scrub thread as being accepted for
3.5.0 are all now marked with FixVersion = 3.5.0

Issues which have been proposed for 3.5.0 but have not yet been agreed for
3.5.0 are now all marked with FixVersion = 3.5.0-candidate

Please do not mark any issue with a FixVersion of 3.5.0 until we have had
agreement to put it in scope. It is ok to move things to 3.5.0-candidate

We need to start closing out the decisions on the 3.5.0-candidates.

Also as release manager for 3.5.0 I am requesting that all changes for
master must have a clean build on the full test suite before being merged
to master (I would appreciate a heads up too)

My expectation is that if you committed the changes towards 3.4.0, then you
are responsible for tidying up the commits and preparing a branch for
merging.

-Stephen




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

2017-01-04 Thread Guillaume Boué

+1 (committer)

Le 04/01/2017 à 13:16, Stephen Connolly a écrit :

Hi,

We have collectively managed to mess up our ability to follow the original
release plan for 3.4.0 which was originally supposed to consist of an
effective no-op change of Eclipse's Aether for the code after migration to
Apache's Maven Resolver plus some other orthogonal changes around logging
colourization and launcher script bug fixes.

Given that some developer private builds of the current master branch have
been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been
closed with a fixed version of 3.4.0.

For us to release a 3.4.0 with those fixes reverted, could cause confusion
with our user community.

Additionally the informal practice of keeping existing integration tests as
RTC has not been followed, leading to some people to question whether the
integration tests remain valid.

For all the above reasons it is proposed to do *all* the following as an
whole:

1. In git://git.apache.org/maven.git we will rename the current master
branch to `pre-reset-master` and recreate `master`
as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb174dc195fb1
)

2. In git://git.apache.org/maven-integration-testing.git we will rename the
current master branch to `pre-reset-master` and recreate `master`
as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
https://github.com/apache/maven-integration-testing/commit/f31241ad6cb6474e559289f1bd7110ea5d5a4fba
)

3. In git://git.apache.org/maven-resolver.git we will rename the current
master branch to `pre-reset-master` and recreate `master`
as b74f7a1e8837875b4780199f644119f55d22465d (
https://github.com/apache/maven-resolver/commit/b74f7a1e8837875b4780199f644119f55d22465d),
i.e. the 1.0.x branch

We will then proceed to have (ideally) the original committers cherry-pick
(and tidy up an squash... if the original committers are not able to assist
then squashing may not be practicable) those changes that have been agreed
for 3.5.0 as summarized on the
https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
(authorative source of the decisions summarized in the wiki page is the
mail thread:
https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
).

As this involves a --force push on the `master` branch, we want to get the
approval of the committers before continuing.

The vote will be open for at least 72 hours.

The vote will be decided by a simple majority of valid votes cast. There is
no veto.

The vote is open to all committers.

In addition, for the vote to be valid, there must be at least 3x+1 votes
from PMC members

[ ] +1: Yes
[ ] 0:
[ ] -1: No

-Stephen

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

2017-01-01 Thread Guillaume Boué


OK, thanks for confirming this.


Le 01/01/2017 à 23:44, Christian Schulte a écrit :

Am 01/01/17 um 18:44 schrieb Guillaume Boué:

There is a commit about MRESOLVER-9 in tag 2.11 of Wagon:
https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422.
I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't
make it in the resolver release after its reset.

Does not make a difference. Everything is resolved the same way as
before. It's just that the project can be build with MRESOLVER-9 in
place. It can be built the same way now even when MRESOLVER-9 is not
there.  Does not affect anything.


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

2017-01-01 Thread Guillaume Boué


This is the list of JIRA issues that targets colourised logging / are
related to it:

MNG-3507ANSI color logging for improved output visibility   This is 
the
root JIRA issue.
MNG-3705Expression: ${executedProject} doesn't work in reports  SVN
revisions d4d7f4763f34e2c23e590ce02551943a1cad84e5 and
c6fb60b5482a12e3f94b74cd050ba46eddaa2423 are about it and actually
target MNG-3507.
MNG-6037add gossip slf4j provider support   Note that the 
colorization
feature was removed from Gossip.
MNG-6038
use Gossip slf4j provider as default logging, since it supports level
colorizationWONTFIX
MNG-6041Option -l does not disable colorized output Those are
in-version fixes, to be squashed with MNG-3507.
MNG-6043Colorization is disabled too late in batch mode
MNG-6046upgrade JAnsi from 1.12 to 1.13
MNG-6093
create a slf4j-simple provider extension that supports level color
rendering   This supercedes MNG-6038 and adds colorization to the Slf4j
Provider.
MNG-6115
Add Jansi native library search path to our start scripts   This 
adds a
system property to the launcher scripts. Should be safe to add alone
without impacts.


Please add if I forgot some. I hope it'll make deciding whether the
colorization feature, or parts of it, are added to 3.5.0 or later easier.

My personal take is that all of this could be integrated in 3.5.0 as it
does not affect current 3.3.9 build behaviour (that I encountered, at
least) and has a fair number of votes on JIRA. The con of course is that
it represents a complex addition.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

2017-01-01 Thread Guillaume Boué



Le 01/01/2017 à 01:55, Michael Osipov a écrit :
I just went through the list my issues. Here is a safe list I would 
merge/cherry-pick into new master:


FIX-3.5.0: MNG-5457, 


Note: this is dependant upon MRESOLVER-2 (commit 
https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=11b359e188f3b1d25bb6bda60195e7a47ca45bfc), 
so it depends if this makes it in the resolver release after its reset.


MNG-5567, 


This changes the classpath by adding ZIP files to it. I'd say this 
should be FIX-3.5.1 instead.



MNG-6106,


Seconded.


MNG-6136, MNG-6137


There is a commit about MRESOLVER-9 in tag 2.11 of Wagon: 
https://git1-us-west.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=f244ece2eee01500e4b1bc334b8dcd35b47f9422. 
I'm unsure whether it is safe to use this tag if MRESOLVER-9 doesn't 
make it in the resolver release after its reset.




To be transfered to someone else:
MNG-6043 can be merged into Hervé's MNG-3507.

Without issue id FIX-3.5.0:
MNG-   WONTFIX  Added some docs in CLIReporting Utils
NONERemove trailing whitespace
MNG-   WONTFIX  Pass force=true to DefaultWagonManagerTest
#testGetMissingJarForced()
NONEFix checkstyle error
NONEUse static final values instead of literals
NONERemove non-existent m2 include in 
component.xml
NONELanguage style improvements for commit 
5dab4940c9a7d3b362bd2a8b078b183e4eb521bb

MNG-   WONTFIX  Update Maven Dependency Plugin in Super POM
to 2.10
MNG-   WONTFIX  Removing redundant test
MNG-   WONTFIX  Work around a rounding bug existed upto
Java 7
MNG-   WONTFIX  Remove ancient Subversion keywords
MNG-   WONTFIX  Use the proper term for char U+002D (-)
hyphen(-minus) instead of dash

Some of them will be squashed into into closely related commits, will 
have tickets created or are so trivial that they will be applied 
directly.


Drop: MNG-5976

Undecided:
MNG-5708: fixed by Christian's work
MNG-6049: Maybe for Christian, I just pulled PR and IT

Michael


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [DISCUSS] Big Scrub for proposed 3.5.0 (if we reset master)

2016-12-31 Thread Guillaume Boué



Le 31/12/2016 à 22:14, Stephen Connolly a écrit :

FIX-3.5.0: MNG-5607, MNG-5815, MNG-5823, MNG-5824, MNG-5836, MNG-5837,
MNG-5889, MNG-5904, MNG-5946, MNG-5963, MNG-5967, MNG-5968, MNG-6001,
MNG-6003, MNG-6078

I think colourised logging probably should be 3.5.x but I am open to the
idea of making it 3.5.0 as it *should* not affect the build behaviour.

Do we have and seconders for the above?


I find the colorized logging really useful. Didn't encounter any issues 
with it (whether about build behaviour, or just visual behaviour) and it 
makes reading the logs in the console a lot easier. I'd mark this 
FIX-3.5.0 (it spans a couple of JIRA issues, like MNG-3507, MNG-6041 and 
MNG-6046 at least).




Do we have anyone else proposing issues for 3.5.0?


MNG-5962, MNG-5958, MNG-6117.

I noticed that some of those in the complete list of changes are marked 
as fixed for 3.3.9 or older versions on JIRA, like MNG-5923 or MNG-5670. 
Also noticed MNG-6070 which has a comment saying it shouldn't appear in 
release notes. Should they be removed from the list?


- Stephen


On Sat 31 Dec 2016 at 20:10, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


Here are the changes in current master since 3.3.9 (with some minor
changes omitted)

Issue ID   Target Version   Summary
   ==   
MNG-1577   WONTFIX  dependencyManagement does not work for
 transitive dependencies
MNG-2199   WONTFIX  Support version ranges in parent elements
MNG-2478   WONTFIX  add "resources-filtered" filtered resource
 directories to super POM
MNG-3507   WONTFIX  added support for multi-lines error message
 with color
MNG-3507   WONTFIX  ANSI Color logging for improved output
 visibility.
MNG-3705   WONTFIX  fixed mojo execution id color display
MNG-3825   WONTFIX  Dependencies with classifier should not
 always require a version.
MNG-4345   WONTFIX  [regression] Plugin executions contributed
 by default lifecycle mapping execute after
 other plugin executions bound to the same
 phase"
MNG-4347   WONTFIX  import-scoped dependencies of direct
 dependencies are not resolved using profile
 modifications from settings.xml
MNG-4463   WONTFIX  Dependency management import should support
 version ranges.
MNG-4645   WONTFIX  Move central repo definition out of Maven's
 core so it can be more easily changed.
MNG-5227   WONTFIX  The 'optional' flag of a dependency should
 be manageable.
MNG-5297   WONTFIX  improved explanations on prerequisites.maven
 in Maven 3
MNG-5359   WONTFIX  Declared execution in PluginMgmt gets bound
 to lifecycle (regression)
MNG-5368   WONTFIX  UnsupportedOperationException thrown when
 version range is not correct in
 dependencyManagement definitions
MNG-5457   WONTFIX  Show repository id when downloading or
 uploading from/to a remote repository
MNG-5527   WONTFIX  Relocation does not work for imported poms
MNG-5538   WONTFIX  mvn start script causes cygwin warning
MNG-5567   WONTFIX  Zip files are not included in classpaths at
 all
MNG-5600   WONTFIX  Dependency management import should support
 exclusions.
MNG-5607   WONTFIX  Don't use M2_HOME in mvn shell/command
 scripts anymore
MNG-5629   WONTFIX  ClosedChannelException from
 DefaultUpdateCheckManager.read
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
 from Repo that contains a ${parameter}
MNG-5639   WONTFIX  Support resolution of Import Scope POMs
 from Repo that contains a ${parameter}
MNG-5661   WONTFIX  Make MavenProject instances immutable after
 initial construction
MNG-5670   WONTFIX  guard against
 ConcurrentModificationException
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5761   WONTFIX  Dependency management is not transitive.
MNG-5815   WONTFIX  "mvn.cmd" does not indicate failure
 properly when using "&&"
MNG-5823   WONTFIX  mvnDebug doesn't work with M2_HOME with
 spaces -

Re: [VOTE] Releasing Wagon 2.11

2016-12-31 Thread Guillaume Boué

Thanks for the analysis! Agree with dropping fsutil then; I committed 
the addition of the logs with it just so that we can have concrete 
numbers for comparison (the last build indicates there was no permission 
issues in using it, otherwise it wouldn't have timed out but just failed 
to find the file). NIO.2 requires Java 7 though, so looks like a good 
reason to try and update to it (and Jetty 9 in the process, as Olivier 
suggested), but maybe not for this version. That also makes me wonder if 
the NIO.2 SPARSE option doesn't implictly require special privileges on 
Windows (like it does for creating symbolic links).


In any case, the result of the Jenkins build with regard to the commit 
are here 
https://builds.apache.org/job/maven-wagon-jetty8-windows/org.apache.maven.wagon$wagon-http/3/consoleFull. 
The 4 Go test file was created instantly (30 milliseconds), and it timed 
out performing the first download; so the creation of the file isn't an 
issue. I was following the growing size of the download in the target 
directory as it happened and things didn't appear to work slowly.


The tests for wagon-http started at 11:47:28 and timed out after 
11:53:04 when doing the first download for HugeFileDownloadTest; this 
makes up for the 400 seconds (roughly 6-7 minutes) of the Surefire 
timeout. Another breakdown is seen here (oddly without 
HugeFileDownloadTest):


https://builds.apache.org/job/maven-wagon-jetty8-windows/org.apache.maven.wagon$wagon-http/3/testReport/org.apache.maven.wagon.providers.http/

All of this is actually caused by HttpsWagonTest, 
HttpsWagonPreemptiveTest and HugeFileDownloadTest taking each a bit more 
than 2 minutes. I don't think we can cut 
<https://builds.apache.org/job/maven-wagon-jetty8-windows/org.apache.maven.wagon$wagon-http/3/testReport/org.apache.maven.wagon.providers.http/HttpsWagonTest/><https://builds.apache.org/job/maven-wagon-jetty8-windows/org.apache.maven.wagon$wagon-http/3/testReport/org.apache.maven.wagon.providers.http/HttpsWagonPreemptiveTest/>HugeFileDownloadTest 
below 2 minutes (with the sparse file created instantly, I see no room 
for improvements here), so focus should actually be made on those 2 
other tests.


Guillaume


Le 31/12/2016 à 16:51, Michael Osipov a écrit :

Am 2016-12-31 um 12:13 schrieb Guillaume Boué:

Do you think I can add a dummy log before the creation of the test file
(and add the timestamps to the logs of wagon-http), to see how much time
it takes on the Windows Server 2012? I'd like to see the breakdown of
what takes time on the Jenkins machine, perhaps there is nothing we can
do better (except increase the timeout to 500 or so...).


Let me share new findings before I get to the answers. I tested this 
branch on my machine at work which is part of an Active Directory 
domain, I am local admin. It is a regular, 2-core i5 machine with 12 
GiB RAM and medium-size HDD:


1. fsutil failed, domain policy requires elevated permissions to run 
fsutil in command prompt and you even see it because stderr/stdout of 
fsutil is swalled. I tried manually.

2. I have even raised the timeout to 800 seconds, it still fails.

Given this, I'd wouldn't really use fsutil. Rather NIO2 with 
StandardOption.SPARSE. This might work faster.


To your questions: go head and use SLF4J, it is already available. 
Print the log messages and you'll see how much creation really consumes.

I'd test this ony my machine at home and work.

Michael



Le 30/12/2016 à 22:46, Michael Osipov a écrit :

I just pushed another commit to the branch with your changes.
The job does not really work on Windows [1], it simply takes too long
to complete on the Windows Server 2012.

[1]
https://builds.apache.org/job/maven-wagon-jetty8-windows/2/org.apache.maven.wagon$wagon-http/console 




Am 2016-12-29 um 19:10 schrieb Guillaume Boué:
I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the 
Java
code should create a sparse file to have things faster. Using 
setLength
on a random access file probably does it depending on the OS and 
type of

drive, but it isn't creating one in my situation.

When run on Ubuntu, creating the test file is done practically 
instantly

whereas it takes 60 seconds on my Windows machine. Downloading takes
around 30 seconds in Ubuntu, whereas it takes 150 seconds in Windows.

I changed the method creating the test file (makeHugeFile) to:

if ( Os.isFamily( Os.FAMILY_WINDOWS ) )
{
Process p = new ProcessBuilder( "fsutil", "file",
"createnew", hugeFile.getAbsolutePath(),
String.valueOf(
HUGE_FILE_SIZE ) ).start();
p.waitFor();
}
else
{
RandomAccessFile ra = new RandomAccessFile(
hugeFile.getPath(), "rw" );
ra.setLength( HUGE_FILE_SIZE + 1 );
ra.seek( HUGE_FILE_SIZE );
ra.write( 1 );
ra.close();
}

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

2016-12-31 Thread Guillaume Boué




Le 30/12/2016 à 09:01, Robert Scholte a écrit :
On Thu, 29 Dec 2016 18:57:56 +0100, Hervé BOUTEMY 
 wrote:



perhaps maven-resolver will require same reset


+1

IMO we forgot to do a release with the original Aether code with the 
new GAVs.


Robert



and we'll need to define which convention to use on Jira when merging 
code:
remove "Fix Version: 3.4.0" for example, to track what features have 
not been

merged yet

Regards,

Hervé

Le jeudi 29 décembre 2016, 11:18:59 CET Stephen Connolly a écrit :
On ASF infra, our master branch is supposed to be a protected branch 
and

thus cannot be reset or force-pushed without an INFRA ticket.

If we want to reset our master branch in order to clean out the 
history of
the many changes and reverts to and fro etc, we thus need an INFRA 
ticket

raised.

INFRA should not act on such a ticket without the results of a vote 
of the

committers that has at least three binding votes from the PMC (i.e. the
majority of votes cast must be in favour and at least three PMC members
must have voted in favour)

Votes are a great way to *confirm* consensus, but a horrible way to 
build a
community or establish consensus. We should only ever have a vote 
thread

once the consensus seems to be established.

To establish consensus we use a discuss thread.

Please refrain from assigning blame, we want to grow our community not
shrink it. The shorty endorphin rush you get from assigning blame or
performing The Dance Of I Told You So™ will require repeated hits to
maintain which will only lead to a more toxic community.

We have not been good at maintaining our CI infrastructure:

* As a consequence, some people have been developing on master 
rather than
on branches in order to ensure that their development gets the 
benefit of

the integration tests

* This has lead to a lot of micro commits and effectively revert 
commits on

master making it hard to track what actually has changed and what has
actually been fixed.

* Additionally `git blame` probably now could end up confusing people
trying to understand the rationale for some changes

We have not been good at maintaining our Integration tests:

* As a consequence it has been hard to get our CI infrastructure 
working

effectively

* As a consequence, people have been forced to leverage a single 
branch for

CI testing

We have not been good at developing bigger changes in a branch

etc.

I could go on.

My belief is that confidence in 3.4.0 has been eroded.

I propose that we reset master back
to 737de43e392fc15a0ce366db98d70aa18b3f6c03, with an analogous reset of
master for the integration tests, and then immediately commit a dummy
commit so that nobody accidentally does a fast-forward push.

Then we can cherry pick the changes that were on the old master that we
want to have in 3.4.0

This will probably also involve:

* Fixing the CI infrastructure (I favour using a pipeline multibranch
project so that branch development is easier,
https://builds.apache.org/job/maven-jenkinsfile/ is where I have been
trying to prototype this... currently failing because "windows")

* Switching to a culture of branch / PR development for all committers

* Better providing rationale for changes, e.g. we need a succinct
description of the actual regression between 2.x and 3.x in 
resolution of

dependencies of plugins as well as actual easy to understand tests that
demonstrate the behaviour *and* show that it is an actual regression

* etc

But the first step in that would be to reset master...

So...

Is 737de43e392fc15a0ce366db98d70aa18b3f6c03 the correct hash to 
reset to?


What is the correct hash for the integration tests?

Do we want to do this?

What else should we change about our processes to prevent the need 
to do

this again?


Having a vote on all changes to master sounds too much. I think it 
should be up to the developers to always raise discussions whenever a 
change would have impacts on existing ITs, or whenever a new feature is 
considered to be added. Bug fixing should be able to be pushed easily; 
only a commit message describing what the bug actually is, and how the 
fix is done should be necessary.


Commits should, as much as possible, represent a whole unit. That is, if 
it wouldn't make sense to revert to a given revision (because it 
represents some temporary dev state, or incomplete state), then probably 
that revision shouldn't exist. Tests ran on Jenkins should be a 
last-resort (or close to it) IMO: any change that is commited should be 
tested as passing, possibly on different OS (if the change looks like OS 
dependent) and different Maven versions for plugins (I personally test 
with 3.0.5, 3.3.9 and latest snapshot so that a wide range of versions 
are covered).




Should we maybe just drop 3.4.x and jump to 3.5.x also in order to 
signal
that this was a reboot version and any 3.4.x stuff is thus easy to 
detect

and filter?


What exactly would this scenario imply? If it is skipping

Re: [VOTE] Releasing Wagon 2.11

2016-12-31 Thread Guillaume Boué

Do you think I can add a dummy log before the creation of the test file 
(and add the timestamps to the logs of wagon-http), to see how much time 
it takes on the Windows Server 2012? I'd like to see the breakdown of 
what takes time on the Jenkins machine, perhaps there is nothing we can 
do better (except increase the timeout to 500 or so...).


Guillaume


Le 30/12/2016 à 22:46, Michael Osipov a écrit :

I just pushed another commit to the branch with your changes.
The job does not really work on Windows [1], it simply takes too long 
to complete on the Windows Server 2012.


[1] 
https://builds.apache.org/job/maven-wagon-jetty8-windows/2/org.apache.maven.wagon$wagon-http/console


Am 2016-12-29 um 19:10 schrieb Guillaume Boué:

I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the Java
code should create a sparse file to have things faster. Using setLength
on a random access file probably does it depending on the OS and type of
drive, but it isn't creating one in my situation.

When run on Ubuntu, creating the test file is done practically instantly
whereas it takes 60 seconds on my Windows machine. Downloading takes
around 30 seconds in Ubuntu, whereas it takes 150 seconds in Windows.

I changed the method creating the test file (makeHugeFile) to:

if ( Os.isFamily( Os.FAMILY_WINDOWS ) )
{
Process p = new ProcessBuilder( "fsutil", "file",
"createnew", hugeFile.getAbsolutePath(),
String.valueOf(
HUGE_FILE_SIZE ) ).start();
p.waitFor();
}
else
{
RandomAccessFile ra = new RandomAccessFile(
hugeFile.getPath(), "rw" );
ra.setLength( HUGE_FILE_SIZE + 1 );
ra.seek( HUGE_FILE_SIZE );
ra.write( 1 );
ra.close();
}

This matches with the timings I get on Ubuntu (both for the creation of
the file, and the downloading via Wagon). I ran the build several times
with this change without any timeout issues. Can you test this change on
your side?

Side-note: I added "ra.close();" in the code above, because the random
access file wasn't closed otherwise, and then the file wasn't getting
deleted properly.

Guillaume

Le 29/12/2016 à 15:50, Michael Osipov a écrit :

Am 2016-12-29 um 12:24 schrieb Guillaume Boué:
I ran them at least 10 times, and there was the timeout issue each 
time.

Yes, the timeout is Surefire waiting for the forked VM. I applied the
patch (I had done similar tries also) but I still have the issue on
Windows 10.

You'll find the logs attached. It seems that the download is really
advancing (inside target, I can see the file hugetxt slowly
growing), but is just taking a long time. Additionally, the test class
HugeFileDownloadTest is composed of 2 tests, downloading the same 
file 2
times with different parameters: from the logs, it seems one of 
them is

succeeding (taking 140 seconds of the 400 in total), and then it times
out performing the second.

Also, part of the issue is probably with the time it takes to 
create the

4 Go test file that is later downloaded through Wagon (maybe it should
be done by calling the fsutil command when the test runs on Windows).
I'll try to do more timings when running the tests with Ubuntu and see
where the difference is.


Thanks for the analysis. I think the cheapest improvement we can do is
to create the file only once (setUp(), tearDown(). It is created for
each test again. I do not think that this is really necessary.

What type of disks do you have? This test passes on my machine within
70 seconds on a Samsung SSD.

I will apply the patch to the branch because those fixes are necessary
anyway.

Please keep me updated.

Michael


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


-
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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

2016-12-30 Thread Guillaume Boué

Le 30/12/2016 à 17:21, Christian Schulte a écrit :

Am 12/30/16 um 11:00 schrieb Guillaume Boué:

Hi Christian,

I remember adding those 2 ITs after raising a concern on dev (see
attached mail). They were passing with 3.3.9 and latest 3.4.0 at that time.

Is there an issue updating those tests with regard to MNG-5457? I
noticed this is the 5th commit changing it (which I think is a lot), but
the build is still failing on Jenkins and locally with 3.3.9. Maybe we
can assert that the file was actually downloaded in a different manner,
like deleting the folder in the local repository in a setup script, and
testing that the POM and JAR files are present in the local repository
in the verify script? This is what I did in, e.g., the IT "get-artifact".

Another simple solution would be to assert that the log file contains
either "Downloading:" or "Downloading from ...", instead of using a
regular expression (I verified locally that this works fine).

Do you have a Windows box at hand? Would be cool if you could fix those
two scripts to work an Windows. I would have to wait another 2.5 hours
just to find out it's still not working.

I can build all plugins using current 3.4.0-SNAPSHOT by doing:

mvn -DmavenPluginToolsVersion=3.5 -Prun-its verify

There is this issue on Windows and there is another issue with the
maven-assembly-plugin which seems to be related to the invoker or the
updates to the Windows launcher scripts. If you could take a look at it
as well, would also be cool. Failing IT is here:

<https://builds.apache.org/view/Maven/job/maven-master-release-status-test-plugins-windows/ws/plugins-trunk/maven-assembly-plugin/target/it/projects/basic-features/space%20&%20special%20char/>

build.log contains:
'special' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.
The system cannot find the path specified.

Maybe an issue with the current mvn.cmd launcher. Someone with Windows
may fix this in a few minutes.

I remember looking into them. It's actually an issue with the launcher
script on Windows, that is fixed with 3.4.0. Perhaps we can mark the
build as expected to fail with < 3.4.0, and then have the passing one
with >= 3.4.0.

If you step over such an issue, I would not mind if you just fix it and
commit. That's what I am doing as well. Reading some code and noticing
someone just committed something not working for me, I just fix it and
commit it. There is no need to write tons of emails. I do read commit
messages. That's also a channel to use for communication.

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

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

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

2016-12-30 Thread Guillaume Boué

I'm developing both on Windows and on a Ubuntu VM. The 2 ITs passed with
the two systems with 3.0.5, 3.3.9 and 3.4.0 before the log format change
in MNG-5457. I went ahead and committed an update to take account for
that (the tests no longer rely on reading the logs).

If you want to test unit changes faster, you can run the ITs by building
specifically the Dependency Plugin. It can be made even faster by using
the "-Dinvoker.test=..." command-line switch, to select specifically
which ITs to run. Only when the changes are passing do I run the whole
thing, otherwise the feedback loop is pretty slow yes.

Guillaume

Le 30/12/2016 à 15:47, Christian Schulte a écrit :

Am 12/30/16 um 11:00 schrieb Guillaume Boué:

Is there an issue updating those tests with regard to MNG-5457?

I do not have a Windows box. Issue was due to the ITs failing on
Windows. I verified the scripts compile with groovy locally. Currently
there still seems to be an issue with the Windows path separator.

Illegal/unsupported escape sequence near index 26

Running them takes time!

[INFO] *Total time: 02:37 h*
[INFO] Finished at: 2016-12-29T21:04:54-08:00
[INFO] Final Memory: 158M/735M

<https://builds.apache.org/view/Maven/job/maven-master-release-status-test-plugins-windows/>

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

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

Re: svn commit: r1776513 - in /maven/plugins/trunk/maven-dependency-plugin/src/it/projects: copy-from-remote-repository/verify.groovy unpack-from-remote-repository/verify.groovy

2016-12-30 Thread Guillaume Boué

0/fake-remote-unpack-1\\.0\\.jar"
+String expectedDownloadedPattern = "Downloaded.*: file:///" + basedir.getPath().replaceAll( 
"", "") +
+   
"/repo/org/apache/maven/its/dependency/fake-remote-unpack/1\\.0/fake-remote-unpack-1\\.0\\.jar"
  assert buildLog.text =~ expectedDownloadingPattern
  assert buildLog.text =~ expectedDownloadedPattern
  







---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
--- Begin Message ---

Hi Guillaume,

I removed it because I assumed that the RepositorySession is already aware  
of the RemoteRepositories.

All integration tests kept working after this change.
But it seems like you found a case where it is required.
So you can write an integration test to prevent regression in the future  
and restore this part of the code.


thanks,
Robert

On Wed, 10 Aug 2016 20:42:48 +0200, Guillaume Boué <gb...@apache.org>  
wrote:



Hello,

  
In the current 3.0.0-SNAPSHOT version of the maven-dependency-plugin, I  
noticed that the unpack and copy goals do not resolve artifacts from  
remote repositories configured in the POM. This used to work in the  
version 2.10.


  
To reproduce the issue, it is possible to add a remote repo in a sample  
POM file:


  
netbeans

http://bits.netbeans.org/nexus/content/groups/netbeans/
 



And then configure the Dependency Plugin to unpack, for example, the  
artifact org.netbeans.modules:org-netbeans-core:RELEASE81:nbm. The build  
fails in version 3.0.0-SNAPSHOT of the plugin because the new netbeans  
repo isn't taken into account, whereas the artifact is correctly  
downloaded if version 2.10 is used. Furthermore, if the repository  
declaration is moved to the Settings, instead of being in the POM, the  
repo is correctly taken into account for both versions.


  
After looking at the history, it seems to have been removed by this  
commit:


  
https://github.com/apache/maven-plugins/commit/35b9283efa241809a59fb4a828308681fb4a2afe#diff-870eb62b4a419b584383325fa9296a08


  
where the following line was removed:  
buildingRequest.setRemoteRepositories( getRemoteRepos() );


  
Was this intended? If so, we should update the docs to reflect this  
change, I didn't find a change regarding this.



  
I re-added it locally, with the remote repositories being injected in  
the plugin with the "project.remoteArtifactRepositories" property, and  
it solves this issue: the repositories declared in the POM are used,  
alongside those declared in the Settings, like usual. All the ITs still  
pass also.



  
Thanks,



Guillaume


 


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


--- End Message ---

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

Re: [VOTE] Releasing Wagon 2.11

2016-12-29 Thread Guillaume Boué

I have a Toshiba SSHD (MQ02ABD100H). I think the issue is that the Java 
code should create a sparse file to have things faster. Using setLength 
on a random access file probably does it depending on the OS and type of 
drive, but it isn't creating one in my situation.


When run on Ubuntu, creating the test file is done practically instantly 
whereas it takes 60 seconds on my Windows machine. Downloading takes 
around 30 seconds in Ubuntu, whereas it takes 150 seconds in Windows.


I changed the method creating the test file (makeHugeFile) to:

if ( Os.isFamily( Os.FAMILY_WINDOWS ) )
{
Process p = new ProcessBuilder( "fsutil", "file", "createnew", 
hugeFile.getAbsolutePath(),
String.valueOf( HUGE_FILE_SIZE ) 
).start();
p.waitFor();
}
else
{
RandomAccessFile ra = new RandomAccessFile( hugeFile.getPath(), 
"rw" );
ra.setLength( HUGE_FILE_SIZE + 1 );
ra.seek( HUGE_FILE_SIZE );
ra.write( 1 );
ra.close();
}

This matches with the timings I get on Ubuntu (both for the creation of 
the file, and the downloading via Wagon). I ran the build several times 
with this change without any timeout issues. Can you test this change on 
your side?


Side-note: I added "ra.close();" in the code above, because the random 
access file wasn't closed otherwise, and then the file wasn't getting 
deleted properly.


Guillaume

Le 29/12/2016 à 15:50, Michael Osipov a écrit :

Am 2016-12-29 um 12:24 schrieb Guillaume Boué:

I ran them at least 10 times, and there was the timeout issue each time.
Yes, the timeout is Surefire waiting for the forked VM. I applied the
patch (I had done similar tries also) but I still have the issue on
Windows 10.

You'll find the logs attached. It seems that the download is really
advancing (inside target, I can see the file hugetxt slowly
growing), but is just taking a long time. Additionally, the test class
HugeFileDownloadTest is composed of 2 tests, downloading the same file 2
times with different parameters: from the logs, it seems one of them is
succeeding (taking 140 seconds of the 400 in total), and then it times
out performing the second.

Also, part of the issue is probably with the time it takes to create the
4 Go test file that is later downloaded through Wagon (maybe it should
be done by calling the fsutil command when the test runs on Windows).
I'll try to do more timings when running the tests with Ubuntu and see
where the difference is.


Thanks for the analysis. I think the cheapest improvement we can do is 
to create the file only once (setUp(), tearDown(). It is created for 
each test again. I do not think that this is really necessary.


What type of disks do you have? This test passes on my machine within 
70 seconds on a Samsung SSD.


I will apply the patch to the branch because those fixes are necessary 
anyway.


Please keep me updated.

Michael


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Releasing Wagon 2.11

2016-12-29 Thread Guillaume Boué

I ran them at least 10 times, and there was the timeout issue each time. 
Yes, the timeout is Surefire waiting for the forked VM. I applied the 
patch (I had done similar tries also) but I still have the issue on 
Windows 10.


You'll find the logs attached. It seems that the download is really 
advancing (inside target, I can see the file hugetxt slowly 
growing), but is just taking a long time. Additionally, the test class 
HugeFileDownloadTest is composed of 2 tests, downloading the same file 2 
times with different parameters: from the logs, it seems one of them is 
succeeding (taking 140 seconds of the 400 in total), and then it times 
out performing the second.


Also, part of the issue is probably with the time it takes to create the 
4 Go test file that is later downloaded through Wagon (maybe it should 
be done by calling the fsutil command when the test runs on Windows). 
I'll try to do more timings when running the tests with Ubuntu and see 
where the difference is.



Le 29/12/2016 à 01:18, Michael Osipov a écrit :

Am 2016-12-28 um 21:34 schrieb Guillaume Boué:

I have the same results as Hervé, both on Windows and Ubuntu. This is
what I have with Maven 3.3.9:

- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
HugeFileDownloadTest (perhaps the timeout should be increased?)


How often did you run the tests to get this result? I tried at least 
20 times or more.

Can you enable the logging I asked Dan for? You might see something else.

By timeout do you mean the timeout Surefire waits for the forked VM?

Can you try the attached patch? I have noticed that in this 
HugeFileDownloadTest the server is never shutdown as well as in other 
cases.


Michael



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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
2016-12-29T12:14:53.319 [main] INFO org.eclipse.jetty.server.Server - 
jetty-8.1.22.v20160922
2016-12-29T12:14:53.334 [main] INFO org.eclipse.jetty.server.AbstractConnector 
- Started SelectChannelConnector@0.0.0.0:50893
http://localhost:50893 - Session: Opened  
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.client.protocol.RequestAddCookies - CookieSpec selected: 
compatibility
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection 
request: [route: {}->http://localhost:50893][total kept alive: 38; route 
allocated: 0 of 20; total allocated: 39 of 40]
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection 
leased: [id: 254][route: {}->http://localhost:50893][total kept alive: 38; 
route allocated: 1 of 20; total allocated: 40 of 40]
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Opening connection 
{}->http://localhost:50893
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - Connecting to 
localhost/127.0.0.1:50893
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - Connection 
established 127.0.0.1:50896<->127.0.0.1:50893
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.conn.DefaultManagedHttpClientConnection - 
http-outgoing-254: set socket timeout to 180
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Executing request GET 
/hugefile.txt HTTP/1.1
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Target auth state: UNCHALLENGED
2016-12-29T12:14:53.334 [main] DEBUG 
org.apache.http.impl.execchain.MainClientExec - Proxy auth state: UNCHALLENGED
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> GET /hugefile.txt HTTP/1.1
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Cache-control: no-cache
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Cache-store: no-store
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Pragma: no-cache
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Expires: 0
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Accept-Encoding: gzip
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Host: localhost:50893
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> Connection: Keep-Alive
2016-12-29T12:14:53.334 [main] DEBUG org.apache.http.headers - 
http-outgoing-254 >> User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_102)
2016-12-29T12:14:53.459 [main] DEBUG org.apache.http.headers - 
http

Re: [VOTE] Releasing Wagon 2.11

2016-12-28 Thread Guillaume Boué



Le 28/12/2016 à 21:49, Christian Schulte a écrit :

Am 12/28/16 um 21:34 schrieb Guillaume Boué:

I have the same results as Hervé, both on Windows and Ubuntu. This is
what I have with Maven 3.3.9:

- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
HugeFileDownloadTest (perhaps the timeout should be increased?)
- Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
- Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK

With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I
have compilation errors in the test class FileWagonTest (both on Windows
and Ubuntu)

[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8]
 cannot access junit.framework.TestCase
class file for junit.framework.TestCase not found
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52]
 cannot find symbol
symbol:   method getName()
location: class org.apache.maven.wagon.providers.file.FileWagonTest

The JUnit dependency isn't getting pulled. This is the scenario at hand:

- wagon-file has as parent wagon-providers which has a dependency on
wagon-provider-test with scope test.
- wagon-provider-test has a compile scoped dependency on junit
(compile is explicitly written).
- wagon-provider-test has as parent wagon, which has a test scoped
dependency management on junit.

What would be the problem?

Overriding the dependency management is only possible in the direct
dependencies (in the POM). When resolving a dependency, those overrides
are beeing ignored and the management gets applied. That's always been
that way. If your test classes need junit, you should declare junit in
the POM and not rely on it to be there transitively. The dependency
plugin's analyze goal would warn about this for the main artifact
(src/main) but not for the test artifact (src/test).



How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?

This is the tree with Maven 3.3.9:

[DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.slf4j:slf4j-simple:jar:1.7.19:test
[DEBUG]   org.slf4j:slf4j-api:jar:1.7.19:test
[DEBUG]org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT:test
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.5.5:test
[DEBUG]  org.codehaus.plexus:plexus-classworlds:jar:2.2.2:test
[DEBUG]  org.apache.xbean:xbean-reflect:jar:3.4:test
[DEBUG] log4j:log4j:jar:1.2.12:test
[DEBUG] commons-logging:commons-logging-api:jar:1.1:test
[DEBUG]  com.google.collections:google-collections:jar:1.0:test
[DEBUG]   org.easymock:easymock:jar:3.2:test
[DEBUG]  cglib:cglib-nodep:jar:2.2.2:test
[DEBUG]  org.objenesis:objenesis:jar:1.3:test
[DEBUG]   org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:test
[DEBUG]  
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test
[DEBUG]   javax.servlet:javax.servlet-api:jar:3.0.1:test
[DEBUG]   junit:junit:jar:4.11:test (scope managed from compile by 
org.apache.maven.wagon:wagon:2.12-SNAPSHOT)
[DEBUG]  org.hamcrest:hamcrest-core:jar:1.3:test





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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [VOTE] Releasing Wagon 2.11

2016-12-28 Thread Guillaume Boué

I have the same results as Hervé, both on Windows and Ubuntu. This is 
what I have with Maven 3.3.9:


- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in 
HugeFileDownloadTest (perhaps the timeout should be increased?)

- Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
- Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK

With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I 
have compilation errors in the test class FileWagonTest (both on Windows 
and Ubuntu)


[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8]
 cannot access junit.framework.TestCase
  class file for junit.framework.TestCase not found
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52]
 cannot find symbol
  symbol:   method getName()
  location: class org.apache.maven.wagon.providers.file.FileWagonTest

The JUnit dependency isn't getting pulled. This is the scenario at hand:

- wagon-file has as parent wagon-providers which has a dependency on 
wagon-provider-test with scope test.
- wagon-provider-test has a compile scoped dependency on junit 
(compile is explicitly written).
- wagon-provider-test has as parent wagon, which has a test scoped 
dependency management on junit.


What would be the problem?

The tree displayed in the logs when building wagon-provider-test 
correctly lists JUnit with scope compile:


[DEBUG] org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT
[DEBUG]org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]org.codehaus.plexus:plexus-container-default:jar:1.5.5:compile
[DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.2:compile
[DEBUG]   org.apache.xbean:xbean-reflect:jar:3.4:compile
[DEBUG]  log4j:log4j:jar:1.2.12:compile
[DEBUG]  commons-logging:commons-logging-api:jar:1.1:compile
[DEBUG]   com.google.collections:google-collections:jar:1.0:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.easymock:easymock:jar:3.2:compile
[DEBUG]   cglib:cglib-nodep:jar:2.2.2:compile
[DEBUG]   org.objenesis:objenesis:jar:1.3:compile
[DEBUG]org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:compile
[DEBUG]   
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[DEBUG]javax.servlet:javax.servlet-api:jar:3.0.1:compile
[DEBUG]org.slf4j:slf4j-api:jar:1.7.19:compile
[DEBUG]junit:junit:jar:4.11:compile
[DEBUG]   org.hamcrest:hamcrest-core:jar:1.3:compile

But when building wagon-file, the tree is:

[DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.slf4j:slf4j-simple:jar:1.7.19:test
[DEBUG]   org.slf4j:slf4j-api:jar:1.7.19:test
[DEBUG]org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT:test
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.5.5:test
[DEBUG]  org.codehaus.plexus:plexus-classworlds:jar:2.2.2:test
[DEBUG]  org.apache.xbean:xbean-reflect:jar:3.4:test
[DEBUG] log4j:log4j:jar:1.2.12:test
[DEBUG] commons-logging:commons-logging-api:jar:1.1:test
[DEBUG]  com.google.collections:google-collections:jar:1.0:test
[DEBUG]   org.easymock:easymock:jar:3.2:test
[DEBUG]  cglib:cglib-nodep:jar:2.2.2:test
[DEBUG]  org.objenesis:objenesis:jar:1.3:test
[DEBUG]   org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:test
[DEBUG]  
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test
[DEBUG]   javax.servlet:javax.servlet-api:jar:3.0.1:test


Is the problem that, during resolving the dependencies for wagon-file, 
the compiled scope JUnit dependency of the direct wagon-provider-test 
dependency is getting managed to scope test (due to the parent), and 
therefore that this now test-scoped dependency of wagon-provider-test 
isn't retrieved transitively (because it is a test dependency of a 
direct test dependency)?


Guillaume

Le 28/12/2016 à 12:00, Hervé BOUTEMY a écrit :

the branch runs without issue on my machine now:
mvn: 3.3.9, jdk: Oracle 1.7.0_71, OS: Linux

the proposed release was consistently failing on HugeFileDownloadTest

Notice that with Maven 3.4.0-SNAPSHOT, there is a compilation failure:
testCompile (default-testCompile) on project wagon-file

Using "-ldm" makes the build happy again, until a Surefire run fails with a
timeout...

Regards,

Hervé

Le mercredi 28 décembre 2016, 02:05:23 CET Michael Osipov a écrit :

Hi Dan,

Am 2016-12-25 um 19:51

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

2016-12-24 Thread Guillaume Boué

Why would the PMD plugin care about what Doxia require transitively? 
Christian, can you explain a bit more why those changes are needed?



Le 24/12/2016 à 17:59, Hervé BOUTEMY a écrit :

+1

notice that it may show that we have an issue with the way transitivity +
nearest resolution are applied

IIUC this case, we have:
1. a direct dependency with scope = test
2. a transitive dependency with scope = compile

the result can't be just the direct dependency with scope=test: scope of
direct dependency has to switch to compile (and I don't know which version
should be kept: direct or transitive)

I'm sure we have edge cases with transitive dependencies algorithm and scopes

For a long time now, I want to create a builder API to create dependencies
unit tests, to ease creating tests, avoiding the nightmare of creating a bunch
of pom.xml files in a test local repo that are used by a unit test, with hard
to document rationale
Seems like it is time to work on it now...

Regards,

Hervé

Le samedi 24 décembre 2016, 17:03:03 CET Robert Scholte a écrit :

With this commit commons-io gets the default scope.
Suppose PMD drops commons-io, then there's no reason that this dependency
has the compile scope.
Assuming the unittests are using commons-io it makes sense that it has the
test-scope.
Be aware that users can overwrite dependencies of plugins in their pom.xml
Developers can only know about the dependencies for their src/main/java
and src/test/java code, and cannot do any assumptions about transitive
dependencies due to all the override mechanisms in Maven.
It may be clear that I don't like these changes.

Robert

On Sat, 24 Dec 2016 15:56:53 +0100,  wrote:

Author: schulte
Date: Sat Dec 24 14:56:53 2016
New Revision: 1775971

URL: http://svn.apache.org/viewvc?rev=1775971=rev
Log:
[MPMD-230] Required class missing: org/apache/commons/io/IOUtils

Modified:
 maven/plugins/trunk/maven-pmd-plugin/pom.xml

Modified: maven/plugins/trunk/maven-pmd-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/pom.xml?
rev=1775971=1775970=1775971=diff
=
= --- maven/plugins/trunk/maven-pmd-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-pmd-plugin/pom.xml Sat Dec 24 14:56:53 2016
@@ -216,13 +216,13 @@ under the License.

org.apache.httpcomponents
httpclient
4.3.5

-  test
+  

  
  
  
commons-io

commons-io
2.5

-  test
+  

  



-
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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

2016-12-24 Thread Guillaume Boué




Le 24/12/2016 à 17:11, Hervé BOUTEMY a écrit :

Le vendredi 23 décembre 2016, 09:32:50 CET Christian Schulte a écrit :

Am 12/23/16 um 08:16 schrieb Hervé BOUTEMY:

Le vendredi 23 décembre 2016, 03:59:17 CET Christian Schulte a écrit :

Am 12/22/16 um 19:14 schrieb Robert Scholte:

-0.9 for the commandline option, there should be only one truth.

+1


Dependency management is way too important, you should not have an
option
to choose. Better to agree that we are indeed fixing a bug or that we
should maintain the current behavior. And that'll take time. I will have
a
look at all the related issues which could be controlled by this flag
and
find a way to get feedback from more people.

-1 for maintaining the current behavior. Issues will get reported over
and over again.

you keep saying that but don't give any other example than MPLUGIN-296 = a
failure caused by your purist fix in MRESOLVER-8
and you talked about findbugs-maven-plugin, but did not give any pointer

once again, can you give examples of something that MRESOLVER-8 fixes,
apart from the logic of exact resolution?

Why are you questioning making plugin resolution work the same way
project resolution is performed? I don't get that.

please look at "if it ain't broke, don't fix it" proverb, or "never change a
running system"

for example at https://en.wiktionary.org/wiki/if_it_ain't_broke,_don't_fix_it


The bugfix
immediately uncovered a mistake in a POM of a plugin everyone agrees to
be a real issue.

no, I don't agree that it is a real issue


I just verified that selector had that bug right from
the intial resolver contribution outside Apache so has always been
there. Right now only the maven-plugin-plugin version 3.4 is affected.
Version 3.3 and 3.5 are not affected.

I fear it's not only one plugin, but every plugin that applied the
scope=provided recipe that Maven Plugin Tools Annotations promotes


The findbugs-maven-plugin issue
I've been talking about is unrelated to the resolver and is also fixed
in recent releases.

ok, I don't know why you talked about it if it's not related

[...]


I respect logic, since I can imagine that in addition to the case that
worked magically, there can be cases that fail magically = not something
I want forever.
You found a few cases working magically = in fact one recipe based on it,
that is still in our documentation [1] as "").
If we didn't find cases failing magically, pressure to change is not the
same.

Things working magically are a recipe for desaster.

disaster didn't happen for years before your work on "fixing" something that
didn't break: remember to read about "if it ain't broke, don't fix it" proverb,
it has to be known and respected at least in some cases


It's just
unpredictable behaviour presented to be something done intentionally
although things are just a matter of luck or bad luck.

that's why I try to know if you have reported cases (as you told) of something
really broken (= something with bad luck)
IIUC, you don't have any case of bad luck


Especially when a
lot of the POMs around are a result of trial and error. Maven should
have produced an error but did not "magically". Chances are great
someone starts applying his findings to each and every project without
ever noticing things really are not working as intended. We should be
super sure that this trial and error always leads to valid POMs.


And of course, this wrong explanation in our doc should be fixed and
explained: I'll work on that (because, remember, I already told I'm
supportive of improvements): I opened MPLUGIN-321 [2], please review and
improve explanations if necessary = this is the start of something that
will also appear in release notes for the version of Maven that will
contaning the updated plugin resolution algorithm (we'll see later if
it's Maven 3.4.0 or not)

There is nothing wrong about that documentation. It's a special case
with the maven-plugin-plugin. Only that plugin must not use "provided"
for the annotations because that plugin is what needs them at runtime.
It is the provider itself. Other plugins should in fact use "provided"
because the annotations are provided by maven-plugin-plugin and not used
by anything else.

ok, I start to understand: no, the plugin does not provide the annotations
dependency (as I wrote in MPLUGIN-321, Maven core uses META-INF/maven/
plugin.xml) but this is one of the rare case where a dependency is simply *not
used* at runtime...


Ok, I now understand the real impact on plugins: no impact in general, only
maven-plugin-plugin is impacted because it uses annotations to extract
information from bytecode to generate META-INF/maven/plugin.xml

I'll improve MPLUGIN-296 description, which is currently at least not clear at
all (which I knew but could not get any useful answer)

But at least, now, I think I better imagine the impact of this bugfix of a bug
that nobody noticed: it just breaks maven-plugin-plugin, which is an edge case
of the bugfix edge case.
I feel more

Re: Scope promotion of managed dependencies in current Maven master

2016-12-19 Thread Guillaume Boué


Hi Michael,

I can reproduce that behaviour as well. In the current 3.4.0, a 
dependency management that declares a dependency with scope runtime will 
manage a transitive dependency of scope test. A reproducer is


  

  
org.slf4j
slf4j-simple
1.7.21
runtime
  

  
  

  test
  test
  1.0-SNAPSHOT

  

And having in the POM of test:

  

  org.slf4j
  slf4j-simple
  1.7.21
  test

  

This doesn't feel right to me: dependencies of scope test are not 
transitive, so the test scoped slf4j-simple shouldn't be considered 
during dependency resolution. I wouldn't also expect the 
dependencyManagement to change the scope of the inherited slf4j-simple 
(if it were to be inherited), since there are definite rules about which 
scope a transitive dependency should have depending on the scope of the 
declared dependency (summarized in the table here 
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).


Guillaume

Le 19/12/2016 à 15:56, Michael Osipov a écrit :

Hi folks,

I just tried a fresh Maven master (7d1d8ac0c14bdea6c92356436bfc6f8548cbae8b; 
2016-12-19T15:22:22+01:00)
on an in-house project.

My project's parent POM states in depMgmt:


   org.slf4j
   slf4j-api
   ${slf4j.version}


   org.slf4j
   jcl-over-slf4j
   ${slf4j.version}
   runtime


   org.slf4j
   slf4j-simple
   ${slf4j.version}
   runtime


nothing special so far, a WAR module dependends on 
net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
which has slf4j-simple in *test* scope. mvn dependency:tree with 3.3.9 properly 
gives me:

[DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile

Doing this with master gives me:

[DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
[DEBUG]   org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from 
test by com.company.project:project-parent:0.11-SNAPSHOT)

My questions are:
1. Is this another fix in master where I relied on an erratic behavior in core 
previously?
2. Should depMgmthave influence on transitive deps or direct only?

I cannot really say what's right or wrong but now I have two SLF4J bindings on 
my WAR classpath:
SLF4J Simple and Logback, now that is obviously wrong!

Any thoughts?

Michael

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Jenkins job of maven-parent is broken

2016-12-18 Thread Guillaume Boué


Awesome, thanks!


Le 18/12/2016 à 12:52, Hervé BOUTEMY a écrit :

this was a bug on the Jenkins slave, the JDK installation should have been
there:
https://issues.apache.org/jira/browse/INFRA-13129

Gavin fixed it, the build is now passing even on this slave

Regards,

Hervé

Le dimanche 18 décembre 2016, 11:10:21 CET Guillaume Boué a écrit :

Hi,

I noticed the job of maven-parent on Jenkins is failing, because it's
apparently looking for a JDK installation that doesn't exist
(/home/jenkins/tools/java/latest1.6/bin/java).

https://builds.apache.org/job/maven-parent/2062/console

Can someone with authorization to change the configuration fix this? It
hid a build issue with the update of the maven-checkstyle-plugin to 2.17
(MPOM-152) that I had locally.

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast. https://www.avast.com/antivirus


-
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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Jenkins job of maven-parent is broken

2016-12-18 Thread Guillaume Boué


Hi,

I noticed the job of maven-parent on Jenkins is failing, because it's
apparently looking for a JDK installation that doesn't exist
(/home/jenkins/tools/java/latest1.6/bin/java).

https://builds.apache.org/job/maven-parent/2062/console

Can someone with authorization to change the configuration fix this? It
hid a build issue with the update of the maven-checkstyle-plugin to 2.17
(MPOM-152) that I had locally.

Thanks,
Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [jira] [Created] (MPOM-152) Upgrade maven-checkstyle-plugin to 2.17.

2016-12-17 Thread Guillaume Boué

There might be a corner-case here. I remember an issue about this 
upgrade, a dependency onmaven-shared-resourcesneeded to be added:


https://issues.apache.org/jira/browse/MCHECKSTYLE-327?focusedCommentId=15383006=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15383006


Le 18/12/2016 à 01:09, Christian Schulte (JIRA) a écrit :

Christian Schulte created MPOM-152:
--

  Summary: Upgrade maven-checkstyle-plugin to 2.17.
  Key: MPOM-152
  URL: https://issues.apache.org/jira/browse/MPOM-152
  Project: Maven POMs
   Issue Type: Task
 Reporter: Christian Schulte
 Assignee: Christian Schulte
 Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: Cannot build any Maven plugins with current 3.4.0

2016-12-17 Thread Guillaume Boué

Yes, I confirm that the build of the Maven plugins is OK when checking 
out cc5af1306ff91d9bef68737c96c364a371a477d7.



Le 17/12/2016 à 16:43, Hervé BOUTEMY a écrit :

if you avoid the 3 last commits flagged as MNG-6135, you get a fairly working
Maven (even if 3 ITs are still failing)

I don't understand the intend of MNG-6135, but I see the result: a mess

Regards,

Hervé

Le samedi 17 décembre 2016, 15:47:34 CET Guillaume Boué a écrit :

Hi,

With the latest Maven 3.4.0, there is an API incompability with a Plexus
Util version when running the build of any Maven plugins. For example,
with the maven-dependency-plugin:

guillaume@guillaume-VirtualBox:~/workspace-maven/maven-plugins-aggregator/ma
ven-dependency-plugin$ mvn340 --version
Apache Maven 3.4.0-SNAPSHOT (14bff2c5c5a0729e39f7d0fc62ed733222c90a18;
2016-12-17T14:47:33+01:00)
Maven home: /usr/share/apache-maven-3.4.0-SNAPSHOT
Java version: 1.8.0_111, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-i386/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-47-generic", arch: "i386", family: "unix"
guillaume@guillaume-VirtualBox:~/workspace-maven/maven-plugins-aggregator/ma
ven-dependency-plugin$ mvn340 clean install -Prun-its
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building Apache Maven Dependency Plugin 3.0.1-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
maven-dependency-plugin ---
[INFO] Deleting
/home/guillaume/workspace-maven/maven-plugins-aggregator/maven-dependency-pl
ugin/target [INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce
(enforce-bytecode-version) @ maven-dependency-plugin ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce
(ban-known-bad-maven-versions) @ maven-dependency-plugin ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (ensure-no-container-api)
@ maven-dependency-plugin ---
[INFO]
[INFO] --- apache-rat-plugin:0.11:check (rat-check) @
maven-dependency-plugin ---
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 14.885 s
[INFO] Finished at: 2016-12-17T15:15:25+01:00
[INFO] Final Memory: 64M/318M
[INFO]

[ERROR] Failed to execute goal
org.apache.rat:apache-rat-plugin:0.11:check (rat-check) on project
maven-dependency-plugin: Execution rat-check of goal
org.apache.rat:apache-rat-plugin:0.11:check failed: An API
incompatibility was encountered while executing
org.apache.rat:apache-rat-plugin:0.11:check:
java.lang.IllegalAccessError: tried to access field
org.codehaus.plexus.util.DirectoryScanner.DEFAULTEXCLUDES from class
org.apache.rat.mp.AbstractRatMojo
[ERROR] -
[ERROR] realm =plugin>org.apache.rat:apache-rat-plugin:0.11
[ERROR] strategy =
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/rat/apache-rat-plugin/0.1
1/apache-rat-plugin-0.11.jar [ERROR] urls[1] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/maven/doxia/doxia-core/1.
2/doxia-core-1.2.jar [ERROR] urls[2] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/maven/doxia/doxia-logging
-api/1.2/doxia-logging-api-1.2.jar [ERROR] urls[3] =
file:/C:/Users/Guillaume/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2
.9.1.jar [ERROR] urls[4] =
file:/C:/Users/Guillaume/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.
3.04.jar [ERROR] urls[5] =
file:/C:/Users/Guillaume/.m2/repository/commons-lang/commons-lang/2.6/common
s-lang-2.6.jar [ERROR] urls[6] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/httpcomponents/httpclient
/4.0.2/httpclient-4.0.2.jar [ERROR] urls[7] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/httpcomponents/httpcore/4
.0.1/httpcore-4.0.1.jar [ERROR] urls[8] =
file:/C:/Users/Guillaume/.m2/repository/commons-logging/commons-logging/1.1.
1/commons-logging-1.1.1.jar [ERROR] urls[9] =
file:/C:/Users/Guillaume/.m2/repository/commons-codec/commons-codec/1.3/comm
ons-codec-1.3.jar [ERROR] urls[10] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/rat/apache-rat-core/0.11/
apache-rat-core-0.11.jar [ERROR] urls[11] =
file:/C:/Users/Guillaume/.m2/repository/commons-collections/commons-collecti
ons/3.2.1/commons-collections-3.2.1.jar [ERROR] urls[12] =
file:/C:/Users/Guillaume/.m2/repository/commons-io/commons-io/2.2/commons-io
-2.2.jar [ERROR] urls[13] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/commons/commons-compress/
1.5/commons-compress-1.5.jar [ERROR] urls[14] =
file:/C:/Users/Guillaume/.m2/repository/org/tukaani/xz/1.2/xz-1.2.jar
[ERROR] urls[15] =
file:/C:/Users/Guillaume

Cannot build any Maven plugins with current 3.4.0

2016-12-17 Thread Guillaume Boué


Hi,

With the latest Maven 3.4.0, there is an API incompability with a Plexus
Util version when running the build of any Maven plugins. For example,
with the maven-dependency-plugin:

guillaume@guillaume-VirtualBox:~/workspace-maven/maven-plugins-aggregator/maven-dependency-plugin$
mvn340 --version
Apache Maven 3.4.0-SNAPSHOT (14bff2c5c5a0729e39f7d0fc62ed733222c90a18;
2016-12-17T14:47:33+01:00)
Maven home: /usr/share/apache-maven-3.4.0-SNAPSHOT
Java version: 1.8.0_111, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-i386/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-47-generic", arch: "i386", family: "unix"
guillaume@guillaume-VirtualBox:~/workspace-maven/maven-plugins-aggregator/maven-dependency-plugin$
mvn340 clean install -Prun-its
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building Apache Maven Dependency Plugin 3.0.1-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
maven-dependency-plugin ---
[INFO] Deleting
/home/guillaume/workspace-maven/maven-plugins-aggregator/maven-dependency-plugin/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce
(enforce-bytecode-version) @ maven-dependency-plugin ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce
(ban-known-bad-maven-versions) @ maven-dependency-plugin ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (ensure-no-container-api)
@ maven-dependency-plugin ---
[INFO]
[INFO] --- apache-rat-plugin:0.11:check (rat-check) @
maven-dependency-plugin ---
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 14.885 s
[INFO] Finished at: 2016-12-17T15:15:25+01:00
[INFO] Final Memory: 64M/318M
[INFO]

[ERROR] Failed to execute goal
org.apache.rat:apache-rat-plugin:0.11:check (rat-check) on project
maven-dependency-plugin: Execution rat-check of goal
org.apache.rat:apache-rat-plugin:0.11:check failed: An API
incompatibility was encountered while executing
org.apache.rat:apache-rat-plugin:0.11:check:
java.lang.IllegalAccessError: tried to access field
org.codehaus.plexus.util.DirectoryScanner.DEFAULTEXCLUDES from class
org.apache.rat.mp.AbstractRatMojo
[ERROR] -
[ERROR] realm =plugin>org.apache.rat:apache-rat-plugin:0.11
[ERROR] strategy =
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/rat/apache-rat-plugin/0.11/apache-rat-plugin-0.11.jar
[ERROR] urls[1] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/maven/doxia/doxia-core/1.2/doxia-core-1.2.jar
[ERROR] urls[2] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.2/doxia-logging-api-1.2.jar
[ERROR] urls[3] =
file:/C:/Users/Guillaume/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar
[ERROR] urls[4] =
file:/C:/Users/Guillaume/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.jar
[ERROR] urls[5] =
file:/C:/Users/Guillaume/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
[ERROR] urls[6] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/httpcomponents/httpclient/4.0.2/httpclient-4.0.2.jar
[ERROR] urls[7] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/httpcomponents/httpcore/4.0.1/httpcore-4.0.1.jar
[ERROR] urls[8] =
file:/C:/Users/Guillaume/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
[ERROR] urls[9] =
file:/C:/Users/Guillaume/.m2/repository/commons-codec/commons-codec/1.3/commons-codec-1.3.jar
[ERROR] urls[10] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/rat/apache-rat-core/0.11/apache-rat-core-0.11.jar
[ERROR] urls[11] =
file:/C:/Users/Guillaume/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
[ERROR] urls[12] =
file:/C:/Users/Guillaume/.m2/repository/commons-io/commons-io/2.2/commons-io-2.2.jar
[ERROR] urls[13] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/commons/commons-compress/1.5/commons-compress-1.5.jar
[ERROR] urls[14] =
file:/C:/Users/Guillaume/.m2/repository/org/tukaani/xz/1.2/xz-1.2.jar
[ERROR] urls[15] =
file:/C:/Users/Guillaume/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
[ERROR] urls[16] =
file:/C:/Users/Guillaume/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[17] =
file:/C:/Users/Guillaume/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[18] =
file:/C:/Users/Guillaume/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.2/doxia-decoration-model-1.2.jar
[ERROR] urls[19] =

Fwd: Build failed in Jenkins: maven-enforcer #245

2016-11-26 Thread Guillaume Boué


Hmm, the error is

java.lang.IllegalArgumentException 
: /home/jenkins/tools/maven/apache-maven-3.0.5 doesn't have a 'lib' subdirectory - thus cannot be a valid maven installation!


Could someone take a look at the maven-enforcer job on Jenkins? The last 
build went fine, but it seems there was a change in the Maven 
installation used?


Thanks,
Guillaume


 Message transféré 
Sujet : Build failed in Jenkins: maven-enforcer #245
Date :  Sat, 26 Nov 2016 22:50:25 + (UTC)
De :Apache Jenkins Server 
Pour :  notificati...@maven.apache.org, gb...@apache.org



See 

Changes:

[gboue] [MENFORCER-247] Add a "require file checksum" rule
Submitted by: Lyubomyr Shaydariv

New RequireFileChecksum, rule that is non cacheable and inherits from 
AbstractNonCacheableEnforcerRule. This closes #18.

--
[...truncated 280 lines...]
A 
enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer
A 
enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer/rule
AU
enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer/rule/MyCustomRule.java
AUenforcer-api/src/custom-rule-sample/pom.xml
AUenforcer-api/src/custom-rule-sample/usage-pom.xml
AUenforcer-api/pom.xml
AUpom.xml
A README.TXT
A enforcer-rules
A enforcer-rules/src
A enforcer-rules/src/main
A enforcer-rules/src/main/java
A enforcer-rules/src/main/java/org
A enforcer-rules/src/main/java/org/apache
A enforcer-rules/src/main/java/org/apache/maven
A enforcer-rules/src/main/java/org/apache/maven/plugins
A enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireReleaseDeps.java
A 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireUpperBoundDeps.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractVersionEnforcer.java
A 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDistributionManagement.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependencies.java
A 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedRepositories.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireFileChecksum.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractStandardEnforcerRule.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireFilesDontExist.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSnapshotVersion.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DefaultEnforcementRuleHelper.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireEnvironmentVariable.java
A 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSameVersions.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/NoSnapshots.java
A 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanTransitiveDependencies.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireNoRepositories.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractRequireFiles.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireReleaseVersion.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AlwaysPass.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireActiveProfile.java
A 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedPlugins.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireFilesSize.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AlwaysFail.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java
A 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDuplicatePomDependencyVersions.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractNonCacheableEnforcerRule.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/EnforcerExpressionEvaluator.java
AU
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireMavenVersion.java
AU

Re: Need to change a test case in 'maven-filtering'.

2016-11-22 Thread Guillaume Boué


Hi Christian,

This test looks normal to me. When loading the properties, through load 
https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader-, 
the backslash indicates the line terminator, so it needs to be escaped, 
otherwise the method would (silently) ignore it (if it doesn't represent 
a valid escape sequence). So having


edge.escape.hanging=\\


in the properties file means that you'll read "\" for the 
"edge.escape.hanging" property on the Java side. So it's testing that a 
lone escape character doesn't cause any issues during filtering.


Guillaume

Le 22/11/2016 à 01:21, Christian Schulte a écrit :

Hi,

I am currently working on
 and am running into
an issue. With the fix in place an existing test case will start
failing. Here is the issue:

Please take a look at the following line

edge.escape.hanging=\\

from

.


With the fix in place, I would need to change that to

edge.escape.hanging=\

because the input to the filter looks like:

edge.escape.hanging=\\

in

and that is an escaped escape string which would need to become '\'
after filtering. Can I just remove that test case? I expect it is
testing something isn't hanging from somewhere in the past? Well. Seems
it is testing that escaping the escape string does not make something
hang - but incorrectly.

Regards,



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: maven git commit: MNG-5889 - adding logic that looks for the file argument and starts the search for the .mvn directory at the location of the specified POM when present

2016-11-17 Thread Guillaume Boué


Hi,

This caused some ITs to fail on Windows, which I fixed in commit 8ae1a3e9.

There is still one failing IT: 
MavenITmng4625SettingsXmlInterpolationWithXmlMarkupTest. It fails with 
master and Java 8 (on my machine). Looking at the code, it seems more of 
an issue with the test that the script itself. I'm not sure why it 
started to fail in build #1372. Was there a Java version change on Jenkins?


Thanks,
Guillaume

Le 14/11/2016 à 23:12, hbout...@apache.org a écrit :

Repository: maven
Updated Branches:
   refs/heads/master 93a71e2de -> da5b4df93


MNG-5889 - adding logic that looks for the file argument and starts the
search for the .mvn directory at the location of the specified POM when
present


Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/da5b4df9
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/da5b4df9
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/da5b4df9

Branch: refs/heads/master
Commit: da5b4df930925a0cbee95cfdca5c249ff143d91b
Parents: 93a71e2
Author: robert.patrick 
Authored: Thu Sep 15 09:53:06 2016 -0500
Committer: HervÃ© Boutemy 
Committed: Mon Nov 14 22:28:55 2016 +0100

--
  apache-maven/src/bin/mvn | 31 +++--
  apache-maven/src/bin/mvn.cmd | 58 ---
  2 files changed, 83 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven/blob/da5b4df9/apache-maven/src/bin/mvn
--
diff --git a/apache-maven/src/bin/mvn b/apache-maven/src/bin/mvn
index ff6f250..e795073 100755
--- a/apache-maven/src/bin/mvn
+++ b/apache-maven/src/bin/mvn
@@ -121,7 +121,7 @@ fi
  # first directory with .mvn subdirectory is considered project base directory
  find_maven_basedir() {
  (
-  basedir="`pwd`"
+  basedir=`find_file_argument_basedir "$@"`
wdir="`pwd`"
while [ "$wdir" != '/' ] ; do
  if [ -d "$wdir"/.mvn ] ; then
@@ -134,6 +134,33 @@ find_maven_basedir() {
  )
  }
  
+find_file_argument_basedir() {

+(
+  basedir="`pwd`"
+
+  found_file_switch=0
+  for arg in "$@"; do
+if [ ${found_file_switch} -eq 1 ]; then
+  if [ -f ${arg} ]; then
+basedir=$(dirname $(readlink -f "${arg}"))
+if [ ! -d ${basedir} ]; then
+  echo "Directory ${basedir} extracted from the -f/--file command-line argument 
${arg} does not exist" >&2
+  exit 1
+fi
+  else
+echo "POM file ${arg} specified with the -f/--file command line argument does not 
exist" >&2
+exit 1
+  fi
+  break
+fi
+if [ "$arg" = "-f" -o "$arg" = "--file" ]; then
+  found_file_switch=1
+fi
+  done
+  echo "${basedir}"
+)
+}
+
  # concatenates all lines of a file
  concat_lines() {
if [ -f "$1" ]; then
@@ -141,7 +168,7 @@ concat_lines() {
fi
  }
  
-MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"

+MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
  MAVEN_OPTS="`concat_lines "$MAVEN_PROJECTBASEDIR/.mvn/jvm.config"` 
$MAVEN_OPTS"
  
  # For Cygwin, switch project base directory path to Windows format before


http://git-wip-us.apache.org/repos/asf/maven/blob/da5b4df9/apache-maven/src/bin/mvn.cmd
--
diff --git a/apache-maven/src/bin/mvn.cmd b/apache-maven/src/bin/mvn.cmd
index cd81e42..21829fa 100644
--- a/apache-maven/src/bin/mvn.cmd
+++ b/apache-maven/src/bin/mvn.cmd
@@ -86,19 +86,69 @@ set MAVEN_CMD_LINE_ARGS=%*
  set MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%
  if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
  
-set "EXEC_DIR=%CD%"

-set "WDIR=%EXEC_DIR%"
+set EXEC_DIR=%CD%
+set WDIR=%EXEC_DIR%
+
+@REM Look for the --file switch and start the search for the .mvn directory 
from the specified
+@REM POM location, if supplied.
+
+set FILE_ARG=
+:arg_loop
+if "%1" == "-f" (
+  set "FILE_ARG=%2"
+  shift
+  goto process_file_arg
+)
+if "%1" == "--file" (
+  set "FILE_ARG=%2"
+  shift
+  goto process_file_arg
+)
+@REM If none of the above, skip the argument
+shift
+if not "%~1" == "" (
+  goto arg_loop
+) else (
+  goto findBaseDir
+)
+
+:process_file_arg
+if "%FILE_ARG%" == "" (
+  goto findBaseDir
+)
+if not exist "%FILE_ARG%" (
+  echo POM file %FILE_ARG% specified the -f/--file command-line argument does not 
exist >&2
+  goto error
+)
+call :get_directory_from_file %FILE_ARG%
+if not exist "%POM_DIR%" (
+  echo Directory %POM_DIR% extracted from the -f/--file command-line argument 
%FILE_ARG% does not exist >&2
+  goto error
+)
+set WDIR=%POM_DIR%
+goto findBaseDir
+
+:get_directory_from_file
+set "POM_DIR=%~dp1"
+:stripPomDir
+if not "_%POM_DIR:~-1%"=="_\" goto pomDirStripped
+set "POM_DIR=%POM_DIR:~0,-1%"
+goto stripPomDir
+:pomDirStripped

Re: Build failed in Jenkins: maven-plugins-ITs-m3-windows #1762

2016-11-13 Thread Guillaume Boué


Hi,

About the OS name printed, it's a bug in Java 7, that is fixed for 9 and 
was backported down to 8u60, see 
https://bugs.openjdk.java.net/browse/JDK-8066504. This is what I have on 
my machine with Java 8u102:


Apache Maven 3.4.0-SNAPSHOT 
(NON-CANONICAL_2016-11-12T18:53:10+01:00_Guillaume; 
2016-11-12T18:53:10+01:00)

Maven home: C:\apache-maven-3.4.0-SNAPSHOT\bin\..
Java version: 1.8.0_102, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_102\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

So it correctly shows "windows 10".

About the ITs, they don't fail with 3.4.0-SNAPSHOT, but they do with 
3.3.9 on Windows. This was fixed in 3.4.0 with 
https://issues.apache.org/jira/browse/MNG-5962. On other systems, they 
work fine for both 3.3.9 and current 3.4.0-SNAPSHOT.


Guillaume


Le 13/11/2016 à 06:02, Christian Schulte a écrit :

Is there something special about

OS name: "windows server 2012 r2", version: "6.3", arch: "amd64",
family: "windows"

?

I verified the ITs do pass using

Apache Maven 3.4.0-SNAPSHOT (a6f8bd1712a5ae30068424651bac35d2909dc4c1;
2016-11-12T22:15:03+01:00)
Maven home: C:\Users\schulte\Anwendungen\apache-maven-3.4.0-SNAPSHOT\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_80\jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

That's what gets printed for Windows 10 Pro (Microsoft Windows [Version
10.0.14393]), BTW. Someone knows what is failing on Jenkins?

Am 13.11.2016 um 04:02 schrieb Apache Jenkins Server:

See 

Changes:

[schulte] [MRESOURCES-234] Upgrade of commons-io to 2.5 and correction of 
invalid scope.

[schulte] [MWAR-398] Upgrade of plexus-interpolation to 1.24 to correct 
escaping issue.

[schulte] [MRESOURCES-233] Upgrade of plexus-interpolation 1.24 to correct 
escaping issue.

[schulte] [MRRESOURCES-99] Upgrade of plexus-interpolation to 1.24.

[schulte] [MRAR-66] Upgrade of plexus-interpolation to 1.24.

[gboue] [MPH-105] Effective pom aggregation is not triggered

When the plugin is invoked from the command-line, always show all effective 
POMs for all projects in the reactor. When it is invoked from the lifecycle, 
only show all effective POMs for the head project in the reactor (see commit 
497785 and resolution of MPH-21); otherwise, show the effective POM for the 
current project only.

[schulte] [MPIR-350] Upgrade of plexus-interpolation to 1.24.

[schulte] [MPDF-79] Upgrade of plexus-interpolation to 1.24.

[schulte] [MINVOKER-212] Upgrade of plexus-interpolation to 1.24.

[schulte] [MEJB-107] Upgrade of plexus-interpolation to 1.24.

[schulte] [MEAR-245] Upgrade of plexus-interpolation to 1.24.

[schulte] [MDOAP-48] Upgrade of plexus-interpolation to 1.24.

[schulte] [MCHANGES-377] Upgrade of plexus-interpolation to 1.24.

[schulte] [MDEP-544] Upgrade of plexus-interpolation to 1.24.

[schulte] [MCHECKSTYLE-331] Upgrade of plexus-interpolation to 1.24.

[schulte] [MACR-41] Upgrade of plexus-interpolation 1.24 to correct escaping 
issue.

--
[...truncated 11465 lines...]
[INFO] Installing 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-checkstyle-plugin\target\maven-checkstyle-plugin-2.18-SNAPSHOT.jar
 to 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-dependency-plugin\target\local-repo\org\apache\maven\plugins\maven-checkstyle-plugin\2.18-SNAPSHOT\maven-checkstyle-plugin-2.18-SNAPSHOT.jar
[INFO] Installing 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-checkstyle-plugin\pom.xml
 to 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-dependency-plugin\target\local-repo\org\apache\maven\plugins\maven-checkstyle-plugin\2.18-SNAPSHOT\maven-checkstyle-plugin-2.18-SNAPSHOT.pom
[INFO] Installing 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-pmd-plugin\pom.xml
 to 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-dependency-plugin\target\local-repo\org\apache\maven\plugins\maven-pmd-plugin\3.8-SNAPSHOT\maven-pmd-plugin-3.8-SNAPSHOT.pom
[INFO] Installing 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-pmd-plugin\target\maven-pmd-plugin-3.8-SNAPSHOT.jar
 to 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-dependency-plugin\target\local-repo\org\apache\maven\plugins\maven-pmd-plugin\3.8-SNAPSHOT\maven-pmd-plugin-3.8-SNAPSHOT.jar
[INFO] Installing 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-pmd-plugin\pom.xml
 to 
F:\jenkins\jenkins-slave\workspace\maven-plugins-ITs-m3-windows\maven-dependency-plugin\target\local-repo\org\apache\maven\plugins\maven-pmd-plugin\3.8-SNAPSHOT\maven-pmd-plugin-3.8-SNAPSHOT.pom
[INFO] Installing

Re: [jira] [Commented] (MPH-120) Migrate plugin to Maven 3.0

2016-11-12 Thread Guillaume Boué


Hi,

Since the plugin was migrated to Maven 3, would it be possible to rename 
the current 2.2.1 version in JIRA to 3.0.0? This way, I can close this 
issue with the right fix version.


Thanks,
Guillaume

Le 11/11/2016 à 18:33, Hudson (JIRA) a écrit :

 [ 
https://issues.apache.org/jira/browse/MPH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15657606#comment-15657606
 ]

Hudson commented on MPH-120:


SUCCESS: Integrated in Jenkins build maven-plugins #7593 (See 
[https://builds.apache.org/job/maven-plugins/7593/])
[MPH-120] Migrate plugin to Maven 3.0

Bump Maven requirement to 3.0 and version of the plugin to 3.0.0-SNAPSHOT. Replacing 
deprecated APIs like ArtifactFactory with the use of the shared components and removing Maven 
2 specific code. The "expressions" goal that was Maven 2 specific is removed (it is 
now covered in the Javadoc of PluginParameterExpressionEvaluator). (gboue: 
[http://svn.apache.org/viewvc/?view=rev=1769319])
* (edit) maven-help-plugin/pom.xml
* (add) maven-help-plugin/src/it/active-profiles/verify.groovy
* (edit) maven-help-plugin/src/it/active-profiles_multimodule/module/pom.xml
* (edit) maven-help-plugin/src/it/active-profiles_multimodule/verify.groovy
* (edit) maven-help-plugin/src/it/all-profiles/pom.xml
* (edit) maven-help-plugin/src/it/all-profiles/verify.groovy
* (add) maven-help-plugin/src/it/describe-cmd-invalid
* (add) maven-help-plugin/src/it/describe-cmd-invalid/invoker.properties
* (add) maven-help-plugin/src/it/describe-cmd-invalid/pom.xml
* (add) maven-help-plugin/src/it/describe-cmd-invalid/test.properties
* (add) maven-help-plugin/src/it/describe-cmd-with-goal-invalid
* (add) 
maven-help-plugin/src/it/describe-cmd-with-goal-invalid/invoker.properties
* (add) maven-help-plugin/src/it/describe-cmd-with-goal-invalid/pom.xml
* (add) maven-help-plugin/src/it/describe-cmd-with-goal-invalid/test.properties
* (edit) maven-help-plugin/src/it/describe-cmd-with-goal/test.properties
* (add) maven-help-plugin/src/it/describe-cmd-with-goal/verify.groovy
* (edit) maven-help-plugin/src/it/describe-cmd/invoker.properties
* (add) maven-help-plugin/src/it/describe-cmd/test-deploy.properties
* (add) maven-help-plugin/src/it/describe-cmd/test-site.properties
* (delete) maven-help-plugin/src/it/describe-cmd/test.properties
* (add) maven-help-plugin/src/it/describe-cmd/verify.groovy
* (add) maven-help-plugin/src/it/describe-plugin-without-name
* (add) maven-help-plugin/src/it/describe-plugin-without-name/invoker.properties
* (add) maven-help-plugin/src/it/describe-plugin-without-name/pom.xml
* (add) maven-help-plugin/src/it/describe-plugin-without-name/test.properties
* (add) maven-help-plugin/src/it/describe-plugin-without-name/verify.groovy
* (add) maven-help-plugin/src/it/evaluate-settings-servers
* (add) maven-help-plugin/src/it/evaluate-settings-servers/invoker.properties
* (add) maven-help-plugin/src/it/evaluate-settings-servers/pom.xml
* (add) maven-help-plugin/src/it/evaluate-settings-servers/test.properties
* (add) maven-help-plugin/src/it/evaluate-settings-servers/verify.groovy
* (add) maven-help-plugin/src/it/evaluate/verify.groovy
* (delete) maven-help-plugin/src/it/expressions
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/AbstractHelpMojo.java
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/ActiveProfilesMojo.java
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/AllProfilesMojo.java
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EffectivePomMojo.java
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EffectiveSettingsMojo.java
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/EvaluateMojo.java
* (delete) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/ExpressionsMojo.java
* (delete) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/HelpUtil.java
* (delete) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/LoggerRetriever.java
* (edit) 
maven-help-plugin/src/main/java/org/apache/maven/plugins/help/SystemMojo.java
* (edit) maven-help-plugin/src/site/apt/examples/describe-configuration.apt
* (edit) maven-help-plugin/src/site/apt/index.apt.vm
* (edit) maven-help-plugin/src/site/apt/usage.apt
* (add) 
maven-help-plugin/src/test/java/org/apache/maven/plugins/help/ActiveProfilesMojoTest.java
* (add) 
maven-help-plugin/src/test/java/org/apache/maven/plugins/help/AllProfilesMojoTest.java
* (edit) 
maven-help-plugin/src/test/java/org/apache/maven/plugins/help/DescribeMojoTest.java
* (edit) 
maven-help-plugin/src/test/java/org/apache/maven/plugins/help/EvaluateMojoTest.java
* (delete) 
maven-help-plugin/src/test/java/org/apache/maven/plugins/help/ExpressionsMojoTest.java
* (delete)

Re: [jira] [Created] (MNG-6111) incorrect text in help:describe for cmd

2016-11-11 Thread Guillaume Boué


Thanks Karl Heinz!


Le 11/11/2016 à 17:15, Karl Heinz Marbaise a écrit :

Hi Guillaume,

Done so

https://issues.apache.org/jira/browse/MPH-121

Kind regards
Karl Heinz Marbaise

On 11/11/16 16:55, Guillaume Boué wrote:

This issue is for the Maven Help Plugin. Can someone move it to the MPH
JIRA?

Thanks,
Guillaume

Le 11/11/2016 à 13:23, aaa (JIRA) a écrit :

aaa created MNG-6111:


  Summary: incorrect text in help:describe for cmd
  Key: MNG-6111
  URL: https://issues.apache.org/jira/browse/MNG-6111
  Project: Maven
   Issue Type: Bug
   Components: Plugins and Lifecycle
 Affects Versions: 3.3.9
 Reporter: aaa
 Priority: Minor


For example, run "mvn help:describe -Dcmd=post-site" and the text that
comes back is:
...
[INFO] 'post-site' is a lifecycle with the following phases:
* pre-site: Not defined
* site: org.apache.maven.plugins:maven-site-plugin:3.3:site
* post-site: Not defined
* site-deploy: org.apache.maven.plugins:maven-site-plugin:3.3:deploy
...

Should this not be
[INFO] 'post-site' is a phase within the 'site' lifecycle:
* pre-site: Not defined
* site: org.apache.maven.plugins:maven-site-plugin:3.3:site
* post-site: Not defined
* site-deploy: org.apache.maven.plugins:maven-site-plugin:3.3:deploy

or
[INFO] 'post-site' is a phase within the following lifecycle:
* pre-site: Not defined
* site: org.apache.maven.plugins:maven-site-plugin:3.3:site
* post-site: Not defined
* site-deploy: org.apache.maven.plugins:maven-site-plugin:3.3:deploy

Doesn't make any odds to the functionality but, as far as I can tell,
the text is not consistent with the documentation of how lifecycle,
phase, plugin and goal are related.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)




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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: [jira] [Created] (MNG-6111) incorrect text in help:describe for cmd

2016-11-11 Thread Guillaume Boué

This issue is for the Maven Help Plugin. Can someone move it to the MPH 
JIRA?


Thanks,
Guillaume

Le 11/11/2016 à 13:23, aaa (JIRA) a écrit :

aaa created MNG-6111:


  Summary: incorrect text in help:describe for cmd
  Key: MNG-6111
  URL: https://issues.apache.org/jira/browse/MNG-6111
  Project: Maven
   Issue Type: Bug
   Components: Plugins and Lifecycle
 Affects Versions: 3.3.9
 Reporter: aaa
 Priority: Minor


For example, run "mvn help:describe -Dcmd=post-site" and the text that comes 
back is:
...
[INFO] 'post-site' is a lifecycle with the following phases:
* pre-site: Not defined
* site: org.apache.maven.plugins:maven-site-plugin:3.3:site
* post-site: Not defined
* site-deploy: org.apache.maven.plugins:maven-site-plugin:3.3:deploy
...

Should this not be
[INFO] 'post-site' is a phase within the 'site' lifecycle:
* pre-site: Not defined
* site: org.apache.maven.plugins:maven-site-plugin:3.3:site
* post-site: Not defined
* site-deploy: org.apache.maven.plugins:maven-site-plugin:3.3:deploy

or
[INFO] 'post-site' is a phase within the following lifecycle:
* pre-site: Not defined
* site: org.apache.maven.plugins:maven-site-plugin:3.3:site
* post-site: Not defined
* site-deploy: org.apache.maven.plugins:maven-site-plugin:3.3:deploy

Doesn't make any odds to the functionality but, as far as I can tell, the text 
is not consistent with the documentation of how lifecycle, phase, plugin and 
goal are related.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Maven Artifact Transfer Shared Component Release 1.0.0 ?

2016-10-29 Thread Guillaume Boué

About Maven Artifact Transfer, I have 
https://issues.apache.org/jira/browse/MSHARED-596, which would help 
notably in the Install Plugin, and would also simplify the usage of the 
ProjectInstaller.


It would be great to have this in the release; there's a patch attached, 
but looking for feedback.


Thanks,
Guillaume

Le 29/10/2016 à 18:48, Karl Heinz Marbaise a écrit :

Hi Robert,

On 29/10/16 16:24, Robert Scholte wrote:

1.0.0 suggest pretty final to me. I suggest 0.9.0 instead (even though
0.10.0 is a valid version too, still many see 0.9 as "almost final" )


0.9.0 ...sure 0.10.0 is valid too...


Yes that makes it more clear that it is not fully ready...

Kind regards
Karl Heinz Marbaise



Robert

On Sat, 29 Oct 2016 14:03:46 +0200, Karl Heinz Marbaise
 wrote:


Hi to all,

cause the missing release of the shared component is currently
blocking other plugins from being released...


I would suggest to make a 1.0.0 release of the maven-artifact-transfer
shared component so we have the chance to release other plugins like:

maven-install-plugin,
maven-deploy-plugin,
maven-dependency-plugin,
maven-assembly-plugin

afterwards...

I have intentially selected an 1.0.0 so we are able to change the
interfaces if we need and can create a release 2.0.0 or 3.0.0 to
reflect those changes simply...

WDYT ?




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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: svn commit: r1765195 - /maven/plugins/trunk/maven-compiler-plugin/src/site/apt/examples/set-compiler-source-and-target.apt.vm

2016-10-19 Thread Guillaume Boué


Yes that would be nice.

Also, in the same way as there is a note for "target", I thought of 
adding a note about the usage of "source"; it doesn't guarantee that the 
code can compile with the specified JDK version. For that, you need to 
use toolchains (and we can link to the Toolchain Plugin).


Guillaume,


Le 19/10/2016 à 08:09, Hervé BOUTEMY a écrit :

good idea

when I see that, I think we should also talk about maven.compiler.source and
maven.compiler target properties in this focused page, isn't it?

Regards,

Hervé

Le dimanche 16 octobre 2016 22:38:01 gb...@apache.org a écrit :

Author: gboue
Date: Sun Oct 16 22:38:01 2016
New Revision: 1765195

URL: http://svn.apache.org/viewvc?rev=1765195=rev
Log:
Updating the "Setting the -source and -target of the Java Compiler"
documentation page by referencing Java 8 features instead of Java 4. This
closes #69.

Modified:

maven/plugins/trunk/maven-compiler-plugin/src/site/apt/examples/set-compile

r-source-and-target.apt.vm

Modified:
maven/plugins/trunk/maven-compiler-plugin/src/site/apt/examples/set-compile
r-source-and-target.apt.vm URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-compiler-plugin/src/
site/apt/examples/set-compiler-source-and-target.apt.vm?rev=1765195=17651
94=1765195=diff
===
=== ---
maven/plugins/trunk/maven-compiler-plugin/src/site/apt/examples/set-compile
r-source-and-target.apt.vm (original) +++
maven/plugins/trunk/maven-compiler-plugin/src/site/apt/examples/set-compile
r-source-and-target.apt.vm Sun Oct 16 22:38:01 2016 @@ -33,9 +33,9 @@
Setting the <<<-source>>> and <<<-target
such command using <<<-source>>> and <<<-target>>>.  The Compiler Plugin
can also be configured to provide these options during compilation.

-  For example, if you want to enable assertions (<<<-source 1.4>>>) and
also want the -  compiled classes to be compatible with JVM 1.4 (<<<-target
1.4>>>), you can then -  put:
+  For example, if you want to use the Java 8 language features (<<<-source
1.8>>>) +  and also want the compiled classes to be compatible with JVM 1.8
(<<<-target 1.8>>>), +  you can then put:

  +-
  
@@ -48,8 +48,8 @@ Setting the <<<-source>>> and <<<-target
  maven-compiler-plugin
  ${project.version}
  
-  1.4
-  1.4
+  1.8
+  1.8
  

  


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Support for getting local metadata in RepositoryManager

2016-10-15 Thread Guillaume Boué


Hi Karl Heinz,

So I went ahead and created 
https://issues.apache.org/jira/browse/MSHARED-596 for this. The ticket 
is about adding "getPathForLocalMetadata" on the RepositoryManager. In 
turn, this would simplify DefaultProjectInstaller. I attached a patch to 
it but would like some comments before applying it.


Thanks,
Guillaume

Le 09/10/2016 à 15:01, Karl Heinz Marbaise a écrit :

Hi Guillaume,

This is already used in other locations of the maven-artifact-transfer...

Maven30ArtifactRepositoryAdapter, Maven31ArtifactRepositoryAdapter, 
Maven30ArtifactDeployer, Maven31ArtifactDeployer...only to mention a 
few...


org.apache.maven.repository.legacy.metadata.ArtifactMetadata is not 
deprecated and the interface



public interface ArtifactMetadata
extends org.apache.maven.repository.legacy.metadata.ArtifactMetadata
{
void merge( ArtifactMetadata metadata );
}

So the question is simply if we need the merge method? But I'm not 
sure if we should go to legacy area here?


Someone who has a better suggestion/alternatives?


Kind regards
Karl Heinz


On 09/10/16 14:54, Guillaume Boué wrote:

The only quirk is that
org.apache.maven.artifact.metadata.ArtifactMetadata is deprecated... so
this would add usage of the deprecated interface in RepositoryManager.
What is the alternative for this?


Le 09/10/2016 à 14:36, Karl Heinz Marbaise a écrit :

Hi Buillaume,

On 09/10/16 14:28, Guillaume Boué wrote:

If the caller needs to force a different local repository than the one
in the Maven session, they can already call
"repositoryManager.setLocalRepositoryBasedir" on the building request
that is passed to ProjectInstaller. This is what the plugins using
ArtifactInstaller are already doing, and it would be simpler than
creating a whole new MavenArtifactRepository and passing that. Maybe
this ArtifactRepository parameter could even be removed?

For now, its current use by the ProjectInstaller is only to get the 
path

to the metadata to install checksums for them, and this is only needed
because there is no "getPathForLocalMetadata" on the 
RepositoryManager.

How about adding this method, that would delegate to proper
implementation classes for Maven 3.1 or 3.0?


Sounds better and cleaner...


Kind regards
Karl Heinz





Le 09/10/2016 à 11:31, Karl Heinz Marbaise a écrit :

Hi,

Yes it has been introduced by me...and yes not all plugins are using
it cause I would like to have some tests before spreading it to the
"world" of plugins..

Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not 
always

the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué 
<gb...@apache.org>

wrote:


Hi,

 From what I checked, I don't think those plugins should be 
impacted

since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would
get
the path to the artifact with 
"artifactRepository.pathOf(artifact)".

And then go with the one using the RepositoryManager or not,
depending
on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200, <gb...@apache.org> wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the 
local

repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 






Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 





URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929=1763928=1763929=diff 





== 




---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstal

Re: Cannot build current master.

2016-10-11 Thread Guillaume Boué

Regarding this failure, I think it is caused by a capitalization 
issue... The test is looking for 
"missing-artifactid-pluginManagement.xml" (lowercase "i" at artifactid) 
while the file on disk is called 
"missing-artifactId-pluginManagement.xml" (uppercase "i"). I don't have 
the issue on Windows (since I believe it is case insensitive), and don't 
have a Ubuntu box to test this right now.


To me, we just need to change line 647 of DefaultModelValidatorTest to 
have an uppercase "i" at "artifactId".


Guillaume


Le 11/10/2016 à 07:47, Karl Heinz Marbaise a écrit :

Hi,

interesting, cause I couldn't reproduce the issue on my system ..only 
the build server shows an test failure...


I need to investigage the reason for that ...cause other tests from 
the same folder working...


Are you running on Linux / Mac / Windows ? Java Version?

Kind regards
Karl Heinz

On 11/10/16 01:27, Christian Schulte wrote:

Just updated current master and am getting test failures. Just my local
checkout?

$ env LC_ALL=C git branch
* master
  maven-3.x-next

$ env LC_ALL=C git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

testInvalidArtifactIdInPluginManagement(org.apache.maven.model.validation.DefaultModelValidatorTest) 


Time elapsed: 0.04 sec  <<< FAILURE!
junit.framework.AssertionFailedError: missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml
at
org.apache.maven.model.validation.DefaultModelValidatorTest.read(DefaultModelValidatorTest.java:46) 


at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:79) 


at
org.apache.maven.model.validation.DefaultModelValidatorTest.validateRaw(DefaultModelValidatorTest.java:59) 


at
org.apache.maven.model.validation.DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement(DefaultModelValidatorTest.java:647) 



Failed tests:

DefaultModelValidatorTest.testInvalidArtifactIdInPluginManagement:647->validateRaw:59->validateRaw:79->read:46 


missing resource:
/poms/validation/raw-model/missing-artifactid-pluginManagement.xml

[INFO] Maven Model Builder  FAILURE [
22.377 s]


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

2016-10-09 Thread Guillaume Boué

The only quirk is that 
org.apache.maven.artifact.metadata.ArtifactMetadata is deprecated... so 
this would add usage of the deprecated interface in RepositoryManager. 
What is the alternative for this?



Le 09/10/2016 à 14:36, Karl Heinz Marbaise a écrit :

Hi Buillaume,

On 09/10/16 14:28, Guillaume Boué wrote:

If the caller needs to force a different local repository than the one
in the Maven session, they can already call
"repositoryManager.setLocalRepositoryBasedir" on the building request
that is passed to ProjectInstaller. This is what the plugins using
ArtifactInstaller are already doing, and it would be simpler than
creating a whole new MavenArtifactRepository and passing that. Maybe
this ArtifactRepository parameter could even be removed?

For now, its current use by the ProjectInstaller is only to get the path
to the metadata to install checksums for them, and this is only needed
because there is no "getPathForLocalMetadata" on the RepositoryManager.
How about adding this method, that would delegate to proper
implementation classes for Maven 3.1 or 3.0?


Sounds better and cleaner...


Kind regards
Karl Heinz





Le 09/10/2016 à 11:31, Karl Heinz Marbaise a écrit :

Hi,

Yes it has been introduced by me...and yes not all plugins are using
it cause I would like to have some tests before spreading it to the
"world" of plugins..

Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not always
the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué <gb...@apache.org>
wrote:


Hi,

 From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would 
get

the path to the artifact with "artifactRepository.pathOf(artifact)".
And then go with the one using the RepositoryManager or not, 
depending

on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200, <gb...@apache.org> wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the local
repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 





Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 




URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929=1763928=1763929=diff 




== 



---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 



(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 



Sat Oct  8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project )
) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact(

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

2016-10-09 Thread Guillaume Boué

If the caller needs to force a different local repository than the one 
in the Maven session, they can already call 
"repositoryManager.setLocalRepositoryBasedir" on the building request 
that is passed to ProjectInstaller. This is what the plugins using 
ArtifactInstaller are already doing, and it would be simpler than 
creating a whole new MavenArtifactRepository and passing that. Maybe 
this ArtifactRepository parameter could even be removed?


For now, its current use by the ProjectInstaller is only to get the path 
to the metadata to install checksums for them, and this is only needed 
because there is no "getPathForLocalMetadata" on the RepositoryManager. 
How about adding this method, that would delegate to proper 
implementation classes for Maven 3.1 or 3.0?



Le 09/10/2016 à 11:31, Karl Heinz Marbaise a écrit :

Hi,

Yes it has been introduced by me...and yes not all plugins are using 
it cause I would like to have some tests before spreading it to the 
"world" of plugins..


Kind regards
Karl Heinz


On 09/10/16 11:07, Robert Scholte wrote:

Hi,

IIRC ProjectInstaller has been introduced recently, I can imagine it
hasn't been pushed to all plugins which should use it instead of the
ArtifactInstaller.
While implementing maven-artifact-transfer and using it in several
plugins I just hit these edge cases where the local repo is not always
the target repo.

Robert

On Sat, 08 Oct 2016 22:30:11 +0200, Guillaume Boué <gb...@apache.org>
wrote:


Hi,

 From what I checked, I don't think those plugins should be impacted
since they use the ArtifactInstaller directly, and not the
ProjectInstaller.

But I can add an overload taking an ArtifactRepository which would get
the path to the artifact with "artifactRepository.pathOf(artifact)".
And then go with the one using the RepositoryManager or not, depending
on whether the ArtifactRepository is null or not.

Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create
their own local repository, for instance maven-invoker-plugin and
maven-dependency-plugin. In those cases you should pass the
ArtifactRepository.
So we will need those versions too, either as overloaded method or
restored where artifactRepository can be null.

thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200, <gb...@apache.org> wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local
repository should be retrieved from the RepositoryManager

We need to rely on the RepositoryManager to get a hold of the local
repository base directory.

Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 




Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 



URL:
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929=1763928=1763929=diff 



== 


---
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 


(original)
+++
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 


Sat Oct  8 18:43:58 2016
@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project )
) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest,
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest,
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact,
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository,
artifact, metadataFiles, createChecksum );
 }
 else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
 for ( Artifact attached : attachedArtifacts )
 {
 installer.install( buildingRequest,
Collections.singletonList( attached ) );
-ins

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

2016-10-08 Thread Guillaume Boué


Hi,

From what I checked, I don't think those plugins should be impacted 
since they use the ArtifactInstaller directly, and not the ProjectInstaller.


But I can add an overload taking an ArtifactRepository which would get 
the path to the artifact with "artifactRepository.pathOf(artifact)". And 
then go with the one using the RepositoryManager or not, depending on 
whether the ArtifactRepository is null or not.


Guillaume


Le 08/10/2016 à 22:11, Robert Scholte a écrit :

Hi Guillaume,

although this is often true, there are some plugins which create their 
own local repository, for instance maven-invoker-plugin and 
maven-dependency-plugin. In those cases you should pass the 
ArtifactRepository.
So we will need those versions too, either as overloaded method or 
restored where artifactRepository can be null.


thanks,
Robert


On Sat, 08 Oct 2016 20:43:58 +0200,  wrote:


Author: gboue
Date: Sat Oct  8 18:43:58 2016
New Revision: 1763929

URL: http://svn.apache.org/viewvc?rev=1763929=rev
Log:
[MSHARED-595] In DefaultProjectInstaller, the path to the local 
repository should be retrieved from the RepositoryManager


We need to rely on the RepositoryManager to get a hold of the local 
repository base directory.


Modified:
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

Modified: 
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java
URL: 
http://svn.apache.org/viewvc/maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java?rev=1763929=1763928=1763929=diff
== 

--- 
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 
(original)
+++ 
maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java 
Sat Oct  8 18:43:58 2016

@@ -101,7 +101,7 @@ public class DefaultProjectInstaller
 {
 installer.install( buildingRequest,
Collections.singletonList( new ProjectArtifact( project ) ) );
-installChecksums( buildingRequest, 
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact, 
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository, 
artifact, metadataFiles, createChecksum );

 }
 }
@@ -120,7 +120,7 @@ public class DefaultProjectInstaller
 if ( file != null && file.isFile() )
 {
 installer.install( buildingRequest, 
Collections.singletonList( artifact ) );
-installChecksums( buildingRequest, 
artifactRepository, artifact, createChecksum );
+installChecksums( buildingRequest, artifact, 
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository, 
artifact, metadataFiles, createChecksum );

 }
 else if ( !attachedArtifacts.isEmpty() )
@@ -139,7 +139,7 @@ public class DefaultProjectInstaller
 for ( Artifact attached : attachedArtifacts )
 {
 installer.install( buildingRequest, 
Collections.singletonList( attached ) );
-installChecksums( buildingRequest, artifactRepository, 
attached, createChecksum );
+installChecksums( buildingRequest, attached, 
createChecksum );
 addMetaDataFilesForArtifact( artifactRepository, 
attached, metadataFiles, createChecksum );

 }
@@ -153,12 +153,12 @@ public class DefaultProjectInstaller
  * the original POM file (cf. MNG-2820). While the plugin 
currently requires Maven 2.0.6, we continue to hash the
  * installed POM for robustness with regard to future changes 
like re-introducing some kind of POM filtering.

  *
+ * @param buildingRequest The project building request, must not 
be null.
  * @param artifact The artifact for which to create checksums, 
must not be null.
  * @param createChecksum {@code true} if checksum should be 
created, otherwise {@code false}.

  * @throws IOException If the checksums could not be installed.
  */
-private void installChecksums( ProjectBuildingRequest 
buildingRequest, ArtifactRepository artifactRepository,
-   Artifact artifact, boolean 
createChecksum )
+private void installChecksums( ProjectBuildingRequest 
buildingRequest, Artifact artifact, boolean createChecksum )

 throws IOException
 {
 if ( !createChecksum )
@@ -166,7 +166,7 @@ public class DefaultProjectInstaller
 return;
 }
-File artifactFile = getLocalRepoFile( buildingRequest, 
artifactRepository, artifact );
+File artifactFile =

Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file

2016-10-08 Thread Guillaume Boué

Hi,

It is allowed by install:install-file when you set generatePom=false. It 
would install for example a JAR without any POM. It is true that you 
won't be able to depend on the artifact as-is... perhaps we should force 
generatePom=true then?

This was a corner-case that I hit for 
https://issues.apache.org/jira/browse/MINSTALL-128, and I wanted to keep 
the current behaviour.

Guillaume

Le 08/10/2016 à 20:38, Karl Heinz Marbaise a écrit :

Hi Guillaume,

On 08/10/16 20:30, Guillaume Boué (JIRA) wrote:

When creating in-memory Maven projects with the {{ProjectBuilder}},

> it could not have a POM file: the intent is that
>  it only has attached artifacts and only those should get installed.

Maybe I misunderstand a thing here...

But if the project has only attached artifacts and those artifacts 
will be installed without a POM how should I ever use them ?

Kind regards
Karl Heinz Marbaise

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

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

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

Re: Profile Activation

2016-08-12 Thread Guillaume Boué

Hi Robert,

If this is expected, I think the documentation in 
http://maven.apache.org/guides/introduction/introduction-to-profiles.html 
should indeed be clarified. Currently, in that situation, it says 

"The following profile will be activated when the system property "debug" is 
defined with a value which is not "true"."

In this case, when invoking Maven with "mvn initialize", profilea isn't defined 
so I would expect the profile not to be activated. This is also what would 
happen if the value in the profile activation was commented out.

To recap, this is the current result with Maven 3.3.9 for this situation (and 
latest 3.4.0-SNAPSHOT):

 1. mvn initialize: profile activated

 2. mvn initialize -Dprofilea: profile not activated

 3. mvn initialize -Dprofilea=false: profile activated

 4. mvn initialize -Dprofilea=true: profile not activated

Guillaume

> Message du 12/08/16 18:34
> De : "Robert Scholte" 
> A : "Maven Developers List" 
> Copie à : 
> Objet : Re: Profile Activation
> 
> Hi Karl Heinz,
> 
> you should read the activation like this:
> always activate, *unless* profilea is true.
> So it says nothing about the availability of the property.
> Maybe the documentation isn't clear enough.
> 
> Robert
> 
> On Fri, 12 Aug 2016 17:45:21 +0200, Karl Heinz Marbaise 
>  wrote:
> 
> > Hi to all,
> >
> > I have the following profile:
> >
> >
> > 
> > profile-not-value-true
> > 
> > 
> > profilea
> > !true
> > 
> > 
> > 
> > 
> > 
> > com.soebes.maven.plugins
> > echo-maven-plugin
> > 
> > 
> > initialize
> > 
> > echo
> > 
> > 
> > 
> > 
> > 
> > profile not value true
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > So the question is: What would you expect you need to do to activate 
> > this profile?
> >
> > Currently this profile is activated cause if I don't define the property 
> > "profilea" at all it seemed to that Maven is assuming this means "not 
> > value 'true'" ?
> >
> > I have assumed it should be activated if the property exists which means 
> > giving it on command line like this:
> >
> > mvn -Dprofilea
> >
> >
> >
> > WDYT ?
> >
> > 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: Remote repositories in unpack and copy goal of maven-dependency-plugin

2016-08-10 Thread Guillaume Boué

Looks like the XML config was stripped... (?) but the remote repo I tested with 
was at the URL "http://bits.netbeans.org/nexus/content/groups/netbeans/;, 
keeping the default for everything else.

 

 

> Message du 10/08/16 20:43
> De : "Guillaume Boué" 
> A : "dev" 
> Copie à : 
> Objet : Remote repositories in unpack and copy goal of maven-dependency-plugin
> 
> Hello,
> 
>  
> 
> In the current 3.0.0-SNAPSHOT version of the maven-dependency-plugin, I 
> noticed that the unpack and copy goals do not resolve artifacts from remote 
> repositories configured in the POM. This used to work in the version 2.10.
> 
>  
> 
> To reproduce the issue, it is possible to add a remote repo in a sample POM 
> file:
> 
>  
> 
>     
>         
>             netbeans
>             http://bits.netbeans.org/nexus/content/groups/netbeans/
>         
>     
> 
> 
> 
> And then configure the Dependency Plugin to unpack, for example, the artifact 
> org.netbeans.modules:org-netbeans-core:RELEASE81:nbm. The build fails in 
> version 3.0.0-SNAPSHOT of the plugin because the new netbeans repo isn't 
> taken into account, whereas the artifact is correctly downloaded if version 
> 2.10 is used. Furthermore, if the repository declaration is moved to the 
> Settings, instead of being in the POM, the repo is correctly taken into 
> account for both versions.
> 
>  
> 
> After looking at the history, it seems to have been removed by this commit:
> 
>  
> 
> https://github.com/apache/maven-plugins/commit/35b9283efa241809a59fb4a828308681fb4a2afe#diff-870eb62b4a419b584383325fa9296a08
> 
>  
> 
> where the following line was removed: buildingRequest.setRemoteRepositories( 
> getRemoteRepos() );
> 
>  
> 
> Was this intended? If so, we should update the docs to reflect this change, I 
> didn't find a change regarding this.
> 
> 
>  
> 
> I re-added it locally, with the remote repositories being injected in the 
> plugin with the "project.remoteArtifactRepositories" property, and it solves 
> this issue: the repositories declared in the POM are used, alongside those 
> declared in the Settings, like usual. All the ITs still pass also.
> 
> 
>  
> 
> Thanks,
> 
> 
> Guillaume
> 
> 
>  
>

Remote repositories in unpack and copy goal of maven-dependency-plugin

2016-08-10 Thread Guillaume Boué

Hello,

In the current 3.0.0-SNAPSHOT version of the maven-dependency-plugin, I noticed
that the unpack and copy goals do not resolve artifacts from remote
repositories configured in the POM. This used to work in the version 2.10.

To reproduce the issue, it is possible to add a remote repo in a sample POM
file:

netbeans
http://bits.netbeans.org/nexus/content/groups/netbeans/

And then configure the Dependency Plugin to unpack, for example, the artifact
org.netbeans.modules:org-netbeans-core:RELEASE81:nbm. The build fails in
version 3.0.0-SNAPSHOT of the plugin because the new netbeans repo isn't taken
into account, whereas the artifact is correctly downloaded if version 2.10 is
used. Furthermore, if the repository declaration is moved to the Settings,
instead of being in the POM, the repo is correctly taken into account for both
versions.

After looking at the history, it seems to have been removed by this commit:

https://github.com/apache/maven-plugins/commit/35b9283efa241809a59fb4a828308681fb4a2afe#diff-870eb62b4a419b584383325fa9296a08

where the following line was removed: buildingRequest.setRemoteRepositories(
getRemoteRepos() );

Was this intended? If so, we should update the docs to reflect this change, I
didn't find a change regarding this.

I re-added it locally, with the remote repositories being injected in the
plugin with the "project.remoteArtifactRepositories" property, and it solves
this issue: the repositories declared in the POM are used, alongside those
declared in the Settings, like usual. All the ITs still pass also.

Thanks,

Guillaume

Re: Deprecation of ArtifactFactory and its use in new code

2016-07-23 Thread Guillaume Boué

Hi Robert,

 

Thanks for the info, I wasn't aware of this wiki page.

 

I pushed a fix of MDEPLOY-212 and MDEPLOY-213 using this idea in a forked 
repository of maven-plugins here https://github.com/Tunaki/maven-plugins/. All 
the IT still pass (expect from MDEPLOY-181 that is expected to fail) but I'd 
like to have a quick review before committing in trunk.

 

Thanks,

Guillaume

 

> Message du 22/07/16 19:58
> De : "Robert Scholte" 
> A : "Maven Developers List" 
> Copie à : 
> Objet : Re: Deprecation of ArtifactFactory and its use in new code
> 
> Hi Guillaume,
> 
> we have a wiki[1] describing most of the steps that need to be taken.
> Especially the ArtifactFactory is a tricky one. For deploying a 
> MavenProject (deploy:deploy) it should be straight forward.
> For deploying files (deploy:deploy-file) it is probably better to 
> translate it all back to new instance of a MavenProject, attach extra 
> artifacts with the MavenProjectHelper. If I'm correct in that case there's 
> no need for the ArtifactFactory anymore.
> 
> Robert
> 
> [1] 
> https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
> 
> On Fri, 22 Jul 2016 00:54:09 +0200, Guillaume Boué  
> wrote:
> 
> > Hi,
> >
> > 
> > While working on a fix for 
> > https://issues.apache.org/jira/browse/MDEPLOY-212, I found out that the 
> > plugin is using the interface ArtifactFactory (Maven Core), that was 
> > deprecated as of Maven 3. The fix would need to utilize this class in 
> > order to create artifacts but this would add deprecation warnings.
> >
> > 
> > Am I right in saying that this was replaced by RepositorySystem? Should 
> > this one be used for new commit code or is there a plan to fix all of 
> > the deprecation in the future? I'm not sure of all the possible 
> > compatibility consequences of using this interface instead of 
> > ArtifactFactory.
> >
> > 
> > Additionally, I couldn't find a JIRA issue about the correction of those 
> > deprecation (only https://issues.apache.org/jira/browse/MNG-5782 
> > suggesting improving the doc about it): should one be created?
> >
> > 
> > Thanks,
> >
> > Guillaume
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
>

Deprecation of ArtifactFactory and its use in new code

2016-07-21 Thread Guillaume Boué

Hi,

 

While working on a fix for https://issues.apache.org/jira/browse/MDEPLOY-212, I 
found out that the plugin is using the interface ArtifactFactory (Maven Core), 
that was deprecated as of Maven 3. The fix would need to utilize this class in 
order to create artifacts but this would add deprecation warnings.

 

Am I right in saying that this was replaced by RepositorySystem? Should this 
one be used for new commit code or is there a plan to fix all of the 
deprecation in the future? I'm not sure of all the possible compatibility 
consequences of using this interface instead of ArtifactFactory.

 

Additionally, I couldn't find a JIRA issue about the correction of those 
deprecation (only https://issues.apache.org/jira/browse/MNG-5782 suggesting 
improving the doc about it): should one be created?

 

Thanks,

Guillaume

Re: svn commit: r1753099 - in /maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features: simple-dir-format/ this & that/

2016-07-18 Thread Guillaume Boué

Hi,

It turns out there is a bug inside mvn.cmd when evaluating the working
directory with %CD%: this needs to be escaped by enclosing the "set var"
declaration in double quotes. I tested with the mvn.cmd of the latest
3.4.0-SNAPSHOT and this is apparently already fixed (MNG-5962). I reverted
the commit.

Thanks,
Guillaume

2016-07-17 22:50 GMT+02:00 Guillaume Boué <guillaume_b...@orange.fr>:

> Hi Robert,
>
> I see, I will try to debug why the test is failing for spaces and special
> characters. How about naming the folder "space & special char" instead? It
> would make it clearer that this is the purpose of the test.
>
> Regards,
> Guillaume
>
> 2016-07-17 22:39 GMT+02:00 Robert Scholte <rfscho...@apache.org>:
>
>> Hi Guillaume,
>>
>> there's a reason why this directory was called like this (spaces +
>> special character).
>> It is failing on my Windows machine too, but haven't investigated why it
>> is failing, I think the Plexus Commandline doesn't like it...
>> This should be reverted and fixed or excluded for Windows, i.e
>> invoker.family = !windows
>>
>> thanks,
>> Robert
>>
>>
>> On Sun, 17 Jul 2016 20:34:02 +0200, <gb...@apache.org> wrote:
>>
>> Author: gboue
>>> Date: Sun Jul 17 18:34:01 2016
>>> New Revision: 1753099
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1753099=rev
>>> Log:
>>> Renamed "this & that" IT test folder to "simple-dir-format", as this
>>> breaks the ITs when run on Windows: the '&' gets interpreted and Windows
>>> tries to launch the "that" program.
>>>
>>> Added:
>>>
>>> maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/simple-dir-format/
>>>   - copied from r1753098,
>>> maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/this
>>> & that/
>>> Removed:
>>>
>>> maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/this
>>> & that/
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: svn commit: r1753099 - in /maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features: simple-dir-format/ this & that/

2016-07-17 Thread Guillaume Boué

Hi Robert,

I see, I will try to debug why the test is failing for spaces and special
characters. How about naming the folder "space & special char" instead? It
would make it clearer that this is the purpose of the test.

Regards,
Guillaume

2016-07-17 22:39 GMT+02:00 Robert Scholte :

> Hi Guillaume,
>
> there's a reason why this directory was called like this (spaces + special
> character).
> It is failing on my Windows machine too, but haven't investigated why it
> is failing, I think the Plexus Commandline doesn't like it...
> This should be reverted and fixed or excluded for Windows, i.e
> invoker.family = !windows
>
> thanks,
> Robert
>
>
> On Sun, 17 Jul 2016 20:34:02 +0200,  wrote:
>
> Author: gboue
>> Date: Sun Jul 17 18:34:01 2016
>> New Revision: 1753099
>>
>> URL: http://svn.apache.org/viewvc?rev=1753099=rev
>> Log:
>> Renamed "this & that" IT test folder to "simple-dir-format", as this
>> breaks the ITs when run on Windows: the '&' gets interpreted and Windows
>> tries to launch the "that" program.
>>
>> Added:
>>
>> maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/simple-dir-format/
>>   - copied from r1753098,
>> maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/this
>> & that/
>> Removed:
>>
>> maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features/this
>> & that/
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

87 matches

Mail list logo