[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report
[
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426496#comment-16426496
]
Tibor Digana commented on SUREFIRE-1480:
After you ran {{mvn install -DskipTests -Dcheckstyle.skip}} download another
tool, IntelliJ IDEA for free for Community
[IDEA|https://www.jetbrains.com/idea/download/]. Open the project by selecting
{{pom.xml}} in the root of project and open the file as project (not a file).
IDEA will understand the generated sources like {{MessageBuilder}}.
> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
> * Jenkins 2.108
> * Maven 3.??
> * JUnit 4.12
> * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple
> JUnit methods), which are all run in parallel. Some of the tests may be
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
>
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being
> flagged as failed, and Jenkins simply has the message:
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct
> filename!).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report
[
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426493#comment-16426493
]
Tibor Digana commented on SUREFIRE-1480:
ok, now I understand what you are doing. You ran the build in Surefire project
with {{mvn test}}. You have to use {{mvn install}}. It's specific in this
project. Then everything will be just fine.
> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
> * Jenkins 2.108
> * Maven 3.??
> * JUnit 4.12
> * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple
> JUnit methods), which are all run in parallel. Some of the tests may be
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
>
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being
> flagged as failed, and Jenkins simply has the message:
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct
> filename!).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1430) Parallel parameterized JUnit test hangs on Linux
[
https://issues.apache.org/jira/browse/SUREFIRE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426487#comment-16426487
]
Tibor Digana commented on SUREFIRE-1430:
[~christian.beikov]
After investigating this issue I found out that it is not related to Linux. It
was reproduced on Linux only because the number of virtual CPU is 1. So I
turned the configuration from
{code:xml}
1
true
{code}
to
{code:xml}
3
false
{code}
which caused hanging the plugin finally on both Linux and Windows.
If you set {{threadCount}} to 4 all tests pass on both platforms.
It means that we have a bug in parallel computer or dissipation of threads to
suites/classes/methods.
I will develop a unit test and isolate the problem only to
ParallelComputerBuilder.
> Parallel parameterized JUnit test hangs on Linux
>
>
> Key: SUREFIRE-1430
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1430
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.18, 2.18.1, 2.19, 2.19.1, 2.20, 2.20.1
> Environment: Linux/Ubuntu
>Reporter: Christian Beikov
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> This is a follow up of SUREFIRE-1264. The test case is here:
> https://github.com/beikov/surefire-test
> The problem is, that a simple parameterized JUnit test hangs when running in
> parallel mode on Linux.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426411#comment-16426411 ] ASF GitHub Bot commented on MNG-6389: - gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-378801064 @rfscholte I created the maven-toolchain-builder module with the matching packages, see if that works for you 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 > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > Fix For: 3.5.4-candidate > > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module
gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-378801064 @rfscholte I created the maven-toolchain-builder module with the matching packages, see if that works for you 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] (MNG-6387) Pom files should have a dedicated mime type registered ("application/pom+xml" or similar)
[
https://issues.apache.org/jira/browse/MNG-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426401#comment-16426401
]
Alex Dubov commented on MNG-6387:
-
# Make sure that my "/etc/mime.types" is up to date, so Java's
"Files.probeContentType" works as expected.
# Wait for other tools to incorporate the up to date version of the mime
database (this happens fairly regularly).
:)
> Pom files should have a dedicated mime type registered ("application/pom+xml"
> or similar)
> -
>
> Key: MNG-6387
> URL: https://issues.apache.org/jira/browse/MNG-6387
> Project: Maven
> Issue Type: Wish
> Components: POM
>Reporter: Alex Dubov
>Priority: Trivial
>
> For the sake of convenience working with ever growing abundance of packages,
> and, thus, pom files, is not it time to give the humble pom file its own,
> dedicated mime type (something to the tune of "application/pom+xml")?
> Presently, the fact that pom files don't have a dedicated mime type causes
> all kinds of minor but annoying issues in all kinds of least expected places.
> Considering that registering a mime type with IANA is a pretty
> straightforward process and that pom files are widely used for all kinds of
> automation purposes (and not exclusively by maven anymore), I, on behalf of
> the wider community, urge you to consider registering a dedicated pom mime
> type.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report
[
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426353#comment-16426353
]
Mark Lehky commented on SUREFIRE-1480:
--
That was a total fail.
# I added some logging.
# I ran {{mvn -DskipTests -Dcheckstyle.skip install}}, which passed.
# Updated my project to use surefire 3.0.0-SNAPSHOT. I get:
{noformat}
[INFO] --- maven-failsafe-plugin:3.0.0-SNAPSHOT:integration-test (default) @
XXX-integrationtests ---
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.345 s
[INFO] Finished at: 2018-04-04T16:05:24-07:00
[INFO] Final Memory: 26M/409M
[INFO]
---
constituent[0]: file:/Users/mlehky/apache-maven-3.5.0/conf/logging/
constituent[1]: file:/Users/mlehky/apache-maven-3.5.0/lib/aopalliance-1.0.jar
constituent[2]: file:/Users/mlehky/apache-maven-3.5.0/lib/cdi-api-1.0.jar
constituent[3]: file:/Users/mlehky/apache-maven-3.5.0/lib/commons-cli-1.4.jar
constituent[4]: file:/Users/mlehky/apache-maven-3.5.0/lib/commons-io-2.5.jar
constituent[5]: file:/Users/mlehky/apache-maven-3.5.0/lib/commons-lang3-3.5.jar
constituent[6]: file:/Users/mlehky/apache-maven-3.5.0/lib/guava-20.0.jar
constituent[7]: file:/Users/mlehky/apache-maven-3.5.0/lib/guice-4.0-no_aop.jar
constituent[8]: file:/Users/mlehky/apache-maven-3.5.0/lib/jansi-1.13.jar
constituent[9]: file:/Users/mlehky/apache-maven-3.5.0/lib/javax.inject-1.jar
constituent[10]:
file:/Users/mlehky/apache-maven-3.5.0/lib/jcl-over-slf4j-1.7.22.jar
constituent[11]: file:/Users/mlehky/apache-maven-3.5.0/lib/jsr250-api-1.0.jar
constituent[12]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-artifact-3.5.0.jar
constituent[13]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-builder-support-3.5.0.jar
constituent[14]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-compat-3.5.0.jar
constituent[15]: file:/Users/mlehky/apache-maven-3.5.0/lib/maven-core-3.5.0.jar
constituent[16]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-embedder-3.5.0.jar
constituent[17]: file:/Users/mlehky/apache-maven-3.5.0/lib/maven-model-3.5.0.jar
constituent[18]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-model-builder-3.5.0.jar
constituent[19]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-plugin-api-3.5.0.jar
constituent[20]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-repository-metadata-3.5.0.jar
constituent[21]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-resolver-api-1.0.3.jar
constituent[22]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-resolver-connector-basic-1.0.3.jar
constituent[23]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-resolver-impl-1.0.3.jar
constituent[24]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-resolver-provider-3.5.0.jar
constituent[25]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-resolver-spi-1.0.3.jar
constituent[26]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-resolver-transport-wagon-1.0.3.jar
constituent[27]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-resolver-util-1.0.3.jar
constituent[28]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-settings-3.5.0.jar
constituent[29]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-settings-builder-3.5.0.jar
constituent[30]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-shared-utils-3.1.0.jar
constituent[31]:
file:/Users/mlehky/apache-maven-3.5.0/lib/maven-slf4j-provider-3.5.0.jar
constituent[32]:
file:/Users/mlehky/apache-maven-3.5.0/lib/org.eclipse.sisu.inject-0.3.3.jar
constituent[33]:
file:/Users/mlehky/apache-maven-3.5.0/lib/org.eclipse.sisu.plexus-0.3.3.jar
constituent[34]: file:/Users/mlehky/apache-maven-3.5.0/lib/plexus-cipher-1.7.jar
constituent[35]:
file:/Users/mlehky/apache-maven-3.5.0/lib/plexus-component-annotations-1.7.1.jar
constituent[36]:
file:/Users/mlehky/apache-maven-3.5.0/lib/plexus-interpolation-1.24.jar
constituent[37]:
file:/Users/mlehky/apache-maven-3.5.0/lib/plexus-sec-dispatcher-1.4.jar
constituent[38]:
file:/Users/mlehky/apache-maven-3.5.0/lib/plexus-utils-3.0.24.jar
constituent[39]: file:/Users/mlehky/apache-maven-3.5.0/lib/slf4j-api-1.7.22.jar
constituent[40]: file:/Users/mlehky/apache-maven-3.5.0/lib/wagon-file-2.12.jar
constituent[41]:
file:/Users/mlehky/apache-maven-3.5.0/lib/wagon-http-2.12-shaded.jar
constituent[42]:
file:/Users/mlehky/apache-maven-3.5.0/lib/wagon-provider-api-2.12.jar
---
Exception in thread "main" java.lang.Error: Unresolved compilation problems:
The import org.apache.maven.shared.utils.logging.MessageBuilder cannot
be resolved
The import org.apache.maven.shared.utils.logging.MessageUtils cannot be
resolved
MessageBuilder cannot be resolved to a type
[jira] [Comment Edited] (SUREFIRE-1480) parallel tests may produce invalid .xml report
[
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426273#comment-16426273
]
Mark Lehky edited comment on SUREFIRE-1480 at 4/4/18 10:36 PM:
---
I checked out the latest (3.0.0-SNAPSHOT), and from maven-surefire directory I
can {{mvn verify}} everything: "BUILD SUCCESS".
However, I cannot say the same from my IDE - I am an Eclipse guy. I get 138
errors. Any hints?
I can find the class you mentioned no problem. Does the surefire project use
any kind of a logger? For now I'm going to see how far I can get with just
{{System.out}}.
was (Author: mlehky):
I checked out the latest (3.0.0-SNAPSHOT), and from maven-surefire I can {{mvn
verify}} everything: "BUILD SUCCESS".
However, I cannot say the same from my IDE - I am an Eclipse guy. I get 138
errors. Any hints?
I can find the class you mentioned no problem. Does the surefire project use
any kind of a logger? For now I'm going to see how far I can get with just
{{System.out}}.
> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
> * Jenkins 2.108
> * Maven 3.??
> * JUnit 4.12
> * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple
> JUnit methods), which are all run in parallel. Some of the tests may be
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
>
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being
> flagged as failed, and Jenkins simply has the message:
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct
> filename!).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report
[
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426273#comment-16426273
]
Mark Lehky commented on SUREFIRE-1480:
--
I checked out the latest (3.0.0-SNAPSHOT), and from maven-surefire I can {{mvn
verify}} everything: "BUILD SUCCESS".
However, I cannot say the same from my IDE - I am an Eclipse guy. I get 138
errors. Any hints?
I can find the class you mentioned no problem. Does the surefire project use
any kind of a logger? For now I'm going to see how far I can get with just
{{System.out}}.
> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
> * Jenkins 2.108
> * Maven 3.??
> * JUnit 4.12
> * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple
> JUnit methods), which are all run in parallel. Some of the tests may be
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
>
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being
> flagged as failed, and Jenkins simply has the message:
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct
> filename!).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426259#comment-16426259
]
Mike Kelly commented on MNG-6388:
-
And, I can confirm the snapshot build corrects the issue in my case.
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426255#comment-16426255
]
Mike Kelly commented on MNG-6388:
-
We have two OIDs added, according to Wireshark:
* type-id: 1.3.6.1.4.1.311.20.2.3 (id-ms-user-principal-name)
* type-id: 1.3.6.1.5.2.2 (id-pkinit-san)
The first one is a UTF8String like "HTTP/artifactory.example@example.com"
The second is a KRB5PrincipalName, representing basically the same thing as the
UTF8 string above.
These are both added automatically by FreeIPA's PKI component; it generally
seems to require/encourage you to create certs tied to Kerberos Services.
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSITE-816) Generated links in index.html are wrong while using a property in distributionManagement (site)
[
https://issues.apache.org/jira/browse/MSITE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426249#comment-16426249
]
Hervé Boutemy commented on MSITE-816:
-
please provide a test project
and did you try to just rename the property name? distributionManagement.site
is a bad idea: just change it to distributionManagement_site and I can tell you
that it never will be interpolated as org.apache.maven.model.Site@b63dc8
> Generated links in index.html are wrong while using a property in
> distributionManagement (site)
> ---
>
> Key: MSITE-816
> URL: https://issues.apache.org/jira/browse/MSITE-816
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.7
> Environment: C:\...\trunk>mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T20:49:05+01:00)
> Maven home: C:\...\apache-maven-3.5.3\bin\..
> Java version: 1.8.0_72, vendor: Oracle Corporation
> Java home: C:\...\jdk1.8.0_72\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> I have a multi module build which contains several modules furthermore I have
> a {{settings.xml}} which contains a property
> {{file:///C:/Users/Public/site/}}
> which I use in distributionManagement of my pom file...like this:
> {code:xml}
>
> sites
> ${distributionManagement.site}
>
> {code}
> Now I generate a site via
> {{mvn site-deploy}} or {{mvn site site:stage}} will result in the same.
> I get links generated in the {{index.html}} document which look like this:
> {code}
> Description
>
> href="..\..\..\..\..\org.apache.maven.model.Site@1f64b2a\defaults-spring-boot-parent/index.html">defaults-spring-boot-parent
> Defaults Parent for Spring Boot Applications
>
> href="..\..\..\..\..\org.apache.maven.model.Site@b63dc8\default-scripts/index.html">default-scripts
> Defaults Parent for Script projects.
>
> href="..\..\..\..\..\org.apache.maven.model.Site@c13984\scripts-descriptor/index.html">scripts-descriptor
> Assembly descriptor for scripts project.
>
> {code}
> If I replace the entry in distributionManagement with an URL without any
> property:
> {code:xml}
>
> sites
> file:///C:/site/
>
> {code}
> The links are generated correctly...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426146#comment-16426146 ] ASF GitHub Bot commented on MNG-6389: - rfscholte commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-378739685 I don't think the MavenToolchainMerger belongs there. If you take a look at https://maven.apache.org/ref/3.5.3/ I would say we should also introduce a maven-toolchain-builder and move all matching packages to that artifact. 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 > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > Fix For: 3.5.4-candidate > > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] rfscholte commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module
rfscholte commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-378739685 I don't think the MavenToolchainMerger belongs there. If you take a look at https://maven.apache.org/ref/3.5.3/ I would say we should also introduce a maven-toolchain-builder and move all matching packages to that artifact. 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] [Comment Edited] (MNG-6387) Pom files should have a dedicated mime type registered ("application/pom+xml" or similar)
[
https://issues.apache.org/jira/browse/MNG-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426136#comment-16426136
]
Michael Osipov edited comment on MNG-6387 at 4/4/18 8:31 PM:
-
{quote}It's not a "shortcoming of websphere" it's a shortcoming of not being in
the mime database. :)
{quote}
Granted.
What would you do if the MIME type would be registered?
was (Author: michael-o):
{quote}It's not a "shortcoming of websphere" it's a shortcoming of not being in
the mime database. :)
{quote}
> Pom files should have a dedicated mime type registered ("application/pom+xml"
> or similar)
> -
>
> Key: MNG-6387
> URL: https://issues.apache.org/jira/browse/MNG-6387
> Project: Maven
> Issue Type: Wish
> Components: POM
>Reporter: Alex Dubov
>Priority: Trivial
>
> For the sake of convenience working with ever growing abundance of packages,
> and, thus, pom files, is not it time to give the humble pom file its own,
> dedicated mime type (something to the tune of "application/pom+xml")?
> Presently, the fact that pom files don't have a dedicated mime type causes
> all kinds of minor but annoying issues in all kinds of least expected places.
> Considering that registering a mime type with IANA is a pretty
> straightforward process and that pom files are widely used for all kinds of
> automation purposes (and not exclusively by maven anymore), I, on behalf of
> the wider community, urge you to consider registering a dedicated pom mime
> type.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6387) Pom files should have a dedicated mime type registered ("application/pom+xml" or similar)
[
https://issues.apache.org/jira/browse/MNG-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426136#comment-16426136
]
Michael Osipov commented on MNG-6387:
-
{quote}It's not a "shortcoming of websphere" it's a shortcoming of not being in
the mime database. :)
{quote}
> Pom files should have a dedicated mime type registered ("application/pom+xml"
> or similar)
> -
>
> Key: MNG-6387
> URL: https://issues.apache.org/jira/browse/MNG-6387
> Project: Maven
> Issue Type: Wish
> Components: POM
>Reporter: Alex Dubov
>Priority: Trivial
>
> For the sake of convenience working with ever growing abundance of packages,
> and, thus, pom files, is not it time to give the humble pom file its own,
> dedicated mime type (something to the tune of "application/pom+xml")?
> Presently, the fact that pom files don't have a dedicated mime type causes
> all kinds of minor but annoying issues in all kinds of least expected places.
> Considering that registering a mime type with IANA is a pretty
> straightforward process and that pom files are widely used for all kinds of
> automation purposes (and not exclusively by maven anymore), I, on behalf of
> the wider community, urge you to consider registering a dedicated pom mime
> type.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426072#comment-16426072
]
Michael Osipov commented on MNG-6388:
-
[~pioto], out of curiously, do you embed {{OtherName}} with
1.2.840.113554.1.2.2.1 OID and for what pupose?
Anyway,
[here|http://home.apache.org/~michaelo/apache-maven-3.5.4-SNAPSHOT-bin.tar.gz]
is a snapshot build of Maven with updated dependencies. Please test! I'd still
love to see your cert.
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1430) Parallel parameterized JUnit test hangs on Linux
[ https://issues.apache.org/jira/browse/SUREFIRE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1430: --- Fix Version/s: (was: 2.21.1) 3.0.0-M1 > Parallel parameterized JUnit test hangs on Linux > > > Key: SUREFIRE-1430 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1430 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.18, 2.18.1, 2.19, 2.19.1, 2.20, 2.20.1 > Environment: Linux/Ubuntu >Reporter: Christian Beikov >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M1 > > > This is a follow up of SUREFIRE-1264. The test case is here: > https://github.com/beikov/surefire-test > The problem is, that a simple parameterized JUnit test hangs when running in > parallel mode on Linux. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-6389: Fix Version/s: 3.5.4-candidate > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > Fix For: 3.5.4-candidate > > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425978#comment-16425978 ] ASF GitHub Bot commented on MNG-6389: - gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-378700225 @rfscholte can you review and merge when possible? 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 > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module
gastaldi commented on issue #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162#issuecomment-378700225 @rfscholte can you review and merge when possible? 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] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425967#comment-16425967 ] George Gastaldi commented on MNG-6389: -- Created a PR generating this artifact back with the same coordinates https://github.com/apache/maven/pull/162 > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425963#comment-16425963 ] ASF GitHub Bot commented on MNG-6389: - gastaldi opened a new pull request #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ 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 > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] gastaldi opened a new pull request #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module
gastaldi opened a new pull request #162: [MNG-6389] - Move toolchains model generation from maven-core to maven-toolchain module URL: https://github.com/apache/maven/pull/162 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ 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-490) Aggregate goal fails if artifacts not installed
[
https://issues.apache.org/jira/browse/MJAVADOC-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425859#comment-16425859
]
Tibor Digana commented on MJAVADOC-490:
---
My assembly plugin is not able to find jar file however it exists and my issue
happens even without release plugin. It is enough to run
{{install post-site -Dwagon.webdav.continueOnFailure=true -P
release,generate-ddl -e -DskipTests -DskipITs}}
I use {{install}} many times. So my issue is not related to missing jar file in
local repo. It is more about something weird in MavenProject model in
combination with {{javadoc:aggregate}} which runs within site reporting and
{{assembly}} plugin which has {{assembly.xml}}:
{code:xml}
WEB-INF/lib
true
false
test
*:audit-domain:jar:without-validation
{code}
> Aggregate goal fails if artifacts not installed
> ---
>
> Key: MJAVADOC-490
> URL: https://issues.apache.org/jira/browse/MJAVADOC-490
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Shannon Carey
>Priority: Major
>
> Using the javadoc aggregate report causes release:perform to fail if the
> modules were not already installed into the local repository.
> During release:perform's execution of "deploy site-deploy", when
> report:aggregate runs it appears to fork executions on all of the reactor
> modules ("Forking mymodule 0.0.1"). When it gets to a module which has a
> dependency on another module, it cannot find it locally (since that module
> has not yet been installed), tries to download it from Nexus, and ultimately
> fails with "... Could not resolve dependencies for project ... The following
> artifacts could not be resolved ..."
> The only way I can think of to fix this is to add "install" to the
> "preparationGoals" of release:prepare so that the modules are already
> installed before release:perform is run. However, this violates the
> self-containment of release:perform's deploy build, and is generally
> confusing and difficult to diagnose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6389) Move the toolchains model to a separate artifactId
[ https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425830#comment-16425830 ] Robert Scholte commented on MNG-6389: - There used to be a separate [maven-toolchain|http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22maven-toolchain%22] artifact, don't know why it was dropped. I agree that it makes sense to have a separate artifact for the toolchain model. > Move the toolchains model to a separate artifactId > -- > > Key: MNG-6389 > URL: https://issues.apache.org/jira/browse/MNG-6389 > Project: Maven > Issue Type: Improvement > Components: Toolchains >Affects Versions: 3.5.3 >Reporter: George Gastaldi >Priority: Major > > Just as maven-model and maven-settings, it would be nice to have a > maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] jadekler commented on issue #4: Add README.md
jadekler commented on issue #4: Add README.md URL: https://github.com/apache/maven-checkstyle-plugin/pull/4#issuecomment-378666572 Oh! That's a much better README.md haha. I hope it gets merged in soon! 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
[GitHub] jadekler closed pull request #4: Add README.md
jadekler closed pull request #4: Add README.md URL: https://github.com/apache/maven-checkstyle-plugin/pull/4 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/README.md b/README.md new file mode 100644 index 000..e107120 --- /dev/null +++ b/README.md @@ -0,0 +1,3 @@ +# maven-checkstyle-plugin + +Issues are tracked in JIRA: https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-326?filter=allopenissues 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] (MCOMPILER-334) Missing configuration documentation
[ https://issues.apache.org/jira/browse/MCOMPILER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425821#comment-16425821 ] Robert Scholte commented on MCOMPILER-334: -- I guess you are looking for the [goal configuration|https://maven.apache.org/plugins/maven-compiler-plugin/plugin-info.html], or more specific the [compile|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html] configuration. > Missing configuration documentation > --- > > Key: MCOMPILER-334 > URL: https://issues.apache.org/jira/browse/MCOMPILER-334 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.5.1 >Reporter: Paul Millar >Priority: Minor > > The [Usage > page|https://maven.apache.org/plugins/maven-compiler-plugin/usage.html] > should provide information on how to use this plugin. However, there is > almost no mention of the available configuration options on this page. > The navigation panel provides links to several example scenarios: [Compile > Using A Different > JDK|https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html], > [Compile Using -source and -target javac > Options|https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html], > etc. These are (no doubt) very helpful for people solving those specific > problems. However, there is apparently no page that provides the > authoritative description of available configuration options. > Please add a page that provides a list of available configuration options, > their expected formats, the default value (if that option is not specified), > and the semantics if the value is specified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425766#comment-16425766
]
Mike Kelly commented on MNG-6388:
-
Also confirmed that Maven 3.5.2 uses httpclient 4.5.2... so yes, this does seem
like the root cause.
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425764#comment-16425764
]
Mike Kelly commented on MNG-6388:
-
[~garydgregory]: OK, but which version is Maven 3.5.3 using? From what I can
tell, looks like wagon-http uses the buggy 4.5.3...
{noformat}
$ unzip -p lib/wagon-http-3.0.0-shaded.jar
META-INF/maven/org.apache.httpcomponents/httpclient/pom.properties
#Generated by Maven
#Sat Jan 21 16:38:45 CET 2017
version=4.5.3
groupId=org.apache.httpcomponents
artifactId=httpclient{noformat}
Is there a straightforward way to put the newer httpclient into the Maven
classpath to verify that fixes things? Or does it require a new release of
Wagon, to be incorporated in a new release of Maven? I'd like to verify that
replacing it with 4.5.4 or 4.5.2 resolves the issue for me.
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425627#comment-16425627
]
Gary Gregory commented on MNG-6388:
---
[~pioto]: Note that HttpClient 4.5.5 is out.
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425502#comment-16425502
]
Mike Kelly commented on MNG-6388:
-
Interesting to think this may be a regression related to my TLS cert.
FWIW, I'm using a cert signed by our internal PKI (provided by [Red Hat
IdM|https://access.redhat.com/products/identity-management]).
The way I've generated the cert has two DNS names, and two "Other Name" fields,
related to Kerberos.
I think we encountered similar issues with HttpClient in our own application a
few months ago, which were related to HTTPCLIENT-1836 as well. Our initial fix
was downgrade from HttpClient 4.5.3 to 4.5.2. Once 4.5.4 was released, we
upgraded to that, which resolved the problem.
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6389) Move the toolchains model to a separate artifactId
George Gastaldi created MNG-6389: Summary: Move the toolchains model to a separate artifactId Key: MNG-6389 URL: https://issues.apache.org/jira/browse/MNG-6389 Project: Maven Issue Type: Improvement Components: Toolchains Affects Versions: 3.5.3 Reporter: George Gastaldi Just as maven-model and maven-settings, it would be nice to have a maven-toolchains artifactId containing only the model. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6388) Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
[
https://issues.apache.org/jira/browse/MNG-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425190#comment-16425190
]
Oleg Kalnichevski commented on MNG-6388:
bq. this is an interesting case for HTTPCLIENT-1836. Do we need to roll a small
ASN.1 DER parser for both types now?
[~michael-o] Please do feel free to raise a change request in JIRA for this
issue or better yet contribute a patch
Oleg
> Error Fetching Artifacts: "[B cannot be cast to java.lang.String"
> -
>
> Key: MNG-6388
> URL: https://issues.apache.org/jira/browse/MNG-6388
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.3
> Environment: $ docker run --rm -it maven:3-jdk-8 mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T19:49:05Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_162, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.21.1.el7.x86_64", arch: "amd64",
> family: "unix"
>
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T14:49:05-05:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Mike Kelly
>Priority: Major
>
> When using Maven 3.5.3 with Artifactory 5.10.0 configured as a "*" mirror,
> downloads & uploads fail with errors like:
> {noformat}
> [ERROR] Failed to execute goal on project ccc-persistence: Could not resolve
> dependencies for project REDACTED:REDACTED:jar:3.47.0-SNAPSHOT: Failed to
> collect dependencies at org.flywaydb:flyway-core:jar:3.2.1: Failed to read
> artifact descriptor for org.flywaydb:flyway-core:jar:3.2.1: Could not
> transfer artifact org.flywaydb:flyway-core:pom:3.2.1 from/to artifactory
> (https://artifactory.REDACTED.com/artifactory/all): [B cannot be cast to
> java.lang.String -> [Help 1]{noformat}
> I've seen this issue both with the official Docker container, and with Maven
> 3.5.3 from MacPorts; in both cases, downgrading back down to 3.5.2 resolved
> the issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCOMPILER-334) Missing configuration documentation
Paul Millar created MCOMPILER-334: - Summary: Missing configuration documentation Key: MCOMPILER-334 URL: https://issues.apache.org/jira/browse/MCOMPILER-334 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.5.1 Reporter: Paul Millar The [Usage page|https://maven.apache.org/plugins/maven-compiler-plugin/usage.html] should provide information on how to use this plugin. However, there is almost no mention of the available configuration options on this page. The navigation panel provides links to several example scenarios: [Compile Using A Different JDK|https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html], [Compile Using -source and -target javac Options|https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html], etc. These are (no doubt) very helpful for people solving those specific problems. However, there is apparently no page that provides the authoritative description of available configuration options. Please add a page that provides a list of available configuration options, their expected formats, the default value (if that option is not specified), and the semantics if the value is specified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSITE-816) Generated links in index.html are wrong while using a property in distributionManagement (site)
[
https://issues.apache.org/jira/browse/MSITE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425089#comment-16425089
]
Karl Heinz Marbaise commented on MSITE-816:
---
[~hboutemy] after experimenting a bit I found that If I use a skin like
Fluido-Skin 1.7 it works correctly(?). Furthermore I have tested to use the
maven-default-skin with version 1.2. which works also. The issue occurs by
using the default skin without changing the skin in any way (no site.xml at
all). Looks like the version 1.0 is used in such case...
> Generated links in index.html are wrong while using a property in
> distributionManagement (site)
> ---
>
> Key: MSITE-816
> URL: https://issues.apache.org/jira/browse/MSITE-816
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.7
> Environment: C:\...\trunk>mvn --version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T20:49:05+01:00)
> Maven home: C:\...\apache-maven-3.5.3\bin\..
> Java version: 1.8.0_72, vendor: Oracle Corporation
> Java home: C:\...\jdk1.8.0_72\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> I have a multi module build which contains several modules furthermore I have
> a {{settings.xml}} which contains a property
> {{file:///C:/Users/Public/site/}}
> which I use in distributionManagement of my pom file...like this:
> {code:xml}
>
> sites
> ${distributionManagement.site}
>
> {code}
> Now I generate a site via
> {{mvn site-deploy}} or {{mvn site site:stage}} will result in the same.
> I get links generated in the {{index.html}} document which look like this:
> {code}
> Description
>
> href="..\..\..\..\..\org.apache.maven.model.Site@1f64b2a\defaults-spring-boot-parent/index.html">defaults-spring-boot-parent
> Defaults Parent for Spring Boot Applications
>
> href="..\..\..\..\..\org.apache.maven.model.Site@b63dc8\default-scripts/index.html">default-scripts
> Defaults Parent for Script projects.
>
> href="..\..\..\..\..\org.apache.maven.model.Site@c13984\scripts-descriptor/index.html">scripts-descriptor
> Assembly descriptor for scripts project.
>
> {code}
> If I replace the entry in distributionManagement with an URL without any
> property:
> {code:xml}
>
> sites
> file:///C:/site/
>
> {code}
> The links are generated correctly...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
