[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027200#comment-15027200
]
Tibor Digana commented on SUREFIRE-1198:
[~snicoll]
Is it now working for you?
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSITE-752) Cannot use server side includes.
Christian Schulte created MSITE-752:
---
Summary: Cannot use server side includes.
Key: MSITE-752
URL: https://issues.apache.org/jira/browse/MSITE-752
Project: Maven Site Plugin
Issue Type: Bug
Affects Versions: 3.4
Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
Java home: /usr/local/jdk-1.8.0/jre
Default locale: de_DE, platform encoding: UTF-8
Reporter: Christian Schulte
Please see the attached example project. The 'index.xml' document contains some
server side include directives. Executing 'mvn site', the server side includes
won't work as the comments have been processed in a way that
{code}
{code}
becomes
{code}
{code}
Note the extra space.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSITE-752) Cannot use server side includes.
[
https://issues.apache.org/jira/browse/MSITE-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MSITE-752:
Attachment: MSITE-752.zip
Example project demonstrating the issue. Unzip and execute 'mvn site'. The
'target/site/index.html' document contains the non working server side include
directives
{code}
{code}
> Cannot use server side includes.
>
>
> Key: MSITE-752
> URL: https://issues.apache.org/jira/browse/MSITE-752
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.4
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: /usr/local/jdk-1.8.0/jre
> Default locale: de_DE, platform encoding: UTF-8
>Reporter: Christian Schulte
> Attachments: MSITE-752.zip
>
>
> Please see the attached example project. The 'index.xml' document contains
> some server side include directives. Executing 'mvn site', the server side
> includes won't work as the comments have been processed in a way that
> {code}
>
> {code}
> becomes
> {code}
>
> {code}
> Note the extra space.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027545#comment-15027545
]
Vasilii Ruzov commented on SCM-811:
---
No sure, but now I switched to jgit scm provider and I don't see password
anymore.
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-git
>Affects Versions: 1.9.4
> 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] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027573#comment-15027573
]
Vasilii Ruzov commented on SCM-811:
---
Yes, you're right. I see password in line generated by git-client. I've done
some investigation and found that the message I see is the message from
ScmResult, where clean text password is in commandOutput field. So I think the
value of this field should be masked too
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-git
>Affects Versions: 1.9.4
> 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-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027647#comment-15027647
]
Stephane Nicoll commented on SUREFIRE-1198:
---
What do you mean? I confirm that if surefire allows to configure the jar to use
we are happy.
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027677#comment-15027677
]
Robert Scholte commented on SUREFIRE-1198:
--
So you want to test with another jar then the one being uploaded/deployed?
Sounds like an unnecessary hack to me. I suggest to attach a simple project
exposing the problem so we all understand the problem.
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
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=15027692#comment-15027692
]
Hudson commented on DOXIA-492:
--
SUCCESS: Integrated in axiom-trunk #2369 (See
[https://builds.apache.org/job/axiom-trunk/2369/])
Use DOXIA-492 to support snippets in Markdown. (veithen: rev 1716530)
* axiom
* axiom/pom.xml
* axiom/testing/xml-truth/src/site/markdown/index.md.vm
*
axiom/testing/xml-truth/src/test/java/org/apache/axiom/truth/xml/XMLSubjectTest.java
> 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] [Updated] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated SCM-811:
---
Component/s: maven-scm-provider-git
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-git
>Affects Versions: 1.9.4
> 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] [Moved] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte moved MRELEASE-931 to SCM-811:
-
Affects Version/s: (was: 2.5.3)
1.9.4
Issue Type: Improvement (was: Bug)
Key: SCM-811 (was: MRELEASE-931)
Project: Maven SCM (was: Maven Release Plugin)
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-git
>Affects Versions: 1.9.4
> 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] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027551#comment-15027551
]
Robert Scholte commented on SCM-811:
IIUC this line is just the output generated by the git client. You could parse
the output as well, but they are all too specific per SCM client, so you should
do it per type. If you've seen the code, you'll see there's no abstraction
layer to handle this.
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-git
>Affects Versions: 1.9.4
> 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-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027517#comment-15027517
]
Robert Scholte commented on SUREFIRE-1198:
--
I still think that everyone wants/expects (or should expect) the distributable
to be tested and I'm very willing to help solving related issues. So it seems
like the plugin must also decide if should use the adjusted pom.xml, that would
help, right?
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027554#comment-15027554
]
Tibor Digana commented on SUREFIRE-1198:
[~azgard]
If you use assembly plugin, do you attach and override the artifact file with
its default name? If you don't then two jars do not make sense since one of
them is not testable.
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Moved] (SUREFIRE-1199) mvn test classname issue
[ https://issues.apache.org/jira/browse/SUREFIRE-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-5936 to SUREFIRE-1199: --- Affects Version/s: (was: 3.0.5) Component/s: (was: Command Line) Key: SUREFIRE-1199 (was: MNG-5936) Project: Maven Surefire (was: Maven) > mvn test classname issue > > > Key: SUREFIRE-1199 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1199 > Project: Maven Surefire > Issue Type: Bug > 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] [Closed] (MNG-5938) How Maven solves the problem of long builds on large projects?
[ https://issues.apache.org/jira/browse/MNG-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5938. --- Resolution: Not A Problem Assignee: Robert Scholte Could you please use the [mailinglist|http://maven.apache.org/mail-lists.html] to ask these kind of questions. I wasn't aware that we have a type "question" in Jira, but you have more chance on an answer by using the mailinglist. > How Maven solves the problem of long builds on large projects? > -- > > Key: MNG-5938 > URL: https://issues.apache.org/jira/browse/MNG-5938 > Project: Maven > Issue Type: Question >Affects Versions: 3.0.4 >Reporter: Sergey Saraev >Assignee: Robert Scholte > > I am developing a project with 70+ modules. > Reassembly of the project may take 2 hours although usually commit change > only one module (run pmd + checkstyle + cobertura + findbugs + compile + > tests). > How Maven solves the problem of long builds on large projects? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027555#comment-15027555
]
Tibor Digana commented on SUREFIRE-1198:
More than fixing this issue I would say we would need to have ClassLoader for
war and ear due to currently only jar is supported in this feature. Maybe more
archive types..
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1198:
---
Comment: was deleted
(was: More than fixing this issue I would say we would need to have ClassLoader
for war and ear due to currently only jar is supported in this feature. Maybe
more archive types..)
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027556#comment-15027556
]
Tibor Digana commented on SUREFIRE-1198:
More than fixing this issue I would say we would need to have ClassLoader for
war and ear due to currently only jar is supported in this feature. Maybe more
archive types..
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027537#comment-15027537
]
Michael Osipov commented on SCM-811:
[~rfscholte], I think it is worthwhile to have a common approach to this in all
SCM providers.
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-git
>Affects Versions: 1.9.4
> 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-1194) reporter argument does not work for TestNG
[ https://issues.apache.org/jira/browse/SUREFIRE-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028253#comment-15028253 ] ASF GitHub Bot commented on SUREFIRE-1194: -- Github user Tibor17 commented on the pull request: https://github.com/apache/maven-surefire/pull/107#issuecomment-159816428 @juherr Can you add an integration test. I guess there is another API for reporter so that maybe we are missing one of them in our integration tests (testng 6.0). > reporter argument does not work for TestNG > -- > > Key: SUREFIRE-1194 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1194 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.19 >Reporter: Testo Nakada >Assignee: Tibor Digana > Fix For: 2.19.1 > > > TestNG plugin seems to map -reporter command line parameter to reporterslist > which was removed in TestNG project since 2010 > (a4779524b59330e98ee596c5faa43ae1b33ff844). Therefore, this configuration has > stopped working since then. The configuration mentioned in > http://maven.apache.org/surefire/maven-surefire-plugin/examples/testng.html#Using_Custom_Listeners_and_Reporters > does not work as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5939) Problem doing release when sources are generate as well
chibbe created MNG-5939: --- Summary: Problem doing release when sources are generate as well Key: MNG-5939 URL: https://issues.apache.org/jira/browse/MNG-5939 Project: Maven Issue Type: Bug Affects Versions: 3.3.9 Environment: Ubuntu 12.04.5 LTS Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00) Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) Java version: 1.7.0_76, vendor: Oracle Corporation Reporter: chibbe If I specified that sources should be generated with jar-no-fork goal https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . When doing a release with maven-release-plugin it will build the source again when useReleaseProfile is true (use the release profile that adds sources and javadocs to the released artifact). The outcome is that it will run with both jar and jar-no-fork and generate and deploy 2 -sources.jar artifacts, with same version. That makes the release build fails. The same behavior could be reproduced when running both jar and jar-no-fork goal between maven 3.2.1. and maven 3.3.9. Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip With maven 3.3.9 it uploads it 2 times : Uploaded: http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar (722 B at 15.3 KB/sec) Uploading: http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar 722/722 B -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chibbe updated MNG-5939: Attachment: foo.bar.zip Example project. Including logs from both maven 3.2.1 and 3.3.9 > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe > Attachments: foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chibbe updated MNG-5939: Description: If I specified that sources should be generated with jar-no-fork goal https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . When doing a release with maven-release-plugin it will build the source again when useReleaseProfile is true (use the release profile that adds sources and javadocs to the released artifact http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). The outcome is that it will run with both jar and jar-no-fork and generate and deploy 2 -sources.jar artifacts, with same version. That makes the release build fails. The same behavior could be reproduced when running both jar and jar-no-fork goal between maven 3.2.1. and maven 3.3.9. Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip With maven 3.3.9 it uploads it 2 times : Uploaded: http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar (722 B at 15.3 KB/sec) Uploading: http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar 722/722 B was: If I specified that sources should be generated with jar-no-fork goal https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . When doing a release with maven-release-plugin it will build the source again when useReleaseProfile is true (use the release profile that adds sources and javadocs to the released artifact). The outcome is that it will run with both jar and jar-no-fork and generate and deploy 2 -sources.jar artifacts, with same version. That makes the release build fails. The same behavior could be reproduced when running both jar and jar-no-fork goal between maven 3.2.1. and maven 3.3.9. Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip With maven 3.3.9 it uploads it 2 times : Uploaded: http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar (722 B at 15.3 KB/sec) Uploading: http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar 722/722 B > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe > Attachments: foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact > http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail
[
https://issues.apache.org/jira/browse/MSHADE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026892#comment-15026892
]
chibbe commented on MSHADE-195:
---
Also able to reproduce this behavior with maven 3.3.9 worked with maven 3.2.1.
maven-release-plugin:2.5.2
maven-source-plugin:2.4
But shouldn't this be a ticket for release maven-release-plugin or
maven-source-plugin.
> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
> Fix For: waiting-for-feedback, 2.4.3
>
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes
> the problem that Maven will install and deploy the same sources.jar file
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with
> maven-deploy-plugin it *fails the build*, because it tries to upload the
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project project: Failed to deploy artifacts: Could not transfer artifact
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file:
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and
> maven-shade-plugin both attaching the same sources.jar to the build, when
> only one of them should do it. This problem only happens with the sources jar
> and not the main artifact, so a trick similar to replacing the main artifact
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade
> plugin will find the sources and include them in the shaded sources jar, but
> the sources jar won't be attached to the build twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail
[
https://issues.apache.org/jira/browse/MSHADE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026892#comment-15026892
]
chibbe edited comment on MSHADE-195 at 11/25/15 3:05 PM:
-
Also able to reproduce this behavior with maven 3.3.9 worked with maven 3.2.1.
maven-release-plugin:2.5.2
maven-source-plugin:2.4
But shouldn't this be a issue for release maven-release-plugin or
maven-source-plugin.
was (Author: chibbe):
Also able to reproduce this behavior with maven 3.3.9 worked with maven 3.2.1.
maven-release-plugin:2.5.2
maven-source-plugin:2.4
But shouldn't this be a ticket for release maven-release-plugin or
maven-source-plugin.
> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
> Fix For: waiting-for-feedback, 2.4.3
>
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes
> the problem that Maven will install and deploy the same sources.jar file
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with
> maven-deploy-plugin it *fails the build*, because it tries to upload the
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project project: Failed to deploy artifacts: Could not transfer artifact
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file:
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and
> maven-shade-plugin both attaching the same sources.jar to the build, when
> only one of them should do it. This problem only happens with the sources jar
> and not the main artifact, so a trick similar to replacing the main artifact
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade
> plugin will find the sources and include them in the shaded sources jar, but
> the sources jar won't be attached to the build twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSHADE-195) createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail
[
https://issues.apache.org/jira/browse/MSHADE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026892#comment-15026892
]
chibbe edited comment on MSHADE-195 at 11/25/15 3:05 PM:
-
Also able to reproduce this behavior with maven 3.3.9 worked with maven 3.2.1.
maven-release-plugin:2.5.2
maven-source-plugin:2.4
But shouldn't this be a issue for maven-release-plugin or maven-source-plugin.
was (Author: chibbe):
Also able to reproduce this behavior with maven 3.3.9 worked with maven 3.2.1.
maven-release-plugin:2.5.2
maven-source-plugin:2.4
But shouldn't this be a issue for release maven-release-plugin or
maven-source-plugin.
> createSourcesJar with source:jar-no-fork causes sources.jar to be deployed
> twice, causing the build to fail
> ---
>
> Key: MSHADE-195
> URL: https://issues.apache.org/jira/browse/MSHADE-195
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.4
>Reporter: Esko Luontola
> Fix For: waiting-for-feedback, 2.4.3
>
> Attachments: MSHADE-195-example.zip
>
>
> The workaround described in https://issues.apache.org/jira/browse/MSHADE-120
> (i.e. running maven-source-plugin's jar-no-fork goal before shading) causes
> the problem that Maven will install and deploy the same sources.jar file
> twice:
> {noformat}
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> pricing-client ---
> [INFO] Installing xxx/pricing-client/target/pricing-client-0-SNAPSHOT.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.jar
> [INFO] Installing xxx/pricing-client/target/dependency-reduced-pom.xml to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT.pom
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> [INFO] Installing
> xxx/pricing-client/target/pricing-client-0-SNAPSHOT-sources.jar to
> xxx/pricing-client/0-SNAPSHOT/pricing-client-0-SNAPSHOT-sources.jar
> {noformat}
> With maven-install-plugin this doesn't matter that much, but with
> maven-deploy-plugin it *fails the build*, because it tries to upload the
> sources.jar twice to the Maven repository and _Nexus doesn't allow that_:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project project: Failed to deploy artifacts: Could not transfer artifact
> xxx.availability:availability-client:jar:sources:1.0.24 from/to xxx-releases
> (http://xxx/nexus/content/repositories/releases): Failed to transfer file:
> http://xxx/nexus/content/repositories/releases//availability/availability-client/1.0.24/availability-client-1.0.24-sources.jar.
> Return code is: 400, ReasonPhrase: Bad Request.
> {noformat}
> I'm suspecting this to be something like the maven-source-plugin and
> maven-shade-plugin both attaching the same sources.jar to the build, when
> only one of them should do it. This problem only happens with the sources jar
> and not the main artifact, so a trick similar to replacing the main artifact
> is needed also for the sources jar.
> h4. Workaround
> Configure maven-source-plugin with {{false}}. Then the shade
> plugin will find the sources and include them in the shaded sources jar, but
> the sources jar won't be attached to the build twice.
--
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=15027692#comment-15027692
]
Hervé Boutemy edited comment on DOXIA-492 at 11/26/15 6:59 AM:
---
SUCCESS: Integrated in axiom-trunk #2369 (See
[https://builds.apache.org/job/axiom-trunk/2369/])
Use DOXIA-492 to support snippets in Markdown. (veithen:
[r1716530|http://svn.apache.org/r1716530])
* axiom
* axiom/pom.xml
* axiom/testing/xml-truth/src/site/markdown/index.md.vm
*
axiom/testing/xml-truth/src/test/java/org/apache/axiom/truth/xml/XMLSubjectTest.java
was (Author: hudson):
SUCCESS: Integrated in axiom-trunk #2369 (See
[https://builds.apache.org/job/axiom-trunk/2369/])
Use DOXIA-492 to support snippets in Markdown. (veithen: rev 1716530)
* axiom
* axiom/pom.xml
* axiom/testing/xml-truth/src/site/markdown/index.md.vm
*
axiom/testing/xml-truth/src/test/java/org/apache/axiom/truth/xml/XMLSubjectTest.java
> 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] [Created] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
Stephane Nicoll created SUREFIRE-1198:
-
Summary: Failsafe does not allow to use target/classes anymore
Key: SUREFIRE-1198
URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
Project: Maven Surefire
Issue Type: Bug
Reporter: Stephane Nicoll
See [this Spring Boot
issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
anymore. Is there a reason why this behaviour was completely removed in favour
of only the jar file?
It would be nice if we had an option to chose between the two (defaulting to
the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
Robert Weiser created MNG-5937: -- Summary: Maven-Wrapper for unified project environments (analog the Gradle wrapper) Key: MNG-5937 URL: https://issues.apache.org/jira/browse/MNG-5937 Project: Maven Issue Type: Improvement Components: Command Line Reporter: Robert Weiser It would be nice to provide a wrapper for maven which behaves similarily to the wrapper Gradle has. This would allow projects to share Maven in a certain version along with some project-specific Maven options like for example the location of the user or the global settings files or the maximum java heap size to use. There already are projects on github (e.g.: https://github.com/takari/maven-wrapper) providing said feature, however it would be nice to have it developed and maintained by the very people providing us with the offical Maven release. Cheers, Robert -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5938) How Maven solves the problem of long builds on large projects?
[ https://issues.apache.org/jira/browse/MNG-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Saraev updated MNG-5938: --- Description: I am developing a project with 70+ modules. Reassembly of the project may take 2 hours although usually commit change only one module (run pmd + checkstyle + cobertura + findbugs + compile + tests). How Maven solves the problem of long builds on large projects? was: I am developing a project with 70+ modules. Reassembly of the project may take 2 hours although usually commit change only one module (run pmd + checkstyle + cobertura + findbugs + compile + tests). As Maven solves the problem of long builds on large projects? > How Maven solves the problem of long builds on large projects? > -- > > Key: MNG-5938 > URL: https://issues.apache.org/jira/browse/MNG-5938 > Project: Maven > Issue Type: Question >Affects Versions: 3.0.4 >Reporter: Sergey Saraev > > I am developing a project with 70+ modules. > Reassembly of the project may take 2 hours although usually commit change > only one module (run pmd + checkstyle + cobertura + findbugs + compile + > tests). > How Maven solves the problem of long builds on large projects? -- 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=15026423#comment-15026423 ] Michael Osipov commented on MNG-5904: - [~pbenedict], that is a good idea. Every older will yield to undefined behavior. > 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] [Reopened] (MNG-5936) mvn test classname issue
[ https://issues.apache.org/jira/browse/MNG-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Goik reopened MNG-5936: -- My humble apologies but I just reproduced the issue on two more systems: 1. A second Linux host using an 'unspoiled' user account 2. A Windows 8.1 System running both current (freshly installed) Maven 3.3.9 on top of Oracle JDK 1.8 Identical Symptom: Executing "mvn test" yields just one test but according to the doc it should be two. Excerpt from Maven output: ... --- T E S T S --- Running de.hdm_stuttgart.mi.testpiece.FunctionalTest This is from FunctionalTest (singular!). Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 So it clearly states that test methods being contained within class FunctionalTests do not get executed at all. Then merely renaming FunctionalTests to MyTest yields the expected behaviour: ... --- T E S T S --- Running de.hdm_stuttgart.mi.testpiece.MyTest This is from FunctionalTests (plural!). Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec Running de.hdm_stuttgart.mi.testpiece.FunctionalTest This is from FunctionalTest (singular!). Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Results : Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 There is no parent pom.xml or any sort of left over environment whatsoever on these two additional systems. > 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] [Comment Edited] (MNG-5904) Remove the whole Ant Build
[ https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026423#comment-15026423 ] Michael Osipov edited comment on MNG-5904 at 11/25/15 9:10 AM: --- [~pbenedict], that is a good idea. Every older version will result in undefined behavior. was (Author: michael-o): [~pbenedict], that is a good idea. Every older will yield to undefined behavior. > 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] (MNG-5938) How Maven solves the problem of long builds on large projects?
[ https://issues.apache.org/jira/browse/MNG-5938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Saraev updated MNG-5938: --- Summary: How Maven solves the problem of long builds on large projects? (was: As Maven solves the problem of long builds on large projects?) > How Maven solves the problem of long builds on large projects? > -- > > Key: MNG-5938 > URL: https://issues.apache.org/jira/browse/MNG-5938 > Project: Maven > Issue Type: Question >Affects Versions: 3.0.4 >Reporter: Sergey Saraev > > I am developing a project with 70+ modules. > Reassembly of the project may take 2 hours although usually commit change > only one module (run pmd + checkstyle + cobertura + findbugs + compile + > tests). > As Maven solves the problem of long builds on large projects? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5938) As Maven solves the problem of long builds on large projects?
Sergey Saraev created MNG-5938: -- Summary: As Maven solves the problem of long builds on large projects? Key: MNG-5938 URL: https://issues.apache.org/jira/browse/MNG-5938 Project: Maven Issue Type: Question Affects Versions: 3.0.4 Reporter: Sergey Saraev I am developing a project with 70+ modules. Reassembly of the project may take 2 hours although usually commit change only one module (run pmd + checkstyle + cobertura + findbugs + compile + tests). As Maven solves the problem of long builds on large projects? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAVADOC-329) Allow generation of empty javadoc JARs
[
https://issues.apache.org/jira/browse/MJAVADOC-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026584#comment-15026584
]
Vincent Massol commented on MJAVADOC-329:
-
Workaround:
{code}
org.apache.maven.plugins
maven-antrun-plugin
generate-resources
run
{code}
> Allow generation of empty javadoc JARs
> --
>
> Key: MJAVADOC-329
> URL: https://issues.apache.org/jira/browse/MJAVADOC-329
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Vincent Massol
>
> Here's my use case:
> * I want to be able to deploy my artifacts to Maven Central. There's a
> requirement that a javadoc jar exists for the arifact to deploy
> * However I have some maven modules of type packaging = jar that have java
> files but these files are located in an "internal" package (internal api that
> we don't expose to end users since it's not part of our public API contract)
> which we exclude from the javadoc generation
> The problem is that the javadoc plugin doesn't generate any JAR if there are
> no java files matching (even if I have other files such as a package.html
> file in my src/main/javadoc/* directories).
> I'd like it to be possible to generate an "empty" javadoc JAR containing only
> a package.html file for example.
> Thanks a lot
--
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=15026425#comment-15026425
]
Michael Osipov commented on MRELEASE-931:
-
I read it and understood. Just telling you that Git is giving your a wrong
error message.
> 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] [Updated] (MRELEASE-932) ReleaseFailureException of an artefact wich version as a property
[
https://issues.apache.org/jira/browse/MRELEASE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine updated MRELEASE-932:
-
Summary: ReleaseFailureException of an artefact wich version as a property
(was: The artifact requires a different version than what is found)
> ReleaseFailureException of an artefact wich version as a property
> -
>
> Key: MRELEASE-932
> URL: https://issues.apache.org/jira/browse/MRELEASE-932
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5.1, 2.5.3
> Environment: Maven 3.2.1
> Windows 7
> Intel Core i7
>Reporter: Antoine
> Labels: bug
>
> After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
> the following exception:
> {quote}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
> project ping-parent: The artifact (com.mycompagny.myapp:myapp-client)
> requires a different version (15.4.0) than what is found (12.2.1) for the
> expression (version.client.tested) in the project
> (com.mycompagny.myapp:myapp-client).
> cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
> version (15.4.0) than what is found (12.2.1) for the expression
> (version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare
> (default-cli) on project ping-parent: The artifact
> (fr.generali.gael.ping:ping-injection-client) requires a different version
> (15.4.1-git) than what is found (15.4.0) for the expression
> (version.client.tested) in the project
> (fr.generali.gael.ping:ping-client-test).
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> 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
> {quote}
> This error happens in a multi-module application.
> For testing purpose, we depends from an older version of an artefact of the
> same application.
> When the artefact version is an expression (ie. ${version.client.tested}),
> the _AbstractRewritePomsPhase_ class do a chek.
> If we don't use the expression (i.e. properties), the release is working.
> Maven configuration that fails:
> {code}
>
> 12.1.0
>
>
> ${project.groupId}
> myapp-client
> ${version.client.tested}
>
> {code}
> Maven configuration that is working:
> {code}
>
> ${project.groupId}
> myapp-client
> 12.1.0
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026669#comment-15026669 ] Jason van Zyl commented on MNG-5937: It is developed by the people who do the Maven releases. That would be me. > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MRELEASE-932) ReleaseFailureException of an artefact wich version as a property
[
https://issues.apache.org/jira/browse/MRELEASE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine updated MRELEASE-932:
-
Description:
After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
the following exception:
{quote}
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (com.mycompagny.myapp:myapp-client) requires
a different version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (fr.generali.gael.ping:ping-injection-client)
requires a different version (15.4.1-git) than what is found (15.4.0) for the
expression (version.client.tested) in the project
(fr.generali.gael.ping:ping-client-test).
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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
{quote}
This error happens in a multi-module application.
For testing purpose, we depends from an older version of an artefact of the
same application.
When the artefact version is an expression (ie. $\{version.client.tested\}),
the _AbstractRewritePomsPhase_ class do a chek.
If we don't use the expression (i.e. properties), the release is working.
Maven configuration that fails:
{code}
12.1.0
${project.groupId}
myapp-client
${version.client.tested}
{code}
Maven configuration that is working:
{code}
${project.groupId}
myapp-client
12.1.0
{code}
was:
After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
the following exception:
{quote}
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (com.mycompagny.myapp:myapp-client) requires
a different version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (fr.generali.gael.ping:ping-injection-client)
requires a different version (15.4.1-git) than what is found (15.4.0) for the
expression (version.client.tested) in the project
(fr.generali.gael.ping:ping-client-test).
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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
{quote}
This error happens in a multi-module application.
For testing purpose, we depends from an older version of an artefact of the
same application.
When the artefact version is an expression (ie. ${version.client.tested}), the
_AbstractRewritePomsPhase_ class do a chek.
If we don't use the expression (i.e. properties), the release is working.
Maven configuration that fails:
{code}
12.1.0
${project.groupId}
myapp-client
${version.client.tested}
{code}
Maven configuration that is working:
{code}
${project.groupId}
myapp-client
12.1.0
{code}
> ReleaseFailureException of an artefact wich version as a property
> -
>
> Key: MRELEASE-932
> URL: https://issues.apache.org/jira/browse/MRELEASE-932
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5.1, 2.5.3
> Environment: Maven 3.2.1
> Windows 7
> Intel Core i7
>Reporter: Antoine
> Labels: bug
>
> After updating the release maven plugin from version 2.0.0 to
[jira] [Commented] (SUREFIRE-859) Exception in thread "TreadedStreamConsumer" java.lang.RuntimeException during GC
[ https://issues.apache.org/jira/browse/SUREFIRE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026674#comment-15026674 ] ASF GitHub Bot commented on SUREFIRE-859: - Github user Tibor17 commented on the pull request: https://github.com/apache/incubator-brooklyn/pull/1068#issuecomment-159588763 In Surefire 2.19 the prefix "SUREFIRE-859: " was removed. > Exception in thread "TreadedStreamConsumer" java.lang.RuntimeException during > GC > > > Key: SUREFIRE-859 > URL: https://issues.apache.org/jira/browse/SUREFIRE-859 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin, > process forking >Affects Versions: 2.11, 2.12 > Environment: Solaris 5.10, jdk16-1.6.0_11-0 (same with jdk1.5.0_14), > apache-maven-2.2.1 >Reporter: Magnus Naeslund >Assignee: Tibor Digana > Fix For: 2.18.1 > > Attachments: runtimeexception.txt > > > When executing 151 integration tests with 829 test methods on a Solaris > machine, there is an exception: > === > Exception in thread "ThreadStreamConsumer" java.lang.RuntimeException: 176: > [GC 100,177: [ParNew > ... > java.langh.RuntimeException: The forked VM terminated without saying properly > goodbye. VM crash or System.exit called ? > === > (see attachment for full stack traces) > The message of the RuntimeException suggests that the problem is connected to > garbage collection. The stack trace points to ForkClient.java. It looks as if > the method "consumeLine" in ForkClient.java is fed with GC information > instead of the expected string. > The exception occurs with concurrency configuration "parallel='none'" as well > as with "parallel='classes'" in both versions of the surefire plugin, 2.11 > and 2.12. > However, this problem does not show up on a Windows/Cygwin environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026683#comment-15026683 ] Robert Weiser commented on MNG-5937: Shame on me - I should have taken the time to check the official members list. Are there any plans to provide the maven-wrapper as an additional download alternative? > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MRELEASE-932) The artifact requires a different version than what is found
Antoine created MRELEASE-932:
Summary: The artifact requires a different version than what is
found
Key: MRELEASE-932
URL: https://issues.apache.org/jira/browse/MRELEASE-932
Project: Maven Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.5.3, 2.5.1
Environment: Maven 3.2.1
Windows 7
Intel Core i7
Reporter: Antoine
After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
the following exception:
{quote}
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (com.mycompagny.myapp:myapp-client) requires
a different version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (fr.generali.gael.ping:ping-injection-client)
requires a different version (15.4.1-git) than what is found (15.4.0) for the
expression (version.client.tested) in the project
(fr.generali.gael.ping:ping-client-test).
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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
{quote}
This error happens in a multi-module application.
For testing purpose, we depends from an older version of an artefact of the
same application.
When the artefact version is an expression (ie. ${version.client.tested}), the
_AbstractRewritePomsPhase_ class do a chek.
If we don't use the expression (i.e. properties), the release is working.
Maven configuration that fails:
{code}
12.1.0
${project.groupId}
myapp-client
${version.client.tested}
{code}
Maven configuration that is working:
{code}
${project.groupId}
myapp-client
12.1.0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MRELEASE-932) ReleaseFailureException of an artefact wich version as a property
[
https://issues.apache.org/jira/browse/MRELEASE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine updated MRELEASE-932:
-
Description:
After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
the following exception:
{quote}
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (com.mycompagny.myapp:myapp-client) requires
a different version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (fr.generali.gael.ping:ping-injection-client)
requires a different version (15.4.1-git) than what is found (15.4.0) for the
expression (version.client.tested) in the project
(fr.generali.gael.ping:ping-client-test).
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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
{quote}
This error happens in a multi-module application.
For testing purpose, we depends from an older version of an artefact of the
same application.
When the artefact version is an expression (ie. $\{version.client.tested\}),
the
[AbstractRewritePomsPhase|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.release/maven-release-manager/2.5.1/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java/#545]
class do a chek.
If we don't use the expression (i.e. properties), the release is working.
Maven configuration that fails:
{code}
12.1.0
${project.groupId}
myapp-client
${version.client.tested}
{code}
Maven configuration that is working:
{code}
${project.groupId}
myapp-client
12.1.0
{code}
was:
After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
the following exception:
{quote}
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (com.mycompagny.myapp:myapp-client) requires
a different version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
version (15.4.0) than what is found (12.2.1) for the expression
(version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
project ping-parent: The artifact (fr.generali.gael.ping:ping-injection-client)
requires a different version (15.4.1-git) than what is found (15.4.0) for the
expression (version.client.tested) in the project
(fr.generali.gael.ping:ping-client-test).
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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
{quote}
This error happens in a multi-module application.
For testing purpose, we depends from an older version of an artefact of the
same application.
When the artefact version is an expression (ie. $\{version.client.tested\}),
the _AbstractRewritePomsPhase_ class do a chek.
If we don't use the expression (i.e. properties), the release is working.
Maven configuration that fails:
{code}
12.1.0
${project.groupId}
myapp-client
${version.client.tested}
{code}
Maven configuration that is working:
{code}
${project.groupId}
myapp-client
12.1.0
{code}
> ReleaseFailureException of an artefact wich version as a property
> -
>
> Key: MRELEASE-932
> URL: https://issues.apache.org/jira/browse/MRELEASE-932
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5.1, 2.5.3
>
[jira] [Commented] (SUREFIRE-859) Exception in thread "TreadedStreamConsumer" java.lang.RuntimeException during GC
[ https://issues.apache.org/jira/browse/SUREFIRE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026621#comment-15026621 ] ASF GitHub Bot commented on SUREFIRE-859: - Github user m4rkmckenna commented on the pull request: https://github.com/apache/incubator-brooklyn/pull/1068#issuecomment-159575709 From having run locally I get the below log ... no failure but `GC (Allocation Failure)` is interesting can any one shed any light on this? From what i understand java is trying to allocate memory and failing so GC is kicking in (this may be unrelated) ``` 2015-11-25 10:46:45,697 INFO TESTNG PASSED: "Surefire test" - org.apache.brooklyn.rest.client.BrooklynApiRestClientTest.testLocationApi() finished in 8 ms 2015-11-25 10:46:45,698 INFO TESTNG INVOKING CONFIGURATION: "Surefire test" - @AfterClass org.apache.brooklyn.rest.client.BrooklynApiRestClientTest.tearDown() SUREFIRE-859: [GC (Allocation Failure) 217399K->33627K(753664K), 0.0062667 secs] SUREFIRE-859: [GC (Allocation Failure) 230235K->45522K(755712K), 0.0161661 secs] SUREFIRE-859: [GC (Allocation Failure) 255442K->63523K(760320K), 0.0228548 secs] SUREFIRE-859: [GC (Allocation Failure) 273443K->77064K(726528K), 0.0192347 secs] SUREFIRE-859: [GC (Allocation Failure) 253192K->88147K(729088K), 0.0135007 secs] SUREFIRE-859: [GC (Allocation Failure) 264275K->88834K(743424K), 0.0113851 secs] SUREFIRE-859: [GC (Allocation Failure) 264450K->89195K(742912K), 0.0091640 secs] 2015-11-25 10:46:47,978 INFO TESTNG PASSED CONFIGURATION: "Surefire test" - @AfterClass org.apache.brooklyn.rest.client.BrooklynApiRestClientTest.tearDown() finished in 2281 ms ``` > Exception in thread "TreadedStreamConsumer" java.lang.RuntimeException during > GC > > > Key: SUREFIRE-859 > URL: https://issues.apache.org/jira/browse/SUREFIRE-859 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin, > process forking >Affects Versions: 2.11, 2.12 > Environment: Solaris 5.10, jdk16-1.6.0_11-0 (same with jdk1.5.0_14), > apache-maven-2.2.1 >Reporter: Magnus Naeslund >Assignee: Tibor Digana > Fix For: 2.18.1 > > Attachments: runtimeexception.txt > > > When executing 151 integration tests with 829 test methods on a Solaris > machine, there is an exception: > === > Exception in thread "ThreadStreamConsumer" java.lang.RuntimeException: 176: > [GC 100,177: [ParNew > ... > java.langh.RuntimeException: The forked VM terminated without saying properly > goodbye. VM crash or System.exit called ? > === > (see attachment for full stack traces) > The message of the RuntimeException suggests that the problem is connected to > garbage collection. The stack trace points to ForkClient.java. It looks as if > the method "consumeLine" in ForkClient.java is fed with GC information > instead of the expected string. > The exception occurs with concurrency configuration "parallel='none'" as well > as with "parallel='classes'" in both versions of the surefire plugin, 2.11 > and 2.12. > However, this problem does not show up on a Windows/Cygwin environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-859) Exception in thread "TreadedStreamConsumer" java.lang.RuntimeException during GC
[ https://issues.apache.org/jira/browse/SUREFIRE-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026627#comment-15026627 ] ASF GitHub Bot commented on SUREFIRE-859: - Github user neykov commented on the pull request: https://github.com/apache/incubator-brooklyn/pull/1068#issuecomment-159577361 @m4rkmckenna It's unrelated. My understanding of the issue (https://issues.apache.org/jira/browse/SUREFIRE-859) is that surefire is consuming the output of the test process when it sees unexpected format, caused by verbose garbage collection (configured by us). So it will just print the unrecognized output as is. The output itself means that the garbage collector has kicked in because of a failure to allocate a buffer, giving some statistics about the gc run. Just ignore it. > Exception in thread "TreadedStreamConsumer" java.lang.RuntimeException during > GC > > > Key: SUREFIRE-859 > URL: https://issues.apache.org/jira/browse/SUREFIRE-859 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin, > process forking >Affects Versions: 2.11, 2.12 > Environment: Solaris 5.10, jdk16-1.6.0_11-0 (same with jdk1.5.0_14), > apache-maven-2.2.1 >Reporter: Magnus Naeslund >Assignee: Tibor Digana > Fix For: 2.18.1 > > Attachments: runtimeexception.txt > > > When executing 151 integration tests with 829 test methods on a Solaris > machine, there is an exception: > === > Exception in thread "ThreadStreamConsumer" java.lang.RuntimeException: 176: > [GC 100,177: [ParNew > ... > java.langh.RuntimeException: The forked VM terminated without saying properly > goodbye. VM crash or System.exit called ? > === > (see attachment for full stack traces) > The message of the RuntimeException suggests that the problem is connected to > garbage collection. The stack trace points to ForkClient.java. It looks as if > the method "consumeLine" in ForkClient.java is fed with GC information > instead of the expected string. > The exception occurs with concurrency configuration "parallel='none'" as well > as with "parallel='classes'" in both versions of the surefire plugin, 2.11 > and 2.12. > However, this problem does not show up on a Windows/Cygwin environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026679#comment-15026679
]
Tibor Digana commented on SUREFIRE-1198:
Yes there was a reason. The Surefire fixed this as a bug in Version 2.19.
Without it unit test and integration test would not make any difference.
The life cycle:
compile
test
package
integration-test
verify
This means classes is tested in unit test
The package is tested in the integration tests.
May I close this issue?
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026712#comment-15026712
]
Conny Kreyßel commented on SUREFIRE-1198:
-
At first this sounds fully correct to me.
But in second you ignore that some plugins reassemble the jar (shade-plugin or
spring-boot-maven-plugin). That means in intergration tests is not the
"original" jar attached and used, but the "repackaged" jar.
If you use the repackaged jar in integration test, you have also the assigned
dependencies artifacts in classpath. This is really a bad situation.
Maybe the default should use the jar in intergration tests - but we should have
a swicth to disable this and use target/classes instead.
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026714#comment-15026714 ] Jason van Zyl commented on MNG-5937: At some point, it will most likely be integrated. I have a very long blog entry about why it's not. Along with Polyglot Maven and many of the other Takari extensions. Primary reasons are that I prefer the Github infrastructure, and in many cases users have contributed PRs and I can integrate them and release them an hour later because it's critical for that user. I simply can't do that at Apache and I believe it's a fundamental detractor. > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026848#comment-15026848
]
Tibor Digana commented on SUREFIRE-1198:
You can open a pull-request on GitHub and add parameter artifactName for
failsafe only.
We already have such things in AbstractSurefireMojo.
Notice that classes folder is taken anyway if non-jar achive is packaged. For
instance WAR file.
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026854#comment-15026854
]
Stephane Nicoll commented on SUREFIRE-1198:
---
Configuring the jar to use would work for us. I'll have a look.
> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
