[jira] (MDEPLOY-150) deploy-file does not use repository in the same way as deploy
[
https://jira.codehaus.org/browse/MDEPLOY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEPLOY-150:
---
Description:
We use an own lifecycle here which creates a zip file instead of a jar file.
So we use
{noformat}org.apache.maven.plugins:maven-install-plugin:install,org.apache.maven.plugins:maven-install-plugin:install-file{noformat}
which installs the zip file correctly.
Additionally I now wanted to also allow deploying of this zip file to nexus by:
{noformat}org.apache.maven.plugins:maven-deploy-plugin:deploy,org.apache.maven.plugins:maven-deploy-plugin:deploy-file{noformat}
in the pom I have then:
{code:xml}
${project.build.directory}/${project.artifactId}-${project.version}.zip
org.apache.maven.plugins
maven-install-plugin
2.3.1
install-service-zip
install-file
org.apache.maven.plugins
maven-deploy-plugin
2.7
deploy-service-zip
deploy-file
{code}
as well as settings for the repositories within the maven {{settings.xml}}.
As said the install process works perfectly, but I have trouble with the
{{deploy-file}}.
When working without the {{deploy-file}} (only with the {{deploy}}) everything
also works correct for the deployment.
After adding the {{deploy-file}} as shown above I come into trouble, because
beside the property the deploy-plugin requests for the required
parameter.
I wonder about this, because I assumed that the parameter will come from
the choosen repository (release vs snapshot) settings?
When I set the as property beside the property, then I can deploy
a snapshot.
But to deploying snapshot/release this will not work.
In {{deploy}} the url parameter is implicitly correctly choosen, why not in
{{deploy-file}}? this would make the url parameter optional.
So I see this as a bug/feature, because when deploy works in this way, then
{{deploy-file}} should work analogous. Or have I missed something here?
was:
We use an own lifecycle here which creates a zip file instead of a jar file.
So we use
org.apache.maven.plugins:maven-install-plugin:install,org.apache.maven.plugins:maven-install-plugin:install-file
which installs the zip file correctly.
Additionally I now wanted to also allow deploying of this zip file to nexus by:
org.apache.maven.plugins:maven-deploy-plugin:deploy,org.apache.maven.plugins:maven-deploy-plugin:deploy-file
in the pom I have then:
${project.build.directory}/${project.artifactId}-${project.version}.zip
org.apache.maven.plugins
maven-install-plugin
2.3.1
install-service-zip
install-file
org.apache.maven.plugins
maven-deploy-plugin
2.7
deploy-service-zip
deploy-file
[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315774#comment-315774
]
nkeywal commented on SUREFIRE-800:
--
Would it be a solution to limit the usage of this nonconcurrent manager to the
'once' & 'perthread' forkmode? At least short term?
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
> Attachments: 800.v1.patch
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
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-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-800.
---
Resolution: Fixed
The problem is "fixed" (as in "understood", not solved). This is the
ever-recurring issue that junit core does not allow us to demarcate the border
between classes. The actual "problem" is not new, but was caused by a test
running in different order on CI.
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
> Attachments: 800.v1.patch
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
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-937) Test count intermittently incorrect with parallel junit provider
Kristian Rosenvold created SUREFIRE-937: --- Summary: Test count intermittently incorrect with parallel junit provider Key: SUREFIRE-937 URL: https://jira.codehaus.org/browse/SUREFIRE-937 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.12.4 Reporter: Kristian Rosenvold The unit test ConcurrentReporterManagerTest will fail intermittently with wrong test counts. It is expected that this failure may reflect real-life behaviour -- 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-937) Test count intermittently incorrect with parallel junit provider
[ https://jira.codehaus.org/browse/SUREFIRE-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-937. --- Resolution: Fixed Fix Version/s: 2.13 Assignee: Kristian Rosenvold Fixed in 5b56fe7002eb0671ef2035cd39adfb7a89bba5a5, test seems stable now > Test count intermittently incorrect with parallel junit provider > > > Key: SUREFIRE-937 > URL: https://jira.codehaus.org/browse/SUREFIRE-937 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.12.4 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.13 > > > The unit test ConcurrentReporterManagerTest will fail intermittently with > wrong test counts. It is expected that this failure may reflect real-life > behaviour -- 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-933) forkMode onceperthread broken after fix for JUnit category filter with empty result
[
https://jira.codehaus.org/browse/SUREFIRE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-933.
---
Resolution: Fixed
Fixed yet again in 435ef473be35f69dbb0c3187ecf7b54e3f87f49a, thanks for the
patch !
> forkMode onceperthread broken after fix for JUnit category filter with empty
> result
> ---
>
> Key: SUREFIRE-933
> URL: https://jira.codehaus.org/browse/SUREFIRE-933
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
>
> In forkMode {{onceperthread}} (reusable fork), the {{TestsToRun}} object will
> always be a {{LazyTestsToRun}} instance, which throws an excetpion if
> {{getLocatedClasses()}} is called. The fix for SUREFIRE-839 changed
> {{JUnitCoreWrapper}} and {{JUnitCoreProvider}} to call exactly that method.
--
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] (MDEPLOY-135) Add ability to skip deploying certain modules from command line
[
https://jira.codehaus.org/browse/MDEPLOY-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-135.
--
Resolution: Won't Fix
Assignee: Robert Scholte
Although I can't think of a usecase to only deploy a selection, here's a
solution: Add something like the following to your pom:
{code:xml}
false
org.apache.maven.plugins
maven-deploy-plugin
2.7
${module1.deploy.skip}
{code}
If you want to skip this module, add {{-Dmodule1.deploy.skip=true}}
> Add ability to skip deploying certain modules from command line
> ---
>
> Key: MDEPLOY-135
> URL: https://jira.codehaus.org/browse/MDEPLOY-135
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: New Feature
> Components: deploy:deploy
>Affects Versions: 2.6
>Reporter: Gayathri Muralidharan
>Assignee: Robert Scholte
>Priority: Minor
>
> Hi,
> Currently it is possible to skip certain modules during deployment by setting
> the config in the pom file.
> ( true )
> Wouldn't it be nice to have the ability to mention this via command line like
> -Dmaven.deploy.skip= modules-to-be-skipped or something so that frequent
> changes to pom files are not required and this can be specified/modified
> easily from hudson?
> Please correct me if this is already supported or if i am missing something
> here :)
> Thanks,
> Gayathri
--
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] (MDEPLOY-97) the always be 1 on maven-metadata.xml
[ https://jira.codehaus.org/browse/MDEPLOY-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-97. - Resolution: Incomplete Assignee: Robert Scholte No feedback, so closing it as 'incomplete' > the always be 1 on maven-metadata.xml > --- > > Key: MDEPLOY-97 > URL: https://jira.codehaus.org/browse/MDEPLOY-97 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 2.4 > Environment: unix, jdk 1.5 >Reporter: Michael Meng >Assignee: Robert Scholte > Labels: scrub-review-started > Attachments: buildnumber.JPG, clear.doc, goodone.JPG > > > We have setup a project build on cruise control, whose version is SNAPSHOT > (in my case is 70-SNAPSHOT), however, the build result files look fine, but > the build number always be 1, what is the problem ? > You may compare the 2 pic, you will see the difference. the right pic is what > we expect. it has the build number 54,55, 56, 57 > while the left pic's build number always be 1 > in the maven-metadata.xml the buildNumber always 1, no matter how many times > you build it. > 1 > > ubhsc > sc > 70-SNAPSHOT > - > - > 20090320.170754 > 1 > > 20090320170754 > > -- 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-597) Duplicate files added to archive when present in both dependencyset and fileset of the same assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315788#comment-315788 ] Dennis Lundberg commented on MASSEMBLY-597: --- Michal, Can you provide a sample project for this issue? > Duplicate files added to archive when present in both dependencyset and > fileset of the same assembly > > > Key: MASSEMBLY-597 > URL: https://jira.codehaus.org/browse/MASSEMBLY-597 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.2 > Environment: windows 7, Eclipse indigo though the problem is > reproducible from command line build. Java 6 32 bit >Reporter: Eric Daigneault > > Comment added to parent bug, could not re-open the issue so I created this > sub-task instead. Comment copied here for convenience : > > Either version 2.2.2 of the Assembly plugin has a regression or the issue has > not been fixed. I am currently creating zip files from the assembly that > contains duplicate jar files. > Some background : I am using the assembly to create a zip file of an > application. Why Zip ? because the application requires multiple > configuration files and spans larger than just Java so I cannot use a uber > Jar (I would prefer that but technical limitations out of my control force me > otherwise). > This package is built correctly. > To make life simpler I made it possible to extend this package with a project > that can add extra classes (plugins and such) and configuration from a > standard layout in the project that gets picked up by the assembly and merged > with the previous vanilla package. the end result is a fully assembled zip > file with all the customized parts in the right place. > Now, behaviour changed across version wheras previously I would overwrite the > original package with the content of the new one, now I have to start from > the overrides and complete withe the original files. Easily fixed through > changing the order I declared the filesets in the assembly. When using > filesets strictly nothing gets added twice, though the replace was changed to > skip which is a bit counter intuitive. > BUT > Since I extend some parts of the original system, I will share some > dependencies with this one. These dependencies are already present in the > original package and get added through a file set (I get the package and > unzip it in a temporary folder where I integrate it`s content inthe assembly > through a fileset). > I also add the dependencies of the new customized project, and these get > added twice. > I think there is a regression here when filesets and dependencysets interact > where if files are present in both they get added twice in the zip file. Now > I would re-open this current task but it seems I cannot so I will open a sub > task instead. -- 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] (MDEPLOY-114) Add an option to not fail when remote file already exists and redeploy is forbidden
[
https://jira.codehaus.org/browse/MDEPLOY-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-114.
--
Resolution: Won't Fix
Assignee: Robert Scholte
I can think of 2 reasons why a {{release:perform}} fails:
- A failure occurs during the build, for instance because tests fail. In such
cases you would like to deploy all artifacts at the end, a feature added with
MDEPLOY-157
- The deployment itself fails due to connection issues. In this case you could
use the {{--resume-from }} option.
I'd prefer to solve the root-cause, so closing this as "won't fix".
(don't mind reopening this issue if you have a usecase which requires this
feature)
> Add an option to not fail when remote file already exists and redeploy is
> forbidden
> ---
>
> Key: MDEPLOY-114
> URL: https://jira.codehaus.org/browse/MDEPLOY-114
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Wish
> Components: deploy:deploy
>Affects Versions: 2.4
>Reporter: Julien HENRY
>Assignee: Robert Scholte
> Labels: contributers-welcome
>
> In my organisation we are using a MRM (Nexus) with redeployment of release
> that is forbidden.
> Sometimes the release:perform may fail in the middle of a multi-module
> release. It means some modules were deployed but other are not.
> Currently it is not possible to restart the release as it will fail on first
> deployment (usually the parent pom of the multimodule) because the pom was
> already deployed during the first attempt.
> I would like to add an option to the deploy plugin that may deal with this
> case. Perhaps an option like -Dredeploy=false that may either :
> 1) check if the remote file already exists before trying to upload
> 2) try to upload everytime but not fail the build
> The problem with the second proposal is the error returned by Nexus is
> authorization error so we may not be able to distinguish real authorization
> error on a new file and redeploy attempt.
> Caused by: org.apache.maven.wagon.authorization.AuthorizationException:
> Access denied to: http://nexus.mycompany.com/
> content/repositories/myrepo/com/mycustomer/project/parent/3.2.0/parent-3.2.0.pom
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:360)
> Other options may be more complicated like implementing an atomic deploy
> process on multimodule (may need a big change of the deploy protocol).
--
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-933) forkMode onceperthread broken after fix for JUnit category filter with empty result
[
https://jira.codehaus.org/browse/SUREFIRE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315790#comment-315790
]
Andreas Gudian commented on SUREFIRE-933:
-
Thank you for applying it. :)
> forkMode onceperthread broken after fix for JUnit category filter with empty
> result
> ---
>
> Key: SUREFIRE-933
> URL: https://jira.codehaus.org/browse/SUREFIRE-933
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
>
> In forkMode {{onceperthread}} (reusable fork), the {{TestsToRun}} object will
> always be a {{LazyTestsToRun}} instance, which throws an excetpion if
> {{getLocatedClasses()}} is called. The fix for SUREFIRE-839 changed
> {{JUnitCoreWrapper}} and {{JUnitCoreProvider}} to call exactly that method.
--
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] (MDEPLOY-143) deploy-file goal insists on deploying javadoc file for previous deploy-file execution
[
https://jira.codehaus.org/browse/MDEPLOY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315791#comment-315791
]
Robert Scholte commented on MDEPLOY-143:
{quote}Uploading:
http://foo.lan:/nexus/content/repositories/releases/a/b/c/com/vendorx/vjdbc99/11.2.0.1.0/vjdbc99-11.2.0.1.0-javadoc.jar{quote}
This should have been
Uploading:
http\://foo.lan:/nexus/content/repositories/releases/a/b/c/com/vendorx/vjdbc99{color:red}_g{color}/11.2.0.1.0/vjdbc99{color:red}_g{color}-11.2.0.1.0-javadoc.jar
> deploy-file goal insists on deploying javadoc file for previous deploy-file
> execution
> -
>
> Key: MDEPLOY-143
> URL: https://jira.codehaus.org/browse/MDEPLOY-143
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Windows Server 2008 32bit
> jdk 1.6.0_27-b07
>Reporter: JF
>Priority: Minor
>
> I have a pom which I use to package some third party jars to deploy to a
> local nexus.
> However it always fails with the second upload. It seems as if it is always
> picking up the javadoc associated with the first deploy-file execution,
> eventhough I have not specified this.
> Is this a bug, or what am I doing wrong?
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> a.b.c
> vendorx_jdbc_driver_wrapper
> 0.0.1-SNAPSHOT
> pom
>
>
>
> ${basedir}/files/11.2.0.1.0/jdbc/javadoc.zip
>
> ${basedir}/files/11.2.0.1.0/jdbc/javadoctemp
>
> ${basedir}/files/11.2.0.1.0/jdbc/javadoctemp/thejavadocs.jar
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.2
>
>
> prepare
> validate
>
> run
>
>
>
>
>includeemptydirs="true">
>dir="${vendorx_jdbc_driver_wrapper.javadoctemp}" includes="**/*"
> defaultexcludes="false"/>
>
>src="${vendorx_jdbc_driver_wrapper.javadoczip}"
> dest="${vendorx_jdbc_driver_wrapper.javadoctemp}" />
>
>destfile="${vendorx_jdbc_driver_wrapper.javadocfile}"
> basedir="${vendorx_jdbc_driver_wrapper.javadoctemp}/E13995_02/html"/>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.3.1
>
>
> install-library-main
> install
>
> install-file
>
>
>
> ${basedir}/files/11.2.0.1.0/jdbc/lib/vjdbc99.jar
>
> a.b.c.com.vendorx
> vjdbc99
> 11.2.0.1.0
> jar
> true
>
>
>
> install-javadocs-main
> install
>
> install-file
>
>
>
> ${vendorx_jdbc_driver_wrapper.javadocfile}
>
> a.b.c.com.vendorx
> vjdbc99
>
[jira] (MDEPLOY-143) deploy-file goal insists on deploying javadoc file for previous deploy-file execution
[
https://jira.codehaus.org/browse/MDEPLOY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315791#comment-315791
]
Robert Scholte edited comment on MDEPLOY-143 at 12/16/12 1:45 PM:
--
{quote}Uploading:
http://foo.lan:/nexus/content/repositories/releases/a/b/c/com/vendorx/vjdbc99/11.2.0.1.0/vjdbc99-11.2.0.1.0-javadoc.jar{quote}
This should have been
Uploading:
http\://foo.lan:/nexus/content/repositories/releases/a/b/c/com/vendorx/vjdbc99{color:red}_g{color}/11.2.0.1.0/vjdbc99{color:red}_g{color}-11.2.0.1.0-javadoc.jar
Which version of Maven were you using?
was (Author: rfscholte):
{quote}Uploading:
http://foo.lan:/nexus/content/repositories/releases/a/b/c/com/vendorx/vjdbc99/11.2.0.1.0/vjdbc99-11.2.0.1.0-javadoc.jar{quote}
This should have been
Uploading:
http\://foo.lan:/nexus/content/repositories/releases/a/b/c/com/vendorx/vjdbc99{color:red}_g{color}/11.2.0.1.0/vjdbc99{color:red}_g{color}-11.2.0.1.0-javadoc.jar
> deploy-file goal insists on deploying javadoc file for previous deploy-file
> execution
> -
>
> Key: MDEPLOY-143
> URL: https://jira.codehaus.org/browse/MDEPLOY-143
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Windows Server 2008 32bit
> jdk 1.6.0_27-b07
>Reporter: JF
>Priority: Minor
>
> I have a pom which I use to package some third party jars to deploy to a
> local nexus.
> However it always fails with the second upload. It seems as if it is always
> picking up the javadoc associated with the first deploy-file execution,
> eventhough I have not specified this.
> Is this a bug, or what am I doing wrong?
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> a.b.c
> vendorx_jdbc_driver_wrapper
> 0.0.1-SNAPSHOT
> pom
>
>
>
> ${basedir}/files/11.2.0.1.0/jdbc/javadoc.zip
>
> ${basedir}/files/11.2.0.1.0/jdbc/javadoctemp
>
> ${basedir}/files/11.2.0.1.0/jdbc/javadoctemp/thejavadocs.jar
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.2
>
>
> prepare
> validate
>
> run
>
>
>
>
>includeemptydirs="true">
>dir="${vendorx_jdbc_driver_wrapper.javadoctemp}" includes="**/*"
> defaultexcludes="false"/>
>
>src="${vendorx_jdbc_driver_wrapper.javadoczip}"
> dest="${vendorx_jdbc_driver_wrapper.javadoctemp}" />
>
>destfile="${vendorx_jdbc_driver_wrapper.javadocfile}"
> basedir="${vendorx_jdbc_driver_wrapper.javadoctemp}/E13995_02/html"/>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.3.1
>
>
> install-library-main
> install
>
> install-file
>
>
>
> ${basedir}/files/11.2.0.1.0/jdbc/lib/vjdbc99.jar
>
> a.b.c.com.vendorx
> vjdbc99
> 11.2.0.1.0
> jar
> true
>
>
>
>
[jira] (MDEPLOY-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ https://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315792#comment-315792 ] Robert Scholte commented on MDEPLOY-120: Maybe WAGON-381? > Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 > Enterprise > > > Key: MDEPLOY-120 > URL: https://jira.codehaus.org/browse/MDEPLOY-120 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.5 > Environment: Nexus Server: > Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 > 17:17:21 EST 2007 i686 i686 i386 GNU/Linux > Maven client OS: > Windows Server 2003 Enterprise with all security updates applied > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) > Output from mvn -v: > Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) > Java version: 1.6.0_14 > Java home: D:\jdk1.6.0_14\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows" >Reporter: Keith Wedinger >Priority: Blocker > Attachments: mavenuploadfiles.zip, mvn1024.log, mvn1536.log > > > Attached to this issue are the files I am using to deploy a large file to my > Nexus repository. The file being deployed is an EXE file whose size is > 22,413,688 bytes. During deployment, the upload times out after several > minutes with the stack trace below which I captured by running mvn with the > -X argument. Deploying smaller files does appear to work but I have not done > enough testing to determine the threshold when deployment fails. There is no > proxy between the client OS and the Nexus server. The steps to reproduce > this on my system are below. > 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 > Enterprise system. > 2. Run mavenupload.cmd to get the syntax for this command script. The > syntax message is self-explanatory. > The ZIP file also contains my copy of settings.xml, the Maven settings file I > am using. > If you believe this is a Nexus 1.5.0 issue, please let me know and I will > open the appropriate bug for Nexus OSS 1.5.0. > STACK TRACE BEGIN: > -- > Error writing to server > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error transferring file > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.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:592) > 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: Error deploying > artifact: Error transferring file > at > org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240) > 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.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Error transferring file > at > org.apache.maven.ar
[jira] (MDEPLOY-47) Timeout during SCP upload
[ https://jira.codehaus.org/browse/MDEPLOY-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-47. - Resolution: Cannot Reproduce Assignee: Robert Scholte No feedback for over a year, so closing it. > Timeout during SCP upload > - > > Key: MDEPLOY-47 > URL: https://jira.codehaus.org/browse/MDEPLOY-47 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP, Java 1.5, Maven 2.0.4 >Reporter: Dennis Kieselhorst >Assignee: Robert Scholte > Labels: scrub-review-started > > It seems that there is a timeout during the upload. Unfortunately the > deploy-plugin doesn't detect it. I have to close the console and kill the > java process in the task manager. > Uploading: > scp://mydevserver/opt/www/htdocs/maven2/de/dekies/test/test-client/2.8.27rc2/test-client-2.8.27rc2.jar > 4/20K > 8/20K > 12/20K > 16/20K > 20/20K > 20/20K > 20K uploaded > [INFO] Retrieving previous metadata from dekies > [INFO] Uploading repository metadata for: 'artifact > de.dekies.test:test-client' > [INFO] Retrieving previous metadata from dekies > [INFO] Uploading project information for test-client 2.8.27rc2 > --> nothing happens after this (for hours)! -- 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-670) Cannot use site.xml generated by effective-site goal and output parameter as is
[
https://jira.codehaus.org/browse/MSITE-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSITE-670:
Description:
When no site descriptor file exists in the project,
executing the effective-site goal and the site goal in order like below fails.
>mvn -Doutput=src/site/site.xml site:effective-site
>mvn site:site
Error:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.2:site (default-cli) on project
maven-exercise: SiteToolException: Error parsing site descriptor: processing
instruction can not have PITarget with reserveld xml name (position:
START_DOCUMENT seen ...
-->\r\n\r\n [Help 1]
The contents of site.xml generated by effective-site goal:
{code:xml}
http://maven.apache.org/DECORATION/1.3.0
http://maven.apache.org/xsd/decoration-1.3.0.xsd"; name="maven-exercise"
xmlns="http://maven.apache.org/DECORATION/1.3.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
maven-exercise
{code}
When no site descriptor file exists, could you make the generated contents by
the effective-site goal with the output parameter valid as a site descriptor
file, so that the site goal works without removing duplicate XML declaration
and the comments manually from it first?
was:
When no site descriptor file exists in the project,
executing the effective-site goal and the site goal in order like below fails.
>mvn -Doutput=src/site/site.xml site:effective-site
>mvn site:site
Error:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.2:site (default-cli) on project
maven-exercise: SiteToolException: Error parsing site descriptor: processing
instruction can not have PITarget with reserveld xml name (position:
START_DOCUMENT seen ...
-->\r\n\r\n [Help 1]
The contents of site.xml generated by effective-site goal:
http://maven.apache.org/DECORATION/1.3.0
http://maven.apache.org/xsd/decoration-1.3.0.xsd"; name="maven-exercise"
xmlns="http://maven.apache.org/DECORATION/1.3.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
maven-exercise
When no site descriptor file exists, could you make the generated contents by
the effective-site goal with the output parameter valid as a site descriptor
file, so that the site goal works without removing duplicate XML declaration
and the comments manually from it first?
> Cannot use site.xml generated by effective-site goal and output parameter as
> is
> ---
>
> Key: MSITE-670
> URL: https://jira.codehaus.org/browse/MSITE-670
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site descriptor
>Affects Versions: 3.2
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>Reporter: Arata
>Priority: Minor
>
> When no site descriptor file exists in the project,
> executing the effective-site goal and the site goal in order like below fails.
> >mvn -Doutput=src/site/site.xml site:effective-site
> >mvn site:site
> Error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.2:site (default-cli) on project
> maven-exercise: SiteToolException: Error parsing site descriptor: processing
> instruction can not have PITarget with reserveld xml name (position:
> START_DOCUMENT seen ...
> -->\r\n\r\n [Help 1]
> The contents of site.xml generated by effective-site goal:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> http://maven.apache.org/DECORATION/1.3.0
> http://maven.apache.org/xsd/decoration-1.3.0.xsd"; name="maven-exercise"
> xmlns="http://maven.apache.org/DECORATION/1.3.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
> maven-exercise
>
>
>
>
>
>
>
>
> {code}
> When no site descriptor file exists, could you make the generated contents by
> the effective-site goal with the output parameter valid as a site descriptor
> file, so that the site goal works without removing duplicate XML declaration
> and the comments manually from it first?
--
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-670) Cannot use site.xml generated by effective-site goal and output parameter as is
[
https://jira.codehaus.org/browse/MSITE-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-670.
---
Resolution: Fixed
Fix Version/s: 3.3
Assignee: Herve Boutemy
whoops, the http://svn.apache.org/viewvc?rev=1422691&view=rev]
> Cannot use site.xml generated by effective-site goal and output parameter as
> is
> ---
>
> Key: MSITE-670
> URL: https://jira.codehaus.org/browse/MSITE-670
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site descriptor
>Affects Versions: 3.2
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>Reporter: Arata
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 3.3
>
>
> When no site descriptor file exists in the project,
> executing the effective-site goal and the site goal in order like below fails.
> >mvn -Doutput=src/site/site.xml site:effective-site
> >mvn site:site
> Error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.2:site (default-cli) on project
> maven-exercise: SiteToolException: Error parsing site descriptor: processing
> instruction can not have PITarget with reserveld xml name (position:
> START_DOCUMENT seen ...
> -->\r\n\r\n [Help 1]
> The contents of site.xml generated by effective-site goal:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
> http://maven.apache.org/DECORATION/1.3.0
> http://maven.apache.org/xsd/decoration-1.3.0.xsd"; name="maven-exercise"
> xmlns="http://maven.apache.org/DECORATION/1.3.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
> maven-exercise
>
>
>
>
>
>
>
>
> {code}
> When no site descriptor file exists, could you make the generated contents by
> the effective-site goal with the output parameter valid as a site descriptor
> file, so that the site goal works without removing duplicate XML declaration
> and the comments manually from it first?
--
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-668) using groupId in url href should expand comonent dots . into proper path name
[ https://jira.codehaus.org/browse/MSITE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSITE-668. --- Resolution: Not A Bug I don't understand either, and without reply, we can't do anything > using groupId in url href should expand comonent dots . into proper path name > - > > Key: MSITE-668 > URL: https://jira.codehaus.org/browse/MSITE-668 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: documentation >Affects Versions: 2.3 >Reporter: warren crossing >Priority: Minor > > http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html > groupId > A groupId groups a set of related artifacts. Group identifiers generally > resemble a Java package name. For example, the groupId org.apache.maven is > the base groupId for all artifacts produced by the Apache Maven project. > Group identifiers are translated into paths in the Maven Repository; for > example, the org.apache.maven groupId can be found in > /maven2/org/apache/maven on repo1.maven.org. > Please help me identify where this should be done and if so and I will patch > it. -- 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-668) using groupId in url href should expand comonent dots . into proper path name
[
https://jira.codehaus.org/browse/MSITE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
warren crossing reopened MSITE-668:
---
I'm trying to link to the repository where the artifact is uploaded in a
repeatable way.
http://www.mysite.eu/artifactory/snapshots-public/${project.groupId}/${project.artifactId}/${project.version}/"/>
If the groupId is some.project.package and the artifact is codebase then the
url should be interpolated to
http://www.mysite.eu/artifactory/snapshots-public/some/project/package/codebase-1.0/
Maybe there is a way to do this using the velocity engine, or maybe it should
be responsibility of site plugin variable interpolation? It is part of maven
spec that . are expanded to / in repos.
Your thoughts?
> using groupId in url href should expand comonent dots . into proper path name
> -
>
> Key: MSITE-668
> URL: https://jira.codehaus.org/browse/MSITE-668
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.3
>Reporter: warren crossing
>Priority: Minor
>
> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html
> groupId
> A groupId groups a set of related artifacts. Group identifiers generally
> resemble a Java package name. For example, the groupId org.apache.maven is
> the base groupId for all artifacts produced by the Apache Maven project.
> Group identifiers are translated into paths in the Maven Repository; for
> example, the org.apache.maven groupId can be found in
> /maven2/org/apache/maven on repo1.maven.org.
> Please help me identify where this should be done and if so and I will patch
> it.
--
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-668) using groupId in url href should expand comonent dots . into proper path name
[
https://jira.codehaus.org/browse/MSITE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315806#comment-315806
]
Lukas Theussl commented on MSITE-668:
-
Should be closed 'Won't fix' IMO. The character replacement can be easily done
with velocity, e.g:
{noformat}
#set ( $id = $groupId.replaceAll( '.', '/' ) )
{noformat}
It would be very confusing (and simply incorrect) if the site plugin (or some
doxia macro) would do the replacement by default.
> using groupId in url href should expand comonent dots . into proper path name
> -
>
> Key: MSITE-668
> URL: https://jira.codehaus.org/browse/MSITE-668
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.3
>Reporter: warren crossing
>Priority: Minor
>
> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-relationships.html
> groupId
> A groupId groups a set of related artifacts. Group identifiers generally
> resemble a Java package name. For example, the groupId org.apache.maven is
> the base groupId for all artifacts produced by the Apache Maven project.
> Group identifiers are translated into paths in the Maven Repository; for
> example, the org.apache.maven groupId can be found in
> /maven2/org/apache/maven on repo1.maven.org.
> Please help me identify where this should be done and if so and I will patch
> it.
--
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-669) site:stage creates incorrect structure when module paths contains sets of "../"
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-669.
---
Resolution: Incomplete
Assignee: Lukas Theussl
> 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.1, 3.2
>Reporter: Lennart Jörelid
>Assignee: Lukas Theussl
>
> 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] (SUREFIRE-938) out of memory when logging more messages than heap size
Andrew Gaul created SUREFIRE-938: Summary: out of memory when logging more messages than heap size Key: SUREFIRE-938 URL: https://jira.codehaus.org/browse/SUREFIRE-938 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.12.4 Reporter: Andrew Gaul Observed OOM when logging more messages than heap size: Exception in thread "ThreadedStreamConsumer" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.(String.java:215) at java.lang.StringBuilder.toString(StringBuilder.java:430) at org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:225) at org.apache.maven.plugin.surefire.report.TestSetRunListener.wrap(TestSetRunListener.java:230) at org.apache.maven.plugin.surefire.report.TestSetRunListener.testSucceeded(TestSetRunListener.java:161) at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:100) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) at java.lang.Thread.run(Thread.java:662) -- 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
