[jira] (MNG-5151) use CNAME or repo to provide more stability
[ https://jira.codehaus.org/browse/MNG-5151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened MNG-5151: --- Assignee: Olivier Lamy > use CNAME or repo to provide more stability > --- > > Key: MNG-5151 > URL: https://jira.codehaus.org/browse/MNG-5151 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.0.3 >Reporter: Mark Struberg >Assignee: Olivier Lamy > Fix For: 3.0.4 > > > use CNAME or repo to provide more stability -- 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] (MASSEMBLY-576) addClasspath broken in new single goal
[
https://jira.codehaus.org/browse/MASSEMBLY-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286584#comment-286584
]
Dirk Strauss commented on MASSEMBLY-576:
Is this a duplicate of MASSEMBLY-334?
> addClasspath broken in new single goal
> --
>
> Key: MASSEMBLY-576
> URL: https://jira.codehaus.org/browse/MASSEMBLY-576
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 3.0.3
> Ubuntu 11.04
> Sun java 6 (1.6.0_26)
>Reporter: James Davis
>Priority: Blocker
>
> According to the documentation, using true in
> archive/manifest, should place the generated classpath in to the manifest.
> This works with assembly:assembly (now deprecated), but is broken in
> assembly:single
> Here is my plugin definition section:
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
> src/main/assembly/assembly.xml
>
>
>
> com.example.Main
> true
> lib/
>
>
>
>
>
> package
>
> single
>
>
>
>
> and the custom assembly file:
>
> full
>
> jar
>
> false
>
>
> false
> runtime
> true
> lib/
>
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
> I'm not sure if this is just because the documentation does not correctly
> address how to do this or if it is actually just broken. I did check the
> docs and this is how the docs claim you should be able to do this.
--
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] (MECLIPSE-702) -Declipse.addVersionToProjectName=true option does not add Version to referenced project names.
[ https://jira.codehaus.org/browse/MECLIPSE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286641#comment-286641 ] carlo cancellieri commented on MECLIPSE-702: Try adding this to the list: maven-eclipse-plugin 2.5 org.springframework.ide.eclipse.core.springnature Regards, Carlo Cancellieri > -Declipse.addVersionToProjectName=true option does not add Version to > referenced project names. > --- > > Key: MECLIPSE-702 > URL: https://jira.codehaus.org/browse/MECLIPSE-702 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: java 1.6.25, Windows 7 >Reporter: Jake Lee >Priority: Minor > > When calling 'mvn eclipse:eclipse -Declipse.addVersionToProjectName=true' > from a parent directory, so that all underlying projects will be created, the > plugin does not add the Version to the name of projects referenced. When it > is loaded into eclipse, eclipse cannot find the project with name > [refrenced-project-name] even though the project is available with the name > [referenced-project-name]-[version]. -- 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-5151) use CNAME or repo to provide more stability
[ https://jira.codehaus.org/browse/MNG-5151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286651#comment-286651 ] Olivier Lamy commented on MNG-5151: --- finally we will use http://repo.maven.apache.org/maven2 > use CNAME or repo to provide more stability > --- > > Key: MNG-5151 > URL: https://jira.codehaus.org/browse/MNG-5151 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.0.3 >Reporter: Mark Struberg >Assignee: Olivier Lamy > Fix For: 3.0.4 > > > use CNAME or repo to provide more stability -- 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-5151) use CNAME or repo to provide more stability
[ https://jira.codehaus.org/browse/MNG-5151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MNG-5151. - Resolution: Fixed changed r170. > use CNAME or repo to provide more stability > --- > > Key: MNG-5151 > URL: https://jira.codehaus.org/browse/MNG-5151 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.0.3 >Reporter: Mark Struberg >Assignee: Olivier Lamy > Fix For: 3.0.4 > > > use CNAME or repo to provide more stability -- 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] (MASSEMBLY-576) addClasspath broken in new single goal
[
https://jira.codehaus.org/browse/MASSEMBLY-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286653#comment-286653
]
James Davis commented on MASSEMBLY-576:
---
I do not believe so as the generation of items works fine. All that is missing
is adding of the classpath to the output manifest file. It works fine if I use
any of the deprecated goals, just not the new single goal.
> addClasspath broken in new single goal
> --
>
> Key: MASSEMBLY-576
> URL: https://jira.codehaus.org/browse/MASSEMBLY-576
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 3.0.3
> Ubuntu 11.04
> Sun java 6 (1.6.0_26)
>Reporter: James Davis
>Priority: Blocker
>
> According to the documentation, using true in
> archive/manifest, should place the generated classpath in to the manifest.
> This works with assembly:assembly (now deprecated), but is broken in
> assembly:single
> Here is my plugin definition section:
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
> src/main/assembly/assembly.xml
>
>
>
> com.example.Main
> true
> lib/
>
>
>
>
>
> package
>
> single
>
>
>
>
> and the custom assembly file:
>
> full
>
> jar
>
> false
>
>
> false
> runtime
> true
> lib/
>
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
> I'm not sure if this is just because the documentation does not correctly
> address how to do this or if it is actually just broken. I did check the
> docs and this is how the docs claim you should be able to do this.
--
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] (MASSEMBLY-576) addClasspath broken in new single goal
[
https://jira.codehaus.org/browse/MASSEMBLY-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286653#comment-286653
]
James Davis edited comment on MASSEMBLY-576 at 12/22/11 9:16 AM:
-
I do not believe so as the generation of items works fine. All that is missing
is adding of the classpath to the output manifest file. It works fine if I use
any of the deprecated goals, just not the new single goal.
It does sound similar, however they are trying to execute the assembly:assembly
goal which does work fine for me as I stated above.
was (Author: davija):
I do not believe so as the generation of items works fine. All that is
missing is adding of the classpath to the output manifest file. It works fine
if I use any of the deprecated goals, just not the new single goal.
> addClasspath broken in new single goal
> --
>
> Key: MASSEMBLY-576
> URL: https://jira.codehaus.org/browse/MASSEMBLY-576
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 3.0.3
> Ubuntu 11.04
> Sun java 6 (1.6.0_26)
>Reporter: James Davis
>Priority: Blocker
>
> According to the documentation, using true in
> archive/manifest, should place the generated classpath in to the manifest.
> This works with assembly:assembly (now deprecated), but is broken in
> assembly:single
> Here is my plugin definition section:
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
> src/main/assembly/assembly.xml
>
>
>
> com.example.Main
> true
> lib/
>
>
>
>
>
> package
>
> single
>
>
>
>
> and the custom assembly file:
>
> full
>
> jar
>
> false
>
>
> false
> runtime
> true
> lib/
>
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
> I'm not sure if this is just because the documentation does not correctly
> address how to do this or if it is actually just broken. I did check the
> docs and this is how the docs claim you should be able to do this.
--
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-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286685#comment-286685 ] William Ashley commented on MNG-3283: - I also just ran into this issue using maven 3.0.3 with some projects I recently split into modules. The problem goal for me is findbugs:findbugs. > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: https://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- 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-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286685#comment-286685 ] William Ashley edited comment on MNG-3283 at 12/22/11 3:19 PM: --- I also just ran into this issue using maven 3.0.3 with some projects I recently split into modules. was (Author: washley): I also just ran into this issue using maven 3.0.3 with some projects I recently split into modules. The problem goal for me is findbugs:findbugs. > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: https://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- 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-812) log4j classloader problem in 2.11 that is not there in 2.10
Gregor N. Purdy, Sr. created SUREFIRE-812: - Summary: log4j classloader problem in 2.11 that is not there in 2.10 Key: SUREFIRE-812 URL: https://jira.codehaus.org/browse/SUREFIRE-812 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.11 Reporter: Gregor N. Purdy, Sr. Unit test does not fail with 2.10 but does fail with 2.11 Output from failing unit test log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable to a "org.apache.log4j.spi.Configurator" variable. log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of type log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. log4j:ERROR Could not instantiate configurator [org.apache.log4j.xml.DOMConfigurator]. $ mvn -version Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) Plugin config maven-surefire-plugin 2.11 default-test test test -Xmx2048m -Xms1024m true false always 600 true true -Xmx2048m -Xms1024m true false always 600 true true reporting plugin configuration maven-surefire-report-plugin 2.11 -Xmx2048m -Xms1024m true false always 600 true true -- 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-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286685#comment-286685 ] William Ashley edited comment on MNG-3283 at 12/22/11 3:56 PM: --- I also just ran into this issue using maven 3.0.3 with some projects I recently split into modules. Edit: I am experiencing this with the javadoc, findbugs, and dependency plugins. Compilation, tests, packaging all work, in addition to the codehaus cobertura plugin. was (Author: washley): I also just ran into this issue using maven 3.0.3 with some projects I recently split into modules. > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: https://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick >Assignee: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- 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-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-799. --- Resolution: Fixed Fixed in r1222474, thanks for the patch! I made some adjustments to the patch, and you may want to look over those. > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: Improvement > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- 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-812) log4j classloader problem in 2.11 that is not there in 2.10
[ https://jira.codehaus.org/browse/SUREFIRE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286694#comment-286694 ] Kristian Rosenvold commented on SUREFIRE-812: - Could you also verify that the problem is still present on 2.12-SNAPSHOT? > log4j classloader problem in 2.11 that is not there in 2.10 > --- > > Key: SUREFIRE-812 > URL: https://jira.codehaus.org/browse/SUREFIRE-812 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.11 >Reporter: Gregor N. Purdy, Sr. > > Unit test does not fail with 2.10 but does fail with 2.11 > Output from failing unit test > log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable > to a "org.apache.log4j.spi.Configurator" variable. > log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by > log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of > type > log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by > [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. > log4j:ERROR Could not instantiate configurator > [org.apache.log4j.xml.DOMConfigurator]. > $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Plugin config > > maven-surefire-plugin > 2.11 > > > default-test > test > > test > > > -Xmx2048m -Xms1024m > true > false > always > > 600 > true > > true > > > > > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > > reporting plugin configuration > > maven-surefire-report-plugin > 2.11 > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > -- 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-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286692#comment-286692 ] Kristian Rosenvold commented on SUREFIRE-811: - We have previously marked similar issues as "wontFix". I am not flat our rejecting a patch, but I would be interested in hearing about the use cases for this one. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- 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-812) log4j classloader problem in 2.11 that is not there in 2.10
[ https://jira.codehaus.org/browse/SUREFIRE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286693#comment-286693 ] Kristian Rosenvold commented on SUREFIRE-812: - Is there any chance you could produce a small test project that reproduces this issue ? > log4j classloader problem in 2.11 that is not there in 2.10 > --- > > Key: SUREFIRE-812 > URL: https://jira.codehaus.org/browse/SUREFIRE-812 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.11 >Reporter: Gregor N. Purdy, Sr. > > Unit test does not fail with 2.10 but does fail with 2.11 > Output from failing unit test > log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable > to a "org.apache.log4j.spi.Configurator" variable. > log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by > log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of > type > log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by > [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. > log4j:ERROR Could not instantiate configurator > [org.apache.log4j.xml.DOMConfigurator]. > $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Plugin config > > maven-surefire-plugin > 2.11 > > > default-test > test > > test > > > -Xmx2048m -Xms1024m > true > false > always > > 600 > true > > true > > > > > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > > reporting plugin configuration > > maven-surefire-report-plugin > 2.11 > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > -- 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] (MSITE-625) Please add an 'archive' parameter to the 'jar' goal of the 'maven-site-plugin'.
[
https://jira.codehaus.org/browse/MSITE-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MSITE-625.
--
Resolution: Fixed
Fix Version/s: 3.1
Assignee: Olivier Lamy
fixed r1222490
> Please add an 'archive' parameter to the 'jar' goal of the
> 'maven-site-plugin'.
>
>
> Key: MSITE-625
> URL: https://jira.codehaus.org/browse/MSITE-625
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Wish
>Affects Versions: 3.0
>Reporter: Christian Schulte
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.1
>
> Attachments: MSITE-625.patch
>
>
> {code}
> /**
> * The archive configuration to use.
> * See href="http://maven.apache.org/shared/maven-archiver/index.html";>Maven
> Archiver Reference.
> *
> * @parameter
> */
> private MavenArchiveConfiguration archive = new MavenArchiveConfiguration();
> {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] (SUREFIRE-587) Doesn't run tests if they don't end with Test
[
https://jira.codehaus.org/browse/SUREFIRE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286714#comment-286714
]
Christian G commented on SUREFIRE-587:
--
Nearly one year has been passed after the last comment. Are there any plans to
implement this feature?
If not, the workaround above is ok. But it has to be:
{noformat}**/*.class{noformat}
> Doesn't run tests if they don't end with Test
> -
>
> Key: SUREFIRE-587
> URL: https://jira.codehaus.org/browse/SUREFIRE-587
> Project: Maven Surefire
> Issue Type: Wish
> Components: JUnit 3.x support, Junit 4.x support
>Affects Versions: 2.4.3
> Environment: N/A
>Reporter: David J. M. Karlsen
>
> We have a mix of test - some purely junit4 (e.g. not extending anything and
> annotating with @Test) - and some which extends TestCase.
> I've discovered that the ones extending TestCase won't run if the classname
> doesn't end with Test - so that the class CommonsAttributesParserTests won't
> get included (notice the ending "s").
--
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] (MSITE-624) Usage page has incorrect information on the id used by site:stage-deploy
[
https://jira.codehaus.org/browse/MSITE-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-624.
---
Resolution: Fixed
Fix Version/s: 3.1
Assignee: Lukas Theussl
Fixed in [r1222599|http://svn.apache.org/viewvc?rev=1222599&view=rev].
> Usage page has incorrect information on the id used by site:stage-deploy
>
>
> Key: MSITE-624
> URL: https://jira.codehaus.org/browse/MSITE-624
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Environment:
> http://maven.apache.org/plugins/maven-site-plugin/usage.html
>Reporter: SebbASF
>Assignee: Lukas Theussl
> Fix For: 3.1
>
>
> {quote}
> To stage a site and to deploy it, just execute the site:stage-deploy goal
> from your project with the required parameters. The site:stage-deploy goal
> will use the id stagingSite for deployment. So if you need to add your
> username or password in settings.xml, you should use stagingSite for
> that section.
> {quote}
> This is incorrect; the id "stagingSite" is not necessarily used, see:
> http://maven.apache.org/plugins/maven-site-plugin/stage-deploy-mojo.html#stagingRepositoryId
--
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
