[jira] [Created] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
Praveen Sreepada created SUREFIRE-2084:
--
Summary: Jenkins junit plugin fails to parse surefire reports of
failed tests
Key: SUREFIRE-2084
URL: https://issues.apache.org/jira/browse/SUREFIRE-2084
Project: Maven Surefire
Issue Type: Bug
Reporter: Praveen Sreepada
We use junit plugin in jenkins to export the results of the test runs. While
doing so for the failed tests, I see the plugin throwing the following
exception:
{code:java}
Failed to read test report file .xml
org.dom4j.DocumentException: Error on line 144 of document : The content of
elements must consist of well-formed character data or markup.
at org.dom4j.io.SAXReader.read(SAXReader.java:511)
at org.dom4j.io.SAXReader.read(SAXReader.java:392)
at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
at hudson.tasks.junit.TestResult.(TestResult.java:151)
at
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:376)
at
hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6; The
content of elements must consist of well-formed character data or markup.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
at
com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
at org.dom4j.io.SAXReader.read(SAXReader.java:494)
... 17 more{code}
Upon opening the generated xml file, this is what I found - This is the point
(line 144) where it is failing to parse the XML, due to an extra space between
`<` and `message=`
{code:java}
< message="">{code}
This message has been added due to a `Assume.assumeTrue` statement in the test
We use maven-surefire-plugin version 3.0.0-M4
Is this a known issue that has been fixed in later releases? if not, can this
be fixed? Please let me know if you need any more information
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-wrapper] hboutemy commented on pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
hboutemy commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120160163 @gzm55 what is required to do that? FYI, I'll do the 3.1.1 release soon (without this change), then we'll work on merging this PR that fully changes the approach: we'll need to define if it's best to call it 3.2.0 or even 4.0.0... -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-61) let mvnw call mvn directly, without maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533214#comment-17533214 ] ASF GitHub Bot commented on MWRAPPER-61: hboutemy commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120160163 @gzm55 what is required to do that? FYI, I'll do the 3.1.1 release soon (without this change), then we'll work on merging this PR that fully changes the approach: we'll need to define if it's best to call it 3.2.0 or even 4.0.0... > let mvnw call mvn directly, without maven-wrapper.jar > - > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.2.0 > > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-wrapper] hboutemy merged pull request #37: [MWRAPPER-49] add Wrapper version in mvnw/mvnw.cmd scripts
hboutemy merged PR #37: URL: https://github.com/apache/maven-wrapper/pull/37 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-49) add Wrapper version in mvnw/mvnw.cmd scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533215#comment-17533215 ] ASF GitHub Bot commented on MWRAPPER-49: hboutemy merged PR #37: URL: https://github.com/apache/maven-wrapper/pull/37 > add Wrapper version in mvnw/mvnw.cmd scripts > > > Key: MWRAPPER-49 > URL: https://issues.apache.org/jira/browse/MWRAPPER-49 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.1.1 > > > such simple comment will ease tracking what version of the scripts is > installed in a project using wrapper -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MWRAPPER-49) add Wrapper version in mvnw/mvnw.cmd scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MWRAPPER-49. - Assignee: Herve Boutemy Resolution: Fixed done in https://github.com/apache/maven-wrapper/commit/ac8139e50c46bb8cf10af065bae0ddcd74e24666 > add Wrapper version in mvnw/mvnw.cmd scripts > > > Key: MWRAPPER-49 > URL: https://issues.apache.org/jira/browse/MWRAPPER-49 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.1 > > > such simple comment will ease tracking what version of the scripts is > installed in a project using wrapper -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MWRAPPER-42) maven-wrapper fails to self-update maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MWRAPPER-42. - Assignee: Herve Boutemy Resolution: Fixed no answer closing as solved by MWRAPPER-51 if it's not true, you'll open another issue later > maven-wrapper fails to self-update maven-wrapper.jar > > > Key: MWRAPPER-42 > URL: https://issues.apache.org/jira/browse/MWRAPPER-42 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jeremy Norris >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.1 > > > In cases where users do not check-in the maven-wrapper.jar into their > repositories, after executing `mvn wrapper:wrapper -Dtype=script` to update, > the newly updated `mvnw` script will continue to use an older version of > `.mvn/wrapper/maven-wrapper.jar` that was previously downloaded. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MWRAPPER-49) add Wrapper version in mvnw/mvnw.cmd scripts
[ https://issues.apache.org/jira/browse/MWRAPPER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533220#comment-17533220 ] Hudson commented on MWRAPPER-49: Build failed in Jenkins: Maven » Maven TLP » maven-wrapper » master #17 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/master/17/ > add Wrapper version in mvnw/mvnw.cmd scripts > > > Key: MWRAPPER-49 > URL: https://issues.apache.org/jira/browse/MWRAPPER-49 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.1 > > > such simple comment will ease tracking what version of the scripts is > installed in a project using wrapper -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MWRAPPER-61) let mvnw call mvn directly, without maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533223#comment-17533223 ] ASF GitHub Bot commented on MWRAPPER-61: gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120162107 @hboutemy 3.2.0 or 4.0.0 are both OK. Although implementation changes, the cli interface and the dependencies are almost remain same, so, imo, a minor version bump is enough. > let mvnw call mvn directly, without maven-wrapper.jar > - > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.2.0 > > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-wrapper] gzm55 commented on pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120162107 @hboutemy 3.2.0 or 4.0.0 are both OK. Although implementation changes, the cli interface and the dependencies are almost remain same, so, imo, a minor version bump is enough. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAVADOC-700) Plugin duplicates classes in Java 8 all-classes lists
[
https://issues.apache.org/jira/browse/MJAVADOC-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533224#comment-17533224
]
Robert Scholte commented on MJAVADOC-700:
-
Well, it is clearly a bug. Might be that this one was missed when moving from
String to Path where possible. It is simply about reproducing it, fixing it and
make sure no other IT fails.
> Plugin duplicates classes in Java 8 all-classes lists
> --
>
> Key: MJAVADOC-700
> URL: https://issues.apache.org/jira/browse/MJAVADOC-700
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0, 3.3.1
>Reporter: Rob Spoor
>Priority: Major
>
> Versions 3.3.0 and 3.3.1 of the Javadoc Plugin create allclasses-frame.html
> and allclasses-noframe.html files that duplicate all classes, interfaces, etc.
> To reproduce:
> * Clone https://github.com/robtimus/data-url (a simple and small project that
> can be used to showcase the issue)
> * Run {{mvn javadoc:javadoc}}, which uses version 3.2.0
> * Check target/site/apidocs/allclasses-frame.html - no duplicates
> * Run {{mvn javadoc:javadoc -Dversion.plugin.javadoc=3.3.0}} to build the
> same with version 3.3.0
> * Check target/site/apidocs/allclasses-frame.html - all classes are duplicated
> The same issue occurs with {{javadoc:aggregate}}, possibly others as well.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-surefire] slawekjaranowski commented on a diff in pull request #533: chore: Set permissions for GitHub actions
slawekjaranowski commented on code in PR #533: URL: https://github.com/apache/maven-surefire/pull/533#discussion_r867322913 ## .github/workflows/maven-verify.yml: ## @@ -21,8 +21,13 @@ on: push: pull_request: +permissions: + contents: read + Review Comment: why read on this level? ## .github/workflows/maven-verify.yml: ## @@ -21,8 +21,13 @@ on: push: pull_request: +permissions: + contents: read + jobs: build: +permissions: + contents: none Review Comment: and next set to none ... why not on global level? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] sman-81 commented on pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
sman-81 commented on PR #531: URL: https://github.com/apache/maven-surefire/pull/531#issuecomment-1120167809 ``` git checkout master mvn --errors --batch-mode --show-version -D"invoker.streamLogsOnFailures" clean install -nsu -P run-its -Dit.test=Surefire1367AssumptionLogsIT ``` ``` [ERROR] Failures: [ERROR] Surefire1367AssumptionLogsIT.shouldSeeLogsForked:66->verifyReportA:93 [ERROR] Surefire1367AssumptionLogsIT.shouldSeeLogsInPlugin:76->verifyReportA:93 [ERROR] Surefire1367AssumptionLogsIT.shouldSeeLogsParallelForked:46->verifyReportB:109 [ERROR] Surefire1367AssumptionLogsIT.shouldSeeLogsParallelInPlugin:57->verifyReportB:109 [ERROR] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M6:verify (default) on project surefire-its: There are test failures. ``` -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
slawekjaranowski commented on PR #531: URL: https://github.com/apache/maven-surefire/pull/531#issuecomment-1120169304 ... strange but build on CI are green https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-surefire/job/master/ https://github.com/apache/maven-surefire/actions/workflows/maven-verify.yml?query=branch%3Amaster -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533232#comment-17533232
]
Michael Osipov commented on SUREFIRE-2084:
--
Without having the message, no chance.
> Jenkins junit plugin fails to parse surefire reports of failed tests
>
>
> Key: SUREFIRE-2084
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2084
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Praveen Sreepada
>Priority: Major
>
> We use junit plugin in jenkins to export the results of the test runs. While
> doing so for the failed tests, I see the plugin throwing the following
> exception:
> {code:java}
> Failed to read test report file .xml
> org.dom4j.DocumentException: Error on line 144 of document : The content of
> elements must consist of well-formed character data or markup.
> at org.dom4j.io.SAXReader.read(SAXReader.java:511)
> at org.dom4j.io.SAXReader.read(SAXReader.java:392)
> at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
> at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
> at hudson.tasks.junit.TestResult.(TestResult.java:151)
> at
> hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:376)
> at
> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6;
> The content of elements must consist of well-formed character data or markup.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at
> com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at org.dom4j.io.SAXReader.read(SAXReader.java:494)
> ... 17 more{code}
> Upon opening the generated xml file, this is what I found - This is the point
> (line 144) where it is failing to parse the XML, due to an extra space
> between `<` and `message=`
> {code:java}
> < message="">{code}
> This message has been added due to a `Assume.assumeTrue` statement in the test
> We use maven-surefire-plugin version 3.0.0-M4
> Is this a known issue that has been fixed in later releases? if not, can this
> be fixed? Please let me know if you need any more information
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Praveen Sreepada updated SUREFIRE-2084:
---
Description:
We use junit plugin in jenkins to export the results of the test runs. While
doing so for the failed tests, I see the plugin throwing the following
exception:
{code:java}
Failed to read test report file .xml
org.dom4j.DocumentException: Error on line 144 of document : The content of
elements must consist of well-formed character data or markup.
at org.dom4j.io.SAXReader.read(SAXReader.java:511)
at org.dom4j.io.SAXReader.read(SAXReader.java:392)
at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
at hudson.tasks.junit.TestResult.(TestResult.java:151)
at
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:376)
at
hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6; The
content of elements must consist of well-formed character data or markup.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
at
com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
at org.dom4j.io.SAXReader.read(SAXReader.java:494)
... 17 more{code}
Upon opening the generated xml file, this is what I found - This is the point
(line 144) where it is failing to parse the XML, due to an extra space between
`<` and `message=`
{code:java}
< message="Tests enabled on ONS3(stage and Prod) stack only ">{code}
This message has been added due to a `Assume.assumeTrue` statement in the test
We use maven-surefire-plugin version 3.0.0-M4
Is this a known issue that has been fixed in later releases? if not, can this
be fixed? Please let me know if you need any more information
was:
We use junit plugin in jenkins to export the results of the test runs. While
doing so for the failed tests, I see the plugin throwing the following
exception:
{code:java}
Failed to read test report file .xml
org.dom4j.DocumentException: Error on line 144 of document : The content of
elements must consist of well-formed character data or markup.
at org.dom4j.io.SAXReader.read(SAXReader.java:511)
at org.dom4j.io.SAXReader.read(SAXReader.java:392)
at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
at hudson.tasks.jun
[jira] [Commented] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533233#comment-17533233
]
Praveen Sreepada commented on SUREFIRE-2084:
[~michael-o] updated the description with the message
> Jenkins junit plugin fails to parse surefire reports of failed tests
>
>
> Key: SUREFIRE-2084
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2084
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Praveen Sreepada
>Priority: Major
>
> We use junit plugin in jenkins to export the results of the test runs. While
> doing so for the failed tests, I see the plugin throwing the following
> exception:
> {code:java}
> Failed to read test report file .xml
> org.dom4j.DocumentException: Error on line 144 of document : The content of
> elements must consist of well-formed character data or markup.
> at org.dom4j.io.SAXReader.read(SAXReader.java:511)
> at org.dom4j.io.SAXReader.read(SAXReader.java:392)
> at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
> at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
> at hudson.tasks.junit.TestResult.(TestResult.java:151)
> at
> hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:376)
> at
> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6;
> The content of elements must consist of well-formed character data or markup.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at
> com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at org.dom4j.io.SAXReader.read(SAXReader.java:494)
> ... 17 more{code}
> Upon opening the generated xml file, this is what I found - This is the point
> (line 144) where it is failing to parse the XML, due to an extra space
> between `<` and `message=`
> {code:java}
> < message="Tests enabled on ONS3(stage and Prod) stack only ">{code}
> This message has been added due to a `Assume.assumeTrue` statement in the test
> We use maven-surefire-plugin version 3.0.0-M4
> Is this a known issue that has been fixed in later releases? if not, can this
> be fixed? Please let me know if you need any more information
>
--
This messa
[jira] [Updated] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Praveen Sreepada updated SUREFIRE-2084:
---
Description:
We use junit plugin in jenkins to export the results of the test runs. While
doing so for the failed tests, I see the plugin throwing the following
exception:
{code:java}
Failed to read test report file .xml
org.dom4j.DocumentException: Error on line 144 of document : The content of
elements must consist of well-formed character data or markup.
at org.dom4j.io.SAXReader.read(SAXReader.java:511)
at org.dom4j.io.SAXReader.read(SAXReader.java:392)
at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
at hudson.tasks.junit.TestResult.(TestResult.java:151)
at
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:376)
at
hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6; The
content of elements must consist of well-formed character data or markup.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
at
com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
at org.dom4j.io.SAXReader.read(SAXReader.java:494)
... 17 more{code}
Upon opening the generated xml file, this is what I found - This is the point
(line 144) where it is failing to parse the XML, due to an extra space between
`<` and `message=`
{code:java}
< message="Tests enabled on ONS3(stage and Prod) stack only ">{code}
This message has been added due to a `Assume.assumeTrue` statement in the test
We use maven-surefire-plugin version 3.0.0-M4
Is this a known issue that has been fixed in later releases? if not, can this
be fixed? Please let me know if you need any more information
was:
We use junit plugin in jenkins to export the results of the test runs. While
doing so for the failed tests, I see the plugin throwing the following
exception:
{code:java}
Failed to read test report file .xml
org.dom4j.DocumentException: Error on line 144 of document : The content of
elements must consist of well-formed character data or markup.
at org.dom4j.io.SAXReader.read(SAXReader.java:511)
at org.dom4j.io.SAXReader.read(SAXReader.java:392)
at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
at h
[GitHub] [maven-release] BigMichi1 opened a new pull request, #121: [MRELEASE-1082] configuration option for using a shallow clone
BigMichi1 opened a new pull request, #121: URL: https://github.com/apache/maven-release/pull/121 Following this checklist to help us incorporate your contribution quickly and easily: - [ x ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAVADOC) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ x ] Each commit in the pull request should have a meaningful subject line and body. - [ x ] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ x ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ x ] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ x ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This patch makes the shallow clone option configurable while still having the default of `true`. This is useful and needed when running for example a SonarQube analysis during the release process. When the option is `true` like the current hardcoded default the analyzer complains about missing blame information. If the full history is needed the option can now be set to `false` to get the full history. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1069) Upgrade Parent to 36
Slawomir Jaranowski created MSHARED-1069: Summary: Upgrade Parent to 36 Key: MSHARED-1069 URL: https://issues.apache.org/jira/browse/MSHARED-1069 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-dependency-tree Reporter: Slawomir Jaranowski Fix For: maven-dependency-tree-3.1.1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (MSHARED-1069) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MSHARED-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MSHARED-1069: Assignee: Slawomir Jaranowski > Upgrade Parent to 36 > > > Key: MSHARED-1069 > URL: https://issues.apache.org/jira/browse/MSHARED-1069 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-tree >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: maven-dependency-tree-3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533240#comment-17533240
]
Praveen Sreepada commented on SUREFIRE-2084:
I think I have found a similar issue -
https://issues.apache.org/jira/browse/SUREFIRE-1556 - and it seems to have been
fixed in M6 release by [https://github.com/apache/maven-surefire/pull/450], I
will try the new release and will monitor.
> Jenkins junit plugin fails to parse surefire reports of failed tests
>
>
> Key: SUREFIRE-2084
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2084
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Praveen Sreepada
>Priority: Major
>
> We use junit plugin in jenkins to export the results of the test runs. While
> doing so for the failed tests, I see the plugin throwing the following
> exception:
> {code:java}
> Failed to read test report file .xml
> org.dom4j.DocumentException: Error on line 144 of document : The content of
> elements must consist of well-formed character data or markup.
> at org.dom4j.io.SAXReader.read(SAXReader.java:511)
> at org.dom4j.io.SAXReader.read(SAXReader.java:392)
> at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
> at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
> at hudson.tasks.junit.TestResult.(TestResult.java:151)
> at
> hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:376)
> at
> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6;
> The content of elements must consist of well-formed character data or markup.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at
> com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at org.dom4j.io.SAXReader.read(SAXReader.java:494)
> ... 17 more{code}
> Upon opening the generated xml file, this is what I found - This is the point
> (line 144) where it is failing to parse the XML, due to an extra space
> between `<` and `message=`
> {code:java}
>
>
>
> < message="Tests enabled on ONS3(stage and Prod) stack only ">{code}
> This message has been added due to a `Assume.assumeTrue` statement in the test
>
[jira] [Created] (MSHARED-1070) Migrate plexus component to JSR-330
Slawomir Jaranowski created MSHARED-1070: Summary: Migrate plexus component to JSR-330 Key: MSHARED-1070 URL: https://issues.apache.org/jira/browse/MSHARED-1070 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533241#comment-17533241
]
Slawomir Jaranowski commented on SUREFIRE-2084:
---
As you wrote issue is in 3.0.0-M4 ... can you test with the latest version
3.0.0-M6?
> Jenkins junit plugin fails to parse surefire reports of failed tests
>
>
> Key: SUREFIRE-2084
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2084
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Praveen Sreepada
>Priority: Major
>
> We use junit plugin in jenkins to export the results of the test runs. While
> doing so for the failed tests, I see the plugin throwing the following
> exception:
> {code:java}
> Failed to read test report file .xml
> org.dom4j.DocumentException: Error on line 144 of document : The content of
> elements must consist of well-formed character data or markup.
> at org.dom4j.io.SAXReader.read(SAXReader.java:511)
> at org.dom4j.io.SAXReader.read(SAXReader.java:392)
> at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
> at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
> at hudson.tasks.junit.TestResult.(TestResult.java:151)
> at
> hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:376)
> at
> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6;
> The content of elements must consist of well-formed character data or markup.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at
> com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at org.dom4j.io.SAXReader.read(SAXReader.java:494)
> ... 17 more{code}
> Upon opening the generated xml file, this is what I found - This is the point
> (line 144) where it is failing to parse the XML, due to an extra space
> between `<` and `message=`
> {code:java}
>
>
>
> < message="Tests enabled on ONS3(stage and Prod) stack only ">{code}
> This message has been added due to a `Assume.assumeTrue` statement in the test
> We use maven-surefire-plugin version 3.0.0-M4
> Is this a known issue that has been fixed in later releases? if not, can this
> be fixed? Please let
[GitHub] [maven-dependency-tree] slawekjaranowski opened a new pull request, #20: [MSHARED-1069] Upgrade Parent to 36
slawekjaranowski opened a new pull request, #20: URL: https://github.com/apache/maven-dependency-tree/pull/20 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/projects/MSHARED) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MSHARED-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHARED-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. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] hboutemy commented on pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
hboutemy commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120184143 the bump in version is not because of visible change, but a so vast reimplementation that there is a de-facto a risk that someone finds an edge case -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-61) let mvnw call mvn directly, without maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533244#comment-17533244 ] ASF GitHub Bot commented on MWRAPPER-61: hboutemy commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120184143 the bump in version is not because of visible change, but a so vast reimplementation that there is a de-facto a risk that someone finds an edge case > let mvnw call mvn directly, without maven-wrapper.jar > - > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.2.0 > > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-surefire] sman-81 commented on pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
sman-81 commented on PR #531: URL: https://github.com/apache/maven-surefire/pull/531#issuecomment-1120184263 > ... strange but build on CI are green mysterious! My repo is up-to-date with upstream apache:master. Do the CI builds include integration tests? Is the build green if you run this locally: ``` git checkout master mvn --errors --batch-mode --show-version -D"invoker.streamLogsOnFailures" clean install -nsu -P run-its -Dit.test=Surefire1367AssumptionLogsIT ``` -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-61) let mvnw call mvn directly, without maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533246#comment-17533246 ] ASF GitHub Bot commented on MWRAPPER-61: gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120185167 how about these steps for accepting this: > let mvnw call mvn directly, without maven-wrapper.jar > - > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.2.0 > > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-wrapper] gzm55 commented on pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120185167 how about these steps for accepting this: -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] gzm55 commented on pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120185983 > the bump in version is not because of visible change, but a so vast reimplementation that there is a de-facto a risk that someone finds an edge case @hboutemy how about these steps for accepting this: 1. review to find most hiding risks, if _accept_ this implementation, then 2. publish as a new `type`, such as `only-script` for one release 3. replace `script` type with `only-script`, also keep the original script as `script0`, for one or two release 4. remove other types at the last stage -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-61) let mvnw call mvn directly, without maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533248#comment-17533248 ] ASF GitHub Bot commented on MWRAPPER-61: gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120185983 > the bump in version is not because of visible change, but a so vast reimplementation that there is a de-facto a risk that someone finds an edge case @hboutemy how about these steps for accepting this: 1. review to find most hiding risks, if _accept_ this implementation, then 2. publish as a new `type`, such as `only-script` for one release 3. replace `script` type with `only-script`, also keep the original script as `script0`, for one or two release 4. remove other types at the last stage > let mvnw call mvn directly, without maven-wrapper.jar > - > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.2.0 > > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-dependency-tree] slawekjaranowski merged pull request #20: [MSHARED-1069] Upgrade Parent to 36
slawekjaranowski merged PR #20: URL: https://github.com/apache/maven-dependency-tree/pull/20 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] dependabot[bot] commented on pull request #16: Bump maven-site-plugin from 3.10.0 to 3.12.0
dependabot[bot] commented on PR #16: URL: https://github.com/apache/maven-dependency-tree/pull/16#issuecomment-1120187187 Looks like org.apache.maven.plugins:maven-site-plugin is no longer a dependency, so this is no longer needed. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] dependabot[bot] commented on pull request #19: Bump maven-project-info-reports-plugin from 3.2.2 to 3.3.0
dependabot[bot] commented on PR #19: URL: https://github.com/apache/maven-dependency-tree/pull/19#issuecomment-1120187186 Looks like org.apache.maven.plugins:maven-project-info-reports-plugin is no longer a dependency, so this is no longer needed. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] dependabot[bot] closed pull request #16: Bump maven-site-plugin from 3.10.0 to 3.12.0
dependabot[bot] closed pull request #16: Bump maven-site-plugin from 3.10.0 to 3.12.0 URL: https://github.com/apache/maven-dependency-tree/pull/16 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] dependabot[bot] closed pull request #19: Bump maven-project-info-reports-plugin from 3.2.2 to 3.3.0
dependabot[bot] closed pull request #19: Bump maven-project-info-reports-plugin from 3.2.2 to 3.3.0 URL: https://github.com/apache/maven-dependency-tree/pull/19 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MSHARED-1069) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MSHARED-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MSHARED-1069. Resolution: Fixed > Upgrade Parent to 36 > > > Key: MSHARED-1069 > URL: https://issues.apache.org/jira/browse/MSHARED-1069 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-tree >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: maven-dependency-tree-3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-dependency-tree] slawekjaranowski commented on pull request #17: Bump maven-shared-components from 34 to 36
slawekjaranowski commented on PR #17: URL: https://github.com/apache/maven-dependency-tree/pull/17#issuecomment-1120187399 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1069) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MSHARED-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533249#comment-17533249 ] Hudson commented on MSHARED-1069: - Build succeeded in Jenkins: Maven » Maven TLP » maven-dependency-tree » master #10 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dependency-tree/job/master/10/ > Upgrade Parent to 36 > > > Key: MSHARED-1069 > URL: https://issues.apache.org/jira/browse/MSHARED-1069 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-tree >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: maven-dependency-tree-3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-dependency-tree] slawekjaranowski commented on pull request #10: Drop maven 3.0 compatibility
slawekjaranowski commented on PR #10: URL: https://github.com/apache/maven-dependency-tree/pull/10#issuecomment-1120188061 And issue https://issues.apache.org/jira/browse/MSHARED-1071 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1071) Drop maven 3.0 compatibility
Slawomir Jaranowski created MSHARED-1071: Summary: Drop maven 3.0 compatibility Key: MSHARED-1071 URL: https://issues.apache.org/jira/browse/MSHARED-1071 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-dependency-tree] dependabot[bot] commented on pull request #18: Bump maven-javadoc-plugin from 3.3.1 to 3.4.0
dependabot[bot] commented on PR #18: URL: https://github.com/apache/maven-dependency-tree/pull/18#issuecomment-1120188236 Looks like org.apache.maven.plugins:maven-javadoc-plugin is up-to-date now, so this is no longer needed. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] dependabot[bot] closed pull request #18: Bump maven-javadoc-plugin from 3.3.1 to 3.4.0
dependabot[bot] closed pull request #18: Bump maven-javadoc-plugin from 3.3.1 to 3.4.0 URL: https://github.com/apache/maven-dependency-tree/pull/18 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] dependabot[bot] commented on pull request #17: Bump maven-shared-components from 34 to 36
dependabot[bot] commented on PR #17: URL: https://github.com/apache/maven-dependency-tree/pull/17#issuecomment-1120188555 Looks like org.apache.maven.shared:maven-shared-components is up-to-date now, so this is no longer needed. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-tree] dependabot[bot] closed pull request #17: Bump maven-shared-components from 34 to 36
dependabot[bot] closed pull request #17: Bump maven-shared-components from 34 to 36 URL: https://github.com/apache/maven-dependency-tree/pull/17 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
slawekjaranowski commented on PR #531: URL: https://github.com/apache/maven-surefire/pull/531#issuecomment-1120191197 > > Do the CI builds include integration tests? > yes - with many oses > Is the build green if you run this locally: yes ``` Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) Maven home: /usr/local/Cellar/maven/3.8.5/libexec Java version: 1.8.0_322, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Home/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "12.3.1", arch: "x86_64", family: "mac" [INFO] --- [INFO] T E S T S [INFO] --- [INFO] Running org.apache.maven.surefire.its.jiras.Surefire1367AssumptionLogsIT [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.914 s - in org.apache.maven.surefire.its.jiras.Surefire1367AssumptionLogsIT ``` ``` git show -s commit fea624d1503eadfcf95e979bdac7438db05669a5 (HEAD -> master, upstream/master, origin/master, origin/HEAD) ``` -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] slawekjaranowski closed pull request #39: Bump maven-parent from 35 to 36
slawekjaranowski closed pull request #39: Bump maven-parent from 35 to 36 URL: https://github.com/apache/maven-wrapper/pull/39 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] dependabot[bot] commented on pull request #39: Bump maven-parent from 35 to 36
dependabot[bot] commented on PR #39: URL: https://github.com/apache/maven-wrapper/pull/39#issuecomment-1120201618 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MWRAPPER-63) Upgrade Parent to 36
Slawomir Jaranowski created MWRAPPER-63: --- Summary: Upgrade Parent to 36 Key: MWRAPPER-63 URL: https://issues.apache.org/jira/browse/MWRAPPER-63 Project: Maven Wrapper Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (MWRAPPER-63) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MWRAPPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MWRAPPER-63: --- Assignee: Slawomir Jaranowski > Upgrade Parent to 36 > > > Key: MWRAPPER-63 > URL: https://issues.apache.org/jira/browse/MWRAPPER-63 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-wrapper] slawekjaranowski opened a new pull request, #41: [MWRAPPER-63] Upgrade Parent to 36
slawekjaranowski opened a new pull request, #41: URL: https://github.com/apache/maven-wrapper/pull/41 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/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MWRAPPER-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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-63) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MWRAPPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533256#comment-17533256 ] ASF GitHub Bot commented on MWRAPPER-63: slawekjaranowski opened a new pull request, #41: URL: https://github.com/apache/maven-wrapper/pull/41 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/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MWRAPPER-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). > Upgrade Parent to 36 > > > Key: MWRAPPER-63 > URL: https://issues.apache.org/jira/browse/MWRAPPER-63 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-wrapper] slawekjaranowski merged pull request #38: (doc) Fixing doc about installing mvnDebug-scripts
slawekjaranowski merged PR #38: URL: https://github.com/apache/maven-wrapper/pull/38 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] slawekjaranowski commented on pull request #38: (doc) Fixing doc about installing mvnDebug-scripts
slawekjaranowski commented on PR #38: URL: https://github.com/apache/maven-wrapper/pull/38#issuecomment-1120202647 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MWRAPPER-63) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MWRAPPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-63: Fix Version/s: 3.1.1 > Upgrade Parent to 36 > > > Key: MWRAPPER-63 > URL: https://issues.apache.org/jira/browse/MWRAPPER-63 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-wrapper] slawekjaranowski commented on pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
slawekjaranowski commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120205549 my proposition in order to go faster with it 1. in this PR - create new `type` - `only-script` - add IT test - rebase to one commit - add text to PR description ... `I hereby declare this contribution to be licenced under the...` see .github/pull_request_template.md 2. next PR - extends - or create documentations about provided type with requirements 3. release next version ... get feedbacks -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-61) let mvnw call mvn directly, without maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533260#comment-17533260 ] ASF GitHub Bot commented on MWRAPPER-61: slawekjaranowski commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120205549 my proposition in order to go faster with it 1. in this PR - create new `type` - `only-script` - add IT test - rebase to one commit - add text to PR description ... `I hereby declare this contribution to be licenced under the...` see .github/pull_request_template.md 2. next PR - extends - or create documentations about provided type with requirements 3. release next version ... get feedbacks > let mvnw call mvn directly, without maven-wrapper.jar > - > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.2.0 > > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2084) Jenkins junit plugin fails to parse surefire reports of failed tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-2084:
-
Affects Version/s: 3.0.0-M4
> Jenkins junit plugin fails to parse surefire reports of failed tests
>
>
> Key: SUREFIRE-2084
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2084
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Praveen Sreepada
>Priority: Major
>
> We use junit plugin in jenkins to export the results of the test runs. While
> doing so for the failed tests, I see the plugin throwing the following
> exception:
> {code:java}
> Failed to read test report file .xml
> org.dom4j.DocumentException: Error on line 144 of document : The content of
> elements must consist of well-formed character data or markup.
> at org.dom4j.io.SAXReader.read(SAXReader.java:511)
> at org.dom4j.io.SAXReader.read(SAXReader.java:392)
> at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:177)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:349)
> at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:279)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:223)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:197)
> at hudson.tasks.junit.TestResult.(TestResult.java:151)
> at
> hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:147)
> at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3329)
> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> at hudson.remoting.Request$2.run(Request.java:376)
> at
> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 144; columnNumber: 6;
> The content of elements must consist of well-formed character data or markup.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
> at
> com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1473)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.startOfMarkup(XMLDocumentFragmentScannerImpl.java:2635)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at org.dom4j.io.SAXReader.read(SAXReader.java:494)
> ... 17 more{code}
> Upon opening the generated xml file, this is what I found - This is the point
> (line 144) where it is failing to parse the XML, due to an extra space
> between `<` and `message=`
> {code:java}
>
>
>
> < message="Tests enabled on ONS3(stage and Prod) stack only ">{code}
> This message has been added due to a `Assume.assumeTrue` statement in the test
> We use maven-surefire-plugin version 3.0.0-M4
> Is this a known issue that has been fixed in later releases? if not, can this
> be fixed? Please let me know if you need any more information
>
--
This message was sent by Atlassian Jira
[GitHub] [maven-release] michael-o commented on a diff in pull request #121: [MRELEASE-1082] configuration option for using a shallow clone
michael-o commented on code in PR #121:
URL: https://github.com/apache/maven-release/pull/121#discussion_r867354841
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseDescriptorBuilder.java:
##
@@ -473,6 +473,19 @@ public ReleaseDescriptorBuilder setScmCommentPrefix(
String scmCommentPrefix )
return this;
}
+/**
+ * setScmShallowClone.
+ *
+ * @param scmShallowClone a boolean
+ * @return a {@link
org.apache.maven.shared.release.config.ReleaseDescriptorBuilder} object
+ * since 3.0.0-M6
Review Comment:
`@since`
##
maven-release-plugin/src/main/java/org/apache/maven/plugins/release/AbstractScmReleaseMojo.java:
##
@@ -89,6 +89,12 @@
@Parameter( defaultValue = "[maven-release-plugin] ", property =
"scmCommentPrefix" )
private String scmCommentPrefix;
+/**
+ * When cloning a repository if it should be a shallow clone or a full
clone.
+ */
+@Parameter( defaultValue = "true", property = "shallowClone" )
+private boolean shallowClone = true;
Review Comment:
Shouldn't this be `scmShallowClone` for consistency reasons?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Assigned] (MRELEASE-1082) configuration option for shallow checkout
[
https://issues.apache.org/jira/browse/MRELEASE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MRELEASE-1082:
Assignee: Michael Osipov
> configuration option for shallow checkout
> -
>
> Key: MRELEASE-1082
> URL: https://issues.apache.org/jira/browse/MRELEASE-1082
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Affects Versions: 3.0.0-M5
>Reporter: Michael Cramer
>Assignee: Michael Osipov
>Priority: Major
> Labels: checkout, clone, git, shallow, up-for-grabs
>
> after implementing sonar into our release process we noticed that sonar is
> complaining about missing blame information
> {noformat}
> [INFO] [WARNING] Missing blame information for the following files:
> {noformat}
> I've seen that in MRELEASE-993 this new type of checkout was introduced and
> it mentions that "per default" the checkout will use the shallow clone. to
> me, it sounds that this is an option that can be configured, but after taking
> a look in the code I see that {{true}} is hardcoded
> i would propose to make this option configurable and have a default of
> {{true}} that can be changed when needed, e.g. in the case during the release
> sonarqube is called which needs the full history.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-release] michael-o commented on pull request #121: [MRELEASE-1082] configuration option for using a shallow clone
michael-o commented on PR #121: URL: https://github.com/apache/maven-release/pull/121#issuecomment-1120214394 I will take care of the PR as soon as all comments are resolved. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRELEASE-1082) configuration option for shallow checkout
[
https://issues.apache.org/jira/browse/MRELEASE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-1082:
-
Fix Version/s: 3.0.0-M6
> configuration option for shallow checkout
> -
>
> Key: MRELEASE-1082
> URL: https://issues.apache.org/jira/browse/MRELEASE-1082
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Affects Versions: 3.0.0-M5
>Reporter: Michael Cramer
>Assignee: Michael Osipov
>Priority: Major
> Labels: checkout, clone, git, shallow, up-for-grabs
> Fix For: 3.0.0-M6
>
>
> after implementing sonar into our release process we noticed that sonar is
> complaining about missing blame information
> {noformat}
> [INFO] [WARNING] Missing blame information for the following files:
> {noformat}
> I've seen that in MRELEASE-993 this new type of checkout was introduced and
> it mentions that "per default" the checkout will use the shallow clone. to
> me, it sounds that this is an option that can be configured, but after taking
> a look in the code I see that {{true}} is hardcoded
> i would propose to make this option configurable and have a default of
> {{true}} that can be changed when needed, e.g. in the case during the release
> sonarqube is called which needs the full history.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MRELEASE-1063) Maven release plugin should retain settings.security environment variable for its forked executions of release:prepare and release:perform
[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-1063:
-
Fix Version/s: waiting-for-feedback
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> --
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.2
>Reporter: Hans Aikema
>Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-1063) Maven release plugin should retain settings.security environment variable for its forked executions of release:prepare and release:perform
[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533289#comment-17533289
]
Michael Osipov commented on MRELEASE-1063:
--
First of all, this is not an evironment variable, but a mere user property from
a Maven PoV. This property is solely used by Plexus Sec Dispatcher, Maven is
not involved. There cannot be a special treatment. Moreover, the is zero
security benefit here because all you do is to create a line of indirection of
plaintext passwords to another file.
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> --
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.2
>Reporter: Hans Aikema
>Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-1063) Maven release plugin should retain settings.security environment variable for its forked executions of release:prepare and release:perform
[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533290#comment-17533290
]
Michael Osipov commented on MRELEASE-1063:
--
[~cstamas]
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> --
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.2
>Reporter: Hans Aikema
>Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MRELEASE-1063) Maven release plugin should retain settings.security environment variable for its forked executions of release:prepare and release:perform
[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-1063:
-
Fix Version/s: wontfix-candidate
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> --
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.2
>Reporter: Hans Aikema
>Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-surefire] Tibor17 commented on pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
Tibor17 commented on PR #531: URL: https://github.com/apache/maven-surefire/pull/531#issuecomment-1120221689 Utf8RecodingDeferredFileOutputStream.java should not be changed from Java NIO to Java IO, it cost me some time to do it with NIO. You involved two interests in one method. Write is write operation. Close is close. I can show you my proposal to keep the file open between testStarting and test*** but then the method `writeTo` has to reopen it for reading. But is still does not make sense to do this because I am reworking it. Currently it is supposed that the test events are sequential. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-release] BigMichi1 commented on a diff in pull request #121: [MRELEASE-1082] configuration option for using a shallow clone
BigMichi1 commented on code in PR #121: URL: https://github.com/apache/maven-release/pull/121#discussion_r867360662 ## maven-release-plugin/src/main/java/org/apache/maven/plugins/release/AbstractScmReleaseMojo.java: ## @@ -89,6 +89,12 @@ @Parameter( defaultValue = "[maven-release-plugin] ", property = "scmCommentPrefix" ) private String scmCommentPrefix; +/** + * When cloning a repository if it should be a shallow clone or a full clone. + */ +@Parameter( defaultValue = "true", property = "shallowClone" ) +private boolean shallowClone = true; Review Comment: yes you are right -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] gzm55 commented on pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120224490 - [ ] create new type - only-script - [ ] add IT test - [ ] rebase to one commit - [ ] add text to PR description ... I hereby declare this contribution to be licenced under the.. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-61) let mvnw call mvn directly, without maven-wrapper.jar
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533294#comment-17533294 ] ASF GitHub Bot commented on MWRAPPER-61: gzm55 commented on PR #33: URL: https://github.com/apache/maven-wrapper/pull/33#issuecomment-1120224490 - [ ] create new type - only-script - [ ] add IT test - [ ] rebase to one commit - [ ] add text to PR description ... I hereby declare this contribution to be licenced under the.. > let mvnw call mvn directly, without maven-wrapper.jar > - > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.2.0 > > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MWRAPPER-63) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MWRAPPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MWRAPPER-63: -- Affects Version/s: 3.1.0 > Upgrade Parent to 36 > > > Key: MWRAPPER-63 > URL: https://issues.apache.org/jira/browse/MWRAPPER-63 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MSKINS-184) Don't link pages to themselves with empty hrefs
Michael Osipov created MSKINS-184:
-
Summary: Don't link pages to themselves with empty hrefs
Key: MSKINS-184
URL: https://issues.apache.org/jira/browse/MSKINS-184
Project: Maven Skins
Issue Type: Improvement
Components: Fluido Skin
Affects Versions: fluido-1.10.0
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: fluido-1.11.0
I the nav tree, either left or top then item in the tree is linked to itself
with a mere {{#}} which makes a click jump to nowhere, in most cases to the
top. Stop selflinking when the current page correspond to the href.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MRELEASE-1082) Add configuration option for shallow checkout/clone
[
https://issues.apache.org/jira/browse/MRELEASE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-1082:
-
Summary: Add configuration option for shallow checkout/clone (was:
configuration option for shallow checkout)
> Add configuration option for shallow checkout/clone
> ---
>
> Key: MRELEASE-1082
> URL: https://issues.apache.org/jira/browse/MRELEASE-1082
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Affects Versions: 3.0.0-M5
>Reporter: Michael Cramer
>Assignee: Michael Osipov
>Priority: Major
> Labels: checkout, clone, git, shallow, up-for-grabs
> Fix For: 3.0.0-M6
>
>
> after implementing sonar into our release process we noticed that sonar is
> complaining about missing blame information
> {noformat}
> [INFO] [WARNING] Missing blame information for the following files:
> {noformat}
> I've seen that in MRELEASE-993 this new type of checkout was introduced and
> it mentions that "per default" the checkout will use the shallow clone. to
> me, it sounds that this is an option that can be configured, but after taking
> a look in the code I see that {{true}} is hardcoded
> i would propose to make this option configurable and have a default of
> {{true}} that can be changed when needed, e.g. in the case during the release
> sonarqube is called which needs the full history.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-993) Use shallow checkout per default (git scm)
[ https://issues.apache.org/jira/browse/MRELEASE-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533307#comment-17533307 ] Michael Osipov commented on MRELEASE-993: - [~hazendaz], why actually? From a release point of view only the last version is interesting... > Use shallow checkout per default (git scm) > -- > > Key: MRELEASE-993 > URL: https://issues.apache.org/jira/browse/MRELEASE-993 > Project: Maven Release Plugin > Issue Type: Improvement > Components: scm >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.0.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] asfgit closed pull request #121: [MRELEASE-1082] configuration option for using a shallow clone
asfgit closed pull request #121: [MRELEASE-1082] configuration option for using a shallow clone URL: https://github.com/apache/maven-release/pull/121 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRELEASE-1082) Add configuration option for shallow checkout/clone
[
https://issues.apache.org/jira/browse/MRELEASE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRELEASE-1082.
Resolution: Fixed
Fixed with
[8cc2f45c2f424b176a45afc1e245639d56f31048|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=8cc2f45c2f424b176a45afc1e245639d56f31048].
> Add configuration option for shallow checkout/clone
> ---
>
> Key: MRELEASE-1082
> URL: https://issues.apache.org/jira/browse/MRELEASE-1082
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Affects Versions: 3.0.0-M5
>Reporter: Michael Cramer
>Assignee: Michael Osipov
>Priority: Major
> Labels: checkout, clone, git, shallow, up-for-grabs
> Fix For: 3.0.0-M6
>
>
> after implementing sonar into our release process we noticed that sonar is
> complaining about missing blame information
> {noformat}
> [INFO] [WARNING] Missing blame information for the following files:
> {noformat}
> I've seen that in MRELEASE-993 this new type of checkout was introduced and
> it mentions that "per default" the checkout will use the shallow clone. to
> me, it sounds that this is an option that can be configured, but after taking
> a look in the code I see that {{true}} is hardcoded
> i would propose to make this option configurable and have a default of
> {{true}} that can be changed when needed, e.g. in the case during the release
> sonarqube is called which needs the full history.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MRELEASE-1089) Reduce the tag format to the project version only
Michael Osipov created MRELEASE-1089:
Summary: Reduce the tag format to the project version only
Key: MRELEASE-1089
URL: https://issues.apache.org/jira/browse/MRELEASE-1089
Project: Maven Release Plugin
Issue Type: Improvement
Components: scm
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.0.0-M6
Back in the days when this plugin was written and all ASF Maven-based projects
used the ASF Subversion repo, the common practice was to have
trunk/branches/tags for all component groups instead of the common sense to
have one dir per project with trunk/branches/tags. This resulted that the ASF
diverged from the common practice and basically imposed
{project.artifactId}-{project.version} tag format to the entire Java world.
With the emerge of Git one could only have one project per repo where this
approach was pointless anyway.
Proposal: since this is an overhauled practice, it is neither fruitful for
Subversion, Git or Mercurial and a prefix which is appended to every tag is
redudant, replace this format with the version only like many others do now.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MRELEASE-1089) Reduce the tag format to the project version only
[
https://issues.apache.org/jira/browse/MRELEASE-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-1089:
-
Description:
Back in the days when this plugin was written and all ASF Maven-based projects
used the ASF Subversion repo, the common practice was to have
trunk/branches/tags for all component groups instead of the common sense to
have one dir per project with trunk/branches/tags. This resulted that the ASF
diverged from the common practice and basically imposed
{{\{project.artifactId\}-\{project.version\}}} tag format to the entire Java
world. With the emerge of Git one could only have one project per repo where
this approach was pointless anyway.
Proposal: since this is an overhauled practice, it is neither fruitful for
Subversion, Git or Mercurial and a prefix which is appended to every tag is
redudant, replace this format with the version only like many others do now.
was:
Back in the days when this plugin was written and all ASF Maven-based projects
used the ASF Subversion repo, the common practice was to have
trunk/branches/tags for all component groups instead of the common sense to
have one dir per project with trunk/branches/tags. This resulted that the ASF
diverged from the common practice and basically imposed
{project.artifactId}-{project.version} tag format to the entire Java world.
With the emerge of Git one could only have one project per repo where this
approach was pointless anyway.
Proposal: since this is an overhauled practice, it is neither fruitful for
Subversion, Git or Mercurial and a prefix which is appended to every tag is
redudant, replace this format with the version only like many others do now.
> Reduce the tag format to the project version only
> -
>
> Key: MRELEASE-1089
> URL: https://issues.apache.org/jira/browse/MRELEASE-1089
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> Back in the days when this plugin was written and all ASF Maven-based
> projects used the ASF Subversion repo, the common practice was to have
> trunk/branches/tags for all component groups instead of the common sense to
> have one dir per project with trunk/branches/tags. This resulted that the ASF
> diverged from the common practice and basically imposed
> {{\{project.artifactId\}-\{project.version\}}} tag format to the entire Java
> world. With the emerge of Git one could only have one project per repo where
> this approach was pointless anyway.
> Proposal: since this is an overhauled practice, it is neither fruitful for
> Subversion, Git or Mercurial and a prefix which is appended to every tag is
> redudant, replace this format with the version only like many others do now.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-1082) Add configuration option for shallow checkout/clone
[
https://issues.apache.org/jira/browse/MRELEASE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533311#comment-17533311
]
Hudson commented on MRELEASE-1082:
--
Build succeeded in Jenkins: Maven » Maven TLP » maven-release » master #25
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/25/
> Add configuration option for shallow checkout/clone
> ---
>
> Key: MRELEASE-1082
> URL: https://issues.apache.org/jira/browse/MRELEASE-1082
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Affects Versions: 3.0.0-M5
>Reporter: Michael Cramer
>Assignee: Michael Osipov
>Priority: Major
> Labels: checkout, clone, git, shallow, up-for-grabs
> Fix For: 3.0.0-M6
>
>
> after implementing sonar into our release process we noticed that sonar is
> complaining about missing blame information
> {noformat}
> [INFO] [WARNING] Missing blame information for the following files:
> {noformat}
> I've seen that in MRELEASE-993 this new type of checkout was introduced and
> it mentions that "per default" the checkout will use the shallow clone. to
> me, it sounds that this is an option that can be configured, but after taking
> a look in the code I see that {{true}} is hardcoded
> i would propose to make this option configurable and have a default of
> {{true}} that can be changed when needed, e.g. in the case during the release
> sonarqube is called which needs the full history.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MRELEASE-1089) Reduce the tag format to the project version only
[
https://issues.apache.org/jira/browse/MRELEASE-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRELEASE-1089:
-
Description:
Back in the days when this plugin was written and all ASF Maven-based projects
used the ASF Subversion repo, the common practice was to have one
trunk/branches/tags for all component groups instead of the common sense to
have one dir per project with distinct trunk/branches/tags. This resulted that
the ASF diverged from the common practice and basically imposed
}project.artifactId}-{project.version{ tag format to the entire Java
world. With the emerge of Git one can have one project per repo where this
approach was pointless anyway.
Proposal: since this is an overhauled practice, it is neither fruitful for
Subversion, Git or Mercurial and a prefix which is appended to every tag is
redudant, replace this format with the version only like many others do now.
was:
Back in the days when this plugin was written and all ASF Maven-based projects
used the ASF Subversion repo, the common practice was to have
trunk/branches/tags for all component groups instead of the common sense to
have one dir per project with trunk/branches/tags. This resulted that the ASF
diverged from the common practice and basically imposed
{{\{project.artifactId\}-\{project.version\}}} tag format to the entire Java
world. With the emerge of Git one could only have one project per repo where
this approach was pointless anyway.
Proposal: since this is an overhauled practice, it is neither fruitful for
Subversion, Git or Mercurial and a prefix which is appended to every tag is
redudant, replace this format with the version only like many others do now.
> Reduce the tag format to the project version only
> -
>
> Key: MRELEASE-1089
> URL: https://issues.apache.org/jira/browse/MRELEASE-1089
> Project: Maven Release Plugin
> Issue Type: Improvement
> Components: scm
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> Back in the days when this plugin was written and all ASF Maven-based
> projects used the ASF Subversion repo, the common practice was to have one
> trunk/branches/tags for all component groups instead of the common sense to
> have one dir per project with distinct trunk/branches/tags. This resulted
> that the ASF diverged from the common practice and basically imposed
> }project.artifactId}-{project.version{ tag format to the entire Java
> world. With the emerge of Git one can have one project per repo where this
> approach was pointless anyway.
> Proposal: since this is an overhauled practice, it is neither fruitful for
> Subversion, Git or Mercurial and a prefix which is appended to every tag is
> redudant, replace this format with the version only like many others do now.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPDF-104: Attachment: image-2022-05-07-20-26-10-465.png > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPDF-104: Attachment: image-2022-05-07-20-26-03-180.png > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPDF-104: Attachment: (was: image-2022-05-07-20-26-10-465.png) > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533315#comment-17533315 ] Michael Osipov commented on MPDF-104: - Exactly what I have assumed: [![^image-2022-05-07-20-26-03-180.png] Font type must be true type and encoding must be Identity-H. This config is only suitable for Western European languages. > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533315#comment-17533315 ] Michael Osipov edited comment on MPDF-104 at 5/7/22 6:42 PM: - Exactly what I have assumed: [![^image-2022-05-07-20-26-03-180.png] Font type must be true type and encoding must be Identity-H (CID). This config is only suitable for Western European languages. was (Author: michael-o): Exactly what I have assumed: [![^image-2022-05-07-20-26-03-180.png] Font type must be true type and encoding must be Identity-H. This config is only suitable for Western European languages. > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533317#comment-17533317 ] Michael Osipov commented on MPDF-104: - I have found your problem: doxia-module-fo comes with fo-styles.xslt which sets the fonts. Those fonts are only the base fonts which represent Latin scripts. Barely usable for most cases. The file can be overloaded, but I have no idea whether the layers above expose the config for it. Apache FOP itself basically use any font: [https://xmlgraphics.apache.org/fop/2.7/fonts.html|https://xmlgraphics.apache.org/fop/2.7/fonts.html#awt] I don't recommend use any system fonts because this would make the entire build non-portable. Ideally, custom fonts are used which are open source and include most of the Unicode space. Then on needs to decide whether a screen-optimized or print-optimized font and which for serif and sans serif. I expect that the estimated time for this is several days for someone who understands PDF, fonts and Apache FOP. I do understand the two former pretty well, but not FOP. Maybe the community can take care, I wil gladly consult. [~slachiewicz], would you be interested in this? > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MPDF-104) i18n broken
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533317#comment-17533317 ] Michael Osipov edited comment on MPDF-104 at 5/7/22 6:51 PM: - I have found your problem: doxia-module-fo comes with fo-styles.xslt which sets the fonts. Those fonts are only the base fonts which represent Latin scripts. Barely usable for most cases. The file can be overloaded, but I have no idea whether the layers above expose the config for it. Apache FOP itself basically use any font: [https://xmlgraphics.apache.org/fop/2.7/fonts.html|https://xmlgraphics.apache.org/fop/2.7/fonts.html#awt] I don't recommend using any system fonts because this would make the entire build non-portable. Ideally, custom fonts are used which are open source and include most of the Unicode space. Then one needs to decide whether a screen-optimized or print-optimized font and which for serif and sans serif. I expect that the estimated time for this is several days for someone who understands PDF, fonts and Apache FOP. I do understand the two former pretty well, but not FOP. Maybe the community can take care, I wil gladly consult. [~slachiewicz], would you be interested in this? was (Author: michael-o): I have found your problem: doxia-module-fo comes with fo-styles.xslt which sets the fonts. Those fonts are only the base fonts which represent Latin scripts. Barely usable for most cases. The file can be overloaded, but I have no idea whether the layers above expose the config for it. Apache FOP itself basically use any font: [https://xmlgraphics.apache.org/fop/2.7/fonts.html|https://xmlgraphics.apache.org/fop/2.7/fonts.html#awt] I don't recommend use any system fonts because this would make the entire build non-portable. Ideally, custom fonts are used which are open source and include most of the Unicode space. Then on needs to decide whether a screen-optimized or print-optimized font and which for serif and sans serif. I expect that the estimated time for this is several days for someone who understands PDF, fonts and Apache FOP. I do understand the two former pretty well, but not FOP. Maybe the community can take care, I wil gladly consult. [~slachiewicz], would you be interested in this? > i18n broken > --- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MPDF-104) Doxia Apache FOP module uses only Base 14 fonts unusable for non-Latin scripts
[ https://issues.apache.org/jira/browse/MPDF-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPDF-104: Summary: Doxia Apache FOP module uses only Base 14 fonts unusable for non-Latin scripts (was: i18n broken) > Doxia Apache FOP module uses only Base 14 fonts unusable for non-Latin scripts > -- > > Key: MPDF-104 > URL: https://issues.apache.org/jira/browse/MPDF-104 > Project: Maven PDF Plugin > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Xavi Lee >Priority: Major > Attachments: 164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png, > image-2022-05-07-20-26-03-180.png > > > In mybatis release pdf, we can see it doesn't display the words of non > English. It's "#". > If you think it's not plugin problem, please give me a proper example for > using i18n. !164194106-b4c23811-dee7-4849-abc4-6d88d7005d93.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] michael-o opened a new pull request, #122: [MRELEASE-1089] Reduce the tag format to the project version only
michael-o opened a new pull request, #122: URL: https://github.com/apache/maven-release/pull/122 This closes #122 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/MJAVADOC) 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 `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-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 -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-wrapper] slawekjaranowski merged pull request #41: [MWRAPPER-63] Upgrade Parent to 36
slawekjaranowski merged PR #41: URL: https://github.com/apache/maven-wrapper/pull/41 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-63) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MWRAPPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533318#comment-17533318 ] ASF GitHub Bot commented on MWRAPPER-63: slawekjaranowski merged PR #41: URL: https://github.com/apache/maven-wrapper/pull/41 > Upgrade Parent to 36 > > > Key: MWRAPPER-63 > URL: https://issues.apache.org/jira/browse/MWRAPPER-63 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MWRAPPER-63) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MWRAPPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MWRAPPER-63. --- Resolution: Fixed > Upgrade Parent to 36 > > > Key: MWRAPPER-63 > URL: https://issues.apache.org/jira/browse/MWRAPPER-63 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MRELEASE-1063) Maven release plugin should retain settings.security environment variable for its forked executions of release:prepare and release:perform
[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533319#comment-17533319
]
Hans Aikema commented on MRELEASE-1063:
---
[~michael-o] While I agree that the directly presented scenario does not add a
security benefit I do see cases where
* ci builder user home cannot be influenced (so a settings-security.xml with a
master password, or redirection to build-server-admin-writable
settings-security can not be stored)
* some other secured location can be used to store a settings-security.xml with
the master-password
in that case still it is a massive nuisance to have to:
1) explicitly specify the location of the settings-security.xml 3 times for a
maven release command-line
2) having to specify the explicit goals for the release prepare and release
perform, breaking maven's convention-over-configuration paradigm, as the only
way to provide maven with the property for the settings-security file is by
explicitly setting the full goal as maven's release:prepare / release:perform
invocations do not propagate the properties of the main maven invocation they
originate from.
As the maven release plugin is responsible for the invocations of the maven
execution for prepare and perform of the release it should in my view ensure
that any properties given to the main command are propagated to the (forked?)
execution for release preparation and release perform.
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> --
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.2
>Reporter: Hans Aikema
>Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-1063) Maven release plugin should retain settings.security environment variable for its forked executions of release:prepare and release:perform
[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533320#comment-17533320
]
Hans Aikema commented on MRELEASE-1063:
---
Note: If you think that password encryption is no added benefit at all you
should fully remove it from Maven and erase
https://maven.apache.org/guides/mini/guide-encryption.html
If you think it has benefits it should properly support 'convention over
configuration' for the release plugin, allowing easy configuration of the
location of the file that holds the master password for settings secret
encryptions.
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> --
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.2
>Reporter: Hans Aikema
>Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-1079) scm tag is added to child module
[ https://issues.apache.org/jira/browse/MRELEASE-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533321#comment-17533321 ] Michael Osipov commented on MRELEASE-1079: -- Tested the IT, I can confirm the issue. > scm tag is added to child module > > > Key: MRELEASE-1079 > URL: https://issues.apache.org/jira/browse/MRELEASE-1079 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 3.0.0-M5 >Reporter: Markus Schäfer >Assignee: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.0.0-M6 > > > With Version 3.0.0-M5 child modules gets an scm tag during the prepare step > when there is more than one module level. > The Bug seems to be in RewritePomsForReleasePhase. > RewritePomsForDevelopmentPhase removes the scm tag. Only the tagged release > has these scm tags. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MWRAPPER-63) Upgrade Parent to 36
[ https://issues.apache.org/jira/browse/MWRAPPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533322#comment-17533322 ] Hudson commented on MWRAPPER-63: Build succeeded in Jenkins: Maven » Maven TLP » maven-wrapper » master #20 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/master/20/ > Upgrade Parent to 36 > > > Key: MWRAPPER-63 > URL: https://issues.apache.org/jira/browse/MWRAPPER-63 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.1.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-release] pzygielo commented on pull request #122: [MRELEASE-1089] Reduce the tag format to the project version only
pzygielo commented on PR #122: URL: https://github.com/apache/maven-release/pull/122#issuecomment-1120270476 Will similar be applied to https://github.com/apache/maven-release/blob/8cc2f45c2f424b176a45afc1e245639d56f31048/maven-release-manager/src/main/java/org/apache/maven/shared/release/policies/DefaultNamingPolicy.java#L34-L44? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRELEASE-1063) Maven release plugin should retain settings.security environment variable for its forked executions of release:prepare and release:perform
[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533324#comment-17533324
]
Michael Osipov commented on MRELEASE-1063:
--
One of the issues is that it is not evaluated by Maven itself, but rather a
third party component which is totally unaware of Maven. Although, I cannot
tell why this encryption was added, from a security PoV there is zero benefit.
{quote}As the maven release plugin is responsible for the invocations of the
maven execution for prepare and perform of the release it should in my view
ensure that any properties given to the main command are propagated to the
(forked?) execution for release preparation and release perform.
{quote}
I don't agree with this. The caller and the callee are different there is not
implication tha they have to share the same arguments. Fork is different as
direct invocation by human or machine.
Why can't you use {{MAVEN_OPTS}} to solve your problem? That system property
will be added to the JVM and Plexus Sec Dispatcher can consume it.
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> --
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.2
>Reporter: Hans Aikema
>Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-release] michael-o commented on pull request #122: [MRELEASE-1089] Reduce the tag format to the project version only
michael-o commented on PR #122: URL: https://github.com/apache/maven-release/pull/122#issuecomment-1120270763 > Will similar be applied to > > https://github.com/apache/maven-release/blob/8cc2f45c2f424b176a45afc1e245639d56f31048/maven-release-manager/src/main/java/org/apache/maven/shared/release/policies/DefaultNamingPolicy.java#L34-L44 > ? Oh, very nice catch... Yes, it should be consistent throughout, no? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
