[jira] (MPIR-249) new dependency-info report not added to goals index page
Herve Boutemy created MPIR-249: -- Summary: new dependency-info report not added to goals index page Key: MPIR-249 URL: https://jira.codehaus.org/browse/MPIR-249 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependency-info Affects Versions: 2.5 Reporter: Herve Boutemy Priority: Minor -- 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] (MPIR-250) dependency-info packaging information broken: displays ${project.packaging
Herve Boutemy created MPIR-250:
--
Summary: dependency-info packaging information broken: displays
${project.packaging
Key: MPIR-250
URL: https://jira.codehaus.org/browse/MPIR-250
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.5
Reporter: Herve Boutemy
--
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] (MPIR-250) dependency-info packaging information broken: displays ${project.packaging
[
https://jira.codehaus.org/browse/MPIR-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPIR-250.
--
Resolution: Fixed
Fix Version/s: 2.6
Assignee: Simone Tripodi
fixed in [r1369732|https://svn.apache.org/viewvc?view=revisionrevision=1369732]
dependency-info packaging information broken: displays ${project.packaging
Key: MPIR-250
URL: https://jira.codehaus.org/browse/MPIR-250
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.5
Reporter: Herve Boutemy
Assignee: Simone Tripodi
Fix For: 2.6
--
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] (MPIR-147) Dependencies report hangs while accessing SSL site. Connection never closes
[
https://jira.codehaus.org/browse/MPIR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPIR-147:
---
Description:
mvn site hangs while generating the reports (dump below). This is 100%
reproducible.
This happens while contacting maven-repository.dev.java.net. The connection is
opened and never closed. The connection to this external repository was done
successfully several time in the same build.
Notes:
* a timeout would be useful:
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
* for some reason, the site report bypass our corporate repository (nexus). Cf
MPIR-137
* workaround is to enable
dependencyLocationsEnabledfalse/dependencyLocationsEnabled
dependencyDetailsEnabledfalse/dependencyDetailsEnabled
as done in MPIR-137
{noformat}
Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-133 mixed mode):
AWT-AppKit daemon prio=5 tid=0x01038530 nid=0xa0110fa0 runnable
[0x..0xbfffe818]
Low Memory Detector daemon prio=5 tid=0x01009030 nid=0x805800 runnable
[0x..0x]
CompilerThread0 daemon prio=9 tid=0x01008580 nid=0x812c00 waiting on
condition [0x..0xb0b077d8]
Signal Dispatcher daemon prio=9 tid=0x01008130 nid=0x811e00 waiting on
condition [0x..0x]
Finalizer daemon prio=8 tid=0x01007860 nid=0x819200 in Object.wait()
[0xb0a05000..0xb0a05d90]
at java.lang.Object.wait(Native Method)
- waiting on 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
- locked 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
Reference Handler daemon prio=10 tid=0x01007480 nid=0x817800 in Object.wait()
[0xb0984000..0xb0984d90]
at java.lang.Object.wait(Native Method)
- waiting on 0x0a4402b0 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked 0x0a4402b0 (a java.lang.ref.Reference$Lock)
main prio=5 tid=0x01001570 nid=0xb0801000 runnable [0xb07fe000..0xb0800148]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
- locked 0x05a4ba78 (a java.lang.Object)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
- locked 0x05a4bb28 (a com.sun.net.ssl.internal.ssl.AppInputStream)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
- locked 0x06b58100 (a java.io.BufferedInputStream)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957)
- locked 0x06b56708 (a
sun.net.www.protocol.https.DelegateHttpsURLConnection)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printArtifactsLocations(DependenciesRenderer.java:1122)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyRepositoryLocations(DependenciesRenderer.java:641)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239)
at
[jira] (MPIR-147) Dependencies report hangs while accessing SSL site. Connection never closes
[
https://jira.codehaus.org/browse/MPIR-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPIR-147.
--
Resolution: Fixed
Fix Version/s: 2.2
Assignee: Vincent Siveton
Dependencies report hangs while accessing SSL site. Connection never closes
---
Key: MPIR-147
URL: https://jira.codehaus.org/browse/MPIR-147
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.1
Reporter: Jerome Lacoste
Assignee: Vincent Siveton
Fix For: 2.2
mvn site hangs while generating the reports (dump below). This is 100%
reproducible.
This happens while contacting maven-repository.dev.java.net. The connection
is opened and never closed. The connection to this external repository was
done successfully several time in the same build.
Notes:
* a timeout would be useful:
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
* for some reason, the site report bypass our corporate repository (nexus).
Cf MPIR-137
* workaround is to enable
dependencyLocationsEnabledfalse/dependencyLocationsEnabled
dependencyDetailsEnabledfalse/dependencyDetailsEnabled
as done in MPIR-137
{noformat}
Full thread dump Java HotSpot(TM) Client VM (1.5.0_16-133 mixed mode):
AWT-AppKit daemon prio=5 tid=0x01038530 nid=0xa0110fa0 runnable
[0x..0xbfffe818]
Low Memory Detector daemon prio=5 tid=0x01009030 nid=0x805800 runnable
[0x..0x]
CompilerThread0 daemon prio=9 tid=0x01008580 nid=0x812c00 waiting on
condition [0x..0xb0b077d8]
Signal Dispatcher daemon prio=9 tid=0x01008130 nid=0x811e00 waiting on
condition [0x..0x]
Finalizer daemon prio=8 tid=0x01007860 nid=0x819200 in Object.wait()
[0xb0a05000..0xb0a05d90]
at java.lang.Object.wait(Native Method)
- waiting on 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:120)
- locked 0x0a440228 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:136)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
Reference Handler daemon prio=10 tid=0x01007480 nid=0x817800 in
Object.wait() [0xb0984000..0xb0984d90]
at java.lang.Object.wait(Native Method)
- waiting on 0x0a4402b0 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked 0x0a4402b0 (a java.lang.ref.Reference$Lock)
main prio=5 tid=0x01001570 nid=0xb0801000 runnable [0xb07fe000..0xb0800148]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
- locked 0x05a4ba78 (a java.lang.Object)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)
at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
- locked 0x05a4bb28 (a com.sun.net.ssl.internal.ssl.AppInputStream)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
- locked 0x06b58100 (a java.io.BufferedInputStream)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:681)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:626)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:957)
- locked 0x06b56708 (a
sun.net.www.protocol.https.DelegateHttpsURLConnection)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at
org.apache.maven.wagon.providers.http.LightweightHttpWagon.resourceExists(LightweightHttpWagon.java:312)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.dependencyExistsInRepo(RepositoryUtils.java:219)
at
[jira] (MPIR-247) Comparison method violates its general contract! while generating site
[
https://jira.codehaus.org/browse/MPIR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305884#comment-305884
]
Herve Boutemy commented on MPIR-247:
can you provide a sample project showing the problem?
Comparison method violates its general contract! while generating site
Key: MPIR-247
URL: https://jira.codehaus.org/browse/MPIR-247
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: java version 1.7.0_04
Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
maven 3.0.4
Reporter: Mirek Hankus
While generating site, I'm getting exception as follows.
{code}
message : Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
netpr-aggregator: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
violates its general contract!
cause : Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
violates its general contract!
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
project netpr-aggregator: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.1:site failed: Comparison method
violates its general contract!
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
failed: Comparison method violates its general contract!
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 27 more
Caused by: java.lang.IllegalArgumentException: Comparison method violates its
general contract!
at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:835)
at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:453)
at java.util.ComparableTimSort.mergeCollapse(ComparableTimSort.java:376)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:182)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:146)
at java.util.Arrays.sort(Arrays.java:472)
at
[jira] (MPIR-143) Wrong scope/phase requirement documented on project-info-reports:dependencies page
[ https://jira.codehaus.org/browse/MPIR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPIR-143. -- Resolution: Incomplete Wrong scope/phase requirement documented on project-info-reports:dependencies page -- Key: MPIR-143 URL: https://jira.codehaus.org/browse/MPIR-143 Project: Maven 2.x Project Info Reports Plugin Issue Type: Task Affects Versions: 2.1 Environment: maven 2.0.9 Reporter: Stevo Slavic Priority: Minor After discussion on maven user mailing list (see http://markmail.org/search/?q=sslavic%20list%3Aorg.apache.maven.users#query:sslavic%20list%3Aorg.apache.maven.users+page:2+mid:kkzcdmruemiwpeei+state:results ) conclusion was that wrong scope is documented on following page: http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependencies-mojo.html in Attributes section where instead of test in Requires dependency resolution of artifacts in scope: test. it should stand package. -- 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] (MPIR-239) Brazillian Portuguese translation
[ https://jira.codehaus.org/browse/MPIR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPIR-239. -- Resolution: Fixed Fix Version/s: 2.5.1 Assignee: Herve Boutemy applied in [r1371124|http://svn.apache.org/viewvc?rev=1371124view=rev] Brazillian Portuguese translation - Key: MPIR-239 URL: https://jira.codehaus.org/browse/MPIR-239 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Daniel Teleginski Camargo Assignee: Herve Boutemy Priority: Minor Fix For: 2.5.1 Attachments: project-info-report_pt_BR.properties Missing parts for the new 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] (SUREFIRE-900) System.err seems to be ignored
[ https://jira.codehaus.org/browse/SUREFIRE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305890#comment-305890 ] Kristian Rosenvold commented on SUREFIRE-900: - Well we might be able to fix that ;) I just said we capture it and then play it back. Of course we can (and should) play back to stderr. System.err seems to be ignored -- Key: SUREFIRE-900 URL: https://jira.codehaus.org/browse/SUREFIRE-900 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.7.2 Environment: OS/X 10.7.4 Reporter: Marco Brandizi Assignee: Kristian Rosenvold Priority: Minor Attachments: testSureFireStdErr.zip See the attached project. If I send something to System.err from a JUnit test and then I try 'mvn test 2/dev/null', I can still see the output on the console, surefire (or Maven?!) seems to ignore this. I've tried with -Dsurefire.forkMode=false too. Is it possible to redirect the standard error? I'd like to do that because I have a few tests that tests a line command (ie, main()). Since the command is supposed to return XML to the invoker (which, for example, might pipe it to another command), I've implemented this command line by sending all the logging output to System.err (that's possible in Logback via the 'Target' option in the Console appender). When I invoke this line command outside Maven/Surefire it works as I want. In Maven, instead, I cannot what I described. -- 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-2971) Variables are not replaced into installed pom file
[
https://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305891#comment-305891
]
Mike Gould commented on MNG-2971:
-
We need this for a multi-module build. We want to specify that some sibling
module dependencies have the same version as the parent or current project. If
we do this:
dependency
groupIdcom.example/groupId
artifactIdcommon/artifactId
version${project.version}/version
scopecompile/scope
/dependency
then the varible appears in the installed pom and then can't be used by
anything.
Currently - like most people - we have a pre-build step which sets all versions
accross the whole tree.
Putting this functionality into the release plugin would be completely useless
as the release plugin simply doesn't do the right thing for CI style builds
where the version is set from the build number/scm revision etc.
Variables are not replaced into installed pom file
--
Key: MNG-2971
URL: https://jira.codehaus.org/browse/MNG-2971
Project: Maven 2 3
Issue Type: Bug
Components: Deployment, Inheritance and Interpolation
Environment: Windows, Solaris
Maven version 2.0.4
Reporter: Laurent Dauvilaire
Assignee: Ralph Goers
Fix For: Issues to be reviewed for 3.x
Attachments: pom.xml
Variables are not replaced into installed pom file.
Here is a sample pom file
project xmlns=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/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.xxx.root/groupId
artifactIdroot/artifactId
packagingpom/packaging
version${prop.version}/version
nameMy Project/name
...
properties
prop.version3.0.20/prop.version
/properties
/project
The installed pom is into
${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
is the same as the project pom file but the version referenced into the
installed pom file is ${prop.version} instead of 3.0.20
which creates problem to artifacts depending of this one.
Thanks in advance
--
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-622) Unable to create TAR artifacts
Ahmed El-Madhoun created MASSEMBLY-622: -- Summary: Unable to create TAR artifacts Key: MASSEMBLY-622 URL: https://jira.codehaus.org/browse/MASSEMBLY-622 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.3 Environment: [aelmadho@aelmadho-laptop Kernel]$ mvn -version Apache Maven 3.0.4 (rNON-CANONICAL_2012-07-25_12-05_mockbuild; 2012-07-25 08:05:49-0400) Maven home: /usr/share/maven Java version: 1.7.0_05-icedtea, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.5.0-2.fc17.x86_64, arch: amd64, family: unix Reporter: Ahmed El-Madhoun Priority: Critical Attachments: assembly.xml, maven-assembly-error.txt, pom.xml To reproduce the case, you may need to just re-point the POM to the assembly descriptor attached. I am simply able to do the same if I specify a type of jar or zip, but not when using any sort of tar based type. We are using this as a primary basis of our build, which is primarily in C, and I would greatly appreciate any help or feedback on this item. Alot of thanks on the great work already! -- 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-622) Unable to create TAR artifacts
[ https://jira.codehaus.org/browse/MASSEMBLY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305895#comment-305895 ] Ahmed El-Madhoun commented on MASSEMBLY-622: I was able to get passed this issue by changing the amount of artifacts that I am including in the include subfolder, so I changed my assembly descriptor to have this include instead: includes includestblinux-2.6.37/.config/include includestblinux-2.6.37/Module.symvers/include includestblinux-2.6.37/include/**/*.h/include includestblinux-2.6.37/arch/mips/**/include includestblinux-2.6.37/scripts/**/include includestblinux-2.6.37/Makefile/include includeuclinux-rootfs/images/**/include includeuclinux-rootfs/images/vmlinuz-*/include /includes Note includestblinux-2.6.37/include/**/*.h/include is only including header files. I can provide you with full list of files if that would help, but at least, we only need the headers to get passed this, but it would be nice to know if there is an issue and perhaps have it fixed. Thanks in advance for your help! Unable to create TAR artifacts Key: MASSEMBLY-622 URL: https://jira.codehaus.org/browse/MASSEMBLY-622 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.3 Environment: [aelmadho@aelmadho-laptop Kernel]$ mvn -version Apache Maven 3.0.4 (rNON-CANONICAL_2012-07-25_12-05_mockbuild; 2012-07-25 08:05:49-0400) Maven home: /usr/share/maven Java version: 1.7.0_05-icedtea, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.5.x86_64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.5.0-2.fc17.x86_64, arch: amd64, family: unix Reporter: Ahmed El-Madhoun Priority: Critical Attachments: assembly.xml, maven-assembly-error.txt, pom.xml To reproduce the case, you may need to just re-point the POM to the assembly descriptor attached. I am simply able to do the same if I specify a type of jar or zip, but not when using any sort of tar based type. We are using this as a primary basis of our build, which is primarily in C, and I would greatly appreciate any help or feedback on this item. Alot of thanks on the great work already! -- 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-5324) Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with older timestamp
Anton Smeenk created MNG-5324: - Summary: Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with older timestamp Key: MNG-5324 URL: https://jira.codehaus.org/browse/MNG-5324 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4 Reporter: Anton Smeenk Maven can only retrieve an artifact from Nexus with a classifier with latest timestamp. Artifacts with classifiers with an older timestamp cannot be resolved. For example. If I deploy an artifact Apple with classifier A and a bit later deploy the same artifact with classifier B. Next I want to retrieve the artifacts from Nexus: For a module Banana, which needs Apple with classifier A the Artifact resolver will fail. For a module Strawberry, which needs Apple with classifier B the Artifact resolver will succesfully resolve the artifact. I found the cause for this behaviour: With an proxy between Maven and Nexus I could see the behavour of Maven, at the moment that I want to fetch an artifact: First the metadata.xml is fetched from Nexus. This file does contain the timestamp of the latest artifact in nexus and all timestamps of older artifacts, with different classifier. From this metdata file Maven figures out what the correct name is for the artifact. But Maven can resolve the name of classifierb, but not the name of classifierB. The metadata is not correctly parsed! All information is there, but still Maven can only find the artifact with the latest timestamp. Here is an example of an metadata file: metadata modelVersion=1.1.0 groupIdcom.ccv.systems.modules.gen_modem/groupId artifactIdmodem/artifactId version07.20.3-SNAPSHOT/version versioning snapshot timestamp20120809.112920/timestamp buildNumber97/buildNumber /snapshot lastUpdated20120809112920/lastUpdated snapshotVersion classifierclasssifierA/classifier extensionjar/extension value07.20.3-20120809.112124-88/value updated20120809112124/updated /snapshotVersion snapshotVersion classifierclasssifierB/classifier extensionjar/extension value07.20.3-20120809.112920-97/value updated20120809112920/updated /snapshotVersion /snapshotVersions /versioning /metadata -- 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] (MENFORCER-131) DependencyConvergence log statement should be debug instead of info
[
https://jira.codehaus.org/browse/MENFORCER-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305912#comment-305912
]
Sergei Ivanov commented on MENFORCER-131:
-
Yes, please demote the logging to DEBUG. I was going to create a ticket for it,
but it appears it's already been reported.
In some of our projects with lots of dependencies, the plugin dumps hundreds of
lines like below:
{noformat}
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-api 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] org.slf4j:slf4j-log4j12 1.6.2 1.6.2
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
[INFO] log4j:log4j 1.2.16 1.2.16
{noformat}
DependencyConvergence log statement should be debug instead of info
---
Key: MENFORCER-131
URL: https://jira.codehaus.org/browse/MENFORCER-131
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Andrew Ruch
Priority: Minor
Attachments: MENFORCER-131-enforcer-rules.patch
In the DependencyVersionMap on line 87, an log prints every dependency and
its version information. This seems unnecessary as an info level log.
--
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
doxia-book-maven-plugin 1.3
I want to use doxia-book-maven-plugin to create documentation by converting Markdown files to PDF(s). The Markdown module only seems to be available for Doxia 1.3, but I can't find version 1.3 of the corresponding doxia-book-maven-plugin on Maven Central. Is it still in development? Is it only available as a snapshot and if so how would I integrate the snapshot into my build? Best regards Oliver Schrenk
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Halovanic updated MEAR-146: Attachment: ear-remove-librarydirectory-IT.patch ear-remove-librarydirectory.patch Updated to be inside webLogic section Expose parameter to not write library-directory element in application.xml -- Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.7 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Attachments: ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically Generic File Loading) when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like 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] (MRELEASE-786) -Darguments doesn't allow -T to be passed to forked builds for multi threading
Tom Clark created MRELEASE-786:
--
Summary: -Darguments doesn't allow -T to be passed to forked
builds for multi threading
Key: MRELEASE-786
URL: https://jira.codehaus.org/browse/MRELEASE-786
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Tom Clark
I would like to be able to use -T with the release plugin for the compiling
phase, as the plugin is thread safe, which would allow for about half the
release time.
I've tried:
{code}
-Darguments='-T 3'
{code}
which doesn't throw an error but doesn't actually trigger multi threading.
also:
{code}
-Darguments='-T3'
-Darguments='-T 3'
{code}
Both throws an error saying that -T isn't parsable
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project parent: Failed to re-parse additional arguments for Maven invocation.
Unrecognized option: -T - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project parent: Failed to re-parse additional arguments for Maven invocation.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
additional arguments for Maven invocation.
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:295)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed to
re-parse additional arguments for Maven invocation.
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
... 22 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Failed
to re-parse additional arguments for Maven invocation.
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.setupRequest(InvokerMavenExecutor.java:335)
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:394)
at
org.apache.maven.shared.release.exec.AbstractMavenExecutor.executeGoals(AbstractMavenExecutor.java:85)
at
[jira] (MEAR-156) defaultLibBundleDir setting producing odd behavior in Oracle's oepe version of eclipse Galileo
robert stettler created MEAR-156: Summary: defaultLibBundleDir setting producing odd behavior in Oracle's oepe version of eclipse Galileo Key: MEAR-156 URL: https://jira.codehaus.org/browse/MEAR-156 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.7 Environment: Windows 7, Eclipse Galileo (Oracle bundled oepe), 2.9 maven-eclipse-plugin, 2.7 maven-ear-plugin and 2.0 wtp Reporter: robert stettler Attachments: epf-refapp-federated-producer4.zip When I set defaultLibBundle dir as APP-INF/lib my maven dependency libraries are dropped into the APP-INF/lib/APP-INF. When I look at the eclipse project settings under JEE Dependencies I see jars listed as APP-INF/lib/../myjar.jar. In the org.eclipse.wst.common.component file that was generated the archiveName for each jar has ../myjar.jar and the deploy-path is set as APP-INF/lib. If I manually remove the .. from the entries the EAR builds as expected. Not sure what is driving the .. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-786) -Darguments doesn't allow -T to be passed to forked builds for multi threading
[
https://jira.codehaus.org/browse/MRELEASE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-786:
Component/s: prepare
-Darguments doesn't allow -T to be passed to forked builds for multi threading
--
Key: MRELEASE-786
URL: https://jira.codehaus.org/browse/MRELEASE-786
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.2
Reporter: Tom Clark
I would like to be able to use -T with the release plugin for the compiling
phase, as the plugin is thread safe, which would allow for about half the
release time.
I've tried:
{code}
-Darguments='-T 3'
{code}
which doesn't throw an error but doesn't actually trigger multi threading.
also:
{code}
-Darguments='-T3'
-Darguments='-T 3'
{code}
Both throws an error saying that -T isn't parsable
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project parent: Failed to re-parse additional arguments for Maven invocation.
Unrecognized option: -T - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
(default-cli) on project parent: Failed to re-parse additional arguments for
Maven invocation.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to re-parse
additional arguments for Maven invocation.
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:295)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Failed
to re-parse additional arguments for Maven invocation.
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:44)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:291)
... 22 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException:
Failed to re-parse additional arguments for Maven invocation.
at
[jira] (MRELEASE-755) When passing arguments to underlying maven executions not all maven options are accepted
[
https://jira.codehaus.org/browse/MRELEASE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-755:
Summary: When passing arguments to underlying maven executions not all
maven options are accepted (was: When passing aruments to undelying maven
executions not all maven options are accepted)
When passing arguments to underlying maven executions not all maven options
are accepted
Key: MRELEASE-755
URL: https://jira.codehaus.org/browse/MRELEASE-755
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Sandy McPherson
The command
{code}
+ /opt/imc/maven3/bin/mvn -B -PStaged-distribution --settings
../corrie/settings-build-release.xml -gs ../corrie/settings-global.xml
'-Darguments=-PStaged-distribution -s ../corrie/settings-build-release.xml
-gs ../corrie/settings-global.xml' release:prepare -DreleaseVersion=10.3765
{code}
Produces the following error:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2.2:prepare (default-cli) on
project corrie: Failed to re-parse additional arguments for Maven invocation.
Unrecognized option: -g - [Help 1]
[ERROR]
{code}
Also tried with --global-settings and this also failed with an anrecocgnized
option --global-settings
Would seem pointless for the plugin to do any additional parsing, just pass
it to maven and let the underlying execution complain.
--
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-872) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/SUREFIRE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-872. --- Resolution: Fixed Fix Version/s: 2.12.1 use maven-plugin-tools' java 5 annotations -- Key: SUREFIRE-872 URL: https://jira.codehaus.org/browse/SUREFIRE-872 Project: Maven Surefire Issue Type: Task Affects Versions: 2.12 Reporter: Herve Boutemy Fix For: 2.12.1 -- 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-853) test
[ https://jira.codehaus.org/browse/SUREFIRE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-853. --- Resolution: Incomplete Assignee: Kristian Rosenvold test Key: SUREFIRE-853 URL: https://jira.codehaus.org/browse/SUREFIRE-853 Project: Maven Surefire Issue Type: Bug Reporter: #23435;#38634;#23792; Assignee: Kristian Rosenvold -- 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
