[jira] (MEAR-168) Use build final name as default context root
[
https://jira.codehaus.org/browse/MEAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
José Volmei Dal Prá Junior updated MEAR-168:
Attachment: pom.xml
WebModule.java
I made the changes. Can anyone merge the files? Thanks.
> Use build final name as default context root
>
>
> Key: MEAR-168
> URL: https://jira.codehaus.org/browse/MEAR-168
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: all
>Reporter: José Volmei Dal Prá Junior
> Attachments: pom.xml, WebModule.java
>
>
> Sometimes we need to make some conventions when dealing with several modules.
> We need to use the "${project.build.finalName}" as the default "contextRoot"
> mapping.
> The suggestion is: make a global configuration parameter with name
> "mustUseBuildFinalNameAsDefaultWebContextRoot". If this is set to true then
> the "WebModule.getDefaultContextRoot" method must use the build final name as
> context root.
> The global configuration parameter should have false as default value.
> Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories contains other repository ids than requested
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320559#comment-320559
]
Stephen Connolly commented on MNG-5185:
---
Thinking about this some more, what users probably want is a way to mark
specific repository ids as offline.
Most of the cases where -Dmaven.legacyLocalRepository is required are, IMHO,
where the user is not connected to the corporate VPN and so resolution against
the corporate repo should not be attempted because it is "offline"
The "legacy" behaviour is really a global switch for all repositories, much
better IMHO is
{code}
-Dmaven.repositories.offline=central,java.net2,...
{code}
or
{code}
-Dmaven.repository.offline.central
-Dmaven.repository.offline.java.net2
{code}
Now it may not be possible to implement this way with the current Aether, but I
think this is more the solution we should be heading towards.
Another way would be to have a repository-status file on disk that contained
the list of repository id's and their on-line/off-line status... or even an
extension to allow querying... so that users could plug a vpn status detector
into their maven installation and have auto-just-works
> Improve "missing dependency" error message when _maven.repositories contains
> other repository ids than requested
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0.2, 3.0.3, 3.0.4
>Reporter: Mark Derricutt
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from remote repositories. Unfortunately, when "conflicts"
> arise ( GAV is cached in local repo, but POM has no matching repository id
> declared ), Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-434) Allow SVN provider to pick addition system properties per command to issue extra param like --force, etc
[ https://jira.codehaus.org/browse/SCM-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320560#comment-320560 ] Odd Vinje commented on SCM-434: --- Does this mean that the patch with system properties will be included for the 1.9. release? Or do we need a new patch where the issue is solved with parameters? > Allow SVN provider to pick addition system properties per command to issue > extra param like --force, etc > > > Key: SCM-434 > URL: https://jira.codehaus.org/browse/SCM-434 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn >Affects Versions: 1.1 >Reporter: Dan Tran > Fix For: 1.9 > > Attachments: SCM-434-2.diff, SCM-434.patch > > > here is a list of additional properties > svn.params applies to all svn commands > svn.export.params applies to export only > . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-434) Allow SVN provider to pick addition system properties per command to issue extra param like --force, etc
[ https://jira.codehaus.org/browse/SCM-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320564#comment-320564 ] Olivier Lamy commented on SCM-434: -- perso I would prefer Map of parameters but I didn't have time to work on that. > Allow SVN provider to pick addition system properties per command to issue > extra param like --force, etc > > > Key: SCM-434 > URL: https://jira.codehaus.org/browse/SCM-434 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-svn >Affects Versions: 1.1 >Reporter: Dan Tran > Fix For: 1.9 > > Attachments: SCM-434-2.diff, SCM-434.patch > > > here is a list of additional properties > svn.params applies to all svn commands > svn.export.params applies to export only > . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-171) Doxia Tools dead links
[ https://jira.codehaus.org/browse/MNGSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MNGSITE-171: Assignee: Olivier Lamy > Doxia Tools dead links > -- > > Key: MNGSITE-171 > URL: https://jira.codehaus.org/browse/MNGSITE-171 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Steven Swor >Assignee: Olivier Lamy > > The navigation bar for http://maven.apache.org/doxia/ includes a link to > http://maven.apache.org/doxia/doxia-tools/index.html under the "Developer > Docs" menu, but the link is broken. > On a related note (probably caused by the same issue), the link to the Book > Descriptor Reference from http://maven.apache.org/doxia/book/index.html is > dead (it links to > http://maven.apache.org/doxia/doxia-tools/doxia-book-renderer/book.html) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-171) Doxia Tools dead links
[ https://jira.codehaus.org/browse/MNGSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MNGSITE-171. Resolution: Fixed fixed > Doxia Tools dead links > -- > > Key: MNGSITE-171 > URL: https://jira.codehaus.org/browse/MNGSITE-171 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Steven Swor >Assignee: Olivier Lamy > > The navigation bar for http://maven.apache.org/doxia/ includes a link to > http://maven.apache.org/doxia/doxia-tools/index.html under the "Developer > Docs" menu, but the link is broken. > On a related note (probably caused by the same issue), the link to the Book > Descriptor Reference from http://maven.apache.org/doxia/book/index.html is > dead (it links to > http://maven.apache.org/doxia/doxia-tools/doxia-book-renderer/book.html) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-650) Problem with multiple executions of surefire within site plugin 3.0
[ https://jira.codehaus.org/browse/MSITE-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320570#comment-320570 ] Pierre Cardoso commented on MSITE-650: -- I have the same sort of problem in a project of mine (surefire with several executions, all fine with install, all wrong with site); I'm not sure it's really the same, so, without going into details now, I'll just add some comments : - For my project, the problem only happens with Maven 3 (it runs fine with Maven 2.2.1). - For my project, running "mvn -X" shows that something is wrong with the properties : properties of execution X override the defaults in execution Y (unless they are already explicitly declared in Y). Sorry if this is not very clear, I'm a bit short on time now. I'll try to have a look at the [#SUREFIRE-905] project to see if it's indeed the same problem as mine. Thanks. > Problem with multiple executions of surefire within site plugin 3.0 > --- > > Key: MSITE-650 > URL: https://jira.codehaus.org/browse/MSITE-650 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Kristian Rosenvold > > There is a test project attached to SUREFIRE-905 that has a total of 4 > executions of surefire, with different configuration for each. > When running "mvn clean install" inside this project, surefire gets executed > 4 times as expected. When running "mvn site" only the first execution gets > run, the last three get stopped by the configuration-checksum in surefire, > indicating they get executed with the *same* configuration as the default > execution. (Surefire creates a SHA1 hash of all the mojo parameters to avoid > re-running the same configuration, which is why I conclude the three > executions get the same configuration as the default config) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-707) Maven SCM should encode username and password in URL
[ https://jira.codehaus.org/browse/SCM-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320571#comment-320571 ] Christophe Furmaniak commented on SCM-707: -- Same problem for me. I have a '!' in my password and the release always fails. Besides the fact that the release fails, when the release is launched through jenkins, the password appears in cleartext in the logs even if the Mask Password is activated. > Maven SCM should encode username and password in URL > > > Key: SCM-707 > URL: https://jira.codehaus.org/browse/SCM-707 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git, maven-scm-provider-mercurial > (hg), maven-scm-provider-svn >Affects Versions: 1.8 >Reporter: Sebastien Deleuze > Fix For: 1.9 > > > When using SCM over http (tested in my case with Git), Maven SCM should > encode username and password before using them with URL. > In order to reproduce, try to create a release with Maven Release and a user > with a password containing @ character, it will fail. > Please find bellow cmd output : > [INFO] Executing: /bin/sh -c cd /DATA/jenkins/workspace/path && git push > http://username:*@git.forge/git/project/ master:master > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) > on project project: Unable to commit files > Provider message: > The git-push command failed. > Command output: > error: Couldn't resolve host '@***@git.forge' while accessing > http://username:*@git.forge/git/project/info/refs > fatal: HTTP request failed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-186) FileTabCharacter check not working
[
https://jira.codehaus.org/browse/MCHECKSTYLE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320572#comment-320572
]
Dipti Desai commented on MCHECKSTYLE-186:
-
Thanks for your help. I am still facing issues with it. I am not sure what I
could be doing wrong here.
{code}
org.apache.maven.plugins
maven-checkstyle-plugin
2.9.1
**/*.xml,**/*.java
${project.basedir}
checkstyle/kepler-checkstyle-config.xml
${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml
{code}
In the tag, I tried ${project.basedir} as well as
${project.parent.basedir} to make it look through all possible files but the
XMLs are still not being flagged for containing tabs. Do you see something that
I might be missing? Could you please help?
> FileTabCharacter check not working
> --
>
> Key: MCHECKSTYLE-186
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-186
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Reporter: Dipti Desai
>Priority: Minor
>
> The FileTabCharacter check doesnt seem to work. Below is my config:
> {code:xml}
>
> ..
> ..
>
>
>
>
>
> ..
> ..
>
> ..
> ..
>
>
> {code}
> I have my xml files - pom.xml and checkstyle config xml containing tabs but
> none of them are flagged as violations.
> Some additional info - my plugin config looks like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.9.1
>
>
> verify
>
> check
>
>
>
>
>
> checkstyle/kepler-checkstyle-config.xml
>
> ${project.parent.basedir}${file.separator}checkstyle/kepler-checkstyle-suppressions.xml
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories contains other repository ids than requested
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320576#comment-320576
]
Devin Reid commented on MNG-5185:
-
When I'm using a corporate repository, all maven artifact resolution gets
proxied through the corporate repository so the ability to turn off individual
repositories by id is of limited utility to users with that workflow because
they only have one repository id (configured as a mirror with
* in settings.xml).
What -Dmaven.legacyLocalRepository restores, for me at least, is the ability to
stage an offline build for a project on a connected box and then move the
project and the local repository to another box with no network access (and
likely no maven settings configuration) and still be able to build the project
in offline mode.
> Improve "missing dependency" error message when _maven.repositories contains
> other repository ids than requested
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0.2, 3.0.3, 3.0.4
>Reporter: Mark Derricutt
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from remote repositories. Unfortunately, when "conflicts"
> arise ( GAV is cached in local repo, but POM has no matching repository id
> declared ), Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories contains other repository ids than requested
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320577#comment-320577
]
Stephen Connolly commented on MNG-5185:
---
Your corporate repository has an ID, so when off-VPN you would just go
{code}
-Dmaven.repository.offline.corp-mirror
{code}
And then all your corporate artifacts will not be attempted to re-download...
oh that repo is missing... oh fail the build.
-Dmaven.legacyLocalRepository is just a hack on top of a hack, what I am
pointing is a solution to the first hack that removes the need for the second.
> Improve "missing dependency" error message when _maven.repositories contains
> other repository ids than requested
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0.2, 3.0.3, 3.0.4
>Reporter: Mark Derricutt
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from remote repositories. Unfortunately, when "conflicts"
> arise ( GAV is cached in local repo, but POM has no matching repository id
> declared ), Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-9) Missing checkout / stage directory problem
Benson Margulies created MSCMPUB-9: -- Summary: Missing checkout / stage directory problem Key: MSCMPUB-9 URL: https://jira.codehaus.org/browse/MSCMPUB-9 Project: maven-scm-publish-plugin Issue Type: Bug Reporter: Benson Margulies Using https://svn.apache.org/repos/asf/accumulo/trunk, I get a error that I can't explain. Is the plugin, in fact, broken? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-2:publish-scm (scm-publish) on project accumulo-trace: Configured content directory does not exist: /Users/benson/asf/accumulo/trace/target/staging -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-9) Missing checkout / stage directory problem
[ https://jira.codehaus.org/browse/MSCMPUB-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320583#comment-320583 ] Robert Scholte commented on MSCMPUB-9: -- I'm not sure if I had the same issue, but I struggled with my latest release untill I dicovered that this was probably my first release with svn-1.7. After cleaning my home-folder everything worked fine again. > Missing checkout / stage directory problem > --- > > Key: MSCMPUB-9 > URL: https://jira.codehaus.org/browse/MSCMPUB-9 > Project: maven-scm-publish-plugin > Issue Type: Bug >Reporter: Benson Margulies > > Using https://svn.apache.org/repos/asf/accumulo/trunk, I get a error that I > can't explain. Is the plugin, in fact, broken? > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-2:publish-scm > (scm-publish) on project accumulo-trace: Configured content directory does > not exist: /Users/benson/asf/accumulo/trace/target/staging -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-9) Missing checkout / stage directory problem
[ https://jira.codehaus.org/browse/MSCMPUB-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320584#comment-320584 ] Olivier Lamy commented on MSCMPUB-9: which command are you using ? For a multimodule : * mvn site * mvn site:stage * mvn scm-publish:publish-scm > Missing checkout / stage directory problem > --- > > Key: MSCMPUB-9 > URL: https://jira.codehaus.org/browse/MSCMPUB-9 > Project: maven-scm-publish-plugin > Issue Type: Bug >Reporter: Benson Margulies > > Using https://svn.apache.org/repos/asf/accumulo/trunk, I get a error that I > can't explain. Is the plugin, in fact, broken? > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-2:publish-scm > (scm-publish) on project accumulo-trace: Configured content directory does > not exist: /Users/benson/asf/accumulo/trace/target/staging -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-9) Missing checkout / stage directory problem
[ https://jira.codehaus.org/browse/MSCMPUB-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320584#comment-320584 ] Olivier Lamy edited comment on MSCMPUB-9 at 2/27/13 2:12 PM: - which command are you using ? For a multimodule : mvn site site:stage scm-publish:publish-scm was (Author: olamy): which command are you using ? For a multimodule : * mvn site * mvn site:stage * mvn scm-publish:publish-scm > Missing checkout / stage directory problem > --- > > Key: MSCMPUB-9 > URL: https://jira.codehaus.org/browse/MSCMPUB-9 > Project: maven-scm-publish-plugin > Issue Type: Bug >Reporter: Benson Margulies > > Using https://svn.apache.org/repos/asf/accumulo/trunk, I get a error that I > can't explain. Is the plugin, in fact, broken? > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-2:publish-scm > (scm-publish) on project accumulo-trace: Configured content directory does > not exist: /Users/benson/asf/accumulo/trace/target/staging -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-9) Missing checkout / stage directory problem
[ https://jira.codehaus.org/browse/MSCMPUB-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320585#comment-320585 ] Benson Margulies commented on MSCMPUB-9: mvn site followed by mvn site-deploy the failure is in the site-deploy run. I'll try your command line. > Missing checkout / stage directory problem > --- > > Key: MSCMPUB-9 > URL: https://jira.codehaus.org/browse/MSCMPUB-9 > Project: maven-scm-publish-plugin > Issue Type: Bug >Reporter: Benson Margulies > > Using https://svn.apache.org/repos/asf/accumulo/trunk, I get a error that I > can't explain. Is the plugin, in fact, broken? > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-2:publish-scm > (scm-publish) on project accumulo-trace: Configured content directory does > not exist: /Users/benson/asf/accumulo/trace/target/staging -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-707) Maven SCM should encode username and password in URL
[ https://jira.codehaus.org/browse/SCM-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320586#comment-320586 ] Robert Scholte commented on SCM-707: Don't confuse Jenkins logging with Maven logging! Maven can't know that your password was passed by Jenkins and even as masked password: for Maven it is just another key-value pair, provided by someone or something. > Maven SCM should encode username and password in URL > > > Key: SCM-707 > URL: https://jira.codehaus.org/browse/SCM-707 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git, maven-scm-provider-mercurial > (hg), maven-scm-provider-svn >Affects Versions: 1.8 >Reporter: Sebastien Deleuze > Fix For: 1.9 > > > When using SCM over http (tested in my case with Git), Maven SCM should > encode username and password before using them with URL. > In order to reproduce, try to create a release with Maven Release and a user > with a password containing @ character, it will fail. > Please find bellow cmd output : > [INFO] Executing: /bin/sh -c cd /DATA/jenkins/workspace/path && git push > http://username:*@git.forge/git/project/ master:master > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) > on project project: Unable to commit files > Provider message: > The git-push command failed. > Command output: > error: Couldn't resolve host '@***@git.forge' while accessing > http://username:*@git.forge/git/project/info/refs > fatal: HTTP request failed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-9) Missing checkout / stage directory problem
[ https://jira.codehaus.org/browse/MSCMPUB-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320587#comment-320587 ] Olivier Lamy commented on MSCMPUB-9: mvn site-deploy will work only for single module project. > Missing checkout / stage directory problem > --- > > Key: MSCMPUB-9 > URL: https://jira.codehaus.org/browse/MSCMPUB-9 > Project: maven-scm-publish-plugin > Issue Type: Bug >Reporter: Benson Margulies > > Using https://svn.apache.org/repos/asf/accumulo/trunk, I get a error that I > can't explain. Is the plugin, in fact, broken? > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-2:publish-scm > (scm-publish) on project accumulo-trace: Configured content directory does > not exist: /Users/benson/asf/accumulo/trace/target/staging -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-949) Create forkCount parameter
[
https://jira.codehaus.org/browse/SUREFIRE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316633#comment-316633
]
Andreas Gudian edited comment on SUREFIRE-949 at 2/27/13 4:16 PM:
--
We definitely need that. :)
but {{forkMode=perthread}} and {{forkCount=X}} still reads funny. I'd (again)
like to suggest -adding a new parameter {{fork}} (boolean)- (ignore that,
wasn't necessary). Together with {{reuseForks}} and {{forkCount}}, we should be
able to cover everything. We then declare {{forkMode}} as deprecated. WDYT?
was (Author: agudian):
We definitely need that. :)
but {{forkMode=perthread}} and {{forkCount=X}} still reads funny. I'd (again)
like to suggest adding a new parameter {{fork}} (boolean). Together with
{{reuseForks}} and {{forkCount}}, we should be able to cover everything. We
then declare {{forkMode}} as deprecated. WDYT?
> Create forkCount parameter
> --
>
> Key: SUREFIRE-949
> URL: https://jira.codehaus.org/browse/SUREFIRE-949
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 2.14
>
>
> The "threadCount" parameter is overloaded to the extent that it is becoming
> problematic. A forkCount parameter would be nice, maybe supporting the same
> style as maven-core "1.5C" for 1.5 x number of cores.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPDF-29) Improve figure scaling
[
https://jira.codehaus.org/browse/MPDF-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320601#comment-320601
]
Steven Swor commented on MPDF-29:
-
For SVG graphics exported from Google Docs, {{scale-to-fit}} seems to work
better than {{scale-down-to-fit}}. Otherwise the image can end up being really
tiny.
> Improve figure scaling
> --
>
> Key: MPDF-29
> URL: https://jira.codehaus.org/browse/MPDF-29
> Project: Maven 2.x PDF Plugin
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: 1.2
>
>
> From a private mail:
> Today, I found an extremely useful tip for how to get the images/graphics
> "right" both in HTML and PDF. As you know and write in the FAQ, there is a
> challenge with scaling the images, especially when using APT.
> I think it would be useful for others, if you could publish this tip on the
> site for the plugin.
> What I did was this:
> I made a copy of the original fo-styles.xslt, names it pdf-config.xml in my
> src/site/resources.
> Then I replaced the following section:
> {code:xml}
>
> auto
> auto
> auto
> auto
>
> {code}
> with this:
> {code:xml}
>
> scale-down-to-fit
> scale-down-to-fit
> 100%
> 100%
>
> {code}
>
> And VOILA, the scaling was perfect!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-403) add a "skip" configuration option to the dependency plugin
[ https://jira.codehaus.org/browse/MDEP-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-403: --- Fix Version/s: 2.7 Assignee: Brian Fox > add a "skip" configuration option to the dependency plugin > -- > > Key: MDEP-403 > URL: https://jira.codehaus.org/browse/MDEP-403 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: analyze >Affects Versions: 2.6 >Reporter: Henning Schmiedehausen >Assignee: Brian Fox > Fix For: 2.7 > > Attachments: maven-dependency-plugin-skip.patch > > > Most of the maven plugins have a skip configuration option that allows > skipping the execution. The dependency plugin has not. This patch adds this > configuration property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-403) add a "skip" configuration option to the dependency plugin
[ https://jira.codehaus.org/browse/MDEP-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-403. -- Resolution: Fixed patch applied > add a "skip" configuration option to the dependency plugin > -- > > Key: MDEP-403 > URL: https://jira.codehaus.org/browse/MDEP-403 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: analyze >Affects Versions: 2.6 >Reporter: Henning Schmiedehausen >Assignee: Brian Fox > Fix For: 2.7 > > Attachments: maven-dependency-plugin-skip.patch > > > Most of the maven plugins have a skip configuration option that allows > skipping the execution. The dependency plugin has not. This patch adds this > configuration property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-276) analyzer ignores project directories in a multi-module build
[ https://jira.codehaus.org/browse/MSHARED-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MSHARED-276. - Resolution: Fixed Fix Version/s: maven-dependency-analyzer-1.4 Assignee: Brian Fox > analyzer ignores project directories in a multi-module build > > > Key: MSHARED-276 > URL: https://jira.codehaus.org/browse/MSHARED-276 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer >Affects Versions: maven-dependency-analyzer-1.2, > maven-dependency-analyzer-1.3 >Reporter: Henning Schmiedehausen >Assignee: Brian Fox > Fix For: maven-dependency-analyzer-1.4 > > Attachments: DEP-399.patch > > > The dependency analyzer had a patch for MDEP-72 applied a long time ago which > in turn makes it ignore the local folders for a multimodule build. This > change restores this behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-399) Multi-module dependencies incorrectly marked as unused
[
https://jira.codehaus.org/browse/MDEP-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-399.
--
Resolution: Fixed
Fix Version/s: 2.7
Assignee: Brian Fox
> Multi-module dependencies incorrectly marked as unused
> --
>
> Key: MDEP-399
> URL: https://jira.codehaus.org/browse/MDEP-399
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.0-alpha-4, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1, 2.6
>Reporter: Tim Williamson
>Assignee: Brian Fox
> Fix For: 2.7
>
> Attachments: DEP-399.patch, mda-test.tar
>
>
> MDEP-72 made DefaultProjectDependencyAnalyzer.buildArtifactClassMap() only
> consider jar files, i.e.:
> {code}if ( file != null && file.getName().endsWith( ".jar" ) ){code}
> This causes it to ignore all classes defined in a submodule of a multi-module
> project. See the attached example. It has two submodules:
> - a, which defines an interface Foo
> - b, which defines a class FooImpl that implements Foo
> Running "mvn dependency:analyze" results in:
> {code}
> [WARNING] Unused declared dependencies found:
> [WARNING]com.example:a:jar:0.0.1-SNAPSHOT:compile
> {code}
> The following change fixes the issue:
> {code}if ( file != null && (file.getName().endsWith( ".jar" ) ||
> file.isDirectory()) ){code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-299) ClassNotFoundException when running jira-report using Maven 2.2.1
[
https://jira.codehaus.org/browse/MCHANGES-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies reassigned MCHANGES-299:
-
Assignee: Benson Margulies
> ClassNotFoundException when running jira-report using Maven 2.2.1
> -
>
> Key: MCHANGES-299
> URL: https://jira.codehaus.org/browse/MCHANGES-299
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira
>Affects Versions: 2.9
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_22
> Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
> Default locale: sv_SE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Dennis Lundberg
>Assignee: Benson Margulies
>
> When I try to build the site locally for the trunk of maven-changes-plugin
> itself using this command:
> {noformat}
> mvn site -Preporting
> {noformat}
> I get an exception when it is running changes:jira-report, see stack trace
> below. The result is an empty JIRA report.
> I have also tried with Java 1.6 + Maven 2.2.1 with the same results.
> Using Maven 3.0.4 on either Java 1.5 or Java 1.6 however successfully created
> the JIRA report.
> Searching on google I found this comment:
> bq. AFAIK, this happens when, jax-rs api jars cannot find the JAXRS impl
> classes. According to the spec, it get the impl class using a system
> property. If not found defaults to, com.sun.ws.rs.ext.RuntimeDelegateImpl.
> Does that mean that we have some JAXRS impl classes included in the class
> path when using Maven 3, but not when using Maven 2? If so, which jar do we
> need to add as a dependency to maven-changes-plugin to make it work with
> Maven 2 again?
> {noformat}
> [INFO] Generating "JIRA Report" report--- Maven Changes Report Plugin
> 2.9-SNAPSHOT
> Jan 3, 2013 9:35:39 AM org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean
> createWebClient
> SEVERE: java.lang.RuntimeException : java.lang.ClassNotFoundException:
> com.sun.ws.rs.ext.RuntimeDelegateImpl
> [WARNING]
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
> at
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean.createWebClient(JAXRSClientFactoryBean.java:217)
> at org.apache.cxf.jaxrs.client.WebClient.create(WebClient.java:91)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.setupWebClient(RestJiraDownloader.java:508)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:100)
> at
> org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
> at
> org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:302)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:221)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.mav
[jira] (MCHANGES-299) ClassNotFoundException when running jira-report using Maven 2.2.1
[
https://jira.codehaus.org/browse/MCHANGES-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320603#comment-320603
]
Benson Margulies commented on MCHANGES-299:
---
This is a classloading bug in maven 2.2. The class RuntimeDelegateImpl is
sitting right there in org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.6.3:compile,
where it works fine for everything else in creation. However, a guess occurs to
me about the state of the thread classloader, which I will now experiment with.
> ClassNotFoundException when running jira-report using Maven 2.2.1
> -
>
> Key: MCHANGES-299
> URL: https://jira.codehaus.org/browse/MCHANGES-299
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira
>Affects Versions: 2.9
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_22
> Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
> Default locale: sv_SE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Dennis Lundberg
>Assignee: Benson Margulies
>
> When I try to build the site locally for the trunk of maven-changes-plugin
> itself using this command:
> {noformat}
> mvn site -Preporting
> {noformat}
> I get an exception when it is running changes:jira-report, see stack trace
> below. The result is an empty JIRA report.
> I have also tried with Java 1.6 + Maven 2.2.1 with the same results.
> Using Maven 3.0.4 on either Java 1.5 or Java 1.6 however successfully created
> the JIRA report.
> Searching on google I found this comment:
> bq. AFAIK, this happens when, jax-rs api jars cannot find the JAXRS impl
> classes. According to the spec, it get the impl class using a system
> property. If not found defaults to, com.sun.ws.rs.ext.RuntimeDelegateImpl.
> Does that mean that we have some JAXRS impl classes included in the class
> path when using Maven 3, but not when using Maven 2? If so, which jar do we
> need to add as a dependency to maven-changes-plugin to make it work with
> Maven 2 again?
> {noformat}
> [INFO] Generating "JIRA Report" report--- Maven Changes Report Plugin
> 2.9-SNAPSHOT
> Jan 3, 2013 9:35:39 AM org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean
> createWebClient
> SEVERE: java.lang.RuntimeException : java.lang.ClassNotFoundException:
> com.sun.ws.rs.ext.RuntimeDelegateImpl
> [WARNING]
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
> at
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean.createWebClient(JAXRSClientFactoryBean.java:217)
> at org.apache.cxf.jaxrs.client.WebClient.create(WebClient.java:91)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.setupWebClient(RestJiraDownloader.java:508)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:100)
> at
> org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
> at
> org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:302)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:221)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
[jira] (MCHANGES-289) Please add support for HTTP digest authentication to the 'trac-report' plugin.
[ https://jira.codehaus.org/browse/MCHANGES-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MCHANGES-289. - Resolution: Fixed Fix Version/s: 2.9 1451102. > Please add support for HTTP digest authentication to the 'trac-report' plugin. > -- > > Key: MCHANGES-289 > URL: https://jira.codehaus.org/browse/MCHANGES-289 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: trac >Affects Versions: 2.8 >Reporter: Christian Schulte >Priority: Trivial > Fix For: 2.9 > > Attachments: MCHANGES-289.patch > > > Currently the 'trac-report' supports only basic HTTP authentication > transmitting clear-text credentials. The 'trac-report' should also support > the digest HTTP authentication scheme. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-299) ClassNotFoundException when running jira-report using Maven 2.2.1
[
https://jira.codehaus.org/browse/MCHANGES-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MCHANGES-299.
-
Resolution: Fixed
Fix Version/s: 2.9
1451101.
> ClassNotFoundException when running jira-report using Maven 2.2.1
> -
>
> Key: MCHANGES-299
> URL: https://jira.codehaus.org/browse/MCHANGES-299
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira
>Affects Versions: 2.9
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.5.0_22
> Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
> Default locale: sv_SE, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Dennis Lundberg
>Assignee: Benson Margulies
> Fix For: 2.9
>
>
> When I try to build the site locally for the trunk of maven-changes-plugin
> itself using this command:
> {noformat}
> mvn site -Preporting
> {noformat}
> I get an exception when it is running changes:jira-report, see stack trace
> below. The result is an empty JIRA report.
> I have also tried with Java 1.6 + Maven 2.2.1 with the same results.
> Using Maven 3.0.4 on either Java 1.5 or Java 1.6 however successfully created
> the JIRA report.
> Searching on google I found this comment:
> bq. AFAIK, this happens when, jax-rs api jars cannot find the JAXRS impl
> classes. According to the spec, it get the impl class using a system
> property. If not found defaults to, com.sun.ws.rs.ext.RuntimeDelegateImpl.
> Does that mean that we have some JAXRS impl classes included in the class
> path when using Maven 3, but not when using Maven 2? If so, which jar do we
> need to add as a dependency to maven-changes-plugin to make it work with
> Maven 2 again?
> {noformat}
> [INFO] Generating "JIRA Report" report--- Maven Changes Report Plugin
> 2.9-SNAPSHOT
> Jan 3, 2013 9:35:39 AM org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean
> createWebClient
> SEVERE: java.lang.RuntimeException : java.lang.ClassNotFoundException:
> com.sun.ws.rs.ext.RuntimeDelegateImpl
> [WARNING]
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
> at
> org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean.createWebClient(JAXRSClientFactoryBean.java:217)
> at org.apache.cxf.jaxrs.client.WebClient.create(WebClient.java:91)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.setupWebClient(RestJiraDownloader.java:508)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:100)
> at
> org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
> at
> org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:302)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:221)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.
[jira] (MPDF-8) Create one PDF from a multi module project
[
https://jira.codehaus.org/browse/MPDF-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320607#comment-320607
]
Steven Swor commented on MPDF-8:
Until this issue is resolved, here is a workaround. Essentially, it flattens
the site hierarchy, before running the PDF plugin, by copying the sources from
the parent and all child modules into a single folder.
In the parent's pom.xml:
{code:xml}
${project.build.directory}/pdf-aggregate
org.apache.maven.plugins
maven-resources-plugin
aggregate-pdf-sources
pre-site
copy-resources
${site.aggregate.dir}
src/site/
module1/src/site
site.xml
org.apache.maven.plugins
maven-pdf-plugin
1.2
${site.aggregate.dir}
{code}
This works well when the PDF plugin is configured to run as part of the site
phase. If not, simply run {{mvn pre-site pdf:pdf}}.
> Create one PDF from a multi module project
> --
>
> Key: MPDF-8
> URL: https://jira.codehaus.org/browse/MPDF-8
> Project: Maven 2.x PDF Plugin
> Issue Type: New Feature
>Reporter: Lukas Theussl
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
