[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
[ https://issues.apache.org/jira/browse/MINVOKER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755584#comment-16755584 ] Olivier Lamy (*$^¨%`£) commented on MINVOKER-243: - This is broken build when using option such -rf as the code change collect all dependencies from projectReferences even those who currently build (because of using -rf option) > invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0) > -- > > Key: MINVOKER-243 > URL: https://issues.apache.org/jira/browse/MINVOKER-243 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: Christopher Tubbs >Assignee: Robert Scholte >Priority: Blocker > Fix For: 3.2.0 > > > Something seems to have broken between 3.0.1 and 3.1.0, as the install goal > no longer copies transitive dependencies to the localRepositoryPath as it did > in version 3.0.1. > This is very problematic, because if the artifacts are not in the > localRepositoryPath, the invoked project will try to download them from a > remote repository, which isn't possible for SNAPSHOT versions (such as those > in a sibling module in a multi-module project). This can make it difficult to > even build a multi-module project, unless the invoked task is skipped and the > sibling module can be published to a remote snapshot repository temporarily, > and then the build re-executed normally. (Saw this happen in Apache Accumulo > after upgrading to apache-21.pom) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAVADOC-570) --add-modules expects comma-separated arguments
[
https://issues.apache.org/jira/browse/MJAVADOC-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-570.
---
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.1.0
Fixed in
[c2681a49d246646b591281750ac0173d6f2f8834|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=c2681a49d246646b591281750ac0173d6f2f8834]
Thanks for the patch!
> --add-modules expects comma-separated arguments
> ---
>
> Key: MJAVADOC-570
> URL: https://issues.apache.org/jira/browse/MJAVADOC-570
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
>
> It's quicker for me to explain this problem that produce a minimal testcase
> for it. In AbstractJavadocMojo line 5079 we invoke:
> {code:java}
> addArgIfNotEmpty( arguments, "--add-modules", JavadocUtil.quotedPathArgument(
> addModulesLine ) );{code}
> This gets converted to {{addArgIfNotEmpty()}} with {{splitValue=true}} which
> means that comma-separated values get converted to newline-separated values.
> {{--add-modules}} does not like this and does not consume the subsequent
> arguments (they probably get treated as source files instead).
> We should be invoking {{addArgIfNotEmpty()}} with {{splitValue=false}}
> instead.
> If I provide a PR for this, do you still need a testcase?
> On a side-note, it would really help if they documented the expected
> behavior. I only ran across this by chance due to this bug report on OpenJDK:
> [https://bugs.openjdk.java.net/browse/JDK-8165634] and when I converted
> newline to commas in my own project one of the error messages went away.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] rfscholte merged pull request #19: Avoid converting separator characters into newline.
rfscholte merged pull request #19: Avoid converting separator characters into newline. URL: https://github.com/apache/maven-javadoc-plugin/pull/19 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-514) Maven Javadoc Plugin can't get dependency from third party maven repository
[
https://issues.apache.org/jira/browse/MJAVADOC-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755334#comment-16755334
]
Brord van Wierst commented on MJAVADOC-514:
---
[~rfscholte] Oh yea whoeps, i mixed uploading this version on an alternative
maven repo, and uploading my doclet on maven central :)
I will just upload the doclet actually, Thanks for the quick response!
> Maven Javadoc Plugin can't get dependency from third party maven repository
> ---
>
> Key: MJAVADOC-514
> URL: https://issues.apache.org/jira/browse/MJAVADOC-514
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven 3.2.x
>Reporter: Justin Wu
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
>
> I had a Jar is saved in my own maven repository which is runing on Nexus.
> It works well if it is a normal maven dependency.
> but it fails if I declare it in Maven Javadoc Plugin:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.0:jar (attach-javadoc) @ treaty ---
> Downloading:
> https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.pom
> [WARNING] The POM for com.mycompany.util:object-tree-creator:jar:1.0 is
> missing, no dependency information available
> Downloading:
> +[https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.jar|https://repo.maven.apache.org/maven2/com/validusre/util/object-tree-creator/1.0/object-tree-creator-1.0.jar]+
> {noformat}
> This is my code:
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.0.0
>
> bm.mycompany.common.doclet.MyDoclet
> ${project.build.directory}/../../shared-java/target/classes;${project.build.directory}/classes
>
> ${project.build.directory}/../../shared-java/src/java;${project.build.directory}/../src/java
> UTF-8
> public
> com.mycompany.api
> false
>
>
>
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
>
> javax.servlet
> servlet-api
> 2.5
>
>
>
> com.mycompany.util
> object-tree-creator
> 1.0
>
>
>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[ https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755320#comment-16755320 ] Dan Tran commented on SUREFIRE-1546: tested 3.0.0-M4-SNAPSHOT, looking forward to M4 release. Many thanks > JUnit 5 runner does not honor JUnit 5 display names > --- > > Key: SUREFIRE-1546 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1546 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Affects Versions: 2.22.0 >Reporter: Romain Manni-Bucau >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Time Spent: 20m > Remaining Estimate: 0h > > JUnit 5 runner should respect the test @DisplayName instead of displaying the > classname if any is defined. Seems last release doesn't support that feature > of JUnit 5 making the console output and reports not the expected ones. > > Origin: https://github.com/junit-team/junit5/issues/990 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-573) excluding generated sources with sourceFileExcludes not working
[
https://issues.apache.org/jira/browse/MJAVADOC-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755279#comment-16755279
]
Robert Scholte commented on MJAVADOC-573:
-
{{sourceFileExclude}} -entries are relative to the sourceFolder(s)
> excluding generated sources with sourceFileExcludes not working
> ---
>
> Key: MJAVADOC-573
> URL: https://issues.apache.org/jira/browse/MJAVADOC-573
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Jimmy Praet
>Priority: Major
>
> I want to exclude generated source code in the target folder from the javadoc
> plugin execution.
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.0.1
>
>
> process-sources
>
> javadoc
>
>
>
> **/target/**/*.java
>
>
>
>
>
> {code}
> But this isn't working. When I activate debug mode, I see these files are
> still there in the argfile:
>
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/ObjectFactory.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/package-info.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestPortType.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestRequest.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestResponse.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestService.java'
> If instead, I configure
> {code}
> **/intf/**/*.java
> {code}
> then it does work. So I have the impression these exclusion patterns are
> maybe resolved from within the specific source root
> {{D:/projects/JaxUtils/target/generated-sources/jaxws/}} instead of the
> project basedir?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-514) Maven Javadoc Plugin can't get dependency from third party maven repository
[
https://issues.apache.org/jira/browse/MJAVADOC-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755270#comment-16755270
]
Robert Scholte commented on MJAVADOC-514:
-
bq. is it getting soonish-er?
It should, but we're not there yet. With some improvements we hit new issues
regarding JPMS. They must be part of the next release, otherwise we'll get a
load of new issues on the plugin.
bq. Otherwise is it alright if I upload this specific jar to Maven central?
WDYM? Only Maven committers have the proper rights to push this plugin to Maven
Central; not sure what you mean with "this specific jar"
> Maven Javadoc Plugin can't get dependency from third party maven repository
> ---
>
> Key: MJAVADOC-514
> URL: https://issues.apache.org/jira/browse/MJAVADOC-514
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven 3.2.x
>Reporter: Justin Wu
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
>
> I had a Jar is saved in my own maven repository which is runing on Nexus.
> It works well if it is a normal maven dependency.
> but it fails if I declare it in Maven Javadoc Plugin:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.0:jar (attach-javadoc) @ treaty ---
> Downloading:
> https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.pom
> [WARNING] The POM for com.mycompany.util:object-tree-creator:jar:1.0 is
> missing, no dependency information available
> Downloading:
> +[https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.jar|https://repo.maven.apache.org/maven2/com/validusre/util/object-tree-creator/1.0/object-tree-creator-1.0.jar]+
> {noformat}
> This is my code:
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.0.0
>
> bm.mycompany.common.doclet.MyDoclet
> ${project.build.directory}/../../shared-java/target/classes;${project.build.directory}/classes
>
> ${project.build.directory}/../../shared-java/src/java;${project.build.directory}/../src/java
> UTF-8
> public
> com.mycompany.api
> false
>
>
>
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
>
> javax.servlet
> servlet-api
> 2.5
>
>
>
> com.mycompany.util
> object-tree-creator
> 1.0
>
>
>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MENFORCER-325) Add binary compatibility check to dependencyConvergence rule
Marquis Wang created MENFORCER-325: -- Summary: Add binary compatibility check to dependencyConvergence rule Key: MENFORCER-325 URL: https://issues.apache.org/jira/browse/MENFORCER-325 Project: Maven Enforcer Plugin Issue Type: New Feature Reporter: Marquis Wang The dependencyConvergence rule is too strict to use in practice most of the time. If you have a project with even a medium number of dependencies, they are pretty much guaranteed to have transitive dependencies that do not converge. For some very common dependencies like Guava, the maintainers of the project are very careful to maintain binary compatibility with new releases. For these dependencies, a dependency divergence is okay if the included node is binary compatible with all of the diverging nodes. For example, if you have two dependencies, one if which depends on Guava 27 and the other depends on Guava 26, you can safely run with Guava 27 because you know that it is compatible with 26. It would be really helpful if the dependencyConvergence rule were able to check for binary compatibility and take it into account. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-514) Maven Javadoc Plugin can't get dependency from third party maven repository
[
https://issues.apache.org/jira/browse/MJAVADOC-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755179#comment-16755179
]
Brord van Wierst commented on MJAVADOC-514:
---
[~rfscholte] is it getting soonish-er? Otherwise is it alright if I upload this
specific jar to Maven central?
> Maven Javadoc Plugin can't get dependency from third party maven repository
> ---
>
> Key: MJAVADOC-514
> URL: https://issues.apache.org/jira/browse/MJAVADOC-514
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven 3.2.x
>Reporter: Justin Wu
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
>
> I had a Jar is saved in my own maven repository which is runing on Nexus.
> It works well if it is a normal maven dependency.
> but it fails if I declare it in Maven Javadoc Plugin:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.0:jar (attach-javadoc) @ treaty ---
> Downloading:
> https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.pom
> [WARNING] The POM for com.mycompany.util:object-tree-creator:jar:1.0 is
> missing, no dependency information available
> Downloading:
> +[https://repo.maven.apache.org/maven2/com/mycompany/util/object-tree-creator/1.0/object-tree-creator-1.0.jar|https://repo.maven.apache.org/maven2/com/validusre/util/object-tree-creator/1.0/object-tree-creator-1.0.jar]+
> {noformat}
> This is my code:
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.0.0
>
> bm.mycompany.common.doclet.MyDoclet
> ${project.build.directory}/../../shared-java/target/classes;${project.build.directory}/classes
>
> ${project.build.directory}/../../shared-java/src/java;${project.build.directory}/../src/java
> UTF-8
> public
> com.mycompany.api
> false
>
>
>
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
>
> javax.servlet
> servlet-api
> 2.5
>
>
>
> com.mycompany.util
> object-tree-creator
> 1.0
>
>
>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6582) Maven report wrong jdk vendor
[
https://issues.apache.org/jira/browse/MNG-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755176#comment-16755176
]
Michael Osipov commented on MNG-6582:
-
No, that's wrong. These properties are complied into the JDK. Here is what your
see in {{mvn -v}}: {{java.vendor=Oracle Corporation}},
> Maven report wrong jdk vendor
> --
>
> Key: MNG-6582
> URL: https://issues.apache.org/jira/browse/MNG-6582
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Barry
>Priority: Minor
> Fix For: wontfix-candidate
>
>
> I am using OpenJDK and when I perform mvn -version, it says Oracle is the
> vendor.
> {noformat}
> mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default
> locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version:
> "10.13.6", arch: "x86_64", family: "mac"
> {noformat}
> If you were to print the java version straight from the java install path:
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java
> -version
> openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build
> 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> {noformat}
> I updated to the latest install of Maven, and the problem exists there as
> well. Testing done on a Mac.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6582) Maven report wrong jdk vendor
[
https://issues.apache.org/jira/browse/MNG-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755162#comment-16755162
]
Patrick Barry commented on MNG-6582:
Ahh, I see the problem. I recently installed openJDK and there is no installer
for that that (that I know of) so I manually registered the new install. Looks
like the Oracle Java installer used to set a bunch of env variables that I did
not know about!
{noformat}
genesys-maven: mvn help:system | grep java
java.specification.version=11
java.class.path=/usr/local/Cellar/maven/3.6.0/libexec/boot/plexus-classworlds-2.5.2.jar
java.vm.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
java.vm.specification.version=11
sun.java.launcher=SUN_STANDARD
sun.java.command=org.codehaus.plexus.classworlds.launcher.Launcher help:system
java.specification.vendor=Oracle Corporation
java.version.date=2019-01-15
java.home=/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home
java.vm.compressedOopsMode=Zero based
java.specification.name=Java Platform API Specification
java.vm.specification.vendor=Oracle Corporation
java.awt.graphicsenv=sun.awt.CGraphicsEnvironment
java.runtime.version=11.0.2+9
java.runtime.name=OpenJDK Runtime Environment
java.vm.name=OpenJDK 64-Bit Server VM
java.vendor.version=18.9
java.vendor.url.bug=http://bugreport.java.com/bugreport/
java.io.tmpdir=/var/folders/w_/kgpg46bx1ns4bw2tk8fqp1t8gn/T/
java.version=11.0.2
java.vm.specification.name=Java Virtual Machine Specification
java.awt.printerjob=sun.lwawt.macosx.CPrinterJob
java.library.path=/Users/pbarry/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
java.vendor=Oracle Corporation
java.vm.info=mixed mode
java.vm.version=11.0.2+9
java.class.version=55.0{noformat}
> Maven report wrong jdk vendor
> --
>
> Key: MNG-6582
> URL: https://issues.apache.org/jira/browse/MNG-6582
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Barry
>Priority: Minor
> Fix For: wontfix-candidate
>
>
> I am using OpenJDK and when I perform mvn -version, it says Oracle is the
> vendor.
> {noformat}
> mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default
> locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version:
> "10.13.6", arch: "x86_64", family: "mac"
> {noformat}
> If you were to print the java version straight from the java install path:
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java
> -version
> openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build
> 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> {noformat}
> I updated to the latest install of Maven, and the problem exists there as
> well. Testing done on a Mac.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6582) Maven report wrong jdk vendor
Patrick Barry created MNG-6582: -- Summary: Maven report wrong jdk vendor Key: MNG-6582 URL: https://issues.apache.org/jira/browse/MNG-6582 Project: Maven Issue Type: Bug Affects Versions: 3.6.0, 3.5.4 Reporter: Patrick Barry I am using OpenJDK and when I perform mvn -version, it says Oracle is the vendor. ``` mvn -version Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" ``` If you were to print the java version straight from the java install path: ``` /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java -version openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) ``` I updated to the latest install of Maven, and the problem exists there as well. Testing done on a Mac. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6582) Maven report wrong jdk vendor
[
https://issues.apache.org/jira/browse/MNG-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6582:
Description:
I am using OpenJDK and when I perform mvn -version, it says Oracle is the
vendor.
{noformat}
mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 11.0.2, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default locale:
en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.13.6", arch:
"x86_64", family: "mac"
{noformat}
If you were to print the java version straight from the java install path:
{noformat}
/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java
-version
openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build
11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
{noformat}
I updated to the latest install of Maven, and the problem exists there as well.
Testing done on a Mac.
was:
I am using OpenJDK and when I perform mvn -version, it says Oracle is the
vendor.
```
mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 11.0.2, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default locale:
en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.13.6", arch:
"x86_64", family: "mac"
```
If you were to print the java version straight from the java install path:
```
/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java
-version
openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build
11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
```
I updated to the latest install of Maven, and the problem exists there as well.
Testing done on a Mac.
> Maven report wrong jdk vendor
> --
>
> Key: MNG-6582
> URL: https://issues.apache.org/jira/browse/MNG-6582
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Barry
>Priority: Minor
> Fix For: wontfix-candidate
>
>
> I am using OpenJDK and when I perform mvn -version, it says Oracle is the
> vendor.
> {noformat}
> mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default
> locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version:
> "10.13.6", arch: "x86_64", family: "mac"
> {noformat}
> If you were to print the java version straight from the java install path:
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java
> -version
> openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build
> 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> {noformat}
> I updated to the latest install of Maven, and the problem exists there as
> well. Testing done on a Mac.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6582) Maven report wrong jdk vendor
[
https://issues.apache.org/jira/browse/MNG-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755125#comment-16755125
]
Michael Osipov commented on MNG-6582:
-
Please run {{mvn help:system}} and post.
> Maven report wrong jdk vendor
> --
>
> Key: MNG-6582
> URL: https://issues.apache.org/jira/browse/MNG-6582
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Barry
>Priority: Minor
>
> I am using OpenJDK and when I perform mvn -version, it says Oracle is the
> vendor.
> ```
> mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 11.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default
> locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version:
> "10.13.6", arch: "x86_64", family: "mac"
> ```
> If you were to print the java version straight from the java install path:
> ```
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java
> -version
> openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build
> 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> ```
> I updated to the latest install of Maven, and the problem exists there as
> well. Testing done on a Mac.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-798) Add defaultEntries option
[
https://issues.apache.org/jira/browse/MSHARED-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755064#comment-16755064
]
Michael Osipov commented on MSHARED-798:
[~hboutemy], what do you prefer {{addDefaultEntries}} or
{{addReproducibleEntries}}?
> Add defaultEntries option
> -
>
> Key: MSHARED-798
> URL: https://issues.apache.org/jira/browse/MSHARED-798
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Based on MSHARED-362 one should have the option to disable default
> (reproducible) manifest entries explicitly: {{Created-By}},
> {{Build-Jdk-Spec}} with the option {{addDefaultEntries: true}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (WAGON-546) HttpWagon TTL not set
[
https://issues.apache.org/jira/browse/WAGON-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed WAGON-546.
Resolution: Fixed
Fixed with
[dfd22586b6b934aa5a652ca32d57ed26067432fd|https://gitbox.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=dfd22586b6b934aa5a652ca32d57ed26067432fd].
> HttpWagon TTL not set
> -
>
> Key: WAGON-546
> URL: https://issues.apache.org/jira/browse/WAGON-546
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.3.2
>
>
> As discovered in WAGON-545 the property
> {{maven.wagon.httpconnectionManager.ttlSeconds}} is always zero due to
> [incorrect ordering of the code|https://stackoverflow.com/q/5989532/696632].
> Thus, making WAGON-486 a no-op.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (WAGON-545) Connection reset while downloading artifacts in cloud environment (Azure)
[ https://issues.apache.org/jira/browse/WAGON-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed WAGON-545. Resolution: Fixed Fixed implicitly by Fixed with [dfd22586b6b934aa5a652ca32d57ed26067432fd|[https://gitbox.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=dfd22586b6b934aa5a652ca32d57ed26067432fd].] Azure users shall set the TTL to 240 seconds or less. > Connection reset while downloading artifacts in cloud environment (Azure) > - > > Key: WAGON-545 > URL: https://issues.apache.org/jira/browse/WAGON-545 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Microsoft Azure 'Hosted VS2017' >Reporter: Christian Domsch >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.2 > > Attachments: log_10_310.zip, log_10_311.zip, log_10_325.zip, > successful-build-ttl5.zip > > > We are building a huge multi-module project in the azure cloud and experience > random connection resets during our build due to probably the same issue as > in WAGON-486. Since it is stated by Microsoft that they terminate connections > that are idle for longer than four minutes (see solution comment > [here|https://developercommunity.visualstudio.com/content/problem/357696/maven-project-build-failing-with-connection-reset.html], > I set -Dmaven.wagon.httpconnectionManager.ttlSeconds=120. Also, disabling > the http pool does not solve the problem. Attached are logs from out main > build with logging turned on for the wagon components, as mentioned in the > comment section of WAGON-486. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla updated SUREFIRE-1631: Description: I'm seeing spurious "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" messages when running unit tests in a big multi-module project. OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. I'm running Maven from the command line using MinTTY (Cygwin). Things I tried which have no effect: * Reboot / Cold boot (happens first thing on Monday morning when I come into the office and turn on my PC). * More free memory (happens when I only have a single window open). I have 16GB of RAM. * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). * Different versions of the Surefire plugin or Maven * Different JDK 8 builds Things that affect the bug: * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log * Redirecting all log output to a file using logback-test.xml * Running Surefire with forkCount=0 * Running a subset of the tests (-Dtest=...) * Pending Windows updates (I think, not sure about this one). Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never seen it with redirecting log output (~ 10 builds). Redirecting sometimes helps but not always. One thing which I notice is that one of the tests creates an ActiveMQ broker and uses a shutdown hook to stop it. So I created a small test project which demonstrates that Surefire will sometimes cut off stdout. I think that happens because the main process kills the child after a timeout (correct?). So my guess would be that shutdown hooks can mess with the pipeline between the surefire child VM and main Maven process. ActiveMQ might be worse since it stops threads and execution pools (so the output comes slowly with a couple of exceptions sprinkled in when one component loses connection because another is shutting down). But now, it gets weird. When the build succeeds, it takes about ~5 minutes to run 1028 tests. The log is 25 MB. When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) and the log stops in the middle of a test but is also 25 MB. Some of the time discrepancy is probably because writing to a file is faster than printing on a terminal. The strange part is that the log file is about the same size but 30% of the tests haven't run. Most tests log a lot, do I would expect to see a difference of at least a few MB. The Maven part (which contains escape sequences, etc). is just 60 KB. Maybe the parent takes some part of the log output as "child terminated". I'm running out of ideas what to try next. I think a way to log the communication between parent and child would help. Also the parent should terminate the child and then read stdout until EOF to we can see anything that happens afterwards. was: I'm seeing spurious "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" messages when running unit tests in a big multi-module project. OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. I'm running Maven from the command line using MinTTY (Cygwin). Things I tried which have no effect: * Reboot / Cold boot (happens first thing on Monday morning when I come into the office and turn on my PC). * More free memory (happens when I only have a single window open). I have 16GB of RAM. * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). * Different versions of the Surefire plugin or Maven * Different JDK 8 builds Things that affect the bug: * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log * Redirecting all log output to a file using logback-test.xml * Running Surefire with forkCount=0 * Running a subset of the tests (-Dtest=...) * Pending Windows updates (I think, not sure about this one). Counts: I've never seen it with forkCount=0 (~20 test builds). I've never seen it with redirecting log output (~ 10 builds). Redirecting sometimes helps but not always. One thing which I notice is that one of the tests creates an ActiveMQ broker and uses a shutdown hook to stop it. So I created a small test project which demonstrates that Surefire will sometimes cut off stdout. I think that happens because the main process kills the child after a timeout (correct?). So my guess would be that shutdown hooks can mess with the pipeline between the surefire child VM and main Maven process. But now, it gets weird. When the build succeeds, it takes about ~5 minutes to run 1028 tests. The log is 25 MB. When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) and the log stops in the middle of a test but is also 25 MB. Some of the time discrepancy is probably because writing to
[jira] [Created] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
Aaron Digulla created SUREFIRE-1631: --- Summary: Forked VM terminated without properly saying goodbye with AciveMQ Key: SUREFIRE-1631 URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 3.0.0-M2, 2.22.0, 3.0.0-M1, 2.20.1 Reporter: Aaron Digulla I'm seeing spurious "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" messages when running unit tests in a big multi-module project. OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. I'm running Maven from the command line using MinTTY (Cygwin). Things I tried which have no effect: * Reboot / Cold boot (happens first thing on Monday morning when I come into the office and turn on my PC). * More free memory (happens when I only have a single window open). I have 16GB of RAM. * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). * Different versions of the Surefire plugin or Maven * Different JDK 8 builds Things that affect the bug: * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log * Redirecting all log output to a file using logback-test.xml * Running Surefire with forkCount=0 * Running a subset of the tests (-Dtest=...) * Pending Windows updates (I think, not sure about this one). Counts: I've never seen it with forkCount=0 (~20 test builds). I've never seen it with redirecting log output (~ 10 builds). Redirecting sometimes helps but not always. One thing which I notice is that one of the tests creates an ActiveMQ broker and uses a shutdown hook to stop it. So I created a small test project which demonstrates that Surefire will sometimes cut off stdout. I think that happens because the main process kills the child after a timeout (correct?). So my guess would be that shutdown hooks can mess with the pipeline between the surefire child VM and main Maven process. But now, it gets weird. When the build succeeds, it takes about ~5 minutes to run 1028 tests. The log is 25 MB. When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) and the log stops in the middle of a test but is also 25 MB. Some of the time discrepancy is probably because writing to a file is faster than printing on a terminal. The strange part is that the log file is about the same size but 30% of the tests haven't run. Most tests log a lot, do I would expect to see a difference of at least a few MB. The Maven part (which contains escape sequences, etc). is just 60 KB. Maybe the parent takes some part of the log output as "child terminated". I'm running out of ideas what to try next. I think a way to log the communication between parent and child would help. Also the parent should terminate the child and then read stdout until EOF to we can see anything that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MPMD-276) DOC of excludeFromFailureFile for cpd-check is wrong
Albert Motos González created MPMD-276: -- Summary: DOC of excludeFromFailureFile for cpd-check is wrong Key: MPMD-276 URL: https://issues.apache.org/jira/browse/MPMD-276 Project: Maven PMD Plugin Issue Type: Bug Reporter: Albert Motos González Hi, How you can see on your page: [https://maven.apache.org/plugins/maven-pmd-plugin/examples/violation-exclusions.html] for exclude failureFiles in cpd-check the example is exclude-cpd.properties. After a lot of hours of test, looking the source of original pmd plugin code: [https://github.com/sturton/maven-pmd-plugin/blob/master/src/test/resources/unit/excludes/cpd_exclude.txt] you can see that file must be of type txt. The change of wiki is cosmetic but I loose a lot of time trying it, and it's frustrating. And it help a lot of developers Thanks in advance, exclude-cpd.properties -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHARED-798) Add defaultEntries option
Michael Osipov created MSHARED-798:
--
Summary: Add defaultEntries option
Key: MSHARED-798
URL: https://issues.apache.org/jira/browse/MSHARED-798
Project: Maven Shared Components
Issue Type: New Feature
Components: maven-archiver
Affects Versions: maven-archiver-3.3.0
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: maven-archiver-3.4.0
Based on MSHARED-362 one should have the option to disable default
(reproducible) manifest entries explicitly: {{Created-By}}, {{Build-Jdk-Spec}}
with the option {{addDefaultEntries: true}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MSITE-832) stage-deploy fails with maven-site-plugin 3.7.1 and wagon-webdav-jackrabbit 3.3.1: NoSuchMethodError:org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferC
[
https://issues.apache.org/jira/browse/MSITE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli resolved MSITE-832.
---
Resolution: Not A Problem
Fix Version/s: (was: waiting-for-feedback)
wagon-webdav-jackrabbit 3.2.0 works like a charm !!
Thank you.
{code:java}
org.apache.maven.plugins
maven-site-plugin
3.7.1
org.apache.maven.wagon
wagon-webdav-jackrabbit
3.2.0
{code}
> stage-deploy fails with maven-site-plugin 3.7.1 and wagon-webdav-jackrabbit
> 3.3.1:
> NoSuchMethodError:org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I
>
>
> Key: MSITE-832
> URL: https://issues.apache.org/jira/browse/MSITE-832
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Affects Versions: 3.7.1
>Reporter: Enrico Olivelli
>Assignee: Michael Osipov
>Priority: Blocker
> Attachments: msite-832.tar.gz
>
>
> I have this error with Maven 3.6.0 and maven-site-plugin 3.7.1 and
> wagon-webdav-jackrabbit 3.3.1
> {noformat}
> java.lang.NoSuchMethodError:
>
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.getBufferCapacityForTransfer(J)I
> at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.access$000
> (AbstractHttpClientWagon.java:112)
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon$RequestEntityImplementation.writeTo
> (AbstractHttpClientWagon.java:185)
> at org.apache.http.impl.DefaultBHttpClientConnection.sendRequestEntity
> (DefaultBHttpClientConnection.java:156)
> {noformat}
>
> Is there anyworkaround ?
> I am trying to force all of the dependencies in the site plugin
> {code:xml}
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.7.1
>
>
> org.apache.maven.wagon
> wagon-http
> 3.3.1
>
>
> org.apache.maven.wagon
> wagon
> 3.3.1
> pom
>
>
> org.apache.maven.wagon
> wagon-http-shared
> 3.3.1
>
>
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> 3.3.1
>
>
> {code}
> But no result...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1628) maven-failsafe-plugin fails to execute on maven 3.0.5 and java 8
[
https://issues.apache.org/jira/browse/SUREFIRE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754952#comment-16754952
]
Jörg Sesterhenn commented on SUREFIRE-1628:
---
Hello [~michael-o], please see attached MWE.
> maven-failsafe-plugin fails to execute on maven 3.0.5 and java 8
>
>
> Key: SUREFIRE-1628
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1628
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M3
> Environment: maven 3.0.5
> jdk 1.8u111
> sles 12
>Reporter: Jörg Sesterhenn
>Priority: Major
> Attachments: surefire-1628-mwe.zip
>
>
> The plugin seems to require plexus-java which cannot be found.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> (default-integration-test) on project MyParentPOM: Execution
> default-integration-test of goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> failed: Unable to load the mojo 'integration-test' (or one of its required
> components) from the plugin
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3':
> com.google.inject.ProvisionException: Guice provision errors:
> [ERROR] 1) No implementation for
> org.codehaus.plexus.languages.java.jpms.LocationManager was bound.
> [ERROR] while locating org.apache.maven.plugin.failsafe.IntegrationTestMojo
> [ERROR] at
> ClassRealm[plugin>org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
> @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test)
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> [ERROR] -> [Help 1]
> [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] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1628) maven-failsafe-plugin fails to execute on maven 3.0.5 and java 8
[
https://issues.apache.org/jira/browse/SUREFIRE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Sesterhenn updated SUREFIRE-1628:
--
Attachment: surefire-1628-mwe.zip
> maven-failsafe-plugin fails to execute on maven 3.0.5 and java 8
>
>
> Key: SUREFIRE-1628
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1628
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M3
> Environment: maven 3.0.5
> jdk 1.8u111
> sles 12
>Reporter: Jörg Sesterhenn
>Priority: Major
> Attachments: surefire-1628-mwe.zip
>
>
> The plugin seems to require plexus-java which cannot be found.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> (default-integration-test) on project MyParentPOM: Execution
> default-integration-test of goal
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> failed: Unable to load the mojo 'integration-test' (or one of its required
> components) from the plugin
> 'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3':
> com.google.inject.ProvisionException: Guice provision errors:
> [ERROR] 1) No implementation for
> org.codehaus.plexus.languages.java.jpms.LocationManager was bound.
> [ERROR] while locating org.apache.maven.plugin.failsafe.IntegrationTestMojo
> [ERROR] at
> ClassRealm[plugin>org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with
> @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test)
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M3:integration-test
> [ERROR] -> [Help 1]
> [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] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (WAGON-545) Connection reset while downloading artifacts in cloud environment (Azure)
[
https://issues.apache.org/jira/browse/WAGON-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754868#comment-16754868
]
Michael Osipov commented on WAGON-545:
--
This is just perfect:
{noformat}
2019-01-29T08:35:35.1359175Z
[BasicRepositoryConnector-repo.maven.apache.org-136-2] [INFO] I/O exception
(java.net.SocketException) caught when processing request to
{s}->https://repo.maven.apache.org:443: Connection reset
2019-01-29T08:35:35.1359264Z
[BasicRepositoryConnector-repo.maven.apache.org-136-2] [DEBUG] Connection reset
2019-01-29T08:35:35.1359592Z java.net.SocketException: Connection reset
2019-01-29T08:35:35.1368759Z at java.net.SocketInputStream.read
(SocketInputStream.java:210)
2019-01-29T08:35:35.1375248Z at java.net.SocketInputStream.read
(SocketInputStream.java:141)
2019-01-29T08:35:35.1381980Z at sun.security.ssl.InputRecord.readFully
(InputRecord.java:465)
2019-01-29T08:35:35.1382195Z at sun.security.ssl.InputRecord.read
(InputRecord.java:503)
2019-01-29T08:35:35.1382344Z at sun.security.ssl.SSLSocketImpl.readRecord
(SSLSocketImpl.java:975)
2019-01-29T08:35:35.1382511Z at
sun.security.ssl.SSLSocketImpl.readDataRecord (SSLSocketImpl.java:933)
2019-01-29T08:35:35.1382740Z at sun.security.ssl.AppInputStream.read
(AppInputStream.java:105)
2019-01-29T08:35:35.1382896Z at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead
(SessionInputBufferImpl.java:137)
2019-01-29T08:35:35.1385053Z at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer
(SessionInputBufferImpl.java:153)
2019-01-29T08:35:35.1391132Z at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.readLine
(SessionInputBufferImpl.java:282)
2019-01-29T08:35:35.1398320Z at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
(DefaultHttpResponseParser.java:138)
2019-01-29T08:35:35.1401274Z at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
(DefaultHttpResponseParser.java:56)
2019-01-29T08:35:35.1405528Z at
org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractMessageParser.parse
(AbstractMessageParser.java:259)
2019-01-29T08:35:35.1409980Z at
org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.receiveResponseHeader
(DefaultBHttpClientConnection.java:163)
2019-01-29T08:35:35.1413817Z at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.receiveResponseHeader
(CPoolProxy.java:165)
2019-01-29T08:35:35.1420489Z at
org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doReceiveResponse
(HttpRequestExecutor.java:273)
2019-01-29T08:35:35.1452683Z at
org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
(HttpRequestExecutor.java:125)
2019-01-29T08:35:35.1452805Z at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
(MainClientExec.java:272)
2019-01-29T08:35:35.1452856Z at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
(ProtocolExec.java:185)
2019-01-29T08:35:35.1452903Z at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
(RetryExec.java:89)
2019-01-29T08:35:35.1452966Z at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute
(RedirectExec.java:110)
2019-01-29T08:35:35.1453014Z at
org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute
(InternalHttpClient.java:185)
2019-01-29T08:35:35.1453086Z at
org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
(CloseableHttpClient.java:83)
2019-01-29T08:35:35.1453135Z at
org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
(AbstractHttpClientWagon.java:958)
2019-01-29T08:35:35.1453191Z at
org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
(AbstractHttpClientWagon.java:1117)
2019-01-29T08:35:35.1453254Z at
org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
(AbstractHttpClientWagon.java:1094)
2019-01-29T08:35:35.1453299Z at
org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126)
2019-01-29T08:35:35.1453345Z at
org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
2019-01-29T08:35:35.1453401Z at org.apache.maven.wagon.StreamWagon.get
(StreamWagon.java:61)
2019-01-29T08:35:35.1453601Z at
org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
(WagonTransporter.java:567)
2019-01-29T08:35:35.1453648Z at
org.eclipse.aether.transport.wagon.WagonTransporter.execute
(WagonTransporter.java:435)
[jira] [Updated] (WAGON-545) Connection reset while downloading artifacts in cloud environment (Azure)
[ https://issues.apache.org/jira/browse/WAGON-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Domsch updated WAGON-545: --- Attachment: successful-build-ttl5.zip > Connection reset while downloading artifacts in cloud environment (Azure) > - > > Key: WAGON-545 > URL: https://issues.apache.org/jira/browse/WAGON-545 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Microsoft Azure 'Hosted VS2017' >Reporter: Christian Domsch >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.2 > > Attachments: log_10_310.zip, log_10_311.zip, log_10_325.zip, > successful-build-ttl5.zip > > > We are building a huge multi-module project in the azure cloud and experience > random connection resets during our build due to probably the same issue as > in WAGON-486. Since it is stated by Microsoft that they terminate connections > that are idle for longer than four minutes (see solution comment > [here|https://developercommunity.visualstudio.com/content/problem/357696/maven-project-build-failing-with-connection-reset.html], > I set -Dmaven.wagon.httpconnectionManager.ttlSeconds=120. Also, disabling > the http pool does not solve the problem. Attached are logs from out main > build with logging turned on for the wagon components, as mentioned in the > comment section of WAGON-486. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WAGON-545) Connection reset while downloading artifacts in cloud environment (Azure)
[ https://issues.apache.org/jira/browse/WAGON-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-545: - Fix Version/s: (was: waiting-for-feedback) 3.3.2 > Connection reset while downloading artifacts in cloud environment (Azure) > - > > Key: WAGON-545 > URL: https://issues.apache.org/jira/browse/WAGON-545 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Microsoft Azure 'Hosted VS2017' >Reporter: Christian Domsch >Assignee: Michael Osipov >Priority: Major > Fix For: 3.3.2 > > Attachments: log_10_310.zip, log_10_311.zip, log_10_325.zip > > > We are building a huge multi-module project in the azure cloud and experience > random connection resets during our build due to probably the same issue as > in WAGON-486. Since it is stated by Microsoft that they terminate connections > that are idle for longer than four minutes (see solution comment > [here|https://developercommunity.visualstudio.com/content/problem/357696/maven-project-build-failing-with-connection-reset.html], > I set -Dmaven.wagon.httpconnectionManager.ttlSeconds=120. Also, disabling > the http pool does not solve the problem. Attached are logs from out main > build with logging turned on for the wagon components, as mentioned in the > comment section of WAGON-486. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-545) Connection reset while downloading artifacts in cloud environment (Azure)
[ https://issues.apache.org/jira/browse/WAGON-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754839#comment-16754839 ] Michael Osipov commented on WAGON-545: -- I am glad that this works now as expected. Please attach the logfile. To be on the safe side configure 4 min as instructed by Microsoft. I will merge the patch and release Wagon to get this into Maven 3.6.1. Thanks for pointing out this issue. > Connection reset while downloading artifacts in cloud environment (Azure) > - > > Key: WAGON-545 > URL: https://issues.apache.org/jira/browse/WAGON-545 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Microsoft Azure 'Hosted VS2017' >Reporter: Christian Domsch >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: log_10_310.zip, log_10_311.zip, log_10_325.zip > > > We are building a huge multi-module project in the azure cloud and experience > random connection resets during our build due to probably the same issue as > in WAGON-486. Since it is stated by Microsoft that they terminate connections > that are idle for longer than four minutes (see solution comment > [here|https://developercommunity.visualstudio.com/content/problem/357696/maven-project-build-failing-with-connection-reset.html], > I set -Dmaven.wagon.httpconnectionManager.ttlSeconds=120. Also, disabling > the http pool does not solve the problem. Attached are logs from out main > build with logging turned on for the wagon components, as mentioned in the > comment section of WAGON-486. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-573) excluding generated sources with sourceFileExcludes not working
[
https://issues.apache.org/jira/browse/MJAVADOC-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Praet updated MJAVADOC-573:
-
Description:
I want to exclude generated source code in the target folder from the javadoc
plugin execution.
{code:java}
org.apache.maven.plugins
maven-javadoc-plugin
3.0.1
process-sources
javadoc
**/target/**/*.java
{code}
But this isn't working. When I activate debug mode, I see these files are still
there in the argfile:
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/ObjectFactory.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/package-info.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestPortType.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestRequest.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestResponse.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestService.java'
If instead, I configure
{code}
**/intf/**/*.java
{code}
then it does work. So I have the impression these exclusion patterns are maybe
resolved from within the specific source root
{{D:/projects/JaxUtils/target/generated-sources/jaxws/}} instead of the project
basedir?
was:
I want to exclude generated source code in the target folder from the javadoc
plugin execution.
{code:java}
org.apache.maven.plugins
maven-javadoc-plugin
3.0.1
process-sources
javadoc
**/target/**/*.java
{code}
But this isn't working. When I activate debug mode, I see these files are still
there in the argfile:
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/ObjectFactory.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/package-info.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestPortType.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestRequest.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestResponse.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestService.java'
If instead, I configure
{{**/intf/**/*.java}} then it does work.
So I have the impression these exclusion patterns are maybe resolved from
within the specific source root
{{D:/projects/JaxUtils/target/generated-sources/jaxws/}} instead of the project
basedir?
> excluding generated sources with sourceFileExcludes not working
> ---
>
> Key: MJAVADOC-573
> URL: https://issues.apache.org/jira/browse/MJAVADOC-573
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Jimmy Praet
>Priority: Major
>
> I want to exclude generated source code in the target folder from the javadoc
> plugin execution.
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.0.1
>
>
> process-sources
>
> javadoc
>
>
>
> **/target/**/*.java
>
>
>
>
>
> {code}
> But this isn't working. When I activate debug mode, I see these files are
> still there in the argfile:
>
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/ObjectFactory.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/package-info.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestPortType.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestRequest.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestResponse.java'
> 'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestService.java'
> If instead, I configure
> {code}
> **/intf/**/*.java
> {code}
> then it does work. So I have the impression these exclusion patterns are
> maybe resolved from within the specific source root
> {{D:/projects/JaxUtils/target/generated-sources/jaxws/}} instead of the
> project basedir?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-573) excluding generated sources with sourceFileExcludes not working
Jimmy Praet created MJAVADOC-573:
Summary: excluding generated sources with sourceFileExcludes not
working
Key: MJAVADOC-573
URL: https://issues.apache.org/jira/browse/MJAVADOC-573
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Jimmy Praet
I want to exclude generated source code in the target folder from the javadoc
plugin execution.
{code:java}
org.apache.maven.plugins
maven-javadoc-plugin
3.0.1
process-sources
javadoc
**/target/**/*.java
{code}
But this isn't working. When I activate debug mode, I see these files are still
there in the argfile:
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/ObjectFactory.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/package-info.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestPortType.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestRequest.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestResponse.java'
'D:/projects/JaxUtils/target/generated-sources/jaxws/be/fgov/kszbcss/intf/testservice/TestService.java'
If instead, I configure
{{**/intf/**/*.java}} then it does work.
So I have the impression these exclusion patterns are maybe resolved from
within the specific source root
{{D:/projects/JaxUtils/target/generated-sources/jaxws/}} instead of the project
basedir?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (WAGON-545) Connection reset while downloading artifacts in cloud environment (Azure)
[ https://issues.apache.org/jira/browse/WAGON-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754804#comment-16754804 ] Christian Domsch edited comment on WAGON-545 at 1/29/19 9:54 AM: - Ok, sorry for the delay, but I was facing [this|https://issues.apache.org/jira/browse/JS2-1366] issue, as well. So, the build without TTL configured was successful, So heaps of thanks to you! I am just curious, why was it successful, although the default TTL is 5mins, Azure should terminate in four mins? Also, if you interested, I can attach the successful logs (debug still enabled) here. was (Author: cdomsch): Ok, sorry for the delay, but I was facing [this|https://issues.apache.org/jira/browse/JS2-1366] issue, as well. So, the build without TTL configured was successful, So heaps of thanks to you! I am just curious, why was it successful, although the default TTL is 5mins, but Azure should terminate in four mins? > Connection reset while downloading artifacts in cloud environment (Azure) > - > > Key: WAGON-545 > URL: https://issues.apache.org/jira/browse/WAGON-545 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Microsoft Azure 'Hosted VS2017' >Reporter: Christian Domsch >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: log_10_310.zip, log_10_311.zip, log_10_325.zip > > > We are building a huge multi-module project in the azure cloud and experience > random connection resets during our build due to probably the same issue as > in WAGON-486. Since it is stated by Microsoft that they terminate connections > that are idle for longer than four minutes (see solution comment > [here|https://developercommunity.visualstudio.com/content/problem/357696/maven-project-build-failing-with-connection-reset.html], > I set -Dmaven.wagon.httpconnectionManager.ttlSeconds=120. Also, disabling > the http pool does not solve the problem. Attached are logs from out main > build with logging turned on for the wagon components, as mentioned in the > comment section of WAGON-486. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-545) Connection reset while downloading artifacts in cloud environment (Azure)
[ https://issues.apache.org/jira/browse/WAGON-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754804#comment-16754804 ] Christian Domsch commented on WAGON-545: Ok, sorry for the delay, but I was facing [this|https://issues.apache.org/jira/browse/JS2-1366] issue, as well. So, the build without TTL configured was successful, So heaps of thanks to you! I am just curious, why was it successful, although the default TTL is 5mins, but Azure should terminate in four mins? > Connection reset while downloading artifacts in cloud environment (Azure) > - > > Key: WAGON-545 > URL: https://issues.apache.org/jira/browse/WAGON-545 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Microsoft Azure 'Hosted VS2017' >Reporter: Christian Domsch >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > Attachments: log_10_310.zip, log_10_311.zip, log_10_325.zip > > > We are building a huge multi-module project in the azure cloud and experience > random connection resets during our build due to probably the same issue as > in WAGON-486. Since it is stated by Microsoft that they terminate connections > that are idle for longer than four minutes (see solution comment > [here|https://developercommunity.visualstudio.com/content/problem/357696/maven-project-build-failing-with-connection-reset.html], > I set -Dmaven.wagon.httpconnectionManager.ttlSeconds=120. Also, disabling > the http pool does not solve the problem. Attached are logs from out main > build with logging turned on for the wagon components, as mentioned in the > comment section of WAGON-486. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
