[jira] (MWAR-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327740#comment-327740
]
Jeff Black commented on MWAR-280:
-
I tested with 2.4-SNAP, and got comparable build times, but I was unable to
duplicate the original issue with version 2.2. I would be interested to know
if other can still duplicate this issue.
War project with one overlay, goals: clean install:
Maven 3.0.5
- war plugin 2.1.1,build time 54s avg.
- war plugin 2.2, build time 58s avg.
- war plugin 2.4-SNAP, build time 40s avg.
Maven 2.2.1
- war plugin 2.1.1,build time 54s avg.
- war plugin 2.2, build time 54s avg.
- war plugin 2.4-SNAP, build time 52s avg.
Big performance hit in overlay
--
Key: MWAR-280
URL: https://jira.codehaus.org/browse/MWAR-280
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.2
Reporter: Simone Bordet
Fix For: 2.4
Here is the output of version 2.1.1 of the maven war plugin when overlaying
org.cometd.javascript:cometd-javascript-dojo:
{code}
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [7026 msecs]
{code}
Note how it took 7026 ms.
This is the output for the same project, but using version 2.2 of the maven
war plugin:
{code}
[INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [24151 msecs]
{code}
Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=327741#comment-327741
]
Jeff Black commented on MWAR-280:
-
Same thing when building Simone's project, unable to duplicate the original
version 2.2 issue. Very strange.
- war plugin 2.1.1,build time 2:54 avg.
- war plugin 2.2, build time 2:55 avg.
- war plugin 2.4-SNAP, build time 2:44 avg.
Big performance hit in overlay
--
Key: MWAR-280
URL: https://jira.codehaus.org/browse/MWAR-280
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.2
Reporter: Simone Bordet
Fix For: 2.4
Here is the output of version 2.1.1 of the maven war plugin when overlaying
org.cometd.javascript:cometd-javascript-dojo:
{code}
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [7026 msecs]
{code}
Note how it took 7026 ms.
This is the output for the same project, but using version 2.2 of the maven
war plugin:
{code}
[INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [24151 msecs]
{code}
Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-286) Support for Jira custom fields in jira-report columnNames
[
https://jira.codehaus.org/browse/MCHANGES-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317360#comment-317360
]
Jeff Black commented on MCHANGES-286:
-
I second the idea, as it is important concept for the report to be delivered to
external clients that do not have access to our internal JIRA system.
Support for Jira custom fields in jira-report columnNames
-
Key: MCHANGES-286
URL: https://jira.codehaus.org/browse/MCHANGES-286
Project: Maven 2.x Changes Plugin
Issue Type: Wish
Components: jira
Affects Versions: 2.7.1
Reporter: Peter Friberg
A lot of important info is often described in Jira custom fields. In my case,
the report will not fulfill the requirements because I can't output some
important customfields in the report.
I would be happy to see support for this. For example, be able specify:
{code:xml}columnNamesKey,Type,Priority,Summary,customfield_10023,
customfield_10041/columnNames{code}
The descriptive name of the customfield should be returned back to the report.
It would be a good start with the simple custom field types, such as text
fields and single select.
--
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] (MWAR-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306367#comment-306367
]
Jeff Black commented on MWAR-280:
-
We are seeing the same war overlay performance hit difference between versions
2.1.1 and 2.2.
Big performance hit in overlay
--
Key: MWAR-280
URL: https://jira.codehaus.org/browse/MWAR-280
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.2
Reporter: Simone Bordet
Here is the output of version 2.1.1 of the maven war plugin when overlaying
org.cometd.javascript:cometd-javascript-dojo:
{code}
[INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [7026 msecs]
{code}
Note how it took 7026 ms.
This is the output for the same project, but using version 2.2 of the maven
war plugin:
{code}
[INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
[INFO] Packaging webapp
[INFO] Assembling webapp [tutorials-skeleton] in
[/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
[INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [24151 msecs]
{code}
Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
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] Commented: (MCOMPILER-67) NullPointerException when compiling with maven-compiler-plugin 2.1-SNAPSHOT - all projects
[ http://jira.codehaus.org/browse/MCOMPILER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123563 ] Jeff Black commented on MCOMPILER-67: - The workaround (or permanent solution, I'm not sure yet) is to define the compiler plugin in your pom with an explicit version, version2.0.2/version. Surely there has to be a better way to say For all the standard plugins that I use and do not specify a version for, please use the latest release version, and never a SNAPSHOT version. Defining all the plugin versions, even in a single parent pom, seems unreasonable to me. Why would the default be to use plugin SNAPSHOTS? Doesn't this create a fragile project structure? What is the best practice way to have a rock solid project, isolated from deployed SNAPSHOT plugins? NullPointerException when compiling with maven-compiler-plugin 2.1-SNAPSHOT - all projects -- Key: MCOMPILER-67 URL: http://jira.codehaus.org/browse/MCOMPILER-67 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.1 Environment: WinXP, Java 1.5 Reporter: Mike Rokitka Attachments: outfile.txt All of my compiles using Maven have failed, and they were previously working fine yesterday. I believe it is likely due to a bug in the snapshot. I've tried using different versions of the Java, and upgraded to Maven 2.0.8 from 2.0.7, but that had no effect. Attached is the full trace with debug enabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-67) NullPointerException when compiling with maven-compiler-plugin 2.1-SNAPSHOT - all projects
[ http://jira.codehaus.org/browse/MCOMPILER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123564 ] Jeff Black commented on MCOMPILER-67: - The latest thinking seems to be captured here: http://docs.codehaus.org/display/MAVEN/Plugin+packs+and+concrete+versioning NullPointerException when compiling with maven-compiler-plugin 2.1-SNAPSHOT - all projects -- Key: MCOMPILER-67 URL: http://jira.codehaus.org/browse/MCOMPILER-67 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.1 Environment: WinXP, Java 1.5 Reporter: Mike Rokitka Attachments: outfile.txt All of my compiles using Maven have failed, and they were previously working fine yesterday. I believe it is likely due to a bug in the snapshot. I've tried using different versions of the Java, and upgraded to Maven 2.0.8 from 2.0.7, but that had no effect. Attached is the full trace with debug enabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-43) Add skip capability....
[
http://jira.codehaus.org/browse/MCHECKSTYLE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_117129
]
Jeff Black commented on MCHECKSTYLE-43:
---
From the mojo pages linked above, ${checkstyle.skip} is documented, but does
not work.
Add skip capability
-
Key: MCHECKSTYLE-43
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-43
Project: Maven 2.x Checkstyle Plugin
Issue Type: Improvement
Reporter: Daniel Kulp
Since checkstyle can be a time consuming task like running tests, it would be
nice to have a flag similar to the -Dmaven.test.skip=true flag to allow
skipping the checkstyle checks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-359) surefire:surefire failes when there are spaces in directory names
surefire:surefire failes when there are spaces in directory names - Key: SUREFIRE-359 URL: http://jira.codehaus.org/browse/SUREFIRE-359 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.4 Environment: linux maven 2.0.7 surefire-2.4-snapshot Reporter: Jeff Black This issue is similar to others filed, but specific enough I wanted to report it separately. On an ubunu linux system, if I checkout a maven project into a directory with spaces in the full path, surefire will fail the build before the tests are actually executed. (Spaces in the path occur, for example, when I build a Hudson job with spaces in the project name.) [INFO] [clean:clean] [INFO] Deleting directory /home/hudson/.hudson/jobs/sto dirspaces/workspace/persistence/target [INFO] Deleting directory /home/hudson/.hudson/jobs/sto dirspaces/workspace/persistence/target/classes [INFO] Deleting directory /home/hudson/.hudson/jobs/sto dirspaces/workspace/persistence/target/test-classes [INFO] Deleting directory /home/hudson/.hudson/jobs/sto dirspaces/workspace/persistence/target/site [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] Copying 1 resource [INFO] [compiler:compile] [INFO] Compiling 50 source files to /home/hudson/.hudson/jobs/sto dirspaces/workspace/persistence/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] Copying 2 resources [INFO] [compiler:testCompile] [INFO] Compiling 14 source files to /home/hudson/.hudson/jobs/sto dirspaces/workspace/persistence/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /home/hudson/.hudson/jobs/sto dirspaces/workspace/persistence/target/surefire-reports /bin/bash: line 0: cd: /home/hudson/.hudson/jobs/sto: No such file or directory [ERROR] There are test failures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-70) Add project description as a mojo parameter
[
http://jira.codehaus.org/browse/ARCHETYPE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107665
]
Jeff Black commented on ARCHETYPE-70:
-
I would find it more flexible to be able to accept any arbitarty command line
parameter and automatically include that into the velocity map. So the
archetype plugin would have its required and optional parameters, but you could
also include other -D options on the command line with the archetype:create
command, such as -Ddescription=desc and -DprojectName=projectName.
In short, I want to be able to create a fully templated prototype pom.xml with
no modifications to the archetype plugin.
This would keep the archetype plugin cleaner without having to fork it locally
(or patch and release a new official version) for each develope that adds an
additional parameter requirement.
If this sounds reasonable, I can take a stab at contributing this solution.
Any showstoppers that I would need to be aware of.
Jeff
Add project description as a mojo parameter
---
Key: ARCHETYPE-70
URL: http://jira.codehaus.org/browse/ARCHETYPE-70
Project: Maven Archetype
Issue Type: New Feature
Components: Plugin
Reporter: Michael Heuer
Priority: Minor
Attachments: patch.txt
For my archetype bundle, I require the project description as a parameter.
I use it in the pom.xml
description${description}/description
in a license HEADER.txt
/*
${artifactId} ${description}
Copyright ...
in a package.html
html
body
p${description}/p
/body
/html
and so on.
The attached patch to MavenArchetypeMojo.java provides a project description
parameter in addition to project groupId, artifactId, and version:
$ mvn -X archetype:create
-DgroupId=foo
-DartifactId=bar
-Dversion=1.0-SNAPSHOT
-Ddescription=bar description. ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPCLOVER-59) clover report does not include instrumented test lines of code with junit report included
clover report does not include instrumented test lines of code with junit report included - Key: MPCLOVER-59 URL: http://jira.codehaus.org/browse/MPCLOVER-59 Project: Maven 1.x Clover Plugin Issue Type: Bug Affects Versions: 1.11.2 Environment: windows XP/cygwin maven 1.1 maven-junit-report-plugin 1.5.1 Reporter: Jeff Black Running the clover report as the only project report to obtain source lines of code works with the property maven.clover.instrument.tests set = true. However, if the project also specifies the junit report (reportmaven-junit-report-plugin/report), then the clover report will not include test lines of code, even with the property maven.clover.instrument.tests=true. I looked at the junit-report-plugin plugin.jelly, put nothing jumped out at me as being suspect along the lines of modifying maven.test.compile.src.set, for example. This is can reproduced by adding the reportmaven-junit-report-plugin/report to the existing clover plugin test case: testSiteReportAndGenerationOfDifferentFormats -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
