[jira] Commented: (SUREFIRE-648) Make surefire plugin compatible with TestNG 5.14
[ http://jira.codehaus.org/browse/SUREFIRE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237477#action_237477 ] Stevo Slavic commented on SUREFIRE-648: --- Checked, with 5.14.2 it works well. Issue can be closed, not a bug in surefire/failsafe. Make surefire plugin compatible with TestNG 5.14 Key: SUREFIRE-648 URL: http://jira.codehaus.org/browse/SUREFIRE-648 Project: Maven Surefire Issue Type: Improvement Components: TestNG support Affects Versions: 2.6 Reporter: Stevo Slavic Attachments: testng-groups.zip Latest TestNG version surefire plugin is compatible with is 5.13.1. groups configuration option does not work with 5.14. Attached example [^testng-groups.zip] works well when testng version is configured to 5.13.1, and doesn't work as expected when testng version is configured to 5.14. Same applies to failsafe plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-604) bump com.oracle/ojdbc14 to 10.2.0.4.0
[ http://jira.codehaus.org/browse/MEV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237480#action_237480 ] Julien HENRY commented on MEV-604: -- There is a mistake on the repo: in the folder http://repo2.maven.org/maven2/com/oracle/ojdbc14/10.2.0.4.0/ we can find ojdbc14-10.2.0.3.0.pom (note the version mismatch). Could you please fix that. Thanks bump com.oracle/ojdbc14 to 10.2.0.4.0 - Key: MEV-604 URL: http://jira.codehaus.org/browse/MEV-604 Project: Maven Evangelism Issue Type: Improvement Reporter: Craig Assignee: Carlos Sanchez 10.2.0.4.0 has been released. It would be nice to have a pom in the repository for it. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-648) Make surefire plugin compatible with TestNG 5.14
[ http://jira.codehaus.org/browse/SUREFIRE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed SUREFIRE-648. - Resolution: Not A Bug Assignee: Brett Porter posted additional changes to the testng list, and updated the integration tests to make it easier to check. Make surefire plugin compatible with TestNG 5.14 Key: SUREFIRE-648 URL: http://jira.codehaus.org/browse/SUREFIRE-648 Project: Maven Surefire Issue Type: Improvement Components: TestNG support Affects Versions: 2.6 Reporter: Stevo Slavic Assignee: Brett Porter Attachments: testng-groups.zip Latest TestNG version surefire plugin is compatible with is 5.13.1. groups configuration option does not work with 5.14. Attached example [^testng-groups.zip] works well when testng version is configured to 5.13.1, and doesn't work as expected when testng version is configured to 5.14. Same applies to failsafe plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MLINKCHECK-8) Adding configuration for excludeLinks suppresses warnings
Adding configuration for excludeLinks suppresses warnings
-
Key: MLINKCHECK-8
URL: http://jira.codehaus.org/browse/MLINKCHECK-8
Project: Maven 2.x Linkcheck Plugin
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Dennis Lundberg
Here's the configuration I have:
{code}
profiles
profile
idlinkcheck/id
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-linkcheck-plugin/artifactId
version1.0.1/version
configuration
!-- Cannot use this, because it suppresses any warnings
excludedLinks
excludedLink../../../internt*/excludedLink
excludedLink../../../../internt*/excludedLink
/excludedLinks
--
!-- Show warnings for redirects --
httpFollowRedirectfalse/httpFollowRedirect
/configuration
/plugin
/plugins
/reporting
/profile
/profiles
{code}
If I uncomment the excludeLinks configuration I don't get any warnings about
redirects in the report. If I leave the configuration inside a comment I get
the expected warnings.
An example of a URL that produces a redirect warning is http://java.sun.com/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-604) bump com.oracle/ojdbc14 to 10.2.0.4.0
[ http://jira.codehaus.org/browse/MEV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237493#action_237493 ] Carlos Sanchez commented on MEV-604: Fixed. bump com.oracle/ojdbc14 to 10.2.0.4.0 - Key: MEV-604 URL: http://jira.codehaus.org/browse/MEV-604 Project: Maven Evangelism Issue Type: Improvement Reporter: Craig Assignee: Carlos Sanchez 10.2.0.4.0 has been released. It would be nice to have a pom in the repository for it. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-509) site-deploy with flat project layout generates wrong url
site-deploy with flat project layout generates wrong url
Key: MSITE-509
URL: http://jira.codehaus.org/browse/MSITE-509
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:deploy
Affects Versions: 2.1.1
Environment: windows, maven 2.2.1
Reporter: werner mueller
Priority: Minor
Attachments: flat-site-template.zip, screenshot.05-10-2010 13.19.04.png
The site plugin generates a wrong default url when executing the site-deploy
goal (the link pointing to the project.url?)
It is a bit weird the ${project.url} is referenced to calculate the relative
links. That was a but unexpected. The site deploy url often contains scp://
urls while project.url points to the web location. If we map subdomains to
projects this sort of never works as the site deploy url and the project-url
have no common url parts.
There is no configuration to adjust the flat layout for the site plugin?
I'll attach an example project and a screenshot.
There are similar issues reported with the breadcrumb navigation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-510) Sitemap generates wrong links to project overview pages
Sitemap generates wrong links to project overview pages
---
Key: MSITE-510
URL: http://jira.codehaus.org/browse/MSITE-510
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Lukas Theussl
The sitemap creates links {{file:///project-info.html}} and
{{file:///project-reports.html}} to the project-info and project-reports pages,
ie the links are absolute and not relative to the site root.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-205) jira 4 support
jira 4 support -- Key: MCHANGES-205 URL: http://jira.codehaus.org/browse/MCHANGES-205 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.3 Environment: Maven 2.2.1, Jira 4.1.2 Reporter: Frederic Priority: Critical Hello, we've just upgraded to the latest Jira version 4.1.2, and it seems as if the maven-changes-plugin can't handle Jira 4 (we had no problems before when using Jira 3.12.x). Now however, I receive the following lines in the log file. Note that the pid 1 is not correct for the active project. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\surefire-report.html [INFO] Generate Maven Surefire Report report. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\jira-report.html [INFO] Generate JIRA Report report. [DEBUG] JIRA lives at: http://jira.mycompany.be [DEBUG] The JIRA URL http://jira.mycompany.be/browse/PROJECTKEY doesn't include a pid, trying to extract it from JIRA. [DEBUG] Successfully reached JIRA. [DEBUG] Found the pid 1 at http://jira.mycompany.be/browse/PROJECTKEY [DEBUG] download jira issues from url http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [INFO] Downloading from JIRA at: http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [WARNING] Downloading from JIRA failed. Received: [400] So I seem to receive an http error where the server 400 indicating that the request is not valid. I assume Jira 4 URL's are different from previous Jira versions. Can you add Jira 4 support? I'd be glad to provide extra information if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-511) unavailable skin snapshot is used
unavailable skin snapshot is used - Key: MSITE-511 URL: http://jira.codehaus.org/browse/MSITE-511 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.1.1, 2.0.1, 2.0-beta-7 Environment: Apache Maven 2.0.11 (r909250; 2010-02-12 06:55:50+0100) Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Reporter: Michael Brackx Attachments: pom.xml mvn site fails with repository with disabled snapshots having snapshot skins. It seems the disabling of snapshots for the repository is not honored. example pom is attached error: [INFO] SiteToolException: ArtifactResolutionException: Unable to find skin Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.skins:maven-default-skin:jar:1.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), jboss-public (https://repository.jboss.org/nexus/content/groups/public) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MLINKCHECK-8) Adding configuration for excludeLinks suppresses warnings
[
http://jira.codehaus.org/browse/MLINKCHECK-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237506#action_237506
]
Lukas Theussl commented on MLINKCHECK-8:
Confirmed. It seems to be a problem with the link pattern matching inside
linkcheck as it works if you only put absolute URLs inside {{excludedLink}}.
Adding configuration for excludeLinks suppresses warnings
-
Key: MLINKCHECK-8
URL: http://jira.codehaus.org/browse/MLINKCHECK-8
Project: Maven 2.x Linkcheck Plugin
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Dennis Lundberg
Here's the configuration I have:
{code}
profiles
profile
idlinkcheck/id
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-linkcheck-plugin/artifactId
version1.0.1/version
configuration
!-- Cannot use this, because it suppresses any warnings
excludedLinks
excludedLink../../../internt*/excludedLink
excludedLink../../../../internt*/excludedLink
/excludedLinks
--
!-- Show warnings for redirects --
httpFollowRedirectfalse/httpFollowRedirect
/configuration
/plugin
/plugins
/reporting
/profile
/profiles
{code}
If I uncomment the excludeLinks configuration I don't get any warnings
about redirects in the report. If I leave the configuration inside a comment
I get the expected warnings.
An example of a URL that produces a redirect warning is http://java.sun.com/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-604) release:branch should take the commitByProject parameter into account
release:branch should take the commitByProject parameter into account --- Key: MRELEASE-604 URL: http://jira.codehaus.org/browse/MRELEASE-604 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Environment: Maven 2.2.1, Subversion 1.6, Windows, Java 1.6 Reporter: werner mueller The release:prepare goal allows to adjust tagging to a flat directory layout by using the 'commitByProject=true' confiuration option: http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#commitByProject This way the release:perform will add every module into the release tag. When using release:branch only the parent module is commited to the created branch. All sub-modules in the flat directory layout are ignored (or end up somewhere else?). The commitByProject option has no effect for branching. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-205) jira 4 support
[ http://jira.codehaus.org/browse/MCHANGES-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237510#action_237510 ] Frederic commented on MCHANGES-205: --- I've took a look at the html source, and I see where pid 1 comes from: a href=http://support.atlassian.com/secure/CreateIssue.jspa?issuetype=1pid=1;Report a problem/a jira 4 support -- Key: MCHANGES-205 URL: http://jira.codehaus.org/browse/MCHANGES-205 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.3 Environment: Maven 2.2.1, Jira 4.1.2 Reporter: Frederic Priority: Critical Hello, we've just upgraded to the latest Jira version 4.1.2, and it seems as if the maven-changes-plugin can't handle Jira 4 (we had no problems before when using Jira 3.12.x). Now however, I receive the following lines in the log file. Note that the pid 1 is not correct for the active project. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\surefire-report.html [INFO] Generate Maven Surefire Report report. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\jira-report.html [INFO] Generate JIRA Report report. [DEBUG] JIRA lives at: http://jira.mycompany.be [DEBUG] The JIRA URL http://jira.mycompany.be/browse/PROJECTKEY doesn't include a pid, trying to extract it from JIRA. [DEBUG] Successfully reached JIRA. [DEBUG] Found the pid 1 at http://jira.mycompany.be/browse/PROJECTKEY [DEBUG] download jira issues from url http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [INFO] Downloading from JIRA at: http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [WARNING] Downloading from JIRA failed. Received: [400] So I seem to receive an http error where the server 400 indicating that the request is not valid. I assume Jira 4 URL's are different from previous Jira versions. Can you add Jira 4 support? I'd be glad to provide extra information if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-579) No such command 'tag'
No such command 'tag' - Key: SCM-579 URL: http://jira.codehaus.org/browse/SCM-579 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-bazaar Affects Versions: 2.0 Environment: Maven 2.2.1, Java 1.6_21, Windows XP SP3 Reporter: Gergely Kiss The mvn release:prepare fails with the following error when trying to release a trunk checkout with bazaar: [ERROR] BUILD ERROR [INFO] [INFO] An error is occurred in the tag process: No such command 'tag'. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:165) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: org.apache.maven.shared.release.ReleaseExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:94) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:196) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:133) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:96) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:161) ... 19 more Caused by: org.apache.maven.scm.NoSuchCommandScmException: No such command 'tag'. at org.apache.maven.scm.provider.AbstractScmProvider.tag(AbstractScmProvider.java:677) at org.apache.maven.scm.provider.AbstractScmProvider.tag(AbstractScmProvider.java:671) at org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:89) ... 23 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-579) No such command 'tag'
[ http://jira.codehaus.org/browse/SCM-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237517#action_237517 ] Gergely Kiss commented on SCM-579: -- Maybe this is also important: the bazaar repository is hosted on a 'dumb' server (bzr+ssh), but is available through sftp. The developerConnection property looks like this: scm:bazaar:sftp://myu...@bazaarhost/srv/bzr/myproject/trunk No such command 'tag' - Key: SCM-579 URL: http://jira.codehaus.org/browse/SCM-579 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-bazaar Affects Versions: 2.0 Environment: Maven 2.2.1, Java 1.6_21, Windows XP SP3 Reporter: Gergely Kiss The mvn release:prepare fails with the following error when trying to release a trunk checkout with bazaar: [ERROR] BUILD ERROR [INFO] [INFO] An error is occurred in the tag process: No such command 'tag'. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:165) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: org.apache.maven.shared.release.ReleaseExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:94) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:196) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:133) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:96) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:161) ... 19 more Caused by: org.apache.maven.scm.NoSuchCommandScmException: No such command 'tag'. at org.apache.maven.scm.provider.AbstractScmProvider.tag(AbstractScmProvider.java:677) at org.apache.maven.scm.provider.AbstractScmProvider.tag(AbstractScmProvider.java:671) at org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:89) ... 23 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-414) Linkcheck: wrong pattern matching if excludedLink is a relative link
Linkcheck: wrong pattern matching if excludedLink is a relative link Key: DOXIA-414 URL: http://jira.codehaus.org/browse/DOXIA-414 Project: Maven Doxia Issue Type: Bug Affects Versions: 1.1 Reporter: Lukas Theussl See MLINKCHECK-8 for a test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-414) Linkcheck: wrong pattern matching if excludedLink is a relative link
[ http://jira.codehaus.org/browse/DOXIA-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-414. --- Resolution: Fixed Fix Version/s: 1.2 Assignee: Lukas Theussl Fixed in [r1004651|http://svn.apache.org/viewvc?rev=1004651view=rev]. Linkcheck: wrong pattern matching if excludedLink is a relative link Key: DOXIA-414 URL: http://jira.codehaus.org/browse/DOXIA-414 Project: Maven Doxia Issue Type: Bug Affects Versions: 1.1 Reporter: Lukas Theussl Assignee: Lukas Theussl Fix For: 1.2 See MLINKCHECK-8 for a test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MLINKCHECK-8) Adding configuration for excludeLinks suppresses warnings
[
http://jira.codehaus.org/browse/MLINKCHECK-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MLINKCHECK-8.
--
Resolution: Fixed
Fix Version/s: 1.1
Assignee: Lukas Theussl
Fixed with DOXIA-414. Please test.
Adding configuration for excludeLinks suppresses warnings
-
Key: MLINKCHECK-8
URL: http://jira.codehaus.org/browse/MLINKCHECK-8
Project: Maven 2.x Linkcheck Plugin
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Dennis Lundberg
Assignee: Lukas Theussl
Fix For: 1.1
Here's the configuration I have:
{code}
profiles
profile
idlinkcheck/id
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-linkcheck-plugin/artifactId
version1.0.1/version
configuration
!-- Cannot use this, because it suppresses any warnings
excludedLinks
excludedLink../../../internt*/excludedLink
excludedLink../../../../internt*/excludedLink
/excludedLinks
--
!-- Show warnings for redirects --
httpFollowRedirectfalse/httpFollowRedirect
/configuration
/plugin
/plugins
/reporting
/profile
/profiles
{code}
If I uncomment the excludeLinks configuration I don't get any warnings
about redirects in the report. If I leave the configuration inside a comment
I get the expected warnings.
An example of a URL that produces a redirect warning is http://java.sun.com/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4852) [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account
[Regression] Configuration of m-javadoc-p at reportSet level is not taken into
account
--
Key: MNG-4852
URL: http://jira.codehaus.org/browse/MNG-4852
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.0
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Reporter: Julien HENRY
In the JWebUnit project I am using Javadoc aggregation and I put configuration
at the reportSet level. But after upgrading to Maven 3 the configuration is
not taken into account. Moving the configuration to the top level/common
section works but may not be acceptable for all project especially when a
different configuration for each reportSet is needed.
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration
!-- What is put here is taken into account --
/configuration
reportSets
reportSet
idaggregate/id
configuration
!-- What is put here is NOT taken into account --
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
- with Maven 2 I am using m-site-p 2.1.1
- with Maven 3 I am using m-site-p 3.0-beta-2
I don't know if this is a M3 or a m-site-p regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-512) [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account
[
http://jira.codehaus.org/browse/MSITE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237523#action_237523
]
Benjamin Bentmann commented on MSITE-512:
-
The effective POM has the configuration:
{code:xml}
configuration
outputDirectoryD:\z - Kopie\target\site/outputDirectory
reportPlugins
reportPlugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration /
reportSets
reportSet
idaggregate/id
configuration
foobar/foo
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/reportPlugin
reportPlugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
/reportPlugin
/reportPlugins
/configuration
{code}
[Regression] Configuration of m-javadoc-p at reportSet level is not taken
into account
--
Key: MSITE-512
URL: http://jira.codehaus.org/browse/MSITE-512
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0-beta-2
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Reporter: Julien HENRY
In the JWebUnit project I am using Javadoc aggregation and I put
configuration at the reportSet level. But after upgrading to Maven 3 the
configuration is not taken into account. Moving the configuration to the top
level/common section works but may not be acceptable for all project
especially when a different configuration for each reportSet is needed.
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration
!-- What is put here is taken into account --
/configuration
reportSets
reportSet
idaggregate/id
configuration
!-- What is put here is NOT taken into account --
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
- with Maven 2 I am using m-site-p 2.1.1
- with Maven 3 I am using m-site-p 3.0-beta-2
I don't know if this is a M3 or a m-site-p regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MSITE-512) [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account
[
http://jira.codehaus.org/browse/MSITE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-4852 to MSITE-512:
--
Complexity: (was: Intermediate)
Affects Version/s: (was: 3.0)
3.0-beta-2
Key: MSITE-512 (was: MNG-4852)
Project: Maven 2.x Site Plugin (was: Maven 2 3)
[Regression] Configuration of m-javadoc-p at reportSet level is not taken
into account
--
Key: MSITE-512
URL: http://jira.codehaus.org/browse/MSITE-512
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0-beta-2
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Reporter: Julien HENRY
In the JWebUnit project I am using Javadoc aggregation and I put
configuration at the reportSet level. But after upgrading to Maven 3 the
configuration is not taken into account. Moving the configuration to the top
level/common section works but may not be acceptable for all project
especially when a different configuration for each reportSet is needed.
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration
!-- What is put here is taken into account --
/configuration
reportSets
reportSet
idaggregate/id
configuration
!-- What is put here is NOT taken into account --
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
- with Maven 2 I am using m-site-p 2.1.1
- with Maven 3 I am using m-site-p 3.0-beta-2
I don't know if this is a M3 or a m-site-p regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-495) project.getDependencyArtifacts() returns null under forked multimodule report execution
[ http://jira.codehaus.org/browse/MSITE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237526#action_237526 ] Brian Jackson commented on MSITE-495: - Just to close the loop, I confirm this is fixed for my problem project using Maven 3.0-RC3 project.getDependencyArtifacts() returns null under forked multimodule report execution --- Key: MSITE-495 URL: http://jira.codehaus.org/browse/MSITE-495 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 3.0-beta-1 Environment: Apache Maven 3.0-beta-2 (r983206; 2010-08-07 07:00:51-0400) Java version: 1.6.0_17 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x version: 10.5.8 arch: x86_64 Family: mac Reporter: Brian Jackson Assignee: Olivier Lamy Attachments: test.zip Running 'mvn install site' on the attached multimodule project results in the following exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on project test: failed to get Reports: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. NullPointerException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1:site (default-site) on project test: failed to get Reports at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:152) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:86) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:58) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:252) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:100) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:443) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:166) at org.apache.maven.cli.MavenCli.main(MavenCli.java:130) 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:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get Reports at org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:225) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:208) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:144) ... 19 more Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile (default) on project a: Execution default of goal org.codehaus.mojo:aspectj-maven-plugin:1.3:compile failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:87) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:79) at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:254) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:179) at
[jira] Commented: (ARCHETYPE-318) requiredProperty defaultValue not correctly filtered
[
http://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237528#action_237528
]
Krzysztof Cislo commented on ARCHETYPE-318:
---
It would be perfect if we can used not only pure variable but also other
Velocity syntax (as far as archetype is somehow based on Velocity).
E.g.: I want to set module name to generate exampled module with a class. I set
property wit h value test which is used for package name but for class name I
have to set Test so first letter has to be changed to upper case. Of course I
can use two properties but it is much easier for somebody who use my archetype
to set only one.
requiredProperty defaultValue not correctly filtered
Key: ARCHETYPE-318
URL: http://jira.codehaus.org/browse/ARCHETYPE-318
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0-alpha-5
Reporter: Jochen Ehret
Priority: Minor
In our archetype-metadata.xml we´ve defined a requiredProperty with a
default value like this:
requiredProperty key=subArtifactId
defaultValue${artifactId}.itest1/defaultValue
/requiredProperty
When we call archetype:generate and enter the parameters in interactive
mode everything works fine. But when we try to set the parameter
subArtifactId on the command line (mvn archetype:generate
-DsubArtifactId=xyz) or from an archetype.properties file, the value is
ignored. In the generated pom.xml the variable ${subArtifactId} is always
replaced with ${artifactId}.itest1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-205) jira 4 support
[ http://jira.codehaus.org/browse/MCHANGES-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237532#action_237532 ] Frederic commented on MCHANGES-205: --- I've done some extra tests, jira seems to be doing several redirects: (these are the redirects captured when I browse to the URL maven requests): GET http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=10141statusIds=6resolutionIds=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 Redirect to Location: IssueNavigator.jspa?view=rsspid=10141statusIds=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none GET http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=10141statusIds=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 Redirect to Location: IssueNavigator.jspa?view=rsspid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none GET http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 Redirect to Location: ../sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?pid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none http://jira.mycompany.be/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?pid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 200 OK I'm not sure if Maven will handle all these redirects. I'll try to put a proxy logger between Maven and Jira (or has maven a debug option for all network calls)? I guess Maven handles the redirects not corretly and hence result in the http 400 error code. jira 4 support -- Key: MCHANGES-205 URL: http://jira.codehaus.org/browse/MCHANGES-205 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.3 Environment: Maven 2.2.1, Jira 4.1.2 Reporter: Frederic Priority: Critical Hello, we've just upgraded to the latest Jira version 4.1.2, and it seems as if the maven-changes-plugin can't handle Jira 4 (we had no problems before when using Jira 3.12.x). Now however, I receive the following lines in the log file. Note that the pid 1 is not correct for the active project. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\surefire-report.html [INFO] Generate Maven Surefire Report report. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\jira-report.html [INFO] Generate JIRA Report report. [DEBUG] JIRA lives at: http://jira.mycompany.be [DEBUG] The JIRA URL http://jira.mycompany.be/browse/PROJECTKEY doesn't include a pid, trying to extract it from JIRA. [DEBUG] Successfully reached JIRA. [DEBUG] Found the pid 1 at http://jira.mycompany.be/browse/PROJECTKEY [DEBUG] download jira issues from url http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [INFO] Downloading from JIRA at: http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [WARNING] Downloading from JIRA failed. Received: [400] So I seem to receive an http error where the server 400 indicating that the request is not valid. I assume Jira 4 URL's are different from previous Jira versions. Can you add Jira 4 support? I'd be glad to provide extra information if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-205) jira 4 support
[ http://jira.codehaus.org/browse/MCHANGES-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237534#action_237534 ] Frederic commented on MCHANGES-205: --- After sniffing, I obtain exactly the same results, but the last call fails: SNIFFER GET /secure/IssueNavigator.jspa?view=rsspid=10141statusIds=6resolutionIds=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 Location: IssueNavigator.jspa?view=rsspid=10141statusIds=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none GET /secure/IssueNavigator.jspa?view=rsspid=10141statusIds=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 Location: IssueNavigator.jspa?view=rsspid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none GET /secure/IssueNavigator.jspa?view=rsspid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 Location: ../sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?pid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none GET /sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?pid=10141status=6resolution=1sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none HTTP/1.1 HTTP/1.1 400 , message: The value 'PROJECTKEY' does not exist for the field 'project'. Not quite sure how to continue now. jira 4 support -- Key: MCHANGES-205 URL: http://jira.codehaus.org/browse/MCHANGES-205 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.3 Environment: Maven 2.2.1, Jira 4.1.2 Reporter: Frederic Priority: Critical Hello, we've just upgraded to the latest Jira version 4.1.2, and it seems as if the maven-changes-plugin can't handle Jira 4 (we had no problems before when using Jira 3.12.x). Now however, I receive the following lines in the log file. Note that the pid 1 is not correct for the active project. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\surefire-report.html [INFO] Generate Maven Surefire Report report. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\jira-report.html [INFO] Generate JIRA Report report. [DEBUG] JIRA lives at: http://jira.mycompany.be [DEBUG] The JIRA URL http://jira.mycompany.be/browse/PROJECTKEY doesn't include a pid, trying to extract it from JIRA. [DEBUG] Successfully reached JIRA. [DEBUG] Found the pid 1 at http://jira.mycompany.be/browse/PROJECTKEY [DEBUG] download jira issues from url http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [INFO] Downloading from JIRA at: http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [WARNING] Downloading from JIRA failed. Received: [400] So I seem to receive an http error where the server 400 indicating that the request is not valid. I assume Jira 4 URL's are different from previous Jira versions. Can you add Jira 4 support? I'd be glad to provide extra information if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-205) jira 4 support
[ http://jira.codehaus.org/browse/MCHANGES-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237542#action_237542 ] Frederic commented on MCHANGES-205: --- Okay. Seems I'm not passing the correct authentication parameters anymore. Fixed that, and now it seems to work correctly. So one question is remaining: for almost all of our projects we are currently specifying the Jira URL in this format: http://jira.mycompany.be/browse/PROJECTKEY, which seemed to work correct before. However with Jira 4, the plugin is no longer capable of determining the project ID. So do we have to use another format which includes the jiraID, like this: http://jira.mycompany.be/BrowseProject.jspa?id=10141 . Or is there some way to keep the old format working ? jira 4 support -- Key: MCHANGES-205 URL: http://jira.codehaus.org/browse/MCHANGES-205 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.3 Environment: Maven 2.2.1, Jira 4.1.2 Reporter: Frederic Priority: Critical Hello, we've just upgraded to the latest Jira version 4.1.2, and it seems as if the maven-changes-plugin can't handle Jira 4 (we had no problems before when using Jira 3.12.x). Now however, I receive the following lines in the log file. Note that the pid 1 is not correct for the active project. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\surefire-report.html [INFO] Generate Maven Surefire Report report. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\jira-report.html [INFO] Generate JIRA Report report. [DEBUG] JIRA lives at: http://jira.mycompany.be [DEBUG] The JIRA URL http://jira.mycompany.be/browse/PROJECTKEY doesn't include a pid, trying to extract it from JIRA. [DEBUG] Successfully reached JIRA. [DEBUG] Found the pid 1 at http://jira.mycompany.be/browse/PROJECTKEY [DEBUG] download jira issues from url http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [INFO] Downloading from JIRA at: http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [WARNING] Downloading from JIRA failed. Received: [400] So I seem to receive an http error where the server 400 indicating that the request is not valid. I assume Jira 4 URL's are different from previous Jira versions. Can you add Jira 4 support? I'd be glad to provide extra information if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-604) bump com.oracle/ojdbc14 to 10.2.0.4.0
[ http://jira.codehaus.org/browse/MEV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237547#action_237547 ] Craig commented on MEV-604: --- 25 months to do a version bump? I'm impressed... luckily I wasn't really relying on this being resolved, and my project ended over a year ago. bump com.oracle/ojdbc14 to 10.2.0.4.0 - Key: MEV-604 URL: http://jira.codehaus.org/browse/MEV-604 Project: Maven Evangelism Issue Type: Improvement Reporter: Craig Assignee: Carlos Sanchez 10.2.0.4.0 has been released. It would be nice to have a pom in the repository for it. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-512) [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account
[
http://jira.codehaus.org/browse/MSITE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MSITE-512:
---
Assignee: Olivier Lamy
do you have a sample project ?
[Regression] Configuration of m-javadoc-p at reportSet level is not taken
into account
--
Key: MSITE-512
URL: http://jira.codehaus.org/browse/MSITE-512
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0-beta-2
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Reporter: Julien HENRY
Assignee: Olivier Lamy
In the JWebUnit project I am using Javadoc aggregation and I put
configuration at the reportSet level. But after upgrading to Maven 3 the
configuration is not taken into account. Moving the configuration to the top
level/common section works but may not be acceptable for all project
especially when a different configuration for each reportSet is needed.
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration
!-- What is put here is taken into account --
/configuration
reportSets
reportSet
idaggregate/id
configuration
!-- What is put here is NOT taken into account --
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
- with Maven 2 I am using m-site-p 2.1.1
- with Maven 3 I am using m-site-p 3.0-beta-2
I don't know if this is a M3 or a m-site-p regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-512) [Regression] Configuration of m-javadoc-p at reportSet level is not taken into account
[
http://jira.codehaus.org/browse/MSITE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237559#action_237559
]
Julien HENRY commented on MSITE-512:
You can try with JWebUnit trunk:
https://jwebunit.svn.sourceforge.net/svnroot/jwebunit/trunk/
But you have to configure a toolchains:
http://jwebunit.sourceforge.net/building-maven.html
Then run mvn clean site on the top level folder.
[Regression] Configuration of m-javadoc-p at reportSet level is not taken
into account
--
Key: MSITE-512
URL: http://jira.codehaus.org/browse/MSITE-512
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0-beta-2
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Reporter: Julien HENRY
Assignee: Olivier Lamy
In the JWebUnit project I am using Javadoc aggregation and I put
configuration at the reportSet level. But after upgrading to Maven 3 the
configuration is not taken into account. Moving the configuration to the top
level/common section works but may not be acceptable for all project
especially when a different configuration for each reportSet is needed.
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
configuration
!-- What is put here is taken into account --
/configuration
reportSets
reportSet
idaggregate/id
configuration
!-- What is put here is NOT taken into account --
/configuration
reports
reportaggregate/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
- with Maven 2 I am using m-site-p 2.1.1
- with Maven 3 I am using m-site-p 3.0-beta-2
I don't know if this is a M3 or a m-site-p regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4853) Make location of settings-security.xml configurable
Make location of settings-security.xml configurable
---
Key: MNG-4853
URL: http://jira.codehaus.org/browse/MNG-4853
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line
Reporter: Alexander Syedin
Priority: Minor
Are there any reasons why we can't specify name and location of the
settings-security.xml file exactly in the same we do with settings.xml?
It would be nice to be able to specify it from command line, like:
{code:none}
mvn -ss path/to/security-settings.xml
{code}
This is essential in some environments, where user don't have control over home
directory (like continuous integration farm, where each project may have it's
own settings, but not settings-security.xml).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-604) bump com.oracle/ojdbc14 to 10.2.0.4.0
[ http://jira.codehaus.org/browse/MEV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237566#action_237566 ] Carlos Sanchez commented on MEV-604: You can get you your money back mmm, no, you reported the issue in the wrong project, should be MAVENUPLOAD And it was uploaded 8 months ago bump com.oracle/ojdbc14 to 10.2.0.4.0 - Key: MEV-604 URL: http://jira.codehaus.org/browse/MEV-604 Project: Maven Evangelism Issue Type: Improvement Reporter: Craig Assignee: Carlos Sanchez 10.2.0.4.0 has been released. It would be nice to have a pom in the repository for it. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-509) site-deploy with flat project layout generates wrong url
[
http://jira.codehaus.org/browse/MSITE-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237568#action_237568
]
Dennis Lundberg commented on MSITE-509:
---
Which URL is wrong? Is it in the generated site?
What is the value of that URL and what value do you think it should have?
site-deploy with flat project layout generates wrong url
Key: MSITE-509
URL: http://jira.codehaus.org/browse/MSITE-509
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:deploy
Affects Versions: 2.1.1
Environment: windows, maven 2.2.1
Reporter: werner mueller
Priority: Minor
Attachments: flat-site-template.zip, screenshot.05-10-2010
13.19.04.png
The site plugin generates a wrong default url when executing the site-deploy
goal (the link pointing to the project.url?)
It is a bit weird the ${project.url} is referenced to calculate the relative
links. That was a but unexpected. The site deploy url often contains scp://
urls while project.url points to the web location. If we map subdomains to
projects this sort of never works as the site deploy url and the project-url
have no common url parts.
There is no configuration to adjust the flat layout for the site plugin?
I'll attach an example project and a screenshot.
There are similar issues reported with the breadcrumb navigation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element
Might be impossible to have empty strings in systemPropertyVariables element Key: SUREFIRE-649 URL: http://jira.codehaus.org/browse/SUREFIRE-649 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.6 Reporter: Laird Nelson Attachments: surefireEmptyStringIssue.tar.gz This stanza: systemProperties property nameemptyProperty/name value/value /property /systemProperties ...yields from System.getProperty(emptyProperty). This (supposedly better) stanza: systemPropertyVariables emptyProperty/emptyProperty /systemPropertyVariables ...yields null from System.getProperty(emptyProperty). A test case is attached that demonstrates the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-649) Might be impossible to have empty strings in systemPropertyVariables element
[ http://jira.codehaus.org/browse/SUREFIRE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237572#action_237572 ] Laird Nelson commented on SUREFIRE-649: --- I neglected to set the priority down from major, as the workaround is simply to continue to use the deprecated systemProperties stanza. My apologies. Might be impossible to have empty strings in systemPropertyVariables element Key: SUREFIRE-649 URL: http://jira.codehaus.org/browse/SUREFIRE-649 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.6 Reporter: Laird Nelson Attachments: surefireEmptyStringIssue.tar.gz This stanza: systemProperties property nameemptyProperty/name value/value /property /systemProperties ...yields from System.getProperty(emptyProperty). This (supposedly better) stanza: systemPropertyVariables emptyProperty/emptyProperty /systemPropertyVariables ...yields null from System.getProperty(emptyProperty). A test case is attached that demonstrates the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-511) unavailable skin snapshot is used
[ http://jira.codehaus.org/browse/MSITE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237573#action_237573 ] Dennis Lundberg commented on MSITE-511: --- I suggest that you contact the maintainer of the repository, because the skin artifact is only available there in the 1.1-SNAPSHOT version. See https://repository.jboss.org/nexus/content/groups/public/org/apache/maven/skins/maven-default-skin/maven-metadata.xml unavailable skin snapshot is used - Key: MSITE-511 URL: http://jira.codehaus.org/browse/MSITE-511 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-7, 2.0.1, 2.1.1 Environment: Apache Maven 2.0.11 (r909250; 2010-02-12 06:55:50+0100) Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Reporter: Michael Brackx Attachments: pom.xml mvn site fails with repository with disabled snapshots having snapshot skins. It seems the disabling of snapshots for the repository is not honored. example pom is attached error: [INFO] SiteToolException: ArtifactResolutionException: Unable to find skin Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.skins:maven-default-skin:jar:1.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), jboss-public (https://repository.jboss.org/nexus/content/groups/public) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4853) Make location of settings-security.xml configurable
[
http://jira.codehaus.org/browse/MNG-4853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237574#action_237574
]
Benjamin Bentmann commented on MNG-4853:
You should already be able to do so with the system property
{{settings.security}}.
Make location of settings-security.xml configurable
---
Key: MNG-4853
URL: http://jira.codehaus.org/browse/MNG-4853
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line
Reporter: Alexander Syedin
Priority: Minor
Are there any reasons why we can't specify name and location of the
settings-security.xml file exactly in the same we do with settings.xml?
It would be nice to be able to specify it from command line, like:
{code:none}
mvn -ss path/to/security-settings.xml
{code}
This is essential in some environments, where user don't have control over
home directory (like continuous integration farm, where each project may have
it's own settings, but not settings-security.xml).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-205) jira 4 support
[ http://jira.codehaus.org/browse/MCHANGES-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237575#action_237575 ] Dennis Lundberg commented on MCHANGES-205: -- If the plugin doesn't find the pid in the URL it will try to fetch it from JIRA. IIRC there is some parsing involved, that seems to be thrown off. I'll have a closer look. jira 4 support -- Key: MCHANGES-205 URL: http://jira.codehaus.org/browse/MCHANGES-205 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: jira-report Affects Versions: 2.3 Environment: Maven 2.2.1, Jira 4.1.2 Reporter: Frederic Priority: Critical Hello, we've just upgraded to the latest Jira version 4.1.2, and it seems as if the maven-changes-plugin can't handle Jira 4 (we had no problems before when using Jira 3.12.x). Now however, I receive the following lines in the log file. Note that the pid 1 is not correct for the active project. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\surefire-report.html [INFO] Generate Maven Surefire Report report. [DEBUG] Generating C:\javadev\prj\project\subproject\target\site\jira-report.html [INFO] Generate JIRA Report report. [DEBUG] JIRA lives at: http://jira.mycompany.be [DEBUG] The JIRA URL http://jira.mycompany.be/browse/PROJECTKEY doesn't include a pid, trying to extract it from JIRA. [DEBUG] Successfully reached JIRA. [DEBUG] Found the pid 1 at http://jira.mycompany.be/browse/PROJECTKEY [DEBUG] download jira issues from url http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [INFO] Downloading from JIRA at: http://jira.mycompany.be/secure/IssueNavigator.jspa?view=rsspid=1statusIds=1statusIds=3statusIds=4statusIds=5resolutionIds=1component=10106sorter/field=createdsorter/order=DESCsorter/field=prioritysorter/order=DESCtempMax=100reset=truedecorator=none [WARNING] Downloading from JIRA failed. Received: [400] So I seem to receive an http error where the server 400 indicating that the request is not valid. I assume Jira 4 URL's are different from previous Jira versions. Can you add Jira 4 support? I'd be glad to provide extra information if needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4854) [regression] ProjectSorter neglects conflicted versions
[regression] ProjectSorter neglects conflicted versions
---
Key: MNG-4854
URL: http://jira.codehaus.org/browse/MNG-4854
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0-alpha-6
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 12:50:56+0100)
Java version: 1.5.0_22
Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: windows xp version: 5.2 arch: x86 Family: windows
Reporter: Mark Hobson
[ProjectSorter|http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java]
skips vertexes where versions don't match and thus produces incorrect results.
For example, if A depends on B:1.0 but B is resolved to 1.1 (via conflict
resolution or dependency management) then A-B:1.0 is lost. One suspect could
be {{isSpecificVersion}} which returns true for 1.0, which isn't a specific
version like [1.0], so this vertex gets lost as B:1.0 doesn't exist.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4854) [regression] ProjectSorter neglects conflicted versions
[
http://jira.codehaus.org/browse/MNG-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hobson updated MNG-4854:
-
Attachment: MNG-4854-test.patch
Attached test method patch to demonstrate problem.
[regression] ProjectSorter neglects conflicted versions
---
Key: MNG-4854
URL: http://jira.codehaus.org/browse/MNG-4854
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0-alpha-6
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 12:50:56+0100)
Java version: 1.5.0_22
Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: windows xp version: 5.2 arch: x86 Family: windows
Reporter: Mark Hobson
Attachments: MNG-4854-test.patch
[ProjectSorter|http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java]
skips vertexes where versions don't match and thus produces incorrect
results.
For example, if A depends on B:1.0 but B is resolved to 1.1 (via conflict
resolution or dependency management) then A-B:1.0 is lost. One suspect
could be {{isSpecificVersion}} which returns true for 1.0, which isn't a
specific version like [1.0], so this vertex gets lost as B:1.0 doesn't exist.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4854) [regression] ProjectSorter neglects conflicted versions
[
http://jira.codehaus.org/browse/MNG-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237582#action_237582
]
Mark Hobson edited comment on MNG-4854 at 10/5/10 4:01 PM:
---
Attached test method patch to demonstrate problem. This passes on the 2.2.x
branch.
was (Author: mihobson):
Attached test method patch to demonstrate problem.
[regression] ProjectSorter neglects conflicted versions
---
Key: MNG-4854
URL: http://jira.codehaus.org/browse/MNG-4854
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0-alpha-6
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 12:50:56+0100)
Java version: 1.5.0_22
Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: windows xp version: 5.2 arch: x86 Family: windows
Reporter: Mark Hobson
Attachments: MNG-4854-test.patch
[ProjectSorter|http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java]
skips vertexes where versions don't match and thus produces incorrect
results.
For example, if A depends on B:1.0 but B is resolved to 1.1 (via conflict
resolution or dependency management) then A-B:1.0 is lost. One suspect
could be {{isSpecificVersion}} which returns true for 1.0, which isn't a
specific version like [1.0], so this vertex gets lost as B:1.0 doesn't exist.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4854) [regression] ProjectSorter neglects conflicted versions
[
http://jira.codehaus.org/browse/MNG-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4854.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
If {{project:1.0}} depends on {{dependency:2.0}} then it doesn't depend on
{{dependency:1.0}}. See MNG-3814 for more details why versions matter.
[regression] ProjectSorter neglects conflicted versions
---
Key: MNG-4854
URL: http://jira.codehaus.org/browse/MNG-4854
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0-alpha-6
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 12:50:56+0100)
Java version: 1.5.0_22
Java home: C:\Program Files (x86)\Java\jdk1.5.0_22\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: windows xp version: 5.2 arch: x86 Family: windows
Reporter: Mark Hobson
Assignee: Benjamin Bentmann
Attachments: MNG-4854-test.patch
[ProjectSorter|http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/project/ProjectSorter.java]
skips vertexes where versions don't match and thus produces incorrect
results.
For example, if A depends on B:1.0 but B is resolved to 1.1 (via conflict
resolution or dependency management) then A-B:1.0 is lost. One suspect
could be {{isSpecificVersion}} which returns true for 1.0, which isn't a
specific version like [1.0], so this vertex gets lost as B:1.0 doesn't exist.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-334) Run a build on generated project during integration test
[
http://jira.codehaus.org/browse/ARCHETYPE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237584#action_237584
]
Herve Boutemy commented on ARCHETYPE-334:
-
typo fixed: thank you for the review
Run a build on generated project during integration test
Key: ARCHETYPE-334
URL: http://jira.codehaus.org/browse/ARCHETYPE-334
Project: Maven Archetype
Issue Type: New Feature
Components: Plugin
Affects Versions: 2.0-alpha-5
Reporter: Jesse Glick
Priority: Minor
Fix For: 2.x
Currently it seems that {{archetype:integration-test}} just creates some
projects from the archetype with defined parameters and compares their
contents to golden copies. (By the way
http://maven.apache.org/archetype/maven-archetype-plugin/integration-test-mojo.html
does not document this in any way; I had to read {{IntegrationTestMojo}}
source to find this out.)
While that might be useful if you happen to have very complex Velocity
templates and need to test that property substitution works the right way
with different inputs, most archetypes have rather simple templates that just
substitute {{artifactId}} and the like, in which case verifying that the
created POM matches some fixed text is worse than useless: if you make any
changes to the archetype, you are simply going to make identical changes to
the test's golden files.
What would be much more useful in my experience is to check that the newly
generated project actually builds. For example, run {{mvn post-clean verify}}
and check that at a minimum the build completes normally. This would catch
common mistakes you might make when editing archetypes: mistyping a plugin or
dependency name, introducing compilation errors into Java sources, etc. It
would also be valuable to check that no warnings are emitted - such as the
infamous {{File encoding has not been set...}} message when
{{project.build.sourceEncoding}} has been forgotten.
(You could also run {{mvn post-site}}, checking for warnings/errors, and
compare {{target/site}} to a golden copy.)
CI builders running integration tests might also do so with a pristine local
repository (plus cache manager mirroring official public repos), which would
catch accidental references to unreleased plugin/dependency versions that the
archetype developer happened to have in their local repo.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-331) No archetype repository found. ... should not be a warning
[
http://jira.codehaus.org/browse/ARCHETYPE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-331.
---
Resolution: Fixed
Assignee: Herve Boutemy
warning message improved in r1004817
No archetype repository found. ... should not be a warning
Key: ARCHETYPE-331
URL: http://jira.codehaus.org/browse/ARCHETYPE-331
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 2.0-alpha-4
Environment: Maven 3.0 RC3
Reporter: Jesse Glick
Assignee: Herve Boutemy
Priority: Minor
Fix For: 2.0
When creating a project from an archetype in Central, if you do not
explicitly specify the repository URL, you get a warning:
{noformat}
No archetype repository found. Falling back to central repository
(http://repo1.maven.org/maven2).
Use -DarchetypeRepository=your repository if archetype's repository is
elsewhere.
{noformat}
This information is probably irrelevant if the archetype was in fact found.
It is just noise, and the presence of a warning line can distract the user
from real issues. DefaultArchetypeSelector.selectArchetype should print this
at info level or even below.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-318) requiredProperty defaultValue not correctly filtered
[
http://jira.codehaus.org/browse/ARCHETYPE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-318:
Description:
In our archetype-metadata.xml we´ve defined a requiredProperty with a default
value like this:
{code:xml}requiredProperty key=subArtifactId
defaultValue${artifactId}.itest1/defaultValue
/requiredProperty{code}
When we call archetype:generate and enter the parameters in interactive mode
everything works fine. But when we try to set the parameter subArtifactId on
the command line (mvn archetype:generate -DsubArtifactId=xyz) or from an
archetype.properties file, the value is ignored. In the generated pom.xml the
variable ${subArtifactId} is always replaced with ${artifactId}.itest1.
was:
In our archetype-metadata.xml we´ve defined a requiredProperty with a default
value like this:
requiredProperty key=subArtifactId
defaultValue${artifactId}.itest1/defaultValue
/requiredProperty
When we call archetype:generate and enter the parameters in interactive mode
everything works fine. But when we try to set the parameter subArtifactId on
the command line (mvn archetype:generate -DsubArtifactId=xyz) or from an
archetype.properties file, the value is ignored. In the generated pom.xml the
variable ${subArtifactId} is always replaced with ${artifactId}.itest1.
requiredProperty defaultValue not correctly filtered
Key: ARCHETYPE-318
URL: http://jira.codehaus.org/browse/ARCHETYPE-318
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0-alpha-5
Reporter: Jochen Ehret
Priority: Minor
In our archetype-metadata.xml we´ve defined a requiredProperty with a
default value like this:
{code:xml}requiredProperty key=subArtifactId
defaultValue${artifactId}.itest1/defaultValue
/requiredProperty{code}
When we call archetype:generate and enter the parameters in interactive
mode everything works fine. But when we try to set the parameter
subArtifactId on the command line (mvn archetype:generate
-DsubArtifactId=xyz) or from an archetype.properties file, the value is
ignored. In the generated pom.xml the variable ${subArtifactId} is always
replaced with ${artifactId}.itest1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-484) Support adding and overriding report plugins in new maven-site-plugin 3.x reportPlugins configuration format
[
http://jira.codehaus.org/browse/MSITE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MSITE-484:
---
Fix Version/s: 3.0-beta-3
Assignee: Olivier Lamy
Support adding and overriding report plugins in new maven-site-plugin 3.x
reportPlugins configuration format
Key: MSITE-484
URL: http://jira.codehaus.org/browse/MSITE-484
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: inheritance
Affects Versions: 3.0-beta-1
Environment: 3.0-beta-1-SNAPSHOT
Reporter: Michael Pilquist
Assignee: Olivier Lamy
Fix For: 3.0-beta-3
Attachments: site-cfg-inheritance.zip
When using the new configuration format for reportPlugins, it appears that
there's no way to:
- Add a report plugin to a submodule
- Override the configuration of a report plugin in a submodule
Using the old reporting section, both of these use cases were supported.
For large, multi-module builds, it is problematic having to respecify all
reporting plugins in any submodule pom that needs to either add an additional
reporting plugin or change the configuration of a reporting plugin.
Attached is a sample project that has a parent POM configured with
project-info-reports and javadoc plugin and a submodule configured with jxr
plugin and javadoc plugin. The relevant output is here:
{code}
[INFO]
[INFO] Building parent 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent ---
[INFO] Deleting file set: /Users/mpilquist/Downloads/site-parent-issue/target
(included: [**], excluded: [])
[INFO]
[INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @ parent
---
[INFO] configuring reportPlugin
org.apache.maven.plugins:maven-project-info-reports-plugin:2.2
[INFO] configuring reportPlugin
org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
...
[INFO]
[INFO] Building parent-usage-test 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent-usage-test
---
[INFO]
[INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @
parent-usage-test ---
[INFO] configuring reportPlugin org.apache.maven.plugins:maven-jxr-plugin:2.1
[INFO] configuring reportPlugin
org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
{code}
Looking at the maven-site-plugin code, it appears the the reportPlugins
parameter is just a regular array parameter. AFAIK, there's no way to merge
list configuration items. Other plugins have worked around this by defining
additional mojo parameters (e.g., maven-eclipse-plugin and buildCommands /
additionalBuildCommands --
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html).
This isn't the most flexible option though as it only solves 1 level
inheritance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-579) No such command 'tag'
[ http://jira.codehaus.org/browse/SCM-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gergely Kiss closed SCM-579. Resolution: Not A Bug Fix Version/s: 1.4 Sorry for the disturbance, I just found the solution by myself. Bazaar tag support is actually implemented _and released_ in 1.4, but the current maven-release-plugin (2.0) still only uses 1.3 for some reason. It is also weird that the 2.1-SNAPSHOT version of maven-release looks for 1.4-SNAPSHOT (which doesn't exist anymore). So with a slight hack in the pom, tagging works perfectly with Bazaar: build plugins ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.0/version dependencies dependency groupIdorg.apache.maven.scm/groupId artifactIdmaven-scm-api/artifactId version1.4/version /dependency dependency groupIdorg.apache.maven.scm/groupId artifactIdmaven-scm-provider-bazaar/artifactId version1.4/version /dependency /dependencies /plugin ... /plugins /build No such command 'tag' - Key: SCM-579 URL: http://jira.codehaus.org/browse/SCM-579 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-bazaar Affects Versions: 2.0 Environment: Maven 2.2.1, Java 1.6_21, Windows XP SP3 Reporter: Gergely Kiss Fix For: 1.4 The mvn release:prepare fails with the following error when trying to release a trunk checkout with bazaar: [ERROR] BUILD ERROR [INFO] [INFO] An error is occurred in the tag process: No such command 'tag'. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:165) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: org.apache.maven.shared.release.ReleaseExecutionException: An error is occurred in the tag process: No such command 'tag'. at org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:94) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:196) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:133) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:96) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:161) ... 19 more Caused by: org.apache.maven.scm.NoSuchCommandScmException: No such command 'tag'. at
[jira] Updated: (MNG-1911) Building plugins with extensions in a reactor fails
[ http://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1911: -- Fix Version/s: (was: Issues to be reviewed for 3.x) 3.1 Assignee: (was: John Casey) putting into 3.1 so that such an extension to the POM can be made so that this can be made to work again Building plugins with extensions in a reactor fails --- Key: MNG-1911 URL: http://jira.codehaus.org/browse/MNG-1911 Project: Maven 2 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.1 Reporter: Guillaume Nodet Priority: Critical Fix For: 3.1 Attachments: MNG-1911.zip I have the following in my main pom build pluginManagement plugins plugin groupIdorg.apache.servicemix.plugins/groupId artifactIdmaven2-jbi-plugin/artifactId version1.0-SNAPSHOT/version extensionstrue/extensions /plugin /plugins /pluginManagement /build If i try to add it to the modules, the first time, maven complains that it can not download the plugin. If i remove the extensions tag, all works, but i need it :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4850) [regression] filePermissions and directoryPermissions in settings.xml are not honoured
[ http://jira.codehaus.org/browse/MNG-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4850: -- Fix Version/s: 3.0.1 [regression] filePermissions and directoryPermissions in settings.xml are not honoured -- Key: MNG-4850 URL: http://jira.codehaus.org/browse/MNG-4850 Project: Maven 2 3 Issue Type: Bug Components: Settings Affects Versions: 3.0-beta-3 Reporter: Brett Porter Priority: Minor Fix For: 3.0.1 The IT MavenITmng3600DeploymentModeDefaultsTest.testitMNG3600ModesSet is currently failing for all versions of Maven 3. Correspondingly, when using Maven 3 with an SSH wagon listed as an extension, it deploys successfully but ignores the above settings, using default file and directory modes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
