[jira] Closed: (SUREFIRE-776) Annotation based logic to identify Unit tests from Integration Tests
[ https://jira.codehaus.org/browse/SUREFIRE-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-776. --- Resolution: Fixed Assignee: Kristian Rosenvold Issue was fixed with SUREFIRE-329 > Annotation based logic to identify Unit tests from Integration Tests > > > Key: SUREFIRE-776 > URL: https://jira.codehaus.org/browse/SUREFIRE-776 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Affects Versions: 2.10 > Environment: All >Reporter: Josh Smith >Assignee: Kristian Rosenvold > > Currently, based on the documentation, the failsafe plugin only identifies > classes to use as integration tests based on the IT naming scheme in the > class name. > It would be nice to be able to leverage some of the other options in JUNit4 > and use a annotation for that. If we had a @IntegrationTest annotation at the > class/method level then the Failsafe plugin and/or the surefire plugin could > use that to identify what tests went with which tool and when to execute. > Seems like a much cleaner and easier way to filter tests between the phases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-785) Lots of newlines being strewn about in test output
[ https://jira.codehaus.org/browse/SUREFIRE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283353#comment-283353 ] Kristian Rosenvold commented on SUREFIRE-785: - I see that the file log when using redirectTestOutputToFile=true contains superfluous newlines. Is there any other case you're talking about ? > Lots of newlines being strewn about in test output > -- > > Key: SUREFIRE-785 > URL: https://jira.codehaus.org/browse/SUREFIRE-785 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.10 > Environment: Linux 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 > UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_25" > Java(TM) SE Runtime Environment (build 1.6.0_25-b06) > Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode) > Apache Maven 3.0.3 (r1075438; 2011-02-28 11:31:09-0600) > Maven home: /home/david/local/apache-maven > Java version: 1.6.0_25, vendor: Sun Microsystems Inc. > Java home: /home/david/local/jdk/sun-jdk-1.6.0_25-x86_64/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.40.4-5.fc15.x86_64", arch: "amd64", family: > "unix" >Reporter: David M. Lloyd > > Since 2.10, surefire has been emitting lots of superfluous newlines. I was > looking at commit 81694ee84e5155d402ea8564196e8aaf34ec7cec as a potential > culprit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-644) Correctly remove directory in gitexe provider
Correctly remove directory in gitexe provider - Key: SCM-644 URL: https://jira.codehaus.org/browse/SCM-644 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.5 Reporter: Bertrand Paquet Priority: Minor Attachments: patch Gitexe provider does not issue -r option when removing directory. Directory removal is possible by removing all files in directory, but it's not compatible with others SCM like svn. Patch and tests are attaches. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-279) an patterns do not work with .tar.gz packaging
[
https://jira.codehaus.org/browse/MDEP-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MDEP-279.
-
Resolution: Duplicate
Assignee: Brett Porter (was: Brian Fox)
> an patterns do not work with .tar.gz packaging
>
>
> Key: MDEP-279
> URL: https://jira.codehaus.org/browse/MDEP-279
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.0, 2.1
>Reporter: Torben Knerr
>Assignee: Brett Porter
>
> I have created a {{myapp-1.0-jar-with-dependencies.tar.gz}} file using the
> maven-assembly-plugin:
> {code}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
> jar-with-dependencies
>
> tar.gz
>
> false
>
>
>
>
> true
> runtime
>
> *:jar:*
>
>
>
>
> {code}
> Now I want to unpack {{myapp-1.0-jar-with-dependencies.tar.gz}} to another
> maven project's target directory, but exclude some of the files in the
> .tar.gz file:
> {code}
>
> maven-dependency-plugin
>
>
> copy-to-shared-folder
> generate-sources
>
> unpack
>
>
>
>
> my.group.id
> myapp
> 1.0
>
> jar-with-dependencies
> tar.gz
> **/*.*
>
> **/bad-file.jar,**/some-stuff.log
>
> ${project.build.directory}/myapp-libs
>
>
> true
> true
>
>
>
>
> {code}
> *However, the {{}} and {{}} sections are completely
> ignored here.*
> I have noticed that for {{zip}} dependencies the include/exclude
> filters are working as expected, but I would assume that it should for for
> {{.tar.gz}} as well
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-288) The includes/excludes feature on the dependency:unpack goal does not work for artifacts of type tar.gz
[
https://jira.codehaus.org/browse/MDEP-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MDEP-288.
-
Resolution: Duplicate
> The includes/excludes feature on the dependency:unpack goal does not work for
> artifacts of type tar.gz
> --
>
> Key: MDEP-288
> URL: https://jira.codehaus.org/browse/MDEP-288
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.1
>Reporter: Bryan Engel
>Assignee: Brian Fox
>
> I am trying to unpack an artifact of type tar.gz and filter some of the
> files. Nothing is filtered. This works for artifacts of type zip, but not
> tar.gz.
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.1
>
>
> modules
> process-resources
>
> unpack
>
>
>
>
>
> org.apache.maven
> apache-maven
> tar.gz
> src
> 2.2.1
> out1
> **/*.txt
>
>
>
> org.apache.maven
> apache-maven
> zip
> src
> 2.2.1
> out2
> **/*.txt
>
>
>
>
>
>
> log output:
> C:\tmp>mvn process-resources
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building FabricServer Installer
> [INFO]task-segment: [process-resources]
> [INFO]
>
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory C:\tmp\src\main\resources
> [INFO] [dependency:unpack {execution: modules}]
> [INFO] Configured Artifact: org.apache.maven:apache-maven:src:2.2.1:tar.gz
> [INFO] Configured Artifact: org.apache.maven:apache-maven:src:2.2.1:zip
> [INFO] Unpacking C:\Documents and
> Settings\\.m2\repository\org\apache\maven\apache-maven\2.2.1\apache-maven-2.2.1-
> src.tar.gz to
> C:\tmp\out1
>with includes null and excludes:**/*.txt
> [INFO] Expanding C:\Documents and
> Settings\\.m2\repository\org\apache\maven\apache-maven\2.2.1\apache-maven-2.2.1-
> src.tar.gz to C:\DOCUME~1\bengel\LOCALS~1\Temp\tmp1546101557682884989.tar
> [INFO] Expanding: C:\DOCUME~1\bengel\LOCALS~1\Temp\tmp1546101557682884989.tar
> into C:\tmp\out1
> [INFO] Unpacking C:\Documents and
> Settings\\.m2\repository\org\apache\maven\apache-maven\2.2.1\apache-maven-2.2.1-
> src.zip to
> C:\tmp\out2
>with includes null and excludes:**/*.txt
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 17 seconds
> [INFO] Finished at: Thu Sep 30 15:20:28 EDT 2010
> [INFO] Final Memory: 13M/24M
> [INFO]
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-459) releaseProfiles has no effect without passing profiles in the command line
[ https://jira.codehaus.org/browse/MRELEASE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283370#comment-283370 ] Chris Watts commented on MRELEASE-459: -- This also seems to effect maven3 maven-release-plugin:2.2.1 Not sure if it's to do with running maven thus: mvn release:prepare release:perform > releaseProfiles has no effect without passing profiles in the command line > --- > > Key: MRELEASE-459 > URL: https://jira.codehaus.org/browse/MRELEASE-459 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.0-beta-8, 2.0-beta-9 >Reporter: Andreas Christoforides > Attachments: patch.txt > > > The releaseProfiles parameter on the perform goal is not taken into > consideration when no other profiles are passed in the command line. In other > words, the current code only uses the value of the parameter if you have > additional profiles passed in. > Example: > mvn release:perform -P someProfile (uses releaseProfiles value) > mvn release:perform (does NOT use releaseProfiles value) > The plugin should use the parameter even if no other profiles are passed. It > should actually encourage release profiles configured in your POM as opposed > to arbitrary profiles passed in the command line. > I have included a patch that uses the releaseProfiles parameter regardless of > any profiles passed in the command line. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-338) Use of default excludes in unpack should be configurable
Use of default excludes in unpack should be configurable
Key: MDEP-338
URL: https://jira.codehaus.org/browse/MDEP-338
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack, unpack-dependencies
Affects Versions: 2.3
Reporter: Brett Porter
In the unpack method, include/exclude selectors are used, which have "default
excludes" configured. This can not be turned off.
I believe this option should be available, and it should default to {{false}}.
While this changes behaviour in some instances (though not all, due to a bug -
see related issue MDEP-337), I believe it is the expected behaviour. The
default excludes are not expected to be present in the archive in the first
place.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-337) Application of default excludes is inconsistent
Application of default excludes is inconsistent
---
Key: MDEP-337
URL: https://jira.codehaus.org/browse/MDEP-337
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack, unpack-dependencies
Affects Versions: 2.3
Reporter: Brett Porter
In the unpack method, include/exclude selectors are used, which have "default
excludes" configured. When a POM configures the following, the default excludes
are also applied:
{code:xml}
**/something.txt
{code}
However, if no excludes are present, then the default excludes are not applied.
If no excludes are present, then the default excludes should be applied in the
same way as if they were. However, I don't believe the exclusions should be on
by default (see related issue).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-338) Use of default excludes in unpack should be configurable
[
https://jira.codehaus.org/browse/MDEP-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith E. Campbell updated MDEP-338:
---
Attachment: useDefaultExcludes.patch
UnpackMojo.patch
AbstractDependencyMojo.patch
Here is a possible patch generated against plugin version 2.3.
> Use of default excludes in unpack should be configurable
>
>
> Key: MDEP-338
> URL: https://jira.codehaus.org/browse/MDEP-338
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 2.3
>Reporter: Brett Porter
> Attachments: AbstractDependencyMojo.patch, UnpackMojo.patch,
> useDefaultExcludes.patch
>
>
> In the unpack method, include/exclude selectors are used, which have "default
> excludes" configured. This can not be turned off.
> I believe this option should be available, and it should default to
> {{false}}. While this changes behaviour in some instances (though not all,
> due to a bug - see related issue MDEP-337), I believe it is the expected
> behaviour. The default excludes are not expected to be present in the archive
> in the first place.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-338) Use of default excludes in unpack should be configurable
[
https://jira.codehaus.org/browse/MDEP-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith E. Campbell updated MDEP-338:
---
Attachment: AbstractDependencyMojo.patch
> Use of default excludes in unpack should be configurable
>
>
> Key: MDEP-338
> URL: https://jira.codehaus.org/browse/MDEP-338
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 2.3
>Reporter: Brett Porter
> Attachments: AbstractDependencyMojo.patch,
> AbstractDependencyMojo.patch, UnpackMojo.patch, useDefaultExcludes.patch
>
>
> In the unpack method, include/exclude selectors are used, which have "default
> excludes" configured. This can not be turned off.
> I believe this option should be available, and it should default to
> {{false}}. While this changes behaviour in some instances (though not all,
> due to a bug - see related issue MDEP-337), I believe it is the expected
> behaviour. The default excludes are not expected to be present in the archive
> in the first place.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-338) Use of default excludes in unpack should be configurable
[
https://jira.codehaus.org/browse/MDEP-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith E. Campbell updated MDEP-338:
---
Attachment: UnpackDependenciesMojo.patch
> Use of default excludes in unpack should be configurable
>
>
> Key: MDEP-338
> URL: https://jira.codehaus.org/browse/MDEP-338
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 2.3
>Reporter: Brett Porter
> Attachments: AbstractDependencyMojo.patch,
> AbstractDependencyMojo.patch, UnpackDependenciesMojo.patch, UnpackMojo.patch,
> useDefaultExcludes.patch
>
>
> In the unpack method, include/exclude selectors are used, which have "default
> excludes" configured. This can not be turned off.
> I believe this option should be available, and it should default to
> {{false}}. While this changes behaviour in some instances (though not all,
> due to a bug - see related issue MDEP-337), I believe it is the expected
> behaviour. The default excludes are not expected to be present in the archive
> in the first place.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-338) Use of default excludes in unpack should be configurable
[
https://jira.codehaus.org/browse/MDEP-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283373#comment-283373
]
Keith E. Campbell commented on MDEP-338:
Sorry for the bungled file attach. The correct three files are:
AbstractDependencyMojo.patch
UnpackDependenciesMojo.patch
UnpackMojo.patch
The useDefaultExcludes was posted in error.
> Use of default excludes in unpack should be configurable
>
>
> Key: MDEP-338
> URL: https://jira.codehaus.org/browse/MDEP-338
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 2.3
>Reporter: Brett Porter
> Attachments: AbstractDependencyMojo.patch,
> AbstractDependencyMojo.patch, UnpackDependenciesMojo.patch, UnpackMojo.patch,
> useDefaultExcludes.patch
>
>
> In the unpack method, include/exclude selectors are used, which have "default
> excludes" configured. This can not be turned off.
> I believe this option should be available, and it should default to
> {{false}}. While this changes behaviour in some instances (though not all,
> due to a bug - see related issue MDEP-337), I believe it is the expected
> behaviour. The default excludes are not expected to be present in the archive
> in the first place.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-390) Several parameters of the create-from-project mojo lack documentation
Several parameters of the create-from-project mojo lack documentation - Key: ARCHETYPE-390 URL: https://jira.codehaus.org/browse/ARCHETYPE-390 Project: Maven Archetype Issue Type: Bug Components: Plugin Affects Versions: 2.1 Reporter: Benson Margulies All the parameters of create-from-project should be documented or marked @readonly so that they don't show up at all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-391) The defaultEncoding parameter is never used.
The defaultEncoding parameter is never used. Key: ARCHETYPE-391 URL: https://jira.codehaus.org/browse/ARCHETYPE-391 Project: Maven Archetype Issue Type: Bug Components: Plugin Affects Versions: 2.1 Reporter: Benson Margulies The create-from-project as a defaultEncoding parameter which is not used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPMD-67) Using JDK 1.6 causes ParseException: Can't use generics unless running in JDK 1.5 mode!
[ https://jira.codehaus.org/browse/MPMD-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=283374#comment-283374 ] Kaushal Kumar commented on MPMD-67: --- property was not working in tag of maven-pmd-plugin, so i moved this property as common property in my pom.xml, like UTF-8 UTF-8 1.5 This worked for me. > Using JDK 1.6 causes ParseException: Can't use generics unless running in JDK > 1.5 mode! > --- > > Key: MPMD-67 > URL: https://jira.codehaus.org/browse/MPMD-67 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Maven 2.0.8 > JDK 1.6 >Reporter: Will Hoover > Fix For: 2.3 > > > While using Maven PMD plugin with: > > org.apache.maven.plugins > maven-pmd-plugin > 2.2 > > true > utf-8 > 100 > > 1.6 > > > > **/generated/*.java > > > > I get the following error even though JDK is 1.6: > [WARNING] Failure executing PMD for: SomeGenericJavaClass.java > net.sourceforge.pmd.PMDException: Error while parsing > SomeGenericJavaClass.java > at net.sourceforge.pmd.PMD.processFile(PMD.java:104) > at net.sourceforge.pmd.PMD.processFile(PMD.java:64) > at net.sourceforge.pmd.PMD.processFile(PMD.java:150) > at > org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:228) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > 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) > Caused by: net.sourceforge.pmd.ast.ParseException: Can't use generics unless > running in JDK 1.5 mode! > at > net.sourceforge.pmd.ast.JavaParser.checkForBadGenericsUsage(JavaParser.java:32) > at > net.sourceforge.pmd.ast.JavaParser.TypeArguments(JavaParser.java:1962) > at > net.sourceforge.pmd.ast.JavaParser.ClassOrInterfaceType(JavaParser.java:1911) > at > net.sourceforge.pmd.ast.JavaParser.ReferenceType(JavaParser.java:1862) > at net.sourceforge.pmd.ast.JavaParser.Type(JavaP
