[jira] [Comment Edited] (DOXIA-492) Add support for doxia macros in markdown documents.
[
https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025934#comment-15025934
]
Hervé Boutemy edited comment on DOXIA-492 at 11/25/15 7:24 AM:
---
SUCCESS: Integrated in doxia-all #175 (See
[https://builds.apache.org/job/doxia-all/175/])
[DOXIA-492] fixed macro support, with unit test (hboutemy:
[r1716285|http://svn.apache.org/r1716285])
*
./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
*
./doxia/doxia-modules/doxia-module-markdown/src/test/java/org/apache/maven/doxia/module/markdown/MarkdownParserTest.java
* ./doxia/doxia-modules/doxia-module-markdown/src/test/resources/macro-toc.md
was (Author: hudson):
SUCCESS: Integrated in doxia-all #175 (See
[https://builds.apache.org/job/doxia-all/175/])
[DOXIA-492] fixed macro support, with unit test (hboutemy: rev 1716285)
*
./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
*
./doxia/doxia-modules/doxia-module-markdown/src/test/java/org/apache/maven/doxia/module/markdown/MarkdownParserTest.java
* ./doxia/doxia-modules/doxia-module-markdown/src/test/resources/macro-toc.md
> Add support for doxia macros in markdown documents.
> ---
>
> Key: DOXIA-492
> URL: https://issues.apache.org/jira/browse/DOXIA-492
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.4
>Reporter: Juergen Kellerer
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
> Attachments: maven-site-plugin-integration-test.patch, screen.png
>
>
> It would be nice if doxia macros could be supported also inside markdown
> documents (similar to APT).
> Existing macros (especially snippet) is very useful, however with the power
> of maven there's the ability to register own macros for a build process which
> enables reuse of resources and improves dryness in general.
> A syntax which may work could be the following:
> * Block Level
> {noformat}
>#`??MACRO_NAME MACRO_ARGS`
> {noformat}
> * Inline
> {noformat}
> `??MACRO_NAME MACRO_ARGS`
> {noformat}
> Reference:
> http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html
> E.g. using "Texts" it works just from the Editor:
> !screen.png!
> When macros are not interpreted, they fallback to a code block, thus it's
> easy to edit these sort of documents with one of the existing nice markdown
> editors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DOXIA-492) Add support for doxia macros in markdown documents.
[
https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025937#comment-15025937
]
Hervé Boutemy edited comment on DOXIA-492 at 11/25/15 7:24 AM:
---
SUCCESS: Integrated in maven-plugins #4835 (See
[https://builds.apache.org/job/maven-plugins/4835/])
[DOXIA-492] fixed macro support
Submitted by: Andreas Veithen (hboutemy:
[r1716287|http://svn.apache.org/r1716287])
* maven-site-plugin/src/it/markdown-format/src/site/markdown/index.md
* maven-site-plugin/src/it/markdown-format/verify.groovy
was (Author: hudson):
SUCCESS: Integrated in maven-plugins #4835 (See
[https://builds.apache.org/job/maven-plugins/4835/])
[DOXIA-492] fixed macro support
Submitted by: Andreas Veithen (hboutemy: rev 1716287)
* maven-site-plugin/src/it/markdown-format/src/site/markdown/index.md
* maven-site-plugin/src/it/markdown-format/verify.groovy
> Add support for doxia macros in markdown documents.
> ---
>
> Key: DOXIA-492
> URL: https://issues.apache.org/jira/browse/DOXIA-492
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.4
>Reporter: Juergen Kellerer
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
> Attachments: maven-site-plugin-integration-test.patch, screen.png
>
>
> It would be nice if doxia macros could be supported also inside markdown
> documents (similar to APT).
> Existing macros (especially snippet) is very useful, however with the power
> of maven there's the ability to register own macros for a build process which
> enables reuse of resources and improves dryness in general.
> A syntax which may work could be the following:
> * Block Level
> {noformat}
>#`??MACRO_NAME MACRO_ARGS`
> {noformat}
> * Inline
> {noformat}
> `??MACRO_NAME MACRO_ARGS`
> {noformat}
> Reference:
> http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html
> E.g. using "Texts" it works just from the Editor:
> !screen.png!
> When macros are not interpreted, they fallback to a code block, thus it's
> easy to edit these sort of documents with one of the existing nice markdown
> editors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026310#comment-15026310
]
Vasilii Ruzov edited comment on MRELEASE-931 at 11/25/15 6:53 AM:
--
try to read everything again and look at the problem I described. problem is
not in the cert but the PLAINTEXT PASSWORD in log in case of git failure. ssl
cert problem is just a simulation to show the exact output when git fails
was (Author: ruzovas):
try to read everything again and look at the problem I described. problem is
not in the cert but the PLAINTEXT PASSWORD in log in case of git failure
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026310#comment-15026310
]
Vasilii Ruzov commented on MRELEASE-931:
try to read everything again and look at the problem I described. problem is
not in the cert but the PLAINTEXT PASSWORD in log in case of git failure
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026308#comment-15026308
]
Vasilii Ruzov commented on MRELEASE-931:
output, yes.
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIA-492) Add support for doxia macros in markdown documents.
[
https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025934#comment-15025934
]
Hudson commented on DOXIA-492:
--
SUCCESS: Integrated in doxia-all #175 (See
[https://builds.apache.org/job/doxia-all/175/])
[DOXIA-492] fixed macro support, with unit test (hboutemy: rev 1716285)
*
./doxia/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
*
./doxia/doxia-modules/doxia-module-markdown/src/test/java/org/apache/maven/doxia/module/markdown/MarkdownParserTest.java
* ./doxia/doxia-modules/doxia-module-markdown/src/test/resources/macro-toc.md
> Add support for doxia macros in markdown documents.
> ---
>
> Key: DOXIA-492
> URL: https://issues.apache.org/jira/browse/DOXIA-492
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.4
>Reporter: Juergen Kellerer
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
> Attachments: maven-site-plugin-integration-test.patch, screen.png
>
>
> It would be nice if doxia macros could be supported also inside markdown
> documents (similar to APT).
> Existing macros (especially snippet) is very useful, however with the power
> of maven there's the ability to register own macros for a build process which
> enables reuse of resources and improves dryness in general.
> A syntax which may work could be the following:
> * Block Level
> {noformat}
>#`??MACRO_NAME MACRO_ARGS`
> {noformat}
> * Inline
> {noformat}
> `??MACRO_NAME MACRO_ARGS`
> {noformat}
> Reference:
> http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html
> E.g. using "Texts" it works just from the Editor:
> !screen.png!
> When macros are not interpreted, they fallback to a code block, thus it's
> easy to edit these sort of documents with one of the existing nice markdown
> editors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIA-492) Add support for doxia macros in markdown documents.
[
https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025937#comment-15025937
]
Hudson commented on DOXIA-492:
--
SUCCESS: Integrated in maven-plugins #4835 (See
[https://builds.apache.org/job/maven-plugins/4835/])
[DOXIA-492] fixed macro support
Submitted by: Andreas Veithen (hboutemy: rev 1716287)
* maven-site-plugin/src/it/markdown-format/src/site/markdown/index.md
* maven-site-plugin/src/it/markdown-format/verify.groovy
> Add support for doxia macros in markdown documents.
> ---
>
> Key: DOXIA-492
> URL: https://issues.apache.org/jira/browse/DOXIA-492
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.4
>Reporter: Juergen Kellerer
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
> Attachments: maven-site-plugin-integration-test.patch, screen.png
>
>
> It would be nice if doxia macros could be supported also inside markdown
> documents (similar to APT).
> Existing macros (especially snippet) is very useful, however with the power
> of maven there's the ability to register own macros for a build process which
> enables reuse of resources and improves dryness in general.
> A syntax which may work could be the following:
> * Block Level
> {noformat}
>#`??MACRO_NAME MACRO_ARGS`
> {noformat}
> * Inline
> {noformat}
> `??MACRO_NAME MACRO_ARGS`
> {noformat}
> Reference:
> http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html
> E.g. using "Texts" it works just from the Editor:
> !screen.png!
> When macros are not interpreted, they fallback to a code block, thus it's
> easy to edit these sort of documents with one of the existing nice markdown
> editors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DOXIA-492) Add support for doxia macros in markdown documents.
[
https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed DOXIA-492.
---
Resolution: Fixed
Assignee: Hervé Boutemy
Fix Version/s: 1.7
code fixed, unit test added in Doxia and integration test added into m-site-p
thank you for your help: now I am under even more pressure to do the release :)
> Add support for doxia macros in markdown documents.
> ---
>
> Key: DOXIA-492
> URL: https://issues.apache.org/jira/browse/DOXIA-492
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.4
>Reporter: Juergen Kellerer
>Assignee: Hervé Boutemy
> Fix For: 1.7
>
> Attachments: maven-site-plugin-integration-test.patch, screen.png
>
>
> It would be nice if doxia macros could be supported also inside markdown
> documents (similar to APT).
> Existing macros (especially snippet) is very useful, however with the power
> of maven there's the ability to register own macros for a build process which
> enables reuse of resources and improves dryness in general.
> A syntax which may work could be the following:
> * Block Level
> {noformat}
>#`??MACRO_NAME MACRO_ARGS`
> {noformat}
> * Inline
> {noformat}
> `??MACRO_NAME MACRO_ARGS`
> {noformat}
> Reference:
> http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html
> E.g. using "Texts" it works just from the Editor:
> !screen.png!
> When macros are not interpreted, they fallback to a code block, thus it's
> easy to edit these sort of documents with one of the existing nice markdown
> editors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5936) mvn test classname issue
[
https://issues.apache.org/jira/browse/MNG-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MNG-5936.
Resolution: Cannot Reproduce
Assignee: Karl Heinz Marbaise
The execution of tests in this case is related to maven-surefire-plugin and
it's appropriate configuration of the [naming
schema|https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes]...
And renaming the second {{FunctionalTests}} into {{MyTestClass.java}} will not
change the result cause it does not match the naming schema...Only if in one of
your parent pom's the configuration for maven-surefire-plugin has been change
could explain the behaviour in the second case so i will close this issue. If
you have further information please don't hesitate to reopen the issue and
explain more in details what the problem is.
> mvn test classname issue
>
>
> Key: MNG-5936
> URL: https://issues.apache.org/jira/browse/MNG-5936
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.0.5
> Environment: Ubuntu Linux 14.04 x86_64 / Oracle Java 1.8.0_66 / Junit
> 4.12
>Reporter: Martin Goik
>Assignee: Karl Heinz Marbaise
> Labels: junit
>
> Complete source code available at
> https://cloud.mi.hdm-stuttgart.de/owncloud/index.php/s/6dTJHyjm5y1yVGY.
> Project contains two test classes "FunctionalTests" (plural) and
> "FunctionalTest" (singular). Test methods within the latter get executed,
> those from the first class won't:
> mvn test
> ...
> Tests run: 1, ...
> Merely renaming class FunctionalTests to e.g. "MyTestClass" solves the issue
> resulting in:
> Tests run: 2, ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5904) Remove the whole Ant Build
[ https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025379#comment-15025379 ] Jason van Zyl commented on MNG-5904: @Paul Benedict +1, I think that's reasonable. > Remove the whole Ant Build > -- > > Key: MNG-5904 > URL: https://issues.apache.org/jira/browse/MNG-5904 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.4.0 > > > We should remove the whole Ant build cause we have a large number of Maven > versions which could be used to start building Maven itself. > So i don't see any usefulness in it anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Domagala updated MWAR-360:
-
Description:
Example:
I have WAR project 'Base' with class A.
I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
extends A.
Then 'Base' must have true
Finally, I have WAR project 'Level2' with class C extends B. For the same
reason 'Level1' must have true
Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
Level1 contains Base
Actual: Level1 and Base are overlayed together. That wastes time.
{noformat}
[INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
[INFO] Processing overlay [ id mwar:Level1]
[INFO] Processing overlay [ id Base:Base]
[INFO] Webapp assembled in [26 msecs]
{noformat}
Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
"fake"
{noformat}
[INFO] mwar:Level2:war:0.0.1-SNAPSHOT
[INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
[INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
[INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
[INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
{noformat}
Proposed solution: There should be option 'notOverlayTransitiveWar' which allow
exclude WARs like 'Base' from overlaying, because the transitive WAR may be
reached only over JAR and I think there is no reason any JAR really depends on
WAR.
Workaround is manually define ovelays in plugin configuration, but Maven spirit
is Convention over Configuration
was:
Example:
I have WAR project 'Base' with class A.
I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
extends A.
Then 'Base' must have true
Finally, I have WAR project 'Level2' with class C extends B. For the same
reason 'Level1' must have true
Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
Level1 contains Base
Actual: Level1 and Base are overlayed together. That wastes time.
[INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
[INFO] Processing overlay [ id mwar:Level1]
[INFO] Processing overlay [ id Base:Base]
[INFO] Webapp assembled in [26 msecs]
Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
"fake"
[INFO] mwar:Level2:war:0.0.1-SNAPSHOT
[INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
[INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
[INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
[INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
Proposed solution: There should be option 'notOverlayTransitiveWar' which allow
exclude WARs like 'Base' from overlaying, because the transitive WAR may be
reached only over JAR and I think there is no reason any JAR really depends on
WAR.
Workaround is manually define ovelays in plugin configuration, but Maven spirit
is Convention over Configuration
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
Michal Domagala created MWAR-360: Summary: Overlay: ignore WAR which is transitively dependent over JAR Key: MWAR-360 URL: https://issues.apache.org/jira/browse/MWAR-360 Project: Maven WAR Plugin Issue Type: Improvement Reporter: Michal Domagala Priority: Minor Example: I have WAR project 'Base' with class A. I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B extends A. Then 'Base' must have true Finally, I have WAR project 'Level2' with class C extends B. For the same reason 'Level1' must have true Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because Level1 contains Base Actual: Level1 and Base are overlayed together. That wastes time. [INFO] Copying webapp resources [mwar/Level2/src/main/webapp] [INFO] Processing overlay [ id mwar:Level1] [INFO] Processing overlay [ id Base:Base] [INFO] Webapp assembled in [26 msecs] Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is "fake" [INFO] mwar:Level2:war:0.0.1-SNAPSHOT [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile Proposed solution: There should be option 'notOverlayTransitiveWar' which allow exclude WARs like 'Base' from overlaying, because the transitive WAR may be reached only over JAR and I think there is no reason any JAR really depends on WAR. Workaround is manually define ovelays in plugin configuration, but Maven spirit is Convention over Configuration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5904) Remove the whole Ant Build
[ https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025348#comment-15025348 ] Karl Heinz Marbaise commented on MNG-5904: -- @Paul Benedict The idea you suggested sounds very good and simple. > Remove the whole Ant Build > -- > > Key: MNG-5904 > URL: https://issues.apache.org/jira/browse/MNG-5904 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.4.0 > > > We should remove the whole Ant build cause we have a large number of Maven > versions which could be used to start building Maven itself. > So i don't see any usefulness in it anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5936) mvn test classname issue
Martin Goik created MNG-5936: Summary: mvn test classname issue Key: MNG-5936 URL: https://issues.apache.org/jira/browse/MNG-5936 Project: Maven Issue Type: Bug Components: Command Line Affects Versions: 3.0.5 Environment: Ubuntu Linux 14.04 x86_64 / Oracle Java 1.8.0_66 / Junit 4.12 Reporter: Martin Goik Complete source code available at https://cloud.mi.hdm-stuttgart.de/owncloud/index.php/s/6dTJHyjm5y1yVGY. Project contains two test classes "FunctionalTests" (plural) and "FunctionalTest" (singular). Test methods within the latter get executed, those from the first class won't: mvn test ... Tests run: 1, ... Merely renaming class FunctionalTests to e.g. "MyTestClass" solves the issue resulting in: Tests run: 2, ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1197) Surefire 2.19 breaks tests under Windows due to fork problem
[ https://issues.apache.org/jira/browse/SUREFIRE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024681#comment-15024681 ] Tibor Digana commented on SUREFIRE-1197: Make sure you use the right local repo path. Override it again. Launch the Maven build in offline mode. mvn -o test Most probably the snapshot version was downloaded from web using another content. On Tue, Nov 24, 2015 at 4:10 PM, Thorsten Meinl (JIRA) > Surefire 2.19 breaks tests under Windows due to fork problem > > > Key: SUREFIRE-1197 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1197 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.19 > Environment: Windows 7 >Reporter: Thorsten Meinl >Assignee: Tibor Digana > > After switching from Surefire 2.18.1 to 2.19 our tests under Windows have > stopped working (Linux and Mac are still running fine). The only error > message is > Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on > project server.ejb: Error occurred in starting fork, check output in log -> > [Help 1] > (Full stacktrace below). > Is checked the log and even enabled full debug messages but there is not > indication whatsoever what the problem can be. Given that everything worked > perfectly fine until we switched to 2.19 this seems to be a bug in this > version. I'm happy to provide further details if you tell me what you need > and how I can acquire it. > === > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) > on project server.ejb: Error occurred in starting fork, check output in log > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.MojoFailureException: Error occurred in > starting fork, check output in log > at > org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:326) > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:316) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:880) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:739) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 19 more > Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: > Error occurred in starting fork, check output in log > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:559) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:461) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:229) >
[jira] [Commented] (SUREFIRE-1197) Surefire 2.19 breaks tests under Windows due to fork problem
[ https://issues.apache.org/jira/browse/SUREFIRE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024650#comment-15024650 ] Thorsten Meinl commented on SUREFIRE-1197: -- Did as you described, but I don't find any of the files that you mentioned anywhere in my projects. Only the usual *Test.txt files with the results for each test class. I'm sure I'm using 2.20-SNAPSHOT because the fork error message shows this version number. > Surefire 2.19 breaks tests under Windows due to fork problem > > > Key: SUREFIRE-1197 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1197 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.19 > Environment: Windows 7 >Reporter: Thorsten Meinl >Assignee: Tibor Digana > > After switching from Surefire 2.18.1 to 2.19 our tests under Windows have > stopped working (Linux and Mac are still running fine). The only error > message is > Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on > project server.ejb: Error occurred in starting fork, check output in log -> > [Help 1] > (Full stacktrace below). > Is checked the log and even enabled full debug messages but there is not > indication whatsoever what the problem can be. Given that everything worked > perfectly fine until we switched to 2.19 this seems to be a bug in this > version. I'm happy to provide further details if you tell me what you need > and how I can acquire it. > === > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) > on project server.ejb: Error occurred in starting fork, check output in log > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.MojoFailureException: Error occurred in > starting fork, check output in log > at > org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:326) > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:316) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:880) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:739) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 19 more > Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: > Error occurred in starting fork, check output in log > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:559) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:461) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:2
[jira] [Commented] (MSHARED-466) Filtering dependencies does not retain the order of the unfiltered list
[
https://issues.apache.org/jira/browse/MSHARED-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024552#comment-15024552
]
Beirtí Ó'Nunáin commented on MSHARED-466:
-
I originally raised this against the MDEP jira but it doesn't seem to have
gotten any attention. Here is the patch I have used locally to remedy the issue.
Index: AbstractArtifactFeatureFilter.java
===
— AbstractArtifactFeatureFilter.java (revision 1701613)
+++ AbstractArtifactFeatureFilter.java (working copy)
@@ -20,7 +20,7 @@
*/
import java.util.Arrays;
-import java.util.HashSet;
+import java.util.LinkedHashSet;
import java.util.Iterator;
import java.util.List;
import java.util.Set;
@@ -83,7 +83,7 @@
*/
private Set filterIncludes( Set artifacts, List theIncludes )
{
Set result = new HashSet();
+ Set result = new LinkedHashSet();
Iterator includeIter = theIncludes.iterator();
while ( includeIter.hasNext() )
@@ -116,7 +116,7 @@
*/
private Set filterExcludes( Set artifacts, List theExcludes )
{
Set result = new HashSet();
+ Set result = new LinkedHashSet();
Iterator iter = artifacts.iterator();
while ( iter.hasNext() )
> Filtering dependencies does not retain the order of the unfiltered list
> ---
>
> Key: MSHARED-466
> URL: https://issues.apache.org/jira/browse/MSHARED-466
> Project: Maven Shared Components
> Issue Type: Bug
>Affects Versions: maven-common-artifact-filters-1.4
>Reporter: Beirtí Ó'Nunáin
>
> If you use the dependency:build-classpath mojo, you get the dependency list
> as specified in the pom. However, if you introduce filtering, you end up
> losing the dependency order. It seems that the
> org.apache.maven.shared.artifact.filter.collection.ArtifactsFilter declares
> 'Set' instead of 'SortedSet' and that the
> org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter
> returns a HashSet instead of a LinkedHashSet, even though a LinkedHashSet is
> being passed in.
> The impact of this is that you cannot generate a correctly-ordered classpath
> when using filters. The fix is very straightforward, simply change the
> filterIncludes and filterExcludes methods of AbstractArtifactFeatureFilter to
> use a LinkedHashSet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSHARED-466) Filtering dependencies does not retain the order of the unfiltered list
Beirtí Ó'Nunáin created MSHARED-466: --- Summary: Filtering dependencies does not retain the order of the unfiltered list Key: MSHARED-466 URL: https://issues.apache.org/jira/browse/MSHARED-466 Project: Maven Shared Components Issue Type: Bug Affects Versions: maven-common-artifact-filters-1.4 Reporter: Beirtí Ó'Nunáin If you use the dependency:build-classpath mojo, you get the dependency list as specified in the pom. However, if you introduce filtering, you end up losing the dependency order. It seems that the org.apache.maven.shared.artifact.filter.collection.ArtifactsFilter declares 'Set' instead of 'SortedSet' and that the org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter returns a HashSet instead of a LinkedHashSet, even though a LinkedHashSet is being passed in. The impact of this is that you cannot generate a correctly-ordered classpath when using filters. The fix is very straightforward, simply change the filterIncludes and filterExcludes methods of AbstractArtifactFeatureFilter to use a LinkedHashSet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1197) Surefire 2.19 breaks tests under Windows due to fork problem
[ https://issues.apache.org/jira/browse/SUREFIRE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024359#comment-15024359 ] Tibor Digana edited comment on SUREFIRE-1197 at 11/24/15 12:14 PM: --- Not necessary to debug it. Please extract "surefire.local.repository.zip" from SUREFIRE-1193 in your local repo and use Surefire Version 2.20-SNAPSHOT in your project. This produces *.txt files in some target folders of your project. Generated file names start with surefire-finished1, surefire-finished2, surefire-error-ite, surefire-error-t1, surefire-error-t2. Please extract the zip in your Maven local repository (perhaps your repo is mapped to ~/.m2/repository/), run the project again and upload the files as a zip to Jira. I will analyze it. Thx. was (Author: tibor17): Not necessary to debug it. Please extract "surefire.local.repository.zip" from SUREFIRE-1193 in your local repo and use Surefire Version 2.20-SNAPSHOT in your project. This produces *.txt files in some target folders of your project. Generated file names start with surefire-finished1, surefire-finished2, surefire-error-ite, surefire-error-t1, surefire-error-t2. Please extract the zip in your Maven local repository run (perhaps your repo is mapped to ~/.m2/repository/), run the project again and upload the files as a zip to Jira. I will analyze it. Thx. > Surefire 2.19 breaks tests under Windows due to fork problem > > > Key: SUREFIRE-1197 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1197 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.19 > Environment: Windows 7 >Reporter: Thorsten Meinl >Assignee: Tibor Digana > > After switching from Surefire 2.18.1 to 2.19 our tests under Windows have > stopped working (Linux and Mac are still running fine). The only error > message is > Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on > project server.ejb: Error occurred in starting fork, check output in log -> > [Help 1] > (Full stacktrace below). > Is checked the log and even enabled full debug messages but there is not > indication whatsoever what the problem can be. Given that everything worked > perfectly fine until we switched to 2.19 this seems to be a bug in this > version. I'm happy to provide further details if you tell me what you need > and how I can acquire it. > === > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) > on project server.ejb: Error occurred in starting fork, check output in log > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.MojoFailureException: Error occurred in > starting fork, check output in log > at > org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:326) > at > org.apache.maven.plugin.surefire.Suref
[jira] [Commented] (SUREFIRE-1197) Surefire 2.19 breaks tests under Windows due to fork problem
[ https://issues.apache.org/jira/browse/SUREFIRE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024359#comment-15024359 ] Tibor Digana commented on SUREFIRE-1197: Not necessary to debug it. Please extract "surefire.local.repository.zip" from SUREFIRE-1193 in your local repo and use Surefire Version 2.20-SNAPSHOT in your project. This produces *.txt files in some target folders of your project. Generated file names start with surefire-finished1, surefire-finished2, surefire-error-ite, surefire-error-t1, surefire-error-t2. Please extract the zip in your Maven local repository run (perhaps your repo is mapped to ~/.m2/repository/), run the project again and upload the files as a zip to Jira. I will analyze it. Thx. > Surefire 2.19 breaks tests under Windows due to fork problem > > > Key: SUREFIRE-1197 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1197 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.19 > Environment: Windows 7 >Reporter: Thorsten Meinl >Assignee: Tibor Digana > > After switching from Surefire 2.18.1 to 2.19 our tests under Windows have > stopped working (Linux and Mac are still running fine). The only error > message is > Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on > project server.ejb: Error occurred in starting fork, check output in log -> > [Help 1] > (Full stacktrace below). > Is checked the log and even enabled full debug messages but there is not > indication whatsoever what the problem can be. Given that everything worked > perfectly fine until we switched to 2.19 this seems to be a bug in this > version. I'm happy to provide further details if you tell me what you need > and how I can acquire it. > === > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) > on project server.ejb: Error occurred in starting fork, check output in log > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.MojoFailureException: Error occurred in > starting fork, check output in log > at > org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:326) > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:316) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:880) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:739) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 19 more > Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: > Error occurred in starting fork, check output i
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024196#comment-15024196
]
Michael Osipov commented on MRELEASE-931:
-
Input? You mean output, don't you?
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024194#comment-15024194
]
Michael Osipov commented on MRELEASE-931:
-
.bq SSL certificate problem: self signed certificate in certificate chain
The problem is obviously not the cert...
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024194#comment-15024194
]
Michael Osipov edited comment on MRELEASE-931 at 11/24/15 10:18 AM:
bq. SSL certificate problem: self signed certificate in certificate chain
The problem is obviously not the cert...
was (Author: michael-o):
.bq SSL certificate problem: self signed certificate in certificate chain
The problem is obviously not the cert...
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1197) Surefire 2.19 breaks tests under Windows due to fork problem
[ https://issues.apache.org/jira/browse/SUREFIRE-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024079#comment-15024079 ] Thorsten Meinl commented on SUREFIRE-1197: -- Unfortunately your fix didn't resolve the issue. I also cannot send you the project because it's closed source code. I'm trying to isolate the problem with a minimal test but this may take a few days. Now that I have the source code I'm also happy to debug it. Do you have any pointers where to start? I also noticed that the fork error comes *after* all tests have run successfully. > Surefire 2.19 breaks tests under Windows due to fork problem > > > Key: SUREFIRE-1197 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1197 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.19 > Environment: Windows 7 >Reporter: Thorsten Meinl >Assignee: Tibor Digana > > After switching from Surefire 2.18.1 to 2.19 our tests under Windows have > stopped working (Linux and Mac are still running fine). The only error > message is > Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on > project server.ejb: Error occurred in starting fork, check output in log -> > [Help 1] > (Full stacktrace below). > Is checked the log and even enabled full debug messages but there is not > indication whatsoever what the problem can be. Given that everything worked > perfectly fine until we switched to 2.19 this seems to be a bug in this > version. I'm happy to provide further details if you tell me what you need > and how I can acquire it. > === > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) > on project server.ejb: Error occurred in starting fork, check output in log > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.MojoFailureException: Error occurred in > starting fork, check output in log > at > org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:326) > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:316) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:880) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:739) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 19 more > Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: > Error occurred in starting fork, check output in log > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:559) > at > org.apache.maven.plugin.surefire.booterclient.ForkStar
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024014#comment-15024014
]
Vasilii Ruzov commented on MRELEASE-931:
I don't want to see password in any input.
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024012#comment-15024012
]
Vasilii Ruzov commented on MRELEASE-931:
what do you mean by "incorrect"?
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024003#comment-15024003
]
Michael Osipov commented on MRELEASE-931:
-
Would even like to see the password in any output at all?
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-931) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/MRELEASE-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023982#comment-15023982
]
Michael Osipov commented on MRELEASE-931:
-
Have you noticed that the error shown by Git is incorrect?
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: MRELEASE-931
> URL: https://issues.apache.org/jira/browse/MRELEASE-931
> Project: Maven Release Plugin
> Issue Type: Bug
>Affects Versions: 2.5.3
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
