[jira] (WAGON-375) wagon-http-lightweight must try to use persistent connection from the jdk
[ https://jira.codehaus.org/browse/WAGON-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened WAGON-375: not fixed so reopen as need more work. wagon-http-lightweight must try to use persistent connection from the jdk -- Key: WAGON-375 URL: https://jira.codehaus.org/browse/WAGON-375 Project: Maven Wagon Issue Type: Improvement Components: wagon-http-lightweight Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 2.3 -- 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] (SCM-684) Mercurial - Unparseable date
franek created SCM-684:
--
Summary: Mercurial - Unparseable date
Key: SCM-684
URL: https://jira.codehaus.org/browse/SCM-684
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-mercurial (hg)
Affects Versions: 1.5
Reporter: franek
Priority: Blocker
Scm Activity Plugin returns a warning for many lines of my code :
{code}
java.text.ParseException: Unparseable date: u...@mail.com c55d9b230751 Wed
Jun 06 14:15:52 2012 +0200
at java.text.DateFormat.parse(DateFormat.java:337) ~[na:1.6.0_31]
at
org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:112)
~[maven-scm-api-1.7.jar:1.7]
at
org.apache.maven.scm.provider.hg.command.blame.HgBlameConsumer.doConsume(HgBlameConsumer.java:71)
[maven-scm-provider-hg-1.7.jar:1.7]
at
org.apache.maven.scm.provider.hg.command.HgConsumer.consumeLine(HgConsumer.java:131)
[maven-scm-provider-hg-1.7.jar:1.7]
at
org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:197)
[plexus-utils-2.0.5.jar:na]
{code}
It is due to this command :
{code}
hg blame --user --date --changeset File.txt
{code}
It returns :
{code}
firstname lastname u...@mail.com c55d9b230751 Tue Jun 19 14:20:07 2012 +0200:
{code}
Whereas the plugins expects (no space between firstname and lastname) :
{code}
firstnamelastname u...@mail.com c55d9b230751 Tue Jun 19 14:20:07 2012 +0200:
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNGSITE-157) Download links not working
[
https://jira.codehaus.org/browse/MNGSITE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305047#comment-305047
]
Marc Guenther commented on MNGSITE-157:
---
I notice that this does NOT happen for the .zip files, only for the .tar.gz
files. It seems Safari looks at the URL, which ends with .gz, and as it also
gets a content-Encoding of gz, it somehow decides to download the html page as
a file and store it under the .tar.gz name.
Why do the URLs of the html mirror pages have to end in .tar.gz or .zip anyway?
If you would just name that .html (what they are) it would be less confusing to
users and to Safari.
I find a link which is named apache-maven-3.0.4-bin.tar.gz and whose URL ends
with apache-maven-3.0.4-bin.tar.gz and which does NOT download
apache-maven-3.0.4-bin.tar.gz but instead leads to a html text page very
confusing. But maybe it's just me.
Download links not working
--
Key: MNGSITE-157
URL: https://jira.codehaus.org/browse/MNGSITE-157
Project: Maven Project Web Site
Issue Type: Bug
Environment: MacOSX 10.6, Safari 5.1.5
Reporter: Marc Guenther
Assignee: Olivier Lamy
Would it be possible to fix the download links on
http://maven.apache.org/download.html for maven .tar.gz files?
When I click on apache-maven-3.0.4-bin.tar.gz, I get a file
{{apache-maven-3.0.4-bin.tar.gz}} which is 6591bytes long. Uncompressing from
the Finder does not work and closer inspection reveals that this is in fact a
gzipped html file, which points you to the list of mirrors.
This has been confusing new users for years now. Does not seem too hard to
fix...
--
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] (MDEP-363) The plugin should not write debug messages to 'System.out'.
Christian Schulte created MDEP-363: -- Summary: The plugin should not write debug messages to 'System.out'. Key: MDEP-363 URL: https://jira.codehaus.org/browse/MDEP-363 Project: Maven 2.x Dependency Plugin Issue Type: Task Affects Versions: 2.4 Reporter: Christian Schulte Priority: Trivial -- 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-758) Documentation incorrect for running single integration test
[ https://jira.codehaus.org/browse/SUREFIRE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305072#comment-305072 ] Art O Cathain edited comment on SUREFIRE-758 at 7/31/12 11:13 AM: -- I don't think -Dtest works at all. The surefire runner picks up the specified test in that case. 2.11 is fine, -Dit.test works as expected there. was (Author: artbristol): Agree, this used to work with 2.10, now you need to do -Dtest rather than -Dit.test. Documentation needs updating. Documentation incorrect for running single integration test --- Key: SUREFIRE-758 URL: https://jira.codehaus.org/browse/SUREFIRE-758 Project: Maven Surefire Issue Type: Improvement Components: documentation Reporter: Lyle Hanson Priority: Minor The online documentation for Failsafe which describes [Running a Single Test|http://maven.apache.org/plugins/maven-failsafe-plugin/examples/single-test.html] shows: bq.mvn -Dit.test=ITCircle verify The it.test parameter does not seem to work. Rather, the same parameter as Surefire (-Dtest=foo) appears to also work for Failsafe. -- 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] (MCHANGELOG-108) read/write changelog.xml inconsistency
[
https://jira.codehaus.org/browse/MCHANGELOG-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samuel Van Reeth updated MCHANGELOG-108:
Attachment: MCHANGELOG-108-useTagNamesFromChangeLogSetClass.patch
Fix in ChangelogHandler:
when reading the changelog.xml file, use the correct Xml tag names for
attributes startVersion and endVersion
read/write changelog.xml inconsistency
--
Key: MCHANGELOG-108
URL: https://jira.codehaus.org/browse/MCHANGELOG-108
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Grzegorz Kochanski
Priority: Minor
Attachments: MCHANGELOG-108-useTagNamesFromChangeLogSetClass.patch
ChangelogHandler.java:165
bufSet.setStartVersion(new
ScmTag(attributes.getValue(startTag)));
bufSet.setEndVersion(new ScmTag(attributes.getValue(endTag)));
ChangeLogSet.java:180
if ( startVersion != null )
{
buffer.append( startVersion=\ )
.append( getStartVersion() )
.append( \ );
}
if ( endVersion != null )
{
buffer.append( endVersion=\ )
.append( getEndVersion() )
.append( \ );
}
Please fix field name to startVersion/endVersion.
When changelog.xml is present then settings like: type, range, dates should
be taken from this file during repoprt generation.
--
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] (MCHANGELOG-108) read/write changelog.xml inconsistency
[
https://jira.codehaus.org/browse/MCHANGELOG-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305075#comment-305075
]
Samuel Van Reeth edited comment on MCHANGELOG-108 at 7/31/12 11:34 AM:
---
Current behaviour:
the xml is created with attributes startVersion and endVersion on element
changeset (ChangeLogSet, maven-scm-api dependency), but when reading the xml,
the code (ChangelogHandler.java) looks for attributes startTag and endTag,
finding no such attributes.
This results in a report with headers Changes since project creation rather
than expected Changes between
Fix in ChangelogHandler:
use startVersion and endVersion instead of startTag and endTag
was (Author: rodikal):
Fix in ChangelogHandler:
when reading the changelog.xml file, use the correct Xml tag names for
attributes startVersion and endVersion
read/write changelog.xml inconsistency
--
Key: MCHANGELOG-108
URL: https://jira.codehaus.org/browse/MCHANGELOG-108
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Grzegorz Kochanski
Priority: Minor
Attachments: MCHANGELOG-108-useTagNamesFromChangeLogSetClass.patch
ChangelogHandler.java:165
bufSet.setStartVersion(new
ScmTag(attributes.getValue(startTag)));
bufSet.setEndVersion(new ScmTag(attributes.getValue(endTag)));
ChangeLogSet.java:180
if ( startVersion != null )
{
buffer.append( startVersion=\ )
.append( getStartVersion() )
.append( \ );
}
if ( endVersion != null )
{
buffer.append( endVersion=\ )
.append( getEndVersion() )
.append( \ );
}
Please fix field name to startVersion/endVersion.
When changelog.xml is present then settings like: type, range, dates should
be taken from this file during repoprt generation.
--
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] (MCHANGELOG-108) read/write changelog.xml inconsistency
[
https://jira.codehaus.org/browse/MCHANGELOG-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305075#comment-305075
]
Samuel Van Reeth edited comment on MCHANGELOG-108 at 7/31/12 11:35 AM:
---
Current behaviour:
the xml is created with attributes startVersion and endVersion on element
changeset (ChangeLogSet, maven-scm-api dependency), but when reading the xml,
the code (ChangelogHandler.java) looks for attributes startTag and endTag,
finding no such attributes.
This results in a report with headers Changes since project creation rather
than expected Changes between
Fix in ChangelogHandler:
use startVersion and endVersion instead of startTag and endTag (see
patch file)
was (Author: rodikal):
Current behaviour:
the xml is created with attributes startVersion and endVersion on element
changeset (ChangeLogSet, maven-scm-api dependency), but when reading the xml,
the code (ChangelogHandler.java) looks for attributes startTag and endTag,
finding no such attributes.
This results in a report with headers Changes since project creation rather
than expected Changes between
Fix in ChangelogHandler:
use startVersion and endVersion instead of startTag and endTag
read/write changelog.xml inconsistency
--
Key: MCHANGELOG-108
URL: https://jira.codehaus.org/browse/MCHANGELOG-108
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Grzegorz Kochanski
Priority: Minor
Attachments: MCHANGELOG-108-useTagNamesFromChangeLogSetClass.patch
ChangelogHandler.java:165
bufSet.setStartVersion(new
ScmTag(attributes.getValue(startTag)));
bufSet.setEndVersion(new ScmTag(attributes.getValue(endTag)));
ChangeLogSet.java:180
if ( startVersion != null )
{
buffer.append( startVersion=\ )
.append( getStartVersion() )
.append( \ );
}
if ( endVersion != null )
{
buffer.append( endVersion=\ )
.append( getEndVersion() )
.append( \ );
}
Please fix field name to startVersion/endVersion.
When changelog.xml is present then settings like: type, range, dates should
be taken from this file during repoprt generation.
--
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] (MSHARED-233) dependency:tree report switches managed scope and version
[
https://jira.codehaus.org/browse/MSHARED-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy moved MDEP-362 to MSHARED-233:
Component/s: (was: tree)
maven-dependency-tree
Affects Version/s: (was: 2.5)
maven-dependency-tree-2.0
Key: MSHARED-233 (was: MDEP-362)
Project: Maven Shared Components (was: Maven 2.x Dependency
Plugin)
dependency:tree report switches managed scope and version
-
Key: MSHARED-233
URL: https://jira.codehaus.org/browse/MSHARED-233
Project: Maven Shared Components
Issue Type: Bug
Components: maven-dependency-tree
Affects Versions: maven-dependency-tree-2.0
Reporter: Joseph Walton
Attachments:
0002-MDEP-362-Report-managed-scope-and-version-changes-co.patch
The dependency:tree report switches scope and version when reporting managed
changes:
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from
2.4; version selected from constraint 2.4)
{noformat}
instead of
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (version managed from
2.4; version selected from constraint 2.4)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-233) dependency:tree report switches managed scope and version
[
https://jira.codehaus.org/browse/MSHARED-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSHARED-233.
-
Resolution: Fixed
Fix Version/s: maven-dependency-tree-2.0
Assignee: Herve Boutemy
fixed in [r1367732|http://svn.apache.org/viewvc?rev=1367732view=rev]
thank you
dependency:tree report switches managed scope and version
-
Key: MSHARED-233
URL: https://jira.codehaus.org/browse/MSHARED-233
Project: Maven Shared Components
Issue Type: Bug
Components: maven-dependency-tree
Affects Versions: maven-dependency-tree-2.0
Reporter: Joseph Walton
Assignee: Herve Boutemy
Fix For: maven-dependency-tree-2.0
Attachments:
0002-MDEP-362-Report-managed-scope-and-version-changes-co.patch
The dependency:tree report switches scope and version when reporting managed
changes:
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from
2.4; version selected from constraint 2.4)
{noformat}
instead of
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (version managed from
2.4; version selected from constraint 2.4)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-361) dependency:tree's use of version selected from constraint is too verbose
[
https://jira.codehaus.org/browse/MDEP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MDEP-361.
--
Resolution: Cannot Reproduce
Assignee: Herve Boutemy
AFAIK, this is fixed since
[r1365268|http://svn.apache.org/viewvc?rev=1365268view=rev], and checked by
tree it
dependency:tree's use of version selected from constraint is too verbose
--
Key: MDEP-361
URL: https://jira.codehaus.org/browse/MDEP-361
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Affects Versions: 2.5
Reporter: Joseph Walton
Assignee: Herve Boutemy
Attachments:
0001-MDEP-361-Only-print-versions-that-differ-from-their-.patch
MDEP-339's fix increases the level of verbosity in the dependency tree to
include the specified constraint as well as the actual version. In many
builds, these will be identical.
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from
2.4; version selected from constraint 2.4)
{noformat}
The format change makes diffing the old and new versions difficult to see
what behaviour has changed. In the case where the constraint is the same as
the version it doesn't seem to add much information.
I'd suggest omitting it when the version exactly matches the constraint.
--
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] (MDEP-363) The plugin should not write debug messages to 'System.out'.
[ https://jira.codehaus.org/browse/MDEP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305093#comment-305093 ] Herve Boutemy commented on MDEP-363: what do you do to see such debug messages? which ones? I can't reproduce The plugin should not write debug messages to 'System.out'. --- Key: MDEP-363 URL: https://jira.codehaus.org/browse/MDEP-363 Project: Maven 2.x Dependency Plugin Issue Type: Task Affects Versions: 2.4 Reporter: Christian Schulte Priority: Trivial -- 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] (MDEP-352) Attributes for ArtifactItems referenced in AbstractFromConfigurationMojo.java are incorrect (documentation patch attached)
[ https://jira.codehaus.org/browse/MDEP-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MDEP-352. -- Resolution: Fixed Fix Version/s: 2.5 Assignee: Herve Boutemy patch applied in [r1367744|http://svn.apache.org/viewvc?rev=1367744view=rev] thank you Attributes for ArtifactItems referenced in AbstractFromConfigurationMojo.java are incorrect (documentation patch attached) -- Key: MDEP-352 URL: https://jira.codehaus.org/browse/MDEP-352 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.4 Reporter: Matthew Farwell Assignee: Herve Boutemy Priority: Minor Fix For: 2.5 Attachments: MDEP-352.patch The ArtifactItems attributes listed in the AbstractFromConfigurationMojo.java are incorrect and out of date. In particular overwrite - overWrite and location - outputDirectory. -- 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] (MDEP-355) dependency:get destination parameter is wrong in the documentation
[ https://jira.codehaus.org/browse/MDEP-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MDEP-355. -- Resolution: Not A Bug Assignee: Herve Boutemy destination is the name of the parameter when you configure it in a POM, but dest is the CLI parameter name The generated documentation has been improved in maven-plugin-plugin 3.1: see the result in http://maven.apache.org/plugins/maven-dependency-plugin-2.5/get-mojo.html dependency:get destination parameter is wrong in the documentation -- Key: MDEP-355 URL: https://jira.codehaus.org/browse/MDEP-355 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: get Affects Versions: 2.4 Environment: Windows 7 Reporter: COLLIGNON Assignee: Herve Boutemy Priority: Minor In the documentation of dependency:get in version 2.4 (http://maven.apache.org/plugins/maven-dependency-plugin/get-mojo.html), the parameter destination is specified to copy the artifact into, if other than the local repository. In fact this parameter not working (nothing change when is passed), but the parameter dest (describe in the details) will do the job. -- 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] (MDEP-363) The plugin should not write debug messages to 'System.out'.
[ https://jira.codehaus.org/browse/MDEP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MDEP-363: --- Attachment: pom.xml Executing 'mvn generate-resources' on this POM, no 'System.out' messages are printed. Repeating 'mvn generate-resources' without 'clean'ing the project, debug messages are printed to 'System.out'. The plugin should not write debug messages to 'System.out'. --- Key: MDEP-363 URL: https://jira.codehaus.org/browse/MDEP-363 Project: Maven 2.x Dependency Plugin Issue Type: Task Affects Versions: 2.4 Reporter: Christian Schulte Priority: Trivial Attachments: pom.xml -- 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] (MDEP-363) The plugin should not write debug messages to 'System.out'.
[
https://jira.codehaus.org/browse/MDEP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305100#comment-305100
]
Christian Schulte commented on MDEP-363:
{code}
Script started on Tue Jul 31 22:30:31 2012
$ mvn clean
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building mdep363 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ mdep363 ---
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.537s
[INFO] Finished at: Tue Jul 31 22:30:37 CEST 2012
[INFO] Final Memory: 3M/15M
[INFO]
$ mvn generate-resources
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building mdep363 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.4:unpack (default) @ mdep363 ---
[INFO] Configured Artifact: org.apache:apache-jar-resource-bundle:1.4:jar
[INFO] Unpacking
/home/schulte/.m2/central/org/apache/apache-jar-resource-bundle/1.4/apache-jar-resource-bundle-1.4.jar
to /tmp/mdep363/target/dependency with includes and excludes
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 9.668s
[INFO] Finished at: Tue Jul 31 22:30:57 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO]
$
$ mvn generate-resources
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building mdep363 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.4:unpack (default) @ mdep363 ---
[INFO] Configured Artifact: org.apache:apache-jar-resource-bundle:1.4:jar
isMarkerOlder:
artifact1 =
/home/schulte/.m2/central/org/apache/apache-jar-resource-bundle/1.4/apache-jar-resource-bundle-1.4.jar
marker=
/tmp/mdep363/target/dependency-maven-plugin-markers/org.apache-apache-jar-resource-bundle-jar-1.4.marker
artifact1 lastModified: 1335224583000
marker lastModified: 1335224583000
false = marker older than artifact?
[INFO] apache-jar-resource-bundle-1.4.jar already unpacked.
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.487s
[INFO] Finished at: Tue Jul 31 22:31:02 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO]
$ ^D
Script done on Tue Jul 31 22:31:06 2012
{code}
The plugin should not write debug messages to 'System.out'.
---
Key: MDEP-363
URL: https://jira.codehaus.org/browse/MDEP-363
Project: Maven 2.x Dependency Plugin
Issue Type: Task
Affects Versions: 2.4
Reporter: Christian Schulte
Priority: Trivial
Attachments: pom.xml
--
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] (MDEP-363) The plugin should not write debug messages to 'System.out'.
[ https://jira.codehaus.org/browse/MDEP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305102#comment-305102 ] Christian Schulte commented on MDEP-363: See [r1085956|http://svn.apache.org/viewvc?view=revisionrevision=1085956]. The plugin should not write debug messages to 'System.out'. --- Key: MDEP-363 URL: https://jira.codehaus.org/browse/MDEP-363 Project: Maven 2.x Dependency Plugin Issue Type: Task Affects Versions: 2.4 Reporter: Christian Schulte Priority: Trivial Attachments: pom.xml -- 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-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305103#comment-305103 ] Tony Lampada commented on MNG-5127: --- I have found a workaround for the situation above using a build extensions. There's a lot of room for improvement though - http://stackoverflow.com/questions/11749375/import-maven-plugin-configuration-by-composition-rather-than-inheritance-can-it CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-5127 URL: https://jira.codehaus.org/browse/MNG-5127 Project: Maven 2 3 Issue Type: Bug Reporter: Gilles Scokart Assignee: John Casey Attachments: daddy.zip The goal is to activate a maven profile based on OS user name. When I create a standalone project with a profile activation, it works, however, when I define the profile in a parent pom, it is never activated. this works: ... profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties /properties So in this case, my profile is activated based on my OS user name [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': The following profiles are active: - TONY (source: pom) -- However, if I now have the profiles definition in the parent pom, it doesn't work when I build a child project So the child project references the parent pom containing the profiles and the activation, but when it is built, the profile is not activated PARENT POM: ... profiles profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties ... CHILD POM (the one being built) project parent groupIdcom.capgemini.be.proj1/groupId artifactIdparent/artifactId version4.0.2/version /parent [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 Application [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': There are no active profiles. -- 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-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305103#comment-305103 ] Tony Lampada edited comment on MNG-5127 at 7/31/12 4:38 PM: I have found a workaround for the situation above using a build extension. There's a lot of room for improvement though - http://stackoverflow.com/questions/11749375/import-maven-plugin-configuration-by-composition-rather-than-inheritance-can-it was (Author: tonylampada): I have found a workaround for the situation above using a build extensions. There's a lot of room for improvement though - http://stackoverflow.com/questions/11749375/import-maven-plugin-configuration-by-composition-rather-than-inheritance-can-it CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-5127 URL: https://jira.codehaus.org/browse/MNG-5127 Project: Maven 2 3 Issue Type: Bug Reporter: Gilles Scokart Assignee: John Casey Attachments: daddy.zip The goal is to activate a maven profile based on OS user name. When I create a standalone project with a profile activation, it works, however, when I define the profile in a parent pom, it is never activated. this works: ... profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties /properties So in this case, my profile is activated based on my OS user name [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': The following profiles are active: - TONY (source: pom) -- However, if I now have the profiles definition in the parent pom, it doesn't work when I build a child project So the child project references the parent pom containing the profiles and the activation, but when it is built, the profile is not activated PARENT POM: ... profiles profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties ... CHILD POM (the one being built) project parent groupIdcom.capgemini.be.proj1/groupId artifactIdparent/artifactId version4.0.2/version /parent [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 Application [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': There are no active profiles. -- 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-785) Arguments containing spaces and quotes cause the forked maven process to fail
Rob Elliot created MRELEASE-785: --- Summary: Arguments containing spaces and quotes cause the forked maven process to fail Key: MRELEASE-785 URL: https://jira.codehaus.org/browse/MRELEASE-785 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.2 Environment: *nix Reporter: Rob Elliot The following config: plugin artifactIdmaven-release-plugin/artifactId configuration mavenExecutorIdforked-path/mavenExecutorId useReleaseProfilefalse/useReleaseProfile arguments-Dgpg.passphrase=a phrase 'containing' quotes and spaces/arguments /configuration /plugin causes the forked clean verify to fail. This is preventing me using my gpg key as part of an automated release process. This is due to a bug in Plexus Utils which I have raised as issue 152 http://jira.codehaus.org/browse/PLXUTILS-152, and for which I have raised a pull request here: https://github.com/sonatype/plexus-utils/pull/5. I am raising an issue on the release plugin as when/if a fixed version of plexus utils is released the maven release plugin will need to upgrade to this new version to benefit. -- 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] (MDEP-361) dependency:tree's use of version selected from constraint is too verbose
[
https://jira.codehaus.org/browse/MDEP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305113#comment-305113
]
Joseph Walton commented on MDEP-361:
Yes, confirming that the change fixes this issue for me, and also shows the
constraint when it's a range. Thanks.
dependency:tree's use of version selected from constraint is too verbose
--
Key: MDEP-361
URL: https://jira.codehaus.org/browse/MDEP-361
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Affects Versions: 2.5
Reporter: Joseph Walton
Assignee: Herve Boutemy
Attachments:
0001-MDEP-361-Only-print-versions-that-differ-from-their-.patch
MDEP-339's fix increases the level of verbosity in the dependency tree to
include the specified constraint as well as the actual version. In many
builds, these will be identical.
{noformat}
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile (scope managed from
2.4; version selected from constraint 2.4)
{noformat}
The format change makes diffing the old and new versions difficult to see
what behaviour has changed. In the case where the constraint is the same as
the version it doesn't seem to add much information.
I'd suggest omitting it when the version exactly matches the constraint.
--
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] (MNGSITE-157) Download links not working
[
https://jira.codehaus.org/browse/MNGSITE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305115#comment-305115
]
Brett Porter commented on MNGSITE-157:
--
The URLs need the filename to download in it somewhere as that's how the CGI
figures out what to offer links to. Changing that to a query parameter would
have quite some impact across the ASF :)
It looks like this bug has been fixed in Safari 6, so I think we can close it
again now. Can anyone else confirm?
Download links not working
--
Key: MNGSITE-157
URL: https://jira.codehaus.org/browse/MNGSITE-157
Project: Maven Project Web Site
Issue Type: Bug
Environment: MacOSX 10.6, Safari 5.1.5
Reporter: Marc Guenther
Assignee: Olivier Lamy
Would it be possible to fix the download links on
http://maven.apache.org/download.html for maven .tar.gz files?
When I click on apache-maven-3.0.4-bin.tar.gz, I get a file
{{apache-maven-3.0.4-bin.tar.gz}} which is 6591bytes long. Uncompressing from
the Finder does not work and closer inspection reveals that this is in fact a
gzipped html file, which points you to the list of mirrors.
This has been confusing new users for years now. Does not seem too hard to
fix...
--
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] (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects
[
https://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MDEP-194:
---
Component/s: unpack-dependencies
ArchiverException when using maven dependency plugin in multi-module projects
-
Key: MDEP-194
URL: https://jira.codehaus.org/browse/MDEP-194
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack-dependencies
Affects Versions: 2.0
Reporter: Sascha Hofer
Attachments:
maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact2.patch,
maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch,
mdep-194-its-aoc.diff, mdp-194-src-main-aoc.diff,
plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
Having the following module hierarchy the _unpack-dependencies_ goal of the
_maven-dependency-plugin_ produces an _ArchiverException_.
* A
** B
** C (depends on B)
I took a quick look into the code and found that when unpacking the
dependencies of module *C* the method _unpack(File, File, String, String)_ of
class _org.apache.maven.plugin.dependency.AbstractDependencyMojo_ gets passed
the *target/classes* directory of *B* as source file (instead of the created
jar).
part of the pom.xml which caused the error:
{noformat}
profile
idmulti-module-coverage/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idunpack-dependencies/id
phaseprocess-classes/phase
goals
goalunpack-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/classes/outputDirectory
excludeClassifierstests/excludeClassifiers
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{noformat}
exception:
{noformat}
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
at
org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-98) The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MDEP-98:
--
Description:
Using maven-dependency-plugin in a multimodule project inside a module wich has
a dependency with another module in the same project the next error ocurrs :
{noformat}org.codehaus.plexus.archiver.ArchiverException: The source must not
be a directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
at
org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error unpacking file:
c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to:
c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.{noformat}
Project structure is as follows:
plataforma
- platform-core
- platform-bundle
- platform-bundle-jar
- platform-bundle-src
and the error happens on executing any goal from parent pom.
maven-dependency-plugin seems to receive a reference to target/classes
directory for platform-core dependency instead of the URL to my local
repository where platform-core is located.
was:
Using maven-dependency-plugin in a multimodule project inside a module wich has
a dependency with another module in the same project the next error ocurrs :
org.codehaus.plexus.archiver.ArchiverException: The source must not be a
directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
at
org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MDEP-187: --- Component/s: copy dependency:copy fails when invoked from m2e with workspace resolution enabled - Key: MDEP-187 URL: https://jira.codehaus.org/browse/MDEP-187 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy Affects Versions: 2.1 Reporter: Igor Fedorenko Assignee: Brian Fox Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff m2e resolves workspace artifacts to their output folders but dependency:copy expects all artifacts to be files. I will provide trivial patch shortly. -- 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-758) Documentation incorrect for running single integration test
[ https://jira.codehaus.org/browse/SUREFIRE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305119#comment-305119 ] Kristian Rosenvold commented on SUREFIRE-758: - @Lyle; there's probably something else that's the root cause of this issue: A) Failsafe is not being executed, surefire instead. Inspect the log output from your test run B) Your are trying to run a single test method under MS-windows, which is a known bug and has been fixed in the upcoming 2.12.1 C) Your pom is not what you thought it was, check mvn help:effective-pom Surefire has an extensive set of automated tests, and this feature is not broken in itself. This issue will be closed unless you can make a small test project that demonstrates/reproduced. Thanks. Documentation incorrect for running single integration test --- Key: SUREFIRE-758 URL: https://jira.codehaus.org/browse/SUREFIRE-758 Project: Maven Surefire Issue Type: Improvement Components: documentation Reporter: Lyle Hanson Priority: Minor The online documentation for Failsafe which describes [Running a Single Test|http://maven.apache.org/plugins/maven-failsafe-plugin/examples/single-test.html] shows: bq.mvn -Dit.test=ITCircle verify The it.test parameter does not seem to work. Rather, the same parameter as Surefire (-Dtest=foo) appears to also work for Failsafe. -- 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-887) Do not hold forked surefire for debug if there are no tests
[
https://jira.codehaus.org/browse/SUREFIRE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305120#comment-305120
]
Kristian Rosenvold commented on SUREFIRE-887:
-
The fix for this issue involves cleaning up the directory scanning logic;
since it is a bit convoluted. For forkmode never forkMode always the scanning
happens in the plugin, for once it happens inside the fork; the drawback
being that we must fork the process to do scanning (meaning debugging)
I think moving the scanning to the plugin side for once is a very good idea,
since it will make the plugin-provider simpler. Furthermore it will allow us
to simplify the fork starting logic further, which is still sorely needed.
Simplifying the fork logic further may allow us to start the actual fork JVM
*before* the directory scanning is complete, which has the potential of saving
100ms or so per fork invocation.
Do not hold forked surefire for debug if there are no tests
---
Key: SUREFIRE-887
URL: https://jira.codehaus.org/browse/SUREFIRE-887
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: 2.12
Reporter: Marvin Froeder
This is something a bit annoying.
When I enable debug (by either using -Dmaven.surefire.debug=true or
-Dmaven.failsafe.debug=true) surefire will hold maven execution until a
debugger is connected to the forked process.
The problem is that time to time there are no tests to be executed!
So my patch just skips launching the forked VM if there are no tests to be
executed!
{noformat}
Index:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
===
---
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
(revision 1361154)
+++
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
(working copy)
@@ -31,6 +31,7 @@
import java.util.concurrent.Future;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
+
import org.apache.maven.plugin.surefire.CommonReflector;
import org.apache.maven.plugin.surefire.StartupReportConfiguration;
import org.apache.maven.plugin.surefire.booterclient.output.ForkClient;
@@ -47,6 +48,8 @@
import org.apache.maven.surefire.providerapi.SurefireProvider;
import org.apache.maven.surefire.report.RunStatistics;
import org.apache.maven.surefire.suite.RunResult;
+import org.apache.maven.surefire.testset.DirectoryScannerParameters;
+import org.apache.maven.surefire.util.DefaultDirectoryScanner;
import org.codehaus.plexus.util.cli.CommandLineException;
import org.codehaus.plexus.util.cli.CommandLineTimeOutException;
import org.codehaus.plexus.util.cli.CommandLineUtils;
@@ -66,6 +69,7 @@
* @author Dan Fabulich
* @author Carlos Sanchez
* @author Kristian Rosenvold
+ * @author a href='mailto:marvin[at]marvinformatics[dot]com'Marvin
Froeder/a
* @version $Id$
*/
public class ForkStarter
@@ -106,6 +110,12 @@
final String requestedForkMode = forkConfiguration.getForkMode();
try
{
+
+if ( Boolean.FALSE.equals( hasTestToRun() ) )
+{
+return new RunResult( 0, 0, 0, 0 );
+}
+
if ( ForkConfiguration.FORK_ONCE.equals( requestedForkMode ) )
{
final ForkClient forkClient =
@@ -134,6 +144,24 @@
return result;
}
+private Boolean hasTestToRun()
+{
+// verify if there are tests to be executed
+DirectoryScannerParameters params =
providerConfiguration.getDirScannerParams();
+if ( params == null )
+{
+//unknow
+return null;
+}
+
+DefaultDirectoryScanner scanner =
+new DefaultDirectoryScanner( params.getTestClassesDirectory(),
params.getIncludes(), params.getExcludes(),
+ params.getSpecificTests() );
+
+String[] tests = scanner.collectTests();
+return tests.length != 0;
+}
+
private RunResult runSuitesForkPerTestSet( final Properties properties,
int forkCount )
throws SurefireBooterForkException
{
Index:
surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
===
---
surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
(revision 1361154)
+++
[jira] (SUREFIRE-890) maven-failsafe-plugin does not pick up POJO tests
[
https://jira.codehaus.org/browse/SUREFIRE-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-890.
---
Resolution: Not A Bug
Assignee: Kristian Rosenvold
This is not a bug. Using the Pojo provider requires neither JUNIT nor
TestNG to be on the project path. Please let us know if the documentation is
somehow unclear on this.
maven-failsafe-plugin does not pick up POJO tests
-
Key: SUREFIRE-890
URL: https://jira.codehaus.org/browse/SUREFIRE-890
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.12
Environment: Windows 7 Enterprise SP1
Java 1.6
STS 2.9.2.RELEASE
Maven 3.0.2 (external)
Reporter: John Rodriguez
Assignee: Kristian Rosenvold
Priority: Minor
Per the docs here:
http://maven.apache.org/plugins/maven-failsafe-plugin/examples/pojo-test.html
A [POJO] test class should be named **/*Test and should contain test*
methods
However, the following tests are not being executed by the plugin:
Test Class (before)
{code}
public class GameResourceTest {
public void testGetGamesForDate_20120603_status200Expected() ...
public void testGetGamesForDate_20120608_status404Expected() ...
...
}
{/code}
Maven Console
{code}
[INFO] --- maven-failsafe-plugin:2.12:integration-test (integration-test) @
gameservice ---
[INFO] Failsafe report directory: $$$\gameservice\target\failsafe-reports
---
T E S T S
---
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
{/code}
However, if I copy and rename the class appropriately and extend JUnit, the
tests execute.
Test Class (after)
{code}
import junit.framework.TestCase;
public class GameResourceTestIT extends TestCase {
public void testGetGamesForDate_20120603_status200Expected() ...
public void testGetGamesForDate_20120608_status404Expected() ...
...
}
{/code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-890) maven-failsafe-plugin does not pick up POJO tests
[
https://jira.codehaus.org/browse/SUREFIRE-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305122#comment-305122
]
Kristian Rosenvold commented on SUREFIRE-890:
-
Actually, I can see the documentation is a bit inadequate on this.
(http://maven.apache.org/plugins/maven-failsafe-plugin/examples/pojo-test.html)
Doc update coming up
maven-failsafe-plugin does not pick up POJO tests
-
Key: SUREFIRE-890
URL: https://jira.codehaus.org/browse/SUREFIRE-890
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.12
Environment: Windows 7 Enterprise SP1
Java 1.6
STS 2.9.2.RELEASE
Maven 3.0.2 (external)
Reporter: John Rodriguez
Assignee: Kristian Rosenvold
Priority: Minor
Per the docs here:
http://maven.apache.org/plugins/maven-failsafe-plugin/examples/pojo-test.html
A [POJO] test class should be named **/*Test and should contain test*
methods
However, the following tests are not being executed by the plugin:
Test Class (before)
{code}
public class GameResourceTest {
public void testGetGamesForDate_20120603_status200Expected() ...
public void testGetGamesForDate_20120608_status404Expected() ...
...
}
{/code}
Maven Console
{code}
[INFO] --- maven-failsafe-plugin:2.12:integration-test (integration-test) @
gameservice ---
[INFO] Failsafe report directory: $$$\gameservice\target\failsafe-reports
---
T E S T S
---
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
{/code}
However, if I copy and rename the class appropriately and extend JUnit, the
tests execute.
Test Class (after)
{code}
import junit.framework.TestCase;
public class GameResourceTestIT extends TestCase {
public void testGetGamesForDate_20120603_status200Expected() ...
public void testGetGamesForDate_20120608_status404Expected() ...
...
}
{/code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-893) Unsupported provider features should throw exception
Kristian Rosenvold created SUREFIRE-893: --- Summary: Unsupported provider features should throw exception Key: SUREFIRE-893 URL: https://jira.codehaus.org/browse/SUREFIRE-893 Project: Maven Surefire Issue Type: Improvement Reporter: Kristian Rosenvold The feature matrix indicates that not all providers support all features, but some providers do not throw exceptions if the feature is attempted used. http://maven.apache.org/plugins/maven-surefire-plugin-2.12.1/plugins/maven-surefire-plugin/featurematrix.html Add mechanism to throw exception when a provider does not support a feature. -- 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
