[jira] (MNG-5688) mvn script is not compatible with OSX (Darwin) - PATCH ATTACHED
[ https://jira.codehaus.org/browse/MNG-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5688: --- Fix Version/s: 3.3.1 mvn script is not compatible with OSX (Darwin) - PATCH ATTACHED --- Key: MNG-5688 URL: https://jira.codehaus.org/browse/MNG-5688 Project: Maven Issue Type: Bug Components: Command Line, General Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.3 Environment: Darwin hostname.home 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014 Reporter: Arcadiy Ivanov Fix For: 3.3.1 Attachments: mvn.patch mvn shell script contains readlink logic that does not work on Mac OS X. Patch is attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://jira.codehaus.org/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364984#comment-364984 ] Tibor Digana commented on SUREFIRE-1147: @Laurent Can you test surefire 2.17, 2.16 from Maven Central? Thx Unbounded memory usage when running MANY tests -- Key: SUREFIRE-1147 URL: https://jira.codehaus.org/browse/SUREFIRE-1147 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.18.1 Environment: win7, jdk 8u25, mvn 3.2.5 Reporter: Laurent Claisse Attachments: surefire-allocation-traces.png, surefire-leak2.png, surefire-leak3.png, surefire-leak.png I'm writing concurrency tests, checking that this thing is reproducible, that other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to reproduce the leak, the test project is here: https://github.com/vandekeiser/parallel-stream-fork-join-pool) I see in VisualVM that the culprit is WrappedReportEntry, which indirectly holds references to lots of byte[] and char[] (allocation traces and heap dump pics are included in attachment) I forked and patched maven-surefire-common, and that makes the leak go. I had to replace WrappedReportEntry.original by a singleton fake ReportEntry. Bebefore that i had replaced Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a NullOutputStream and the leak was lesser but still here. My fork of maven-surefire-common is there: https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. It IS a patch so i checked the patch checkbox in the issue reporter, but it is NOT intended to be distributed of course since it is very brutal and basic. Also in my test project i explicitly deactivated reporting, but that doesn't make the reporting leak go away at all: disableXmlReporttrue/disableXmlReport printSummaryfalse/printSummary -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-225) Release notes links on site give one the runaround
[ https://jira.codehaus.org/browse/MNGSITE-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364979#comment-364979 ] Eric Schwarzenbach commented on MNGSITE-225: Also, you would think the download would include the release notes. But no, the readme offers a link to the release notes: http://maven.apache.org/release-notes.html which redirects to http://maven.apache.org/release-notes-all.html Release notes links on site give one the runaround -- Key: MNGSITE-225 URL: https://jira.codehaus.org/browse/MNGSITE-225 Project: Maven Project Web Site Issue Type: Bug Reporter: Eric Schwarzenbach They send one on a circlular journey the never arrives at the notes. This page http://maven.apache.org/docs/3.2.5/release-notes.html has a complete release notes for all versions link to http://maven.apache.org/release-notes-all.html which has a Release notes for Maven 3.2.5 link back to http://maven.apache.org/docs/3.2.5/release-notes.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-225) Release notes links on site give one the runaround
Eric Schwarzenbach created MNGSITE-225: -- Summary: Release notes links on site give one the runaround Key: MNGSITE-225 URL: https://jira.codehaus.org/browse/MNGSITE-225 Project: Maven Project Web Site Issue Type: Bug Reporter: Eric Schwarzenbach They send one on a circlular journey the never arrives at the notes. This page http://maven.apache.org/docs/3.2.5/release-notes.html has a complete release notes for all versions link to http://maven.apache.org/release-notes-all.html which has a Release notes for Maven 3.2.5 link back to http://maven.apache.org/docs/3.2.5/release-notes.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5688) mvn script is not compatible with OSX (Darwin) - PATCH ATTACHED
[ https://jira.codehaus.org/browse/MNG-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5688. -- Resolution: Fixed Patch applied 2f21481d068ddf77d97ecf82ca962537cc6c21bb mvn script is not compatible with OSX (Darwin) - PATCH ATTACHED --- Key: MNG-5688 URL: https://jira.codehaus.org/browse/MNG-5688 Project: Maven Issue Type: Bug Components: Command Line, General Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.3 Environment: Darwin hostname.home 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014 Reporter: Arcadiy Ivanov Fix For: 3.3.1 Attachments: mvn.patch mvn shell script contains readlink logic that does not work on Mac OS X. Patch is attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365001#comment-365001
]
Dawid Weiss commented on MASSEMBLY-742:
---
Hi Krisitan. Thanks for the heads up. I'm on vacation this week and I won't be
able to verify if everything works as expected. I will let you know once I come
back. This shouldn't hold the release; it's not a showstopper, it is merely
annoying.
Unclosed ZipFile warnings when ZIP archives are included
Key: MASSEMBLY-742
URL: https://jira.codehaus.org/browse/MASSEMBLY-742
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5.2
Reporter: Dawid Weiss
Assignee: Kristian Rosenvold
Priority: Minor
Fix For: 2.5.3, 2.5.4
Attachments: example.zip, MASSEMBLY-742.patch
I get the following warnings at the end of Maven build:
{code}
Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
{code}
These warnings originate from assembly plugin, but in fact they're caused by
the fact that plexus resource abstraction opens up a ZipFile from
commons-compress, but never closes it. Commons-compress then force-closes all
such objects in finalize, emitting a warning.
I created a synthetic capture of the allocation stack in maven assembly, it's
here:
{code}
org.apache.commons.compress.archivers.zip.ZipFile.init(ZipFile.java:211)
org.apache.commons.compress.archivers.zip.ZipFile.init(ZipFile.java:193)
org.apache.commons.compress.archivers.zip.ZipFile.init(ZipFile.java:154)
org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:483)
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{code}
Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
[
https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364997#comment-364997
]
Chris Graham commented on SCM-775:
--
No, this appears to be the most active issue for me at the moment, and I'll be
working on them all at the same time, as well as one or two more that I need to
add.
Request for new optional parameter RTC (workItem) with release:prepare to
associate workitem with changesets got created during build process
-
Key: SCM-775
URL: https://jira.codehaus.org/browse/SCM-775
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
Maven {{release:prepare}} command is failing with below error while
delivering updated pom.xml to the stream due to Preconditions configured in
RTC to have comments and associated work item with every delivery.
{noformat}
[ERROR] Name: Deliver
[ERROR] Participant Reports:
[ERROR] Name: Require Work items and Comments
[ERROR] A work item must be associated with the change set.`
[ERROR] At least one of the associated work items must specify that the work
is planned for the current iteration.
[ERROR] At least one of the associated work items must be assigned to you.
[ERROR] Problem running 'deliver':
[ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
be associated with the change set.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
on project junit-ext: Unable to commit files
Provider message:
Error code for Jazz SCM deliver command - 17
{noformat}
I can not find any optional parameters on
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
for release:prepare command which I can use and pass the RTC workitem number
on command line.
Suggestion:
It will be great if you can provide optional parameters like workItem which
I can use and pass RTC workitem number with release:prepare at command line.
Example: {{mvn -PmyProfile release:prepare -DworkItem=123456}}
So build process should associate change sets created by {{release:prepare}}
with work item 123456 and deliver change sets to the stream.
As of now I have to use {{-DpushChanges=false}} parameter to block delivery
process and I have to manually find the change sets, associate them with work
item and deliver them before I run {{release:perform}}.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-347) javadoc:aggregate-jar doesn't create Javadoc JAR if failOnError=false and there is an error
[
https://jira.codehaus.org/browse/MJAVADOC-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MJAVADOC-347:
-
Fix Version/s: (was: 2.10.2)
next-release
javadoc:aggregate-jar doesn't create Javadoc JAR if failOnError=false and
there is an error
---
Key: MJAVADOC-347
URL: https://jira.codehaus.org/browse/MJAVADOC-347
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Luis Miranda
Fix For: next-release
Attachments:
0001-MJAVADOC-347-added-JavadocJarTest.testContinueIfFail.patch,
0002-MJAVADOC-347-continue-with-archive-creation-if-failO.patch
We are generating Javadocs for a large multi-module build, so there are bound
to be some errors (for example, in 3rd party dependencies).
Currently we set failOnError=false, but we found that the {{aggregate-jar}}
MOJO does not produce a JAR if there are errors. The problem comes down to
this code in JavadocJar:
{code}
try
{
executeReport( Locale.getDefault() );
if ( innerDestDir.exists() )
{
File outputFile = generateArchive( innerDestDir, finalName +
- + getClassifier() + .jar );
if ( !attach )
{
getLog().info( NOT adding javadoc to attached artifacts
list. );
}
else
{
// TODO: these introduced dependencies on the project are
going to become problematic - can we expor
// through metadata instead?
projectHelper.attachArtifact( project, javadoc,
getClassifier(), outputFile );
}
}
}
catch ( ArchiverException e )
{
failOnError( ArchiverException: Error while creating archive, e
);
}
catch ( IOException e )
{
failOnError( IOException: Error while creating archive, e );
}
catch ( MavenReportException e )
{
failOnError( MavenReportException: Error while creating
archive, e );
}
catch ( RuntimeException e )
{
failOnError( RuntimeException: Error while creating archive, e
);
}
{code}
If there is an error in {{executeReport( Locale.getDefault() )}} then the
MOJO will just give up and not try to create the archive. I think that if
failOnError is set, then we should try to create the archive anyway.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-474) .gitignore file is not copied to archetype JAR
[
https://jira.codehaus.org/browse/ARCHETYPE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schlichtherle updated ARCHETYPE-474:
--
Affects Version/s: 2.3
.gitignore file is not copied to archetype JAR
--
Key: ARCHETYPE-474
URL: https://jira.codehaus.org/browse/ARCHETYPE-474
Project: Maven Archetype
Issue Type: Bug
Components: Creator
Affects Versions: 2.2, 2.3
Reporter: Christian Schlichtherle
In the file {{src/main/resources/META-INF/maven/archetype-metadata.xml}}, I
have something like this:
{code}
...
fileSets
fileSet filtered=false packaged=false
directory/
includes
include.*ignore/include
/includes
/fileSet
/fileSets
...
{code}
In the directory {{src/main/resources/archetype-resources}}, there are two
files {{.gitignore}} and {{.hgignore}}. Now when I create the archetype from
the resources, only the {{.hgignore}} file gets copied into the archetype,
but not the {{.gitignore}} file.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-714) display statistics about Doxia documents rendered
[ https://jira.codehaus.org/browse/MSITE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-714: Description: there is info on reports generation, but nothing on Doxia document parsed (or *when* it happens, either before or after reports) was: there is info on reports generation, but nothing on Doxia document parsed (adn even *when* it happens, either before or after reports) display statistics about Doxia documents rendered - Key: MSITE-714 URL: https://jira.codehaus.org/browse/MSITE-714 Project: Maven Site Plugin Issue Type: Improvement Components: doxia integration Affects Versions: 3.3 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.4 there is info on reports generation, but nothing on Doxia document parsed (or *when* it happens, either before or after reports) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-714) display statistics about Doxia documents rendered
[ https://jira.codehaus.org/browse/MSITE-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSITE-714: Description: there is info on reports generation, but nothing on Doxia document parsed (adn even *when* it happens, either before or after reports) was: there is info on reports generation, but nothing on Doxia document parsed display statistics about Doxia documents rendered - Key: MSITE-714 URL: https://jira.codehaus.org/browse/MSITE-714 Project: Maven Site Plugin Issue Type: Improvement Components: doxia integration Affects Versions: 3.3 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.4 there is info on reports generation, but nothing on Doxia document parsed (adn even *when* it happens, either before or after reports) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-215) Add flag for recompressZippedFiles
Falko Modler created MEAR-215: - Summary: Add flag for recompressZippedFiles Key: MEAR-215 URL: https://jira.codehaus.org/browse/MEAR-215 Project: Maven Ear Plugin Issue Type: New Feature Affects Versions: 2.10 Reporter: Falko Modler Priority: Minor Just like: https://jira.codehaus.org/browse/MASSEMBLY-630 https://jira.codehaus.org/browse/MWAR-292 See also: https://jira.codehaus.org/browse/MASSEMBLY-639 https://jira.codehaus.org/browse/MWAR-297 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364924#comment-364924
]
Kristian Rosenvold commented on MASSEMBLY-742:
--
I have tested your project. As long as plexus-io 2.5 is used *together* with
the latest snapshot of archiver, it should work properly. Sorry about the delay
on this one, you may want to give it a spin... I'll be releasing soon
Unclosed ZipFile warnings when ZIP archives are included
Key: MASSEMBLY-742
URL: https://jira.codehaus.org/browse/MASSEMBLY-742
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.5.2
Reporter: Dawid Weiss
Assignee: Kristian Rosenvold
Priority: Minor
Fix For: 2.5.3, 2.5.4
Attachments: example.zip, MASSEMBLY-742.patch
I get the following warnings at the end of Maven build:
{code}
Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
{code}
These warnings originate from assembly plugin, but in fact they're caused by
the fact that plexus resource abstraction opens up a ZipFile from
commons-compress, but never closes it. Commons-compress then force-closes all
such objects in finalize, emitting a warning.
I created a synthetic capture of the allocation stack in maven assembly, it's
here:
{code}
org.apache.commons.compress.archivers.zip.ZipFile.init(ZipFile.java:211)
org.apache.commons.compress.archivers.zip.ZipFile.init(ZipFile.java:193)
org.apache.commons.compress.archivers.zip.ZipFile.init(ZipFile.java:154)
org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:483)
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{code}
Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-471) Make a final Maven 2.2.1 release
[ https://jira.codehaus.org/browse/ARCHETYPE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed ARCHETYPE-471. -- Resolution: Fixed Make a final Maven 2.2.1 release Key: ARCHETYPE-471 URL: https://jira.codehaus.org/browse/ARCHETYPE-471 Project: Maven Archetype Issue Type: Task Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 2.3 Release current state with prereqs amped up to 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1149) Tests from dependency jar ignore parallel execution
[
https://jira.codehaus.org/browse/SUREFIRE-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364939#comment-364939
]
Tibor Digana commented on SUREFIRE-1149:
Run
mvn help:effective-pom log.txt
and have a look in log.txt what junit version is used - let us know.
If you remove dependenciesToScan, is the running in parallel?
Which failsafe version worked in this example?
I don't understand how you use this POM.
In first part of the description you say that does fork, and finally this forks:
mvn failsafe:integration-test -DforkCount=3
So what's the difference in forking mode without parameter parallel/ ?
Tests from dependency jar ignore parallel execution
---
Key: SUREFIRE-1149
URL: https://jira.codehaus.org/browse/SUREFIRE-1149
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin,
Maven Surefire Plugin, process forking
Affects Versions: 2.18.1
Reporter: Christopher Smith
Attachments: pom.xml
I have a Selenium test suite that is contained in a module of my main
application but that needs to be run against an instance deployed to a
staging environment. I package the tests into a jar and have a separate POM
that declares {{dependenciesToScan}} and is executed in a later CI step. The
tests execute, but the runner completely ignores any parallel configuration:
neither {{parallel}} nor {{forkCount}} has any effect. The debug log shows
that the plugin is switching to parallel mode, but then it runs them serially
in a single Java process. As these are browser-driving tests, serial
execution drastically increases running time.
Running the tests directly from the main project tree using {{mvn
failsafe:integration-test -DforkCount=3}} forks multiple JVMs and executes
the tests in parallel.
The attached POM is the one used to execute the tests after deployment, and
which ignores parallel execution for test from the jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
[
https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364975#comment-364975
]
AShit Shah commented on SCM-775:
Hi Chris,
I think by mistake you inserted your comment (Chris Graham added a comment -
Yesterday 7:53 PM) on wrong Ticket. This ticket is for optional parameter RTC
(workItem) with release:prepare to associate workitem with changesets got
created during build process.
Issue you are referring in comment is issue with mvn release:perform + Jazz
RTC SCM-774.
I have already provided platform information in SCM-774 ticket.
Thanks.
Request for new optional parameter RTC (workItem) with release:prepare to
associate workitem with changesets got created during build process
-
Key: SCM-775
URL: https://jira.codehaus.org/browse/SCM-775
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-jazz
Affects Versions: 1.9.1
Reporter: AShit Shah
Maven {{release:prepare}} command is failing with below error while
delivering updated pom.xml to the stream due to Preconditions configured in
RTC to have comments and associated work item with every delivery.
{noformat}
[ERROR] Name: Deliver
[ERROR] Participant Reports:
[ERROR] Name: Require Work items and Comments
[ERROR] A work item must be associated with the change set.`
[ERROR] At least one of the associated work items must specify that the work
is planned for the current iteration.
[ERROR] At least one of the associated work items must be assigned to you.
[ERROR] Problem running 'deliver':
[ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
be associated with the change set.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
on project junit-ext: Unable to commit files
Provider message:
Error code for Jazz SCM deliver command - 17
{noformat}
I can not find any optional parameters on
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
for release:prepare command which I can use and pass the RTC workitem number
on command line.
Suggestion:
It will be great if you can provide optional parameters like workItem which
I can use and pass RTC workitem number with release:prepare at command line.
Example: {{mvn -PmyProfile release:prepare -DworkItem=123456}}
So build process should associate change sets created by {{release:prepare}}
with work item 123456 and deliver change sets to the stream.
As of now I have to use {{-DpushChanges=false}} parameter to block delivery
process and I have to manually find the change sets, associate them with work
item and deliver them before I run {{release:perform}}.
Thanks.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
