Deprecation of ArtifactFactory and its use in new code

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

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

re: Remote repositories in unpack and copy goal of maven-dependency-plugin

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 : &qu

Re: Profile Activation

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

Re: svn commit: r1753099 - in /maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features: simple-dir-format/ this & that/

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

Re: svn commit: r1753099 - in /maven/plugins/trunk/maven-assembly-plugin/src/it/projects/basic-features: simple-dir-format/ this & that/

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

Re: Deprecation of ArtifactFactory and its use in new code

/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 us

Re: Update Cwiki Roadmap 2017

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

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

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,

Reviewing MNG-6105

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,

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

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

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

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

Re: MNG-5629 and MNG-6117 look good

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.

Passing a system property already defined on CLI to Failsafe Plugin

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

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

operty 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> wro

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

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, 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 Fa

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

+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

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

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

Re: [jira] [Commented] (MSHARED-594) NullPointerException is thrown when trying to install a project without POM file

://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 co

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

, 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 a

Re: svn commit: r1763929 - /maven/shared/trunk/maven-artifact-transfer/src/main/java/org/apache/maven/shared/project/install/internal/DefaultProjectInstaller.java

o 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...@apach

Re: Maven Artifact Transfer Shared Component Release 1.0.0 ?

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

Re: svn commit: r1765195 - /maven/plugins/trunk/maven-compiler-plugin/src/site/apt/examples/set-compiler-source-and-target.apt.vm

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).

Re: [jira] [Commented] (MPH-120) Migrate plugin to Maven 3.0

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 : [

Re: [jira] [Created] (MNG-6111) incorrect text in help:describe for cmd

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

Re: Need to change a test case in 'maven-filtering'.

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

Fwd: Build failed in Jenkins: maven-enforcer #245

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

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

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

Re: [jira] [Created] (MNG-6111) incorrect text in help:describe for cmd

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

Re: Build failed in Jenkins: maven-plugins-ITs-m3-windows #1762

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;

Re: Cannot build current master.

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

Support for getting local metadata in RepositoryManager

a ); } 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.Artifa

Cannot build any Maven plugins with current 3.4.0

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

Re: Cannot build any Maven plugins with current 3.4.0

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

Re: [jira] [Created] (MPOM-152) Upgrade maven-checkstyle-plugin to 2.17.

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

Re: Moving forward on 3.5.0

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

Re: Moving forward on 3.5.0

y 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: htt

Next version for MPLUGIN in JIRA

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

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

dback 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 scrip

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

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

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

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

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

+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

Re: [VOTE] Releasing Wagon 2.11

). 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

Re: [VOTE] Releasing Wagon 2.11

://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

Re: [DISCUSS] Resetting Master branch to 737de43e392fc15a0ce366db98d70aa18b3f6c03

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

Re: [VOTE] Releasing Wagon 2.11

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 patc

Re: [VOTE] Releasing Wagon 2.11

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 f

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

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

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

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

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

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

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

og.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 t

Jenkins job of maven-parent is broken

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

Re: Jenkins job of maven-parent is broken

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

Re: Scope promotion of managed dependencies in current Maven master

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

Re: Roadmap to the next Maven release (Re: Improving Jenkins)

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

Re: [VOTE] Releasing Wagon 2.11

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 -

Re: [VOTE] Releasing Wagon 2.11

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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

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

Re: New Branch SUREFIRE-1342

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

Re: New Branch SUREFIRE-1342

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 a

Re: New Branch SUREFIRE-1342

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é

Re: New Branch SUREFIRE-1342

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

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

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

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

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!

Re: New Branch SUREFIRE-1342

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

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

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

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

+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

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

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 b

Wrong library.jansi.path in master 3.5.1 startup scripts

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

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

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

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

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:

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

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

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

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 r

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

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

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é

Re: Code review. Please approve new branches.

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

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

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

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

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

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

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:

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

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

Version 3.0.0 on JIRA for MANTRUN

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

Artifact "has been attached with deprecated code" warning

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:

Re: [VOTE] Release Apache Maven Resolver version 1.1.1

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.

Re: Question concerning Maven Core

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,

Re: [VOTE] Release Apache Maven 3.5.3

+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

Re: [VOTE] Release Apache Maven 3.5.3

(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 "" at the very last line

Re: [VOTE] Release Maven Help Plugin version 3.0.0

+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: