[jira] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of "../"
Lennart Jörelid created MSITE-669:
-
Summary: site:stage creates incorrect structure when module paths
contains sets of "../"
Key: MSITE-669
URL: https://jira.codehaus.org/browse/MSITE-669
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:stage(-deploy)
Affects Versions: 3.2, 3.1
Reporter: Lennart Jörelid
Given the module definitions given below, the site:stage goal produces sets of
maps relative to the staging directory - i.e. outside of the target directory.
{code:xml}
../../validation/validation-api
../../validation/validation-aspect
../parent
{code}
The staged site should be fully included within the staging directory. It would
appear that relativization of links for site:stage should take special links
into consideration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGELOG-79) Add support for "tag" type report of Subversion
[
https://jira.codehaus.org/browse/MCHANGELOG-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315221#comment-315221
]
Tom Briers commented on MCHANGELOG-79:
--
Hi,
I applied the patches on a personnel checkout and I do not think this is
correct.
What seems to be done is the following:
* get revision of tag A
* get revision of tag B
* execute svn --non-interactive log -v -r revA:revB
svn://theUrlToTheRepositoryOfYourCurrentCheckout
I think the correct way is:
* get revision of tag A
* get revision of tag B
* execute svn --non-interactive log -v -r revA:revB svn://theUrlToTheTagB
> Add support for "tag" type report of Subversion
> ---
>
> Key: MCHANGELOG-79
> URL: https://jira.codehaus.org/browse/MCHANGELOG-79
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Reporter: Kinugasa Noriko
> Attachments:
> MCHANGELOG-79_0001-Add-support-for-svn-tag-diffs.-Redo-the-original-MCH.patch,
>
> MCHANGELOG-79-Add-support-for-svn-tag-diffs-New-Patch-no-BranchBase-property.patch,
> SvnTag_changelog.patch, svntag-report-sample.JPG
>
>
> Currently, Changelog plugin don't support Subversion's tag.
> This patch make The "tag" type report available even if you are using
> Subversion.
> This gets each revision of tags in Subversion system, and generates the
> log-report between those revisions.
> For example, assume you have following repositoy structure:
> {noformat}
> http://example.com/svn/project
> +trunk/
> |+src/
> | ...
> +tags/
> |+1.0/
> |+1.1/
> |+1.2/
> |+2.0/
> |+2.1/
> +branches/
> +1.x/
> {noformat}
> To generate svn log's between 1.1 and 1.2 tag in 1.x branch:
> [pom.xml]
> {code:xml}
> ...
>
>
>
> scm:svn:http://example.com/svn/project
>
> ...
>
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.2.1
>
>
> tag
>
>
> 1.2
> 1.1
>
>
> branches/1.x
>
> Windows-31J
>
>
>
>
> ...
> {code}
> To generate svn log-report between 2.1 and 2.0 tag in trunk:
> [pom.xml]
> {code:xml}
> ...
>
>
>
> scm:svn:http://example.com/svn/project
>
> ...
>
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.2.1
>
>
> tag
>
>
> 2.0
> 2.1
>
>
> [trunk]
>
> Windows-31J
>
>
>
>
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-729) release:branch makes pom changes for branch in 'master' before branching
[
https://jira.codehaus.org/browse/MRELEASE-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-729.
---
Resolution: Duplicate
Assignee: Robert Scholte
> release:branch makes pom changes for branch in 'master' before branching
>
>
> Key: MRELEASE-729
> URL: https://jira.codehaus.org/browse/MRELEASE-729
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: branch, Git
>Affects Versions: 2.2.2
>Reporter: Joseph Walton
>Assignee: Robert Scholte
>
> {{release:branch}} makes the change for the branch version before branching.
> This means the version change is seen in the trunk's history.
> If master is currently '1-SNAPSHOT':
> {code}
> * 1-SNAPSHOT [master]
> {code}
> and I create a new 'branch-with-hacks' branch as '1.hacks-SNAPSHOT' then I'll
> see this in my log:
> {code}
> * 1-SNAPSHOT [master]
> |
> * 1.hacks-SNAPSHOT [branch-with-hacks]
> |
> * 1-SNAPSHOT
> {code}
> with a commit and a revert on master where I would expect:
> {code}
> * 1.hacks-SNAPSHOT [branch-with-hacks]
> |
> * 1-SNAPSHOT [master]
> {code}
> with 'master' remaining unaffected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315231#comment-315231 ] Darryl L. Miles commented on MRELEASE-780: -- How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315231#comment-315231 ] Darryl L. Miles edited comment on MRELEASE-780 at 12/7/12 10:50 AM: How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic doing one or more commits for code changes, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. was (Author: dlmiles): How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-780) Prevent Tag from additional commits
[ https://jira.codehaus.org/browse/MRELEASE-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315231#comment-315231 ] Darryl L. Miles edited comment on MRELEASE-780 at 12/7/12 10:53 AM: How do you mean exactly ? You are speaking about a release that is made and a tag for that release is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic doing one or more commits for code changes, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. was (Author: dlmiles): How do you mean exactly ? You are speaking about a release that is made when a tag is created ? * As it looks like project.scm.tag is edited to be the tag name that is created. In which case the new pom.xml is committed (with this change) into the tag version. * There is also the message that appears in the SCM commit log history to help identify the commit as being for a particular release. There are other bugs about excess commits showing up in the main tree relating to releases and branches. But if I understand your bug here correctly you have used release:branch already, then did some work on the topic doing one or more commits for code changes, then decide to release:prepare from that branch ? So there should be at least 1 commit for the 2 reasons cited above IMHO. Please update this ticket in respect of how you think it should be working. > Prevent Tag from additional commits > > > Key: MRELEASE-780 > URL: https://jira.codehaus.org/browse/MRELEASE-780 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.3.2 >Reporter: E > > If you create an release from the branch there should be no commits on the > tag-folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5405) Execute goal does not passes from mojos.xml pluginMetadata
Ben Tatham created MNG-5405: --- Summary: Execute goal does not passes from mojos.xml pluginMetadata Key: MNG-5405 URL: https://jira.codehaus.org/browse/MNG-5405 Project: Maven 2 & 3 Issue Type: Bug Components: Plugin API Affects Versions: 3.0.4 Reporter: Ben Tatham In pluginMetadata (.mojos.xml) that describes an ant-based plugin, adding foo:bar Doesn't make its way in to the plugin.xml. I tracked down the bug to a missing setter in: maven-plugin-tools-model-3.2 org.apache.maven.plugin.tools.model.PluginMetadataParser line 131 When copying the LifecycleExecution out of the Mojo into the MojoDescriptor, it sets the execution lifecycle and phase, but skips the goal. Trivial fix, not even worth a path, imho. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-931) Surefire crashes if test depends on unknown group
Gili created SUREFIRE-931:
-
Summary: Surefire crashes if test depends on unknown group
Key: SUREFIRE-931
URL: https://jira.codehaus.org/browse/SUREFIRE-931
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.12.4
Reporter: Gili
Attachments: TestFailed.zip
Unzip and run the attached testcase.
Surefire throws the following exception:
{code}
Configuring TestNG with:
org.apache.maven.surefire.testng.conf.TestNG652Configurator@6127ffd7
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: org.testng.TestNGException:
DependencyMap::Method "AppTest.removeNonExistentLocation()[pri:0,
instance:null(com.mycompany.testfailed.AppTest)]" depends on nonexistent group
"getLocation"
at
org.testng.DependencyMap.getMethodsThatBelongTo(DependencyMap.java:45)
at org.testng.TestRunner.createDynamicGraph(TestRunner.java:1079)
at org.testng.TestRunner.privateRun(TestRunner.java:734)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1123)
at org.testng.TestNG.run(TestNG.java:1031)
at
org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77)
at
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110)
at
org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:106)
... 9 more
{code}
and prints:
"The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?"
Expected behavior:
# Kill this misleading error message, please. I wasted a lot of time looking in
the wrong direction because of it.
# Surefire should report this as a normal test failure, not a crash.
See http://netbeans.org/bugzilla/show_bug.cgi?id=219097 for a related
discussion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-932) Improve or remove logging of TestNG configurator
Gili created SUREFIRE-932:
-
Summary: Improve or remove logging of TestNG configurator
Key: SUREFIRE-932
URL: https://jira.codehaus.org/browse/SUREFIRE-932
Project: Maven Surefire
Issue Type: Improvement
Components: TestNG support
Affects Versions: 2.12.4
Reporter: Gili
Priority: Minor
When running TestNG tests under Surefire it prints:
{code}Configuring TestNG with:
org.apache.maven.surefire.testng.conf.TestNG652Configurator@37c9313b{code}
I don't think anyone can do anything useful with this. The message should
either be removed or improved to print something more meaningful than the
configurator's hashcode.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
