[GitHub] [maven-dependency-plugin] twillouer opened a new pull request #107: Correct typo for depencency:tree -DoutputFile
twillouer opened a new pull request #107: URL: https://github.com/apache/maven-dependency-plugin/pull/107 Little typo in dependency:tree who handle the parameter outputFile instead of output Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEP) 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. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-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. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). 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. - [ ] 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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-surefire] eolivelli commented on pull request #315: [SUREFIRE-1843] - Trademarks / privacy policy footer displays broken
eolivelli commented on pull request #315: URL: https://github.com/apache/maven-surefire/pull/315#issuecomment-699579937 @Tibor17 got it. Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/27/20, 2:42 AM:
--
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (tested on JDK 11 and 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to run on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to run on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-S
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:30 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to run on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHO
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:29 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7. {{jboss.java.home}}
maven property may be omitted if Maven runs on Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:28 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpneJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/c
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:28 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpenJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command (tested on OpneJDK 1.8 + Oracle JDK 1.7
as {{jboss.java.home}} maven property and on Oracle JDK 1.7):
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment]
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:26 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple (requires JDK 1.8):
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
[GitHub] [maven-enforcer] mkarg commented on pull request #80: Support for Java 13, 14 and 15 using Extra Enforcer Rules 1.3
mkarg commented on pull request #80: URL: https://github.com/apache/maven-enforcer/pull/80#issuecomment-699555868 @khmarbaise @hboutemy Kindly requesting review. :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-enforcer] mkarg opened a new pull request #80: Support for Java 13, 14 and 15 using Extra Enforcer Rules 1.3
mkarg opened a new pull request #80: URL: https://github.com/apache/maven-enforcer/pull/80 Upgrading to Extra Enforcer Rules 1.3, so Maven Enforcer Plugin could support Java 13, 14 and 15. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:17 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
One more thing I found with JBoss AS/ WildFly is that this Maven EAR Plugin
configuration
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
is not sufficient to solve these warnings - we need to provide "lib/" prefix
for class-path entries to make JBoss AS / WildFly happy.
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I belie
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:07 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause error / deployment failure on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
> assembly.xml contains incorrect references to modules
>
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 10:07 PM:
---
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without workaround I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
# workaround exists
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov edited comment on MEAR-267 at 9/26/20, 9:57 PM:
--
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to rub on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{$\{JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without workaround I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
# workaround exists
was (Author: abrarovm):
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to execute on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{${JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their
[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202689#comment-17202689
]
Marat Abrarov commented on MEAR-267:
I added integration test deploying WildFly 20.0.1.Final (the latest version of
WildFly ex JBoss AS) and EAR into that WildFly instance here (is based on [my
master branch|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] with
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/wildfly-managed-it]
Test can be executed with simple:
{code:bash}
$ mvn clean verify
{code}
I added integration test deploying JBoss AS 7.1.1.Final (the oldest version of
JBoss AS I was able to execute on Oracle JDK 1.7) and EAR into that JBoss AS
instance here (is based on my master branch with workaround):
[https://github.com/mabrarov/MEAR-267-issue-demo/compare/master...mabrarov:feature/jboss-managed-it]
Test can be executed with this command:
{code:bash}
$ mvn clean verify -Djboss.java.home=${JAVA7_HOME}
{code}
where {{${JAVA7_HOME}}} is location of Oracle JDK 1.7.
Without
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
I get just *warning* and *no errors* on WildFly 20.0.1.Final:
{noformat}
00:38:03,488 WARN [org.jboss.as.server.deployment] (MSC service thread 1-6)
WFLYSRV0059: Class Path entry guava-19.0.jar in
XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar
does not point to a valid jar for a Class-Path reference.
{noformat}
and on JBoss AS 7.1.1.Final:
{noformat}
00:50:33,947 WARN [org.jboss.as.server.deployment] (MSC service thread 1-5)
Class Path entry guava-19.0.jar in
"XXX/MEAR-267-issue-demo/MEAR-267-ear/content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar"
does not point to a valid jar for a Class-Path reference.
{noformat}
I believe we can decrease priority of this bug, because:
# this bug doesn't cause errors / deployment errors on semi-modern and modern
Java EE application servers
#
[workaround|https://issues.apache.org/jira/browse/MEAR-267?focusedCommentId=17202439&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17202439]
exists
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #315: [SUREFIRE-1843] - Trademarks / privacy policy footer displays broken
Tibor17 commented on pull request #315: URL: https://github.com/apache/maven-surefire/pull/315#issuecomment-699548728 @eolivelli Pls use the "Rebase and merge" for single commit pull instead of a pure merge in the future. The the history would be one flow commits instead of a side track. Thx This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Created] (SUREFIRE-1846) Remove Base64 in the Encoder/Decoder and gain the performance for the communication flow: Fork to Plugin
Tibor Digana created SUREFIRE-1846: -- Summary: Remove Base64 in the Encoder/Decoder and gain the performance for the communication flow: Fork to Plugin Key: SUREFIRE-1846 URL: https://issues.apache.org/jira/browse/SUREFIRE-1846 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin, Maven Surefire Plugin, process forking Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 3.0.0-M6 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1845) Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for the tests with logs
[ https://issues.apache.org/jira/browse/SUREFIRE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1845. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=32bd56b4ea908147592ef92c71c4e7936e070993 > Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck > for the tests with logs > - > > Key: SUREFIRE-1845 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1845 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > The fix would speed up the cache 8 times. > After we have applied fast TCP/IP encoder and decoder along with the fix for > this issue we have got fast Test3 in the integration test > ConsoleOutputIT#largerSoutThanMemory(), i.e. 0.44 seconds of the test exec > time from previous 8.8 seconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-278) Ear plugin includes the same artifact twice if used without clean
[ https://issues.apache.org/jira/browse/MEAR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202673#comment-17202673 ] Hudson commented on MEAR-278: - Build succeeded in Jenkins: Maven » Maven TLP » maven-ear-plugin » master #27 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/27/ > Ear plugin includes the same artifact twice if used without clean > - > > Key: MEAR-278 > URL: https://issues.apache.org/jira/browse/MEAR-278 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Fabian Meier >Assignee: Robert Scholte >Priority: Major > Labels: infosupport > Fix For: 3.1.0 > > Attachments: test-ear.zip > > Time Spent: 10m > Remaining Estimate: 0h > > The problem of > https://stackoverflow.com/questions/47436946/maven-ear-plugin-doubled-artifact-when-not-using-clean > still persists. If you rebuild an ear after changing dependency versions, the > new dependencies are included along with the old ones, leading to an > inconsistent ear. The attached Maven project shows this behaviour. It was > first build with "install", where log4j was in version 1.2.8. After changing > the version to 1.2.17, the project was "installed" again, leading to an ear > that contains both log4j versions simultaneously. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MEAR-216) Unable to include dependencies of type test-jar
[
https://issues.apache.org/jira/browse/MEAR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MEAR-216:
---
Fix Version/s: (was: 3.1.0)
waiting-for-feedback
> Unable to include dependencies of type test-jar
> ---
>
> Key: MEAR-216
> URL: https://issues.apache.org/jira/browse/MEAR-216
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Maxim Frolov
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: test-jar-in-ear-2.zip, test-jar-in-ear.zip
>
>
> Please implement support for artifacts of type *test-jar*.
> One of the use cases would be to build a test EAR as a mix of production and
> test JARs where the test JARs are used to set up the test data used to test
> the production code.
> Currently including one or more dependencies of type test-jar causes
> *LifecycleExecutionException*:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules: Unknown artifact type[test-jar] for
> artifact_id -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project suite-systemtests-common-ear:
> Failed to initialize ear modules
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
> initialize ear modules
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
> at
> org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown
> artifact type[test-jar] for common-domain-impl
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MEAR-285) EarMojo fails to handle assorted IO Errors
[ https://issues.apache.org/jira/browse/MEAR-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MEAR-285. -- Resolution: Fixed > EarMojo fails to handle assorted IO Errors > -- > > Key: MEAR-285 > URL: https://issues.apache.org/jira/browse/MEAR-285 > Project: Maven Ear Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.1.0 > > > including failure to create work directory, I/O errors when writing files, > and closing input streams used to read manifests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MEAR-194) Output during creation of Ear is not correct
[
https://issues.apache.org/jira/browse/MEAR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MEAR-194.
--
Assignee: Herve Boutemy
Resolution: Fixed
PR merged in
https://github.com/apache/maven-ear-plugin/commit/7f666e10c797918d43bededda36ed0b196efeefe
> Output during creation of Ear is not correct
>
>
> Key: MEAR-194
> URL: https://issues.apache.org/jira/browse/MEAR-194
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Karl Heinz Marbaise
>Assignee: Herve Boutemy
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.1.0
>
>
> Currently during the creation of the ear the output shows something like this:
> {code}
> [INFO] Building jar: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
> {code}
> It should be changed into:
> {code}
> [INFO] Building ear: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
> {code}
> which is more consistent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MEAR-212) Failed to initialize ear modules: Unknown artifact type[mar] for addressing
[
https://issues.apache.org/jira/browse/MEAR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MEAR-212:
---
Fix Version/s: (was: 3.1.0)
waiting-for-feedback
> Failed to initialize ear modules: Unknown artifact type[mar] for addressing
> ---
>
> Key: MEAR-212
> URL: https://issues.apache.org/jira/browse/MEAR-212
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.10
>Reporter: David Hoffer
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I'm trying to generate and ear file but I'm getting the following message:
> Failed to initialize ear modules: Unknown artifact type[mar] for addressing
> (full debug stack trace is below)
> However I don't have any mar artifacts in my dependencies. What I do have is
> a war that has 4 mar files added as resources and I'm making a ear with the
> skinny war feature.
> Why would the ear plugin give this error when it has no nothing to do with
> the mar resources in the war...or perhaps this error has nothing to do with
> those resources, not sure.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project coreservices-ear: Failed to
> initialize ear modules: Unknown artifact type[mar] for addressing -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
> (default-generate-application-xml) on project coreservices-ear: Failed to
> initialize ear modules
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
> initialize ear modules
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
> at
> org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown
> artifact type[mar] for addressing
> at
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
> at
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
> ... 22 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1834) Make warnings for skipped tests configurable
[
https://issues.apache.org/jira/browse/SUREFIRE-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202659#comment-17202659
]
Tibor Digana commented on SUREFIRE-1834:
[~michaelboyles]
Unfortunately I had to revert your improvement about accepting NULL-able run
order calculator in SUREFIRE-1842 because the problem was that the variable
{{directoryScannerParameters}} was there for historical reasons and now it
woun't make sense for the run order calculator.
> Make warnings for skipped tests configurable
>
>
> Key: SUREFIRE-1834
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1834
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Martin Winandy
>Priority: Major
>
> Currently, Surefire outputs warnings for skipped tests.
> For example:
> {noformat}
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 2, Time elapsed:
> 0.037 s - in org.tinylog.core.runtime.LegacyStackTraceAccessTest
> [WARNING] Tests run: 62, Failures: 0, Errors: 0, Skipped: 2
> {noformat}
> I have some platform depending tests, which are enabled or disabled depending
> on the actual platform. It would be great, if a property could be introduced
> to disable warnings for skipped tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1834) Make warnings for skipped tests configurable
[
https://issues.apache.org/jira/browse/SUREFIRE-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202658#comment-17202658
]
Tibor Digana commented on SUREFIRE-1834:
You and your management should be interesting in XML report.
The XML report is relevant and the warning/info can be interpreted as you like.
The log is a worth for developers and the Warning as well. You know why! The
developers use to Ignore the tests due to intermediate changes but they forget
to remove the annotation in their code. This is very useful indicator.
If you want to hide this colour flash about the skipped tests in the log, then
i would say that you would decrease the code quality this way and it is
undesired.
This logger appears in the Extensions API and you can implement yours, and add
your JAR to the classpath of the plugin.
> Make warnings for skipped tests configurable
>
>
> Key: SUREFIRE-1834
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1834
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Martin Winandy
>Priority: Major
>
> Currently, Surefire outputs warnings for skipped tests.
> For example:
> {noformat}
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 2, Time elapsed:
> 0.037 s - in org.tinylog.core.runtime.LegacyStackTraceAccessTest
> [WARNING] Tests run: 62, Failures: 0, Errors: 0, Skipped: 2
> {noformat}
> I have some platform depending tests, which are enabled or disabled depending
> on the actual platform. It would be great, if a property could be introduced
> to disable warnings for skipped tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1845) Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for the tests with logs
[ https://issues.apache.org/jira/browse/SUREFIRE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1845: --- Summary: Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for the tests with logs (was: Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for all tests with logs) > Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck > for the tests with logs > - > > Key: SUREFIRE-1845 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1845 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > The fix would speed up the cache 8 times. > After we have applied fast TCP/IP encoder and decoder along with the fix for > this issue we have got fast Test3 in the integration test > ConsoleOutputIT#largerSoutThanMemory(), i.e. 0.44 seconds of the test exec > time from previous 8.8 seconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1845) Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for all tests with logs
[ https://issues.apache.org/jira/browse/SUREFIRE-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1845: --- Summary: Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for all tests with logs (was: Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for al tests with logs) > Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck > for all tests with logs > - > > Key: SUREFIRE-1845 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1845 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > > The fix would speed up the cache 8 times. > After we have applied fast TCP/IP encoder and decoder along with the fix for > this issue we have got fast Test3 in the integration test > ConsoleOutputIT#largerSoutThanMemory(), i.e. 0.44 seconds of the test exec > time from previous 8.8 seconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1844. -- > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1844: --- Fix Version/s: (was: 3.0.0-M5) 3.0.0-M6 > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1845) Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for al tests with logs
Tibor Digana created SUREFIRE-1845: -- Summary: Fixed the performance of Utf8RecodingDeferredFileOutputStream as a bottleneck for al tests with logs Key: SUREFIRE-1845 URL: https://issues.apache.org/jira/browse/SUREFIRE-1845 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 3.0.0-M6 The fix would speed up the cache 8 times. After we have applied fast TCP/IP encoder and decoder along with the fix for this issue we have got fast Test3 in the integration test ConsoleOutputIT#largerSoutThanMemory(), i.e. 0.44 seconds of the test exec time from previous 8.8 seconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202621#comment-17202621
]
Michael Osipov commented on MINDEXER-125:
-
Go here: https://issues.sonatype.org/projects/OSSRH
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
> Attachments: Screenshot from 2020-09-26 11-07-16.png
>
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-source-plugin] asfgit closed pull request #3: Fix some sonar findings
asfgit closed pull request #3: URL: https://github.com/apache/maven-source-plugin/pull/3 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Commented] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202617#comment-17202617
]
Marco Rizzi commented on MINDEXER-125:
--
[Central Index|https://maven.apache.org/repository/central-index.html] provides
an index of the artifacts and (from Central Index home page) "This index is
build using [Maven Indexer|https://maven.apache.org/maven-indexer/]";.
Maven Central is fine.
Maven Index is missing an artifact (I suppose [~michael-o] you agree on this)
and "Maven Indexer" generated the index, shouldn't the issue be for "Maven
Indexer"?
Shouldn't "Maven Indexer" code be fixed to generate the right index with 4
artifacts instead of just 3?
Is Sonatype in charge of fixing the "Maven Indexer" code?
If yes, then this page
https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/issue-tracking.html
should be changed.
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
> Attachments: Screenshot from 2020-09-26 11-07-16.png
>
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] elharo merged pull request #15: [MEAR-285] check return value from mkdirs
elharo merged pull request #15: URL: https://github.com/apache/maven-ear-plugin/pull/15 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Commented] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202601#comment-17202601
]
Michael Osipov commented on MINDEXER-125:
-
Complaints about Maven Central must go to Donatype, not us.
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
> Attachments: Screenshot from 2020-09-26 11-07-16.png
>
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] mthmulders commented on pull request #378: [MNG-6991] Restore how the local repository is determined
mthmulders commented on pull request #378: URL: https://github.com/apache/maven/pull/378#issuecomment-699469528 > Shall we add a couple of tests that cover the change please? You are right, @eolivelli. I focussed too much on writing an integration test (which is very hard if not impossible for this case) but a unit test turned out pretty easy. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[jira] [Commented] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202563#comment-17202563
]
Marco Rizzi commented on MINDEXER-125:
--
There are 4 artifacts in Maven Repo [1]: jar, source, javadoc and module.
There are only 3 artifacts in the latest Maven Index [2]: source (doc #
14794280), javadoc (doc# 14794281) and module (doc #14794279)
!Screenshot from 2020-09-26 11-07-16.png!
The "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}" is not in the Maven Index.
Isn't this an issue of the Maven Indexer?
[1]
[https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/]
[2] [https://repo1.maven.org/maven2/.index/nexus-maven-repository-index.gz]
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
> Attachments: Screenshot from 2020-09-26 11-07-16.png
>
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Rizzi updated MINDEXER-125:
-
Attachment: Screenshot from 2020-09-26 11-07-16.png
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
> Attachments: Screenshot from 2020-09-26 11-07-16.png
>
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-194) Output during creation of Ear is not correct
[
https://issues.apache.org/jira/browse/MEAR-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202560#comment-17202560
]
Hudson commented on MEAR-194:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-ear-plugin » master #25
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/25/
> Output during creation of Ear is not correct
>
>
> Key: MEAR-194
> URL: https://issues.apache.org/jira/browse/MEAR-194
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.9.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.1.0
>
>
> Currently during the creation of the ear the output shows something like this:
> {code}
> [INFO] Building jar: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
> {code}
> It should be changed into:
> {code}
> [INFO] Building ear: /opt/build/.../xyz-1.0.0-SNAPSHOT.ear
> {code}
> which is more consistent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MDEP-651) unpack-dependencies should warn when it overrides extracted files on macos (case insensitive FS)
[
https://issues.apache.org/jira/browse/MDEP-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MDEP-651:
Assignee: Maarten Mulders
> unpack-dependencies should warn when it overrides extracted files on macos
> (case insensitive FS)
>
>
> Key: MDEP-651
> URL: https://issues.apache.org/jira/browse/MDEP-651
> Project: Maven Dependency Plugin
> Issue Type: Wish
> Components: unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Hasnae Rehioui
>Assignee: Maarten Mulders
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Background :*
> We are upgrading to a recent version of aspose-imaging and ran into an issue
> with our `unpack-dependencies` configuration when ran locally *on macos*
> This is affecting our dev loop mostly, you can reproduce it with
> {code:java}
> git clone https://github.com/viqueen/maven-playground
> cd maven-playground
> mvn test{code}
> long story short :
> `maven-dependency-plugin` has the `unpack-dependencies` mojo that relies on
> plexus un-archiver which in a file system like mac (not case sensitive) ,
> might end up overriding files , leading in some cases to a corrupted class
> path , aspose-imaging library is an example of that : it contains classes and
> interfaces named as follow : com.aspose.internal.imaging.gq/aq (interface) ,
> com.aspose.internal.imaging.gq/aQ (class implementing the interface) ,
> notice the case sensitive naming
> so on mac , the plugin will override the aq interface with the content of aQ
> type , leading to a NoClassDefFoundError because the file name and its
> content do not match
> {code:java}
> java.lang.NoClassDefFoundError: com/aspose/imaging/internal/gq/aq (wrong
> name: com/aspose/imaging/internal/gq/aQ)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> {code}
> *Workaround :*
> turns out our project config no longer requires unpacking dependencies so we
> disabled the thing
> *Suggestion :*
> not sure this is even fixable , but would be nice to have some debug /
> warning logs that it is happening so developers can diagnose errors more
> easily; basically throw in some love onto
> [https://github.com/viqueen/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractUnArchiver.java#L346]
> in our particular use case , we are consuming the plugin through
> [https://bitbucket.org/atlassian/amps/src/903a1ce408da5b8500ed0d7e0e5701eb83d8cde4/amps-maven-plugin/src/main/java/com/atlassian/maven/plugins/amps/MavenGoals.java?at=8.0-stable&fileviewer=file-view-default#MavenGoals.java-458]
> , these internals are not exactly common knowledge and the logs were not
> helping either, devs knew it was FS related though just not clear on what
> triggers the problem
> so optionally failing the build if/when it happens could point our devs on
> the right track much faster
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] hboutemy closed pull request #9: [MEAR-194] Use ear archiver instead of jar archiver
hboutemy closed pull request #9: URL: https://github.com/apache/maven-ear-plugin/pull/9 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-ear-plugin] hboutemy commented on pull request #9: [MEAR-194] Use ear archiver instead of jar archiver
hboutemy commented on pull request #9: URL: https://github.com/apache/maven-ear-plugin/pull/9#issuecomment-699462405 merged and updated to document the unexpectedly complex logic for an issue that we supposed was up-for-grabs... :) thank you everybody for your help and efforts This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-source-plugin] pzygielo edited a comment on pull request #3: Fix some sonar findings
pzygielo edited a comment on pull request #3:
URL: https://github.com/apache/maven-source-plugin/pull/3#issuecomment-699459880
@slachiewicz - thanks for checking.
FYI: Unfortunately - locally run (linux, JDK8) `verify` fails (consistently)
on MSOURCES-95 IT.
```
13|Running post-build script:
.../target/it/MSOURCES-95/verify.groovy
14...target/it/MSOURCES-95/build.log
15
16 >---at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:404)
17 >---at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:650)
18 >---at Script1.run(Script1.groovy:32)
```
as it seems to fail on
```
assert buildLog.text =~ /(?i) Archive .*${testSourcesJarFileName} is
uptodate/
```
But I think it's covered by thread
https://mail-archives.apache.org/mod_mbox/maven-dev/202007.mbox/%3CMailbird-a257189c-b92a-4b17-897d-4eaa5c6850ed%40apache.org%3E
already.
It verifies correctly with JDK11.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
[GitHub] [maven-source-plugin] pzygielo commented on pull request #3: Fix some sonar findings
pzygielo commented on pull request #3: URL: https://github.com/apache/maven-source-plugin/pull/3#issuecomment-699462095 > It's also been reported by @MartinKanters: [MSOURCES-129](https://issues.apache.org/jira/browse/MSOURCES-129), and a fix is in the making: [codehaus-plexus/plexus-archiver#149](https://github.com/codehaus-plexus/plexus-archiver/pull/149). Indeed! This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-source-plugin] mthmulders edited a comment on pull request #3: Fix some sonar findings
mthmulders edited a comment on pull request #3: URL: https://github.com/apache/maven-source-plugin/pull/3#issuecomment-699461617 It's also been reported by @MartinKanters: [MSOURCES-129](https://issues.apache.org/jira/browse/MSOURCES-129), and a fix is in the making: https://github.com/codehaus-plexus/plexus-archiver/pull/149. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-source-plugin] mthmulders commented on pull request #3: Fix some sonar findings
mthmulders commented on pull request #3: URL: https://github.com/apache/maven-source-plugin/pull/3#issuecomment-699461617 It's also been reported by @MartinKanters: [MSOURCES-129](https://issues.apache.org/jira/browse/MSOURCES-129). This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
[GitHub] [maven-source-plugin] pzygielo commented on pull request #3: Fix some sonar findings
pzygielo commented on pull request #3:
URL: https://github.com/apache/maven-source-plugin/pull/3#issuecomment-699459880
@slachiewicz - thanks for checking.
FYI: Unfortunately - locally run (linux) `verify` fails (consistently) on
MSOURCES-95 IT.
```
13|Running post-build script:
.../target/it/MSOURCES-95/verify.groovy
14...target/it/MSOURCES-95/build.log
15
16 >---at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:404)
17 >---at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:650)
18 >---at Script1.run(Script1.groovy:32)
```
as it seems to fail on
```
assert buildLog.text =~ /(?i) Archive .*${testSourcesJarFileName} is
uptodate/
```
But I think it's covered by thread
https://mail-archives.apache.org/mod_mbox/maven-dev/202007.mbox/%3CMailbird-a257189c-b92a-4b17-897d-4eaa5c6850ed%40apache.org%3E
already.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
[GitHub] [maven-source-plugin] pzygielo opened a new pull request #3: Fix some sonar findings
pzygielo opened a new pull request #3: URL: https://github.com/apache/maven-source-plugin/pull/3 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
