[jira] Closed: (SCM-174) Bugfix changelog cmd (take 1) and some general refinements
[ http://jira.codehaus.org/browse/SCM-174?page=all ] Emmanuel Venisse closed SCM-174: Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0 Applied. Bugfix changelog cmd (take 1) and some general refinements -- Key: SCM-174 URL: http://jira.codehaus.org/browse/SCM-174 Project: Maven SCM Type: Bug Components: maven-scm-provider-bazaar Environment: Tested: Tck tests on WinXP and Linux (Gentoo) with Bazaar 0.7 and Continuum with changelog report. Reporter: Torbjørn EIkli Smørgrav Assignee: Emmanuel Venisse Fix For: 1.0 Attachments: SCM-174-maven-scm-provider-bazaar.patch BazaarUtils: - refactored execute cmd, added more debugging onfo (bazaar version) ChangLogCmd: - Avoid null and empty filesets in the ChangeSets General: - More precise javadoc TODO: The changelog report is now generating empty reports (but is not failing as before). I plan to fix that in next my next patch (take 2). -- 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: (MPA-53) Pro cess Torbjørn Eikli Smørgrav
Process Torbjørn Eikli Smørgrav --- Key: MPA-53 URL: http://jira.codehaus.org/browse/MPA-53 Project: Maven Project Administration Type: Task Components: New Committers Versions: 2006-q1 Reporter: Emmanuel Venisse Assigned to: Jason van Zyl Fix For: 2006-q1 Preferred Unix ID: smorgrav or tsmoergrav Full name: Torbjørn Eikli Smørgrav Forwarding email address: [EMAIL PROTECTED] Requested UNIX groups: maven Vote: http://mail-archives.apache.org/mod_mbox/maven-scm-dev/200603.mbox/[EMAIL PROTECTED] -- 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] Closed: (MASSEMBLY-54) Unable to filter files while creating assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-54?page=all ] Allan Ramirez closed MASSEMBLY-54: -- Resolution: Fixed added new tag (filtered) in assembly descriptor for FileItem which will filter the file and add the filtered file to the assembly. files file sourceREADME.TXT/source filteredtrue/filtered /file /files Unable to filter files while creating assembly -- Key: MASSEMBLY-54 URL: http://jira.codehaus.org/browse/MASSEMBLY-54 Project: Maven 2.x Assembly Plugin Type: Improvement Versions: 2.0 Reporter: Chris Hagmann Assignee: Allan Ramirez Fix For: 2.1 Original Estimate: 6 hours Remaining: 6 hours It doesn't seem to be possible to use filtering when creating assemblies. I have a couple of plain-text files which need to be updated when creating the assembly (e.g. README.TXT, .version). -- 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: (MAVENUPLOAD-785) Java Tree Builder 1.3.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-785?page=comments#action_61766 ] Carlos Sanchez commented on MAVENUPLOAD-785: wow, what detailed info ;) yes, edu.ucla.cs.compilers would be better Java Tree Builder 1.3.2 --- Key: MAVENUPLOAD-785 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-785 Project: maven-upload-requests Type: Task Reporter: Greg Kick JTB is a syntax tree builder to be used with the Java Compiler Compiler (JavaCC) parser generator. It is often used as an alternatvie to JJTree due to it's ease of use. -- 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] Closed: (MAVENUPLOAD-786) Wicket 1.2 beta2 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-786?page=all ] Carlos Sanchez closed MAVENUPLOAD-786: -- Assign To: Carlos Sanchez Resolution: Fixed Wicket 1.2 beta2 upload request --- Key: MAVENUPLOAD-786 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-786 Project: maven-upload-requests Type: Task Reporter: Nathan Hamblen Assignee: Carlos Sanchez Please upload, with sources. -- 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: (MAVENUPLOAD-790) iText, a free Java-PDF library
iText, a free Java-PDF library -- Key: MAVENUPLOAD-790 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-790 Project: maven-upload-requests Type: Task Reporter: Bruno Lowagie iText is a free Java-PDF library. Some older versions of iText are already present on iBiblio: http://www.ibiblio.org/maven2/itext/itext/ I don't know who uploaded these old version, but for the most recent iText version, I would like to use the newer naming conventions (see POM) so that the URL looks like this: http://www.ibiblio.org/maven2/com/lowagie/itext/ -- 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] Closed: (CONTINUUM-633) pom aren't deployed to internal snapshot repository
[ http://jira.codehaus.org/browse/CONTINUUM-633?page=all ] Emmanuel Venisse closed CONTINUUM-633: -- Assign To: Emmanuel Venisse (was: Brett Porter) Resolution: Fixed Done. pom aren't deployed to internal snapshot repository --- Key: CONTINUUM-633 URL: http://jira.codehaus.org/browse/CONTINUUM-633 Project: Continuum Type: Bug Components: Web interface Versions: 1.0.3 Reporter: Emmanuel Venisse Assignee: Emmanuel Venisse Fix For: 1.0.3 -- 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: (MAVENUPLOAD-785) Java Tree Builder 1.3.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-785?page=comments#action_61771 ] Greg Kick commented on MAVENUPLOAD-785: --- alright, an updated version is at the same link. Java Tree Builder 1.3.2 --- Key: MAVENUPLOAD-785 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-785 Project: maven-upload-requests Type: Task Reporter: Greg Kick JTB is a syntax tree builder to be used with the Java Compiler Compiler (JavaCC) parser generator. It is often used as an alternatvie to JJTree due to it's ease of use. -- 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: (MNG-2172) dependencyManagementdependencyversion's are not used when evaluating plugindependenciesdependency
[ http://jira.codehaus.org/browse/MNG-2172?page=comments#action_61775 ] Kenney Westerhof commented on MNG-2172: --- Related sources: maven-project/.../DefaultMavenProjectBuilder.java, line 320: call to createManagedVersionMap. Proposal: move to MavenProject. Line 340: call to ArtifactResolver.resolveTransitively( ..., ..., managedVersionMap, ...); maven-core/.../DefaultPluginManager.java, line 608. Call to ArtifactResolver.resolveTransitively(.., ..., ...) (without the managedVersionMap). Proposal: add call to moved createManagedVersionMap function as a parameter. dependencyManagementdependencyversion's are not used when evaluating plugindependenciesdependency - Key: MNG-2172 URL: http://jira.codehaus.org/browse/MNG-2172 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Environment: 2.0.2-SNAPSHOT Reporter: John Allen dep management is not honoured for plugins dep evaluation. kenney hm.. looks like inheritance, after investigating.. the MavenMetaDataSource doesn't use the MavenProject.getDependencyManagement kenney jah.. found it. jallen NICE, estimate... 30 mins or 30 hrs? kenney 30 mins kenney the maven-project DefaultMavenProjectBuilder uses a different method in the ArtifactResolved to resolve deps than the maven-core DefaultPluginManager kenney but all the info is available.. -- 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: (MNG-2173) support dependencies in reporting plugins
support dependencies in reporting plugins - Key: MNG-2173 URL: http://jira.codehaus.org/browse/MNG-2173 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Reporter: John Allen Inconsistency with rest of design. -- 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: (MNG-2174) pluginManagementpluginsplugindependencies do not propogate to child POM plugins (potentially scoped to only affecting child POM plugins that live within a profile)
pluginManagementpluginsplugindependencies do not propogate to child POM plugins (potentially scoped to only affecting child POM plugins that live within a profile) - Key: MNG-2174 URL: http://jira.codehaus.org/browse/MNG-2174 Project: Maven 2 Type: Bug Reporter: John Allen pluginManagementpluginsplugindependencies do not propogate to child POM plugins. Kenny believe this works OKAY if the childs are using the parent pluginManagement preconfigured plugins in their main build section however it does NOT work if the childs are trying to use those preconfigured plugins via their own profiles. Configuration propogates through okay but dependencies are missing and have to be respecified in the child POMs. -- 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: (MIDEA-40) war module-dependencies are jarred and copied to /WEB-INF/classes
war module-dependencies are jarred and copied to /WEB-INF/classes - Key: MIDEA-40 URL: http://jira.codehaus.org/browse/MIDEA-40 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Geoffrey De Smet Fix For: 2.0 A mulitproject with a jar module A and a war module B, where B depends on A, will be configured so that: In web module settings, under Modules and libraries to package: module A : JAR module output and copy file to: /WEB-INF/classes This should either be module A : copy module output to: /WEB-INF/classes or module A : JAR module output and copy file to: /WEB-INF/lib/jarname.jar Both should be supported a believe, as the second one mimics maven and the real way of doing it, but the first one is a lot faster -- 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: (MSUREFIRE-83) Tests run with Surefire are not able to make remote calls to an RMI server of an EJB server
Tests run with Surefire are not able to make remote calls to an RMI server of an EJB server --- Key: MSUREFIRE-83 URL: http://jira.codehaus.org/browse/MSUREFIRE-83 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.2 Environment: Windows 2000, Java JDK 1.4 Reporter: Todd Nine Priority: Blocker Attachments: verbose_app_ output.txt I am unable run any unit tests that connect to a remote RMI server. This includes vanilla RMI, or JBoss remote connections. I can however use the same classpath set by maven with the maven 2 eclipse plugin, and all tests execute successfully. I always receive a socket timeout, which seems to be the root cause of the remote connectivity issues, but I only receive them when running the tests from within surefire. I have attached a stack trace and verbose output. -- 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: (MAVENUPLOAD-791) Upload M12 cayenne and cayenne-nodeps bundles
Upload M12 cayenne and cayenne-nodeps bundles - Key: MAVENUPLOAD-791 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-791 Project: maven-upload-requests Type: Task Reporter: Andrus Adamchik Cayenne is already on ibiblio. Please upload these two new bundles: http://objectstyle.org/downloads/cayenne/maven-bundles/cayenne-1.2M12-bundle.jar http://objectstyle.org/downloads/cayenne/maven-bundles/cayenne-nodeps-1.2M12-bundle.jar Thanks! Andrus -- 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] Closed: (MNG-2168) Manifest dependency includes any scope
[ http://jira.codehaus.org/browse/MNG-2168?page=all ] Guillaume Boissier closed MNG-2168: --- Resolution: Incomplete Manifest dependency includes any scope -- Key: MNG-2168 URL: http://jira.codehaus.org/browse/MNG-2168 Project: Maven 2 Type: Bug Components: maven-archiver Environment: any Reporter: Guillaume Boissier There is no way to specify what classpath dependency need to be taken into account I just need the runtime dependency not the compilation on. build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addClasspathtrue/addClasspath addExtensionstrue/addExtensions /manifest /archive /configuration /plugin /plugins /build -- 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: (MPA-53) Pr ocess Torbjørn Eikli Smørgrav
[ http://jira.codehaus.org/browse/MPA-53?page=comments#action_61787 ] Emmanuel Venisse commented on MPA-53: - CLA is faxed Process Torbjørn Eikli Smørgrav --- Key: MPA-53 URL: http://jira.codehaus.org/browse/MPA-53 Project: Maven Project Administration Type: Task Components: New Committers Versions: 2006-q1 Reporter: Emmanuel Venisse Assignee: Jason van Zyl Fix For: 2006-q1 Preferred Unix ID: smorgrav or tsmoergrav Full name: Torbjørn Eikli Smørgrav Forwarding email address: [EMAIL PROTECTED] Requested UNIX groups: maven Vote: http://mail-archives.apache.org/mod_mbox/maven-scm-dev/200603.mbox/[EMAIL PROTECTED] -- 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] Erstellt: (MDEPLOY-27) Improper build number after deploying a snapshot of maven-javadoc-plugin
Improper build number after deploying a snapshot of maven-javadoc-plugin Key: MDEPLOY-27 URL: http://jira.codehaus.org/browse/MDEPLOY-27 Project: Maven 2.x Deploy Plugin Type: Bug Versions: 2.2 Environment: Windows XP JDK 1.5.0_06 Cygwin environment installed Reporter: Thorsten Heit Priority: Minor I'm trying to use the beta-4 snapshot of the maven-javadoc-plugin and wanted to deploy it on my local maven proxy. The plugin is deployed via: $ mvn compile jar:jar (lots of messages) $ cd target $ mvn deploy:deploy-file -DrepositoryId=bender -Durl=file://H:/maven-proxy/target/repo-local -DpomFile=exported-pom.xml -Dfile=maven-javadoc-plugin-2.0-beta-4-SNAPSHOT.jar (lots of messages) The plugin jar gets copied to the proxy, and so far everything seems to be fine. In another project, I added the following lines to my pom.xml: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.0-beta-4-SNAPSHOT/version configuration tagcreated/tag maxmemory256m/maxmemory /configuration /plugin ... /plugins /build Unfortunately the plugin cannot be downloaded from my proxy: $ mvn clean [INFO] Scanning for projects... [INFO] [INFO] Building base Repository [INFO]task-segment: [clean] [INFO] Downloading: http://bender:/repository/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-4-SNAPSHOT/maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-javadoc-plugin Version: 2.0-beta-4-20060322.180042-2 Reason: Unable to locate resource in repository org.apache.maven.plugins:maven-javadoc-plugin:maven-plugin:2.0-beta-4-20060322.180042-2 from the specified remote repositories: central (http://repo1.maven.org/maven2), bender (http://bender:/repository), snapshots-codehaus-org (http://snapshots.maven.codehaus.org/maven2) which is strange because I just deployed it. I looked into the proxy directories and wondered that the files are named differently: * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar.md5 * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar.sha1 * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom.md5 * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom.sha1 When I manually rename the -1.jar* files to -2.jar* the plugin is downloadable, and mvn clean above will work... To check the above behaviour I removed the deployed files/directories from my maven proxy and redeployed the javadoc plugin: $ mvn -X deploy:deploy-file -DrepositoryId=bender -Durl=file://H:/maven-proxy/target/repo-local -DpomFile=exported-pom.xml -Dfile=maven-javadoc-plugin-2.0-beta-4-SNAPSHOT.jar + Error stacktraces are turned on. [DEBUG] Building Maven user-level plugin registry from: 'C:\Dokumente und Einstellungen\heit\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'c:\Programme\Apache\maven-2.0.2\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [DEBUG] maven-deploy-plugin: resolved to version 2.2 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-deploy-plugin:maven-plugin:2.2 [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [deploy:deploy-file] (aggregator-style) [INFO] [DEBUG] org.apache.maven.plugins:maven-deploy-plugin:maven-plugin:2.2 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: null:maven-project:jar:2.0.1 [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-model:jar:2.0.1 [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: null:plexus-utils:jar:1.0.5 [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime) [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: null:maven-profile:jar:2.0.1 [DEBUG] org.apache.maven:maven-profile:jar:2.0.1
[jira] Created: (MEV-364) Fix dependencies of common-lang 1.0 (add test scope for junit)
Fix dependencies of common-lang 1.0 (add test scope for junit) -- Key: MEV-364 URL: http://jira.codehaus.org/browse/MEV-364 Project: Maven Evangelism Type: Bug Components: Invalid POM, Dependencies Reporter: Guillaume Boissier consider changing dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.7/version /dependency /dependencies to dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.7/version scopetest/scope /dependency /dependencies -- 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: (MSUREFIRE-72) [surefire-testng] SurefireReportMojo.executeReport() throws a java.lang.NumberFormatException
[ http://jira.codehaus.org/browse/MSUREFIRE-72?page=comments#action_61793 ] Thomas Cornet commented on MSUREFIRE-72: Try this workaround (it workde for me) : edit your 'mvn.bat' file and at the end, replace the java launch command by : %MAVEN_JAVA_EXE% %MAVEN_OPTS% -classpath %CLASSWORLDS_JAR% -Dclassworlds.conf=%M2_HOME%\bin\m2.conf -Dmaven.home=%M2_HOME% -Duser.language=en -Duser.country=US org.codehaus.classworlds.Launcher It is overriding the current locale (country and languages) so that the surefire plugin can interpret the comma as a decimal separator, and thus avoid the exception [surefire-testng] SurefireReportMojo.executeReport() throws a java.lang.NumberFormatException - Key: MSUREFIRE-72 URL: http://jira.codehaus.org/browse/MSUREFIRE-72 Project: Maven 2.x Surefire Plugin Type: Bug Reporter: Vincent Siveton Priority: Blocker Fix For: 2.2 Attachments: surefire-api_diff NumberFormat.getInstance() uses the current default locale in the jvm. The patch specifies the English Locale. Here is the full stacktrace: [INFO] Generate Maven Surefire Report report. java.lang.NumberFormatException: For input string: 0,031 at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224) at java.lang.Float.parseFloat(Float.java:394) at org.codehaus.mojo.surefire.ReportTestSuite.startElement(ReportTestSuite.java:78) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:798) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:878) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:1157) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) at javax.xml.parsers.SAXParser.parse(SAXParser.java:311) at org.codehaus.mojo.surefire.ReportTestSuite.init(ReportTestSuite.java:59) at org.codehaus.mojo.surefire.SurefireReportParser.parseXMLReportFiles(SurefireReportParser.java:42) at org.codehaus.mojo.surefire.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:44) at org.codehaus.mojo.surefire.SurefireReportMojo.executeReport(SurefireReportMojo.java:77) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) at org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:1055) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:397) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
[jira] Commented: (MSUREFIRE-59) JUnitBattery dies when TestSuite has an anonymous inner class
[ http://jira.codehaus.org/browse/MSUREFIRE-59?page=comments#action_61794 ]
Aaron Bell commented on MSUREFIRE-59:
-
Still looks broken to me, using the 2.1.3 SNAPSHOT with the simplest of
testcases (attached) gives:
[INFO]task-segment: [test]
[INFO]
[INFO] snapshot org.apache.maven.plugins:maven-surefire-plugin:2.1.3-SNAPSHOT:
checking for updates from snapshots
Downloading:
http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.1.3-SNAPSHOT/maven-surefire-plugin-2.1.3-20060228.012944-10.pom
1K downloaded
Downloading:
http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.1.3-SNAPSHOT/maven-surefire-plugin-2.1.3-20060228.012944-10.jar
9K downloaded
[INFO] [resources:resources]
...
---
T E S T S
---
java.lang.NoSuchMethodException: SurefireTest$1.init()
at java.lang.Class.getConstructor0(Class.java:2647)
at java.lang.Class.getConstructor(Class.java:1629)
at
org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
at
org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
at
org.apache.maven.surefire.battery.JUnitBattery.init(JUnitBattery.java:81)
at
org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
at
org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
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.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:304)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:220)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:368)
...
JUnitBattery dies when TestSuite has an anonymous inner class
-
Key: MSUREFIRE-59
URL: http://jira.codehaus.org/browse/MSUREFIRE-59
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.1.2
Reporter: Mike Perham
Assignee: Brett Porter
Fix For: 2.1.3
Attachments: SimpleTestSuite.java, SurefireTest.java
I have this method in my test suite:
{code}
private static File[] getWSDLFiles() {
URL directoryURL =
WSDLImportTestSuite.class.getResource(/com/webify/wsf/studio/core/wsdl/wsdls);
if (directoryURL != null) {
File directory = new File(directoryURL.getPath());
FilenameFilter filter = new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(.wsdl);
}
};
return directory.listFiles(filter);
}
else {
return null;
}
}
{code}
And surefire fails with this exception:
java.lang.NoSuchMethodException:
com.webify.wsf.studio.core.wsdl.WSDLImportTestSuite$1.init()
at java.lang.Class.getConstructor0(Class.java:1937)
at java.lang.Class.getConstructor(Class.java:1027)
at
org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
at
org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
at
org.apache.maven.surefire.battery.JUnitBattery.init(JUnitBattery.java:81)
at
org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
at
org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
--
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: (MAVENUPLOAD-792) outerthought libraries
outerthought libraries -- Key: MAVENUPLOAD-792 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-792 Project: maven-upload-requests Type: Task Reporter: Jorg Heymans please not that this bundle was made by hand. It contains the libs and poms with full directory structure for projects xReporter and Daisy. i coordinated with Bruno Dumon of Outerthought for creating this archive. -- 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] Updated: (MSUREFIRE-59) JUnitBattery dies when TestSuite has an anonymous inner class
[ http://jira.codehaus.org/browse/MSUREFIRE-59?page=all ]
Aaron Bell updated MSUREFIRE-59:
Attachment: SurefireTest.java
JUnitBattery dies when TestSuite has an anonymous inner class
-
Key: MSUREFIRE-59
URL: http://jira.codehaus.org/browse/MSUREFIRE-59
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.1.2
Reporter: Mike Perham
Assignee: Brett Porter
Fix For: 2.1.3
Attachments: SimpleTestSuite.java, SurefireTest.java
I have this method in my test suite:
{code}
private static File[] getWSDLFiles() {
URL directoryURL =
WSDLImportTestSuite.class.getResource(/com/webify/wsf/studio/core/wsdl/wsdls);
if (directoryURL != null) {
File directory = new File(directoryURL.getPath());
FilenameFilter filter = new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(.wsdl);
}
};
return directory.listFiles(filter);
}
else {
return null;
}
}
{code}
And surefire fails with this exception:
java.lang.NoSuchMethodException:
com.webify.wsf.studio.core.wsdl.WSDLImportTestSuite$1.init()
at java.lang.Class.getConstructor0(Class.java:1937)
at java.lang.Class.getConstructor(Class.java:1027)
at
org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
at
org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
at
org.apache.maven.surefire.battery.JUnitBattery.init(JUnitBattery.java:81)
at
org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
at
org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
--
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: (MCLEAN-7) empty excludes/ removes the directory of the fileset
[ http://jira.codehaus.org/browse/MCLEAN-7?page=comments#action_61796 ]
Jesse McConnell commented on MCLEAN-7:
--
ok, the setting the fileset to null above seems to throw the same exception now
that using an empty excludes statement does...
blows on line 502 of DirectoryScanner when setting excludes.
now...
excludesexclude/excludeexcludes blows up and have the excludes as an
arraylist of size 1 and null inside..
not having the excludes and just the includes yields an arraylist of size 0 and
removes the directory..
and the existing unit test ends up with a excludes arraylist of size 1 with a
element inside.. (which is the only one that passes unit test atm)
empty excludes/ removes the directory of the fileset
--
Key: MCLEAN-7
URL: http://jira.codehaus.org/browse/MCLEAN-7
Project: Maven 2.x Clean Plugin
Type: Bug
Reporter: Jesse McConnell
I was shifting the unit tests over to use the plugin harness and noticed a
test case failing.
if you look at the test case for the fileset test case, the second fileset
test has an addFileset(dir, **, );
this unit test works fine, but when you try and actually do this behavior
using the plugin configuration it brings up an error
fileset
directory${basedir}/target/test-classes/fileset-clean-test/buildOutputDirectory/directory
includes
include**/include
/includes
/fileset
that would be the plugin configuration of the same deal.
(exclude/exclude results in a stack trace)
In this case the directory is getting deleted when configured. You can
exhibit the same behavior with the existing test case if you try and pass
null into the addFileset signature...
this would be the failing test case using the existing plugin, note the null
in the second addFileset()
--
public void testFilesets()
throws Exception
{
String base = TARGET_TEST_DIR + /target;
CleanMojo mojo = new CleanMojo();
mojo.addFileset( createFileset( base, **/file.txt, **/subdir/** )
);
String outputDirectory = TARGET_TEST_DIR + /buildOutputDirectory;
mojo.addFileset( createFileset( outputDirectory, **, null ) );
mojo.execute();
// fileset 1
assertTrue( checkExists( base ) );
assertTrue( checkExists( base + /classes ) );
assertFalse( checkExists( base + /classes/file.txt ) );
/* TODO: looks like a bug in the file-management library
assertTrue( FileUtils.fileExists( base + /subdir/file.txt ) );
*/
// fileset 2
assertTrue( checkExists( outputDirectory ) );
assertFalse( checkExists( outputDirectory + /file.txt ) );
System.exit(-1);
}
--
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: (MAVENUPLOAD-793) xreporter expression library
xreporter expression library Key: MAVENUPLOAD-793 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-793 Project: maven-upload-requests Type: Task Reporter: Jorg Heymans please add to ibiblio/maven2 -- 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: (MAVENUPLOAD-795) daisy html cleaner library
daisy html cleaner library -- Key: MAVENUPLOAD-795 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-795 Project: maven-upload-requests Type: Task Reporter: Jorg Heymans please add to ibiblio/maven2 -- 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: (MAVEN-1270) multiproject:clean fails due to dependencies in reactor set
[ http://jira.codehaus.org/browse/MAVEN-1270?page=comments#action_61790 ]
Yassine Lajmi commented on MAVEN-1270:
--
For CruiseControl Use this :
goal name=clean-update-all
echo/echo
echoClean all /echo
echo/echo
j:catch var=exception
attainGoal name=multiproject:clean/
/j:catch
j:if test=${exception != null}
echo###/echo
echoError while calling goal [${goalName}]:/echo
echo /echo
echo delete manually all target directories :
/echo
echo /echo
delete includeEmptyDirs=true
fileset dir=${basedir}
include name=**/target/
/fileset
/delete
echo###/echo
/j:if
j:set var=maven.test.reportsDirectory scope=parent
value=${maven.build.dir}/test-reports/
echo/echo
echoprepare report dir : ${maven.test.reportsDirectory} /echo
echo/echo
mkdir dir=${maven.test.reportsDirectory}/
echo/echo
echoupdate project /echo
echo/echo
attainGoal name=scm:update-project/
/goal
multiproject:clean fails due to dependencies in reactor set
---
Key: MAVEN-1270
URL: http://jira.codehaus.org/browse/MAVEN-1270
Project: Maven
Type: Improvement
Versions: 1.0-rc2
Environment: RedHat 9.0. Sun JDK 1.4.2_01, Maven 1.0-rc2
Reporter: Cameron Fieber
Priority: Minor
Fix For: 1.1-rc1
I appologize if this is already entered, but I was unable to find it
searching JIRA. This is the same as or similar to #MAVEN-443 which was
marked as can't reproduce.
If you have a multiproject build, you can't execute clean until all artifacts
in that build that depend on other artifacts in the build have been produced.
The ideal behaviour of multiproject:clean would be to either ignore
dependencies not needed for the clean task itself, or consider a dependency
satisfied if it is in the reactor set.
The case where this feature would be a particular benefit is when you have an
existing source tree, which has been built, and a new component is added. If
you do an update and pulling down the new component it has yet to be
compiled. You then can't do multiproject:clean on your existing tree because
the new dependencies to the new component can't be resolved.
--
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] Updated: (CONTINUUM-511) Continuum should use Server VM
[ http://jira.codehaus.org/browse/CONTINUUM-511?page=all ] Matthew Beermann updated CONTINUUM-511: --- Attachment: patch.txt Continuum should use Server VM -- Key: CONTINUUM-511 URL: http://jira.codehaus.org/browse/CONTINUUM-511 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.2 Reporter: Matthew Beermann Priority: Minor Fix For: 1.1 Attachments: patch.txt Continuum could (should?) use the Server VM rather than the default Client VM when running as a service. I'm not fully versed in all the differences between them, but from what I do know, it seems much more appropriate. This would involve adding another wrapper.java.additional parameter to bin/win32/wrapper.conf (-server). -- 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] Closed: (MPTEST-58) Add ability to fail the build on test errors
[ http://jira.codehaus.org/browse/MPTEST-58?page=all ] Lukas Theussl closed MPTEST-58: --- Resolution: Fixed Add ability to fail the build on test errors Key: MPTEST-58 URL: http://jira.codehaus.org/browse/MPTEST-58 Project: maven-test-plugin Type: Improvement Versions: 1.8 Reporter: Mauro Botelho Priority: Trivial Fix For: 1.8 Attachments: maven-test-patch.diff Add ability to fail the build if there are errors in tests. This is very similar to fail on 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: (MCLEAN-7) empty excludes/ removes the directory of the fileset
[ http://jira.codehaus.org/browse/MCLEAN-7?page=comments#action_61804 ]
Jesse McConnell commented on MCLEAN-7:
--
Not sure what to do here...
the original test case used the ** includes and excludes which exhibited
the desired behavior...
Now it would seem to me that
fileset
includes
include**/include
/includes
/fileset
now to me that would be the same thing, but DirectoryScanner specificaly looks
for in the exclude to decide if the directory should be deleted.
fileset
includes
include**/include
/includes
excludes
exclude/exclude
/excludes
/fileset
Now this builds an excludes arraylist of size 1 but null inside, which triggers
a NPE in DirectoryScanner..
fileset
includes
include**/include
/includes
excludes
exclude/exclude
/excludes
/fileset
This certainly doesn't work since it translate to \\ in the fileset
BUT!
fileset
includes
include**/include
/includes
excludes
exclude**/exclude
/excludes
/fileset
does exhibit the correct behavior, since the includes ** matchs the files in
the directory and the ** actually seems to protect the directory. The files
end up getting smoked but the base directory of the fileset is perserved.
This seems a bit off to me, but I am able to configure a fileset that exhibits
the same end behavior of the test case...but this feels like another issue to
me, that ** in includes means something other then ** in excludes.
empty excludes/ removes the directory of the fileset
--
Key: MCLEAN-7
URL: http://jira.codehaus.org/browse/MCLEAN-7
Project: Maven 2.x Clean Plugin
Type: Bug
Reporter: Jesse McConnell
I was shifting the unit tests over to use the plugin harness and noticed a
test case failing.
if you look at the test case for the fileset test case, the second fileset
test has an addFileset(dir, **, );
this unit test works fine, but when you try and actually do this behavior
using the plugin configuration it brings up an error
fileset
directory${basedir}/target/test-classes/fileset-clean-test/buildOutputDirectory/directory
includes
include**/include
/includes
/fileset
that would be the plugin configuration of the same deal.
(exclude/exclude results in a stack trace)
In this case the directory is getting deleted when configured. You can
exhibit the same behavior with the existing test case if you try and pass
null into the addFileset signature...
this would be the failing test case using the existing plugin, note the null
in the second addFileset()
--
public void testFilesets()
throws Exception
{
String base = TARGET_TEST_DIR + /target;
CleanMojo mojo = new CleanMojo();
mojo.addFileset( createFileset( base, **/file.txt, **/subdir/** )
);
String outputDirectory = TARGET_TEST_DIR + /buildOutputDirectory;
mojo.addFileset( createFileset( outputDirectory, **, null ) );
mojo.execute();
// fileset 1
assertTrue( checkExists( base ) );
assertTrue( checkExists( base + /classes ) );
assertFalse( checkExists( base + /classes/file.txt ) );
/* TODO: looks like a bug in the file-management library
assertTrue( FileUtils.fileExists( base + /subdir/file.txt ) );
*/
// fileset 2
assertTrue( checkExists( outputDirectory ) );
assertFalse( checkExists( outputDirectory + /file.txt ) );
System.exit(-1);
}
--
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: (MECLIPSE-83) ear projects should not be java projects
[ http://jira.codehaus.org/browse/MECLIPSE-83?page=comments#action_61813 ] Archimedes Trajano commented on MECLIPSE-83: The following code block should not be present in the .project file buildSpec buildCommand nameorg.eclipse.jdt.core.javabuilder/name arguments/ /buildCommand /buildSpec natures natureorg.eclipse.jdt.core.javanature/nature /natures The only reason I would see is if you want to put JUnit test cases for integration testing on the EAR, but I am not sure if that's the right place to do such a thing. It might be better to have a separate project for integration testing? Or at least detect that the user would want integration testing code in the EAR project. ear projects should not be java projects Key: MECLIPSE-83 URL: http://jira.codehaus.org/browse/MECLIPSE-83 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.1 Environment: Eclipse 3.1.2 Reporter: Archimedes Trajano Given a POM with packagingear/packaging It should create an Enterprise Application project rather than a standard java project. -- 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: (MNGECLIPSE-92) Build path for resource directories should be 'exclude all'
Build path for resource directories should be 'exclude all' --- Key: MNGECLIPSE-92 URL: http://jira.codehaus.org/browse/MNGECLIPSE-92 Project: Maven 2.x Extension for Eclipse Type: Bug Reporter: Brad Davis Assigned to: Eugene Kuleshov Priority: Minor Attachments: mvn2ide.patch when you update the source folders in eclipse, resource folders are placed on the build path in a naive manner. While they should be on the build path so that running and debugging in eclipse places them in the class path, they should have an exclude pattern of exclude all, so that any java files within them will not be compiled and so that directories within the resources folders will not appear as packages. Attached is a patch that corrects this. -- 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: (CONTINUUM-511) Continuum should use Server VM
[ http://jira.codehaus.org/browse/CONTINUUM-511?page=comments#action_61816 ] Matthew Beermann commented on CONTINUUM-511: I haven't taken a stopwatch to it yet, but it certainly feels faster to me... also, Sun would tend to agree: http://java.sun.com/performance/reference/whitepapers/5.0_performance.html Continuum should use Server VM -- Key: CONTINUUM-511 URL: http://jira.codehaus.org/browse/CONTINUUM-511 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.2 Reporter: Matthew Beermann Priority: Minor Fix For: 1.1 Attachments: patch.txt Continuum could (should?) use the Server VM rather than the default Client VM when running as a service. I'm not fully versed in all the differences between them, but from what I do know, it seems much more appropriate. This would involve adding another wrapper.java.additional parameter to bin/win32/wrapper.conf (-server). -- 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] Reopened: (MSUREFIRE-59) JUnitBattery dies when TestSuite has an anonymous inner class
[ http://jira.codehaus.org/browse/MSUREFIRE-59?page=all ]
Brett Porter reopened MSUREFIRE-59:
---
JUnitBattery dies when TestSuite has an anonymous inner class
-
Key: MSUREFIRE-59
URL: http://jira.codehaus.org/browse/MSUREFIRE-59
Project: Maven 2.x Surefire Plugin
Type: Bug
Versions: 2.1.2
Reporter: Mike Perham
Assignee: Brett Porter
Fix For: 2.1.3
Attachments: SimpleTestSuite.java, SurefireTest.java
I have this method in my test suite:
{code}
private static File[] getWSDLFiles() {
URL directoryURL =
WSDLImportTestSuite.class.getResource(/com/webify/wsf/studio/core/wsdl/wsdls);
if (directoryURL != null) {
File directory = new File(directoryURL.getPath());
FilenameFilter filter = new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(.wsdl);
}
};
return directory.listFiles(filter);
}
else {
return null;
}
}
{code}
And surefire fails with this exception:
java.lang.NoSuchMethodException:
com.webify.wsf.studio.core.wsdl.WSDLImportTestSuite$1.init()
at java.lang.Class.getConstructor0(Class.java:1937)
at java.lang.Class.getConstructor(Class.java:1027)
at
org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
at
org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
at
org.apache.maven.surefire.battery.JUnitBattery.init(JUnitBattery.java:81)
at
org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
at
org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
--
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: (MASSEMBLY-75) Unpacked TAR dependencies do not preserve file mode nor uid/gid
Unpacked TAR dependencies do not preserve file mode nor uid/gid --- Key: MASSEMBLY-75 URL: http://jira.codehaus.org/browse/MASSEMBLY-75 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.0.1 Reporter: Maciej Szefler TAR Assemblies generated from unpacking another TAR do not preserver the extended file information (uid/gid/mod). For example: if bar.tar contains an executable file baz and if our .pom has the following dependency: dependency groupIdfoo/groupId artifactIdbar/artifactId typetar/type scopecompile/scope /dependency and our assembly.xml has the following: assembly id/id formats formattar.gz/format /formats dependencySets dependencySet scopecompile/scope outputDirectory/ includes includefoo:bar/include /includes unpacktrue/unpack /dependencySet then the generated assembly will contain baz, but it will no longer be executable. -- 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: (MPMD-22) PMD plugin configuration should accept dependency entries
PMD plugin configuration should accept dependency entries
---
Key: MPMD-22
URL: http://jira.codehaus.org/browse/MPMD-22
Project: Maven 2.x Pmd Plugin
Type: New Feature
Reporter: Subhash Chandran
As described here:
http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
The PMD plugin supports configuration of custom ruleset XML files. But in our
organization, we have written custom ruleset XMLs that refer Java classes (our
PMD extension dependencies). The configuration of the PMD plugin should allow
these dependencies to be specified.
Since we do not have this feature in the current release, we at our
organization are forced to maintain a fork of the PMD plugin with the necessary
dependencies added.
A suggested format:
configuration
rulesets
ruleset/rulesets/basic.xml/ruleset
ruleset/rulesets/controversial.xml/ruleset
rulesetd:\rulesets\strings.xml/ruleset
rulesethttp://localhost/design.xml/ruleset
/rulesets
{color:red}
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.0/version
scopetest/scope
/dependency
{color}
formatxml/format
linkXreftrue/linkXref
sourceEncodingutf-8/sourceEncoding
minimumTokens100/minimumTokens
/configuration
--
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: (MNG-2175) Require an schema to be specified in the configuration block of a plugin
Require an schema to be specified in the configuration block of a plugin Key: MNG-2175 URL: http://jira.codehaus.org/browse/MNG-2175 Project: Maven 2 Type: Improvement Components: POM Versions: 2.0.2 Reporter: Archimedes Trajano Require an schema to be specified in the configuration block of a plugin. e.g. plugins plugin configuration xmlns=http://maven.apache.org/plugins/maven-eclipse-plugin/2.0/; This will ensure that all configuration data is valid for the plugin. It allows pom authors to use the XML editors' autocomplete function as well. -- 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] Updated: (MWAR-7) Referenced projects' artifacts naming scheme behaves differently when ran from reactor
[ http://jira.codehaus.org/browse/MWAR-7?page=all ]
Maria Odea Ching updated MWAR-7:
Attachment: MWAR-7-maven-war-plugin.patch
Referenced projects' artifacts naming scheme behaves differently when ran
from reactor
--
Key: MWAR-7
URL: http://jira.codehaus.org/browse/MWAR-7
Project: Maven 2.x War Plugin
Type: Bug
Environment: maven-war-plugin versions 2.0-beta-1 and 2.0-beta-2
Reporter: Cédric Vidal
Assignee: Maria Odea Ching
Fix For: 2.0
Attachments: MWAR-7-maven-war-plugin.patch
Original Estimate: 10 hours
Remaining: 10 hours
When running mvn install from a war packaged project, the referenced
projects' artifacts are bundled into the WEB-INF/lib directory with the
following naming scheme ${groupId}-${artifactId}-${version}.jar, but when
running mvn install as part of the reactor, the referenced projects'
artifacts are bundled into the WEB-INF/lib directory with the following
naming scheme ${pom.build.finalName}.jar
The naming scheme should be the same in the two situations for the sake of
consistency, but also to avoid the disturbing (for the end user) situation
where you end up having the same dependencies present twice with different
names.
--
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] Closed: (MNG-32) Plugin test harness
[ http://jira.codehaus.org/browse/MNG-32?page=all ] Brett Porter closed MNG-32: --- Resolution: Fixed imported to sandbox Plugin test harness --- Key: MNG-32 URL: http://jira.codehaus.org/browse/MNG-32 Project: Maven 2 Type: Task Components: Sandbox, Plugin API, Design, Patterns Best Practices Reporter: Jason van Zyl Assignee: Jesse McConnell Priority: Blocker Attachments: compiler-harness.patch, jar-harness.patch, maven-compiler-plugin.jar, maven-jar-plugin.jar, maven-project.patch -- 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: (MPMD-22) PMD plugin configuration should accept dependency entries
[ http://jira.codehaus.org/browse/MPMD-22?page=comments#action_61832 ]
Carlos Sanchez commented on MPMD-22:
Have you tried setting dependencies inside plugin
That's how it should work
PMD plugin configuration should accept dependency entries
---
Key: MPMD-22
URL: http://jira.codehaus.org/browse/MPMD-22
Project: Maven 2.x Pmd Plugin
Type: New Feature
Reporter: Subhash Chandran
As described here:
http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
The PMD plugin supports configuration of custom ruleset XML files. But in our
organization, we have written custom ruleset XMLs that refer Java classes
(our PMD extension dependencies). The configuration of the PMD plugin should
allow these dependencies to be specified.
Since we do not have this feature in the current release, we at our
organization are forced to maintain a fork of the PMD plugin with the
necessary dependencies added.
A suggested format:
configuration
rulesets
ruleset/rulesets/basic.xml/ruleset
ruleset/rulesets/controversial.xml/ruleset
rulesetd:\rulesets\strings.xml/ruleset
rulesethttp://localhost/design.xml/ruleset
/rulesets
{color:red}
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.0/version
scopetest/scope
/dependency
{color}
formatxml/format
linkXreftrue/linkXref
sourceEncodingutf-8/sourceEncoding
minimumTokens100/minimumTokens
/configuration
--
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: (MPMD-22) PMD plugin configuration should accept dependency entries
[ http://jira.codehaus.org/browse/MPMD-22?page=comments#action_61833 ]
Subhash Chandran commented on MPMD-22:
--
We tried that. We are getting this exception trace:
start trace--
Reason: Parse error reading POM. Reason: Unrecognised tag: 'dependencies'
(position: START_TAG seen .../configuration\n\n\t\tdependencies... @94:17)
[INFO]
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Parse error reading POM.
Reason: Unrecognised tag: 'dependencies' (position: START_TAG seen
.../configuration\n\n\t\tdependencies... @94:17)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
end trace--
Note that we are trying this in M2.0.2 release. Is this dependencies support
inside plugin part of the yet to be released M2.0.3?
PMD plugin configuration should accept dependency entries
---
Key: MPMD-22
URL: http://jira.codehaus.org/browse/MPMD-22
Project: Maven 2.x Pmd Plugin
Type: New Feature
Reporter: Subhash Chandran
As described here:
http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
The PMD plugin supports configuration of custom ruleset XML files. But in our
organization, we have written custom ruleset XMLs that refer Java classes
(our PMD extension dependencies). The configuration of the PMD plugin should
allow these dependencies to be specified.
Since we do not have this feature in the current release, we at our
organization are forced to maintain a fork of the PMD plugin with the
necessary dependencies added.
A suggested format:
configuration
rulesets
ruleset/rulesets/basic.xml/ruleset
ruleset/rulesets/controversial.xml/ruleset
rulesetd:\rulesets\strings.xml/ruleset
rulesethttp://localhost/design.xml/ruleset
/rulesets
{color:red}
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.0/version
scopetest/scope
/dependency
{color}
formatxml/format
linkXreftrue/linkXref
sourceEncodingutf-8/sourceEncoding
minimumTokens100/minimumTokens
/configuration
--
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] Updated: (MCHECKSTYLE-35) move rules summary to the bottom
[ http://jira.codehaus.org/browse/MCHECKSTYLE-35?page=all ] Brett Porter updated MCHECKSTYLE-35: Fix Version: (was: 2.0) 2.1 move rules summary to the bottom Key: MCHECKSTYLE-35 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-35 Project: Maven 2.x Checkstyle Plugin Type: Improvement Reporter: Brett Porter Fix For: 2.1 -- 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] Updated: (MCHECKSTYLE-34) automatically detect linkXref and default to on
[ http://jira.codehaus.org/browse/MCHECKSTYLE-34?page=all ] Brett Porter updated MCHECKSTYLE-34: Fix Version: (was: 2.0) 2.1 automatically detect linkXref and default to on --- Key: MCHECKSTYLE-34 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-34 Project: Maven 2.x Checkstyle Plugin Type: Improvement Reporter: Brett Porter Fix For: 2.1 -- 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] Updated: (MCHECKSTYLE-30) checkstyle ignores cacheFile
[ http://jira.codehaus.org/browse/MCHECKSTYLE-30?page=all ] Brett Porter updated MCHECKSTYLE-30: Fix Version: 2.0.1 checkstyle ignores cacheFile Key: MCHECKSTYLE-30 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-30 Project: Maven 2.x Checkstyle Plugin Type: Bug Reporter: Brian Fox Fix For: 2.0.1 I'm using a version of checkstyle from svn so I can get custom configuration. The cacheFile seems to be ignored. I tried setting it even though it has a default value, but I nver see the checkstyle-cachefile get created. -- 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] Updated: (MCHECKSTYLE-34) automatically detect linkXref and default to on
[ http://jira.codehaus.org/browse/MCHECKSTYLE-34?page=all ] Brett Porter updated MCHECKSTYLE-34: Fix Version: (was: 2.1) 2.0.1 automatically detect linkXref and default to on --- Key: MCHECKSTYLE-34 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-34 Project: Maven 2.x Checkstyle Plugin Type: Improvement Reporter: Brett Porter Fix For: 2.0.1 -- 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] Updated: (MCHECKSTYLE-33) Patch provides ability to control whether check MOJO violations cause build failure (inline with pmd:check)
[ http://jira.codehaus.org/browse/MCHECKSTYLE-33?page=all ] Brett Porter updated MCHECKSTYLE-33: Fix Version: 2.0.1 Patch provides ability to control whether check MOJO violations cause build failure (inline with pmd:check) --- Key: MCHECKSTYLE-33 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-33 Project: Maven 2.x Checkstyle Plugin Type: Improvement Reporter: John Allen Fix For: 2.0.1 Attachments: CheckstyleViolationCheckMojo.diff Example: mvn -Dcheckstyle.failOnViolation=false checkstyle:check Use case: In the same way that test failures can be prevented from failing the buyild via a CLI arg, builds that enforce governance standards and policies such as no checkstyle violations, no PMD violations, at least XX% of test coverage, no javadoc warnings are more useful if they can also be deactivated via a CLI arg. Note, my previous PMD:check mojo patch already provides support for this violation override. -- 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: (MPMD-22) PMD plugin configuration should accept dependency entries
[ http://jira.codehaus.org/browse/MPMD-22?page=comments#action_61840 ]
Brett Porter commented on MPMD-22:
--
one workaround to try is putting the dependency on the site plugin in the build
section.
PMD plugin configuration should accept dependency entries
---
Key: MPMD-22
URL: http://jira.codehaus.org/browse/MPMD-22
Project: Maven 2.x Pmd Plugin
Type: New Feature
Reporter: Subhash Chandran
As described here:
http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
The PMD plugin supports configuration of custom ruleset XML files. But in our
organization, we have written custom ruleset XMLs that refer Java classes
(our PMD extension dependencies). The configuration of the PMD plugin should
allow these dependencies to be specified.
Since we do not have this feature in the current release, we at our
organization are forced to maintain a fork of the PMD plugin with the
necessary dependencies added.
A suggested format:
configuration
rulesets
ruleset/rulesets/basic.xml/ruleset
ruleset/rulesets/controversial.xml/ruleset
rulesetd:\rulesets\strings.xml/ruleset
rulesethttp://localhost/design.xml/ruleset
/rulesets
{color:red}
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.0/version
scopetest/scope
/dependency
{color}
formatxml/format
linkXreftrue/linkXref
sourceEncodingutf-8/sourceEncoding
minimumTokens100/minimumTokens
/configuration
--
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: (MSUREFIRE-72) [surefire-testng] SurefireReportMojo.executeReport() throws a java.lang.NumberFormatException
[ http://jira.codehaus.org/browse/MSUREFIRE-72?page=comments#action_61841 ] Carlos Sanchez commented on MSUREFIRE-72: - Is this problen in surefire trunk or surefire testng branch ? [surefire-testng] SurefireReportMojo.executeReport() throws a java.lang.NumberFormatException - Key: MSUREFIRE-72 URL: http://jira.codehaus.org/browse/MSUREFIRE-72 Project: Maven 2.x Surefire Plugin Type: Bug Reporter: Vincent Siveton Priority: Blocker Fix For: 2.2 Attachments: surefire-api_diff NumberFormat.getInstance() uses the current default locale in the jvm. The patch specifies the English Locale. Here is the full stacktrace: [INFO] Generate Maven Surefire Report report. java.lang.NumberFormatException: For input string: 0,031 at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224) at java.lang.Float.parseFloat(Float.java:394) at org.codehaus.mojo.surefire.ReportTestSuite.startElement(ReportTestSuite.java:78) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:798) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:878) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(XMLDocumentScannerImpl.java:1157) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) at javax.xml.parsers.SAXParser.parse(SAXParser.java:311) at org.codehaus.mojo.surefire.ReportTestSuite.init(ReportTestSuite.java:59) at org.codehaus.mojo.surefire.SurefireReportParser.parseXMLReportFiles(SurefireReportParser.java:42) at org.codehaus.mojo.surefire.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:44) at org.codehaus.mojo.surefire.SurefireReportMojo.executeReport(SurefireReportMojo.java:77) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) at org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:1055) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:397) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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)java.lang.NullPointerException at
[jira] Closed: (MSUREFIREREP-12) Links (anchors) are not well formed in html reports
[ http://jira.codehaus.org/browse/MSUREFIREREP-12?page=all ] Brett Porter closed MSUREFIREREP-12: Assign To: Brett Porter Resolution: Duplicate Fix Version: (was: 2.0) this purely relies on the version of the site plugin being used. works in SVN. Links (anchors) are not well formed in html reports --- Key: MSUREFIREREP-12 URL: http://jira.codehaus.org/browse/MSUREFIREREP-12 Project: Maven 2.x Surefire report Plugin Type: Bug Environment: all Reporter: Olivier Lamy Assignee: Brett Porter Anchor are not well formed. Relative to http://jira.codehaus.org/browse/MNG-2099 Olivier -- 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: (MPMD-22) PMD plugin configuration should accept dependency entries
[ http://jira.codehaus.org/browse/MPMD-22?page=comments#action_61847 ]
Subhash Chandran commented on MPMD-22:
--
I have located the core issue:
http://jira.codehaus.org/browse/MNG-2173
Can this issue be linked to that one, or should this one be closed?
PMD plugin configuration should accept dependency entries
---
Key: MPMD-22
URL: http://jira.codehaus.org/browse/MPMD-22
Project: Maven 2.x Pmd Plugin
Type: New Feature
Reporter: Subhash Chandran
As described here:
http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
The PMD plugin supports configuration of custom ruleset XML files. But in our
organization, we have written custom ruleset XMLs that refer Java classes
(our PMD extension dependencies). The configuration of the PMD plugin should
allow these dependencies to be specified.
Since we do not have this feature in the current release, we at our
organization are forced to maintain a fork of the PMD plugin with the
necessary dependencies added.
A suggested format:
configuration
rulesets
ruleset/rulesets/basic.xml/ruleset
ruleset/rulesets/controversial.xml/ruleset
rulesetd:\rulesets\strings.xml/ruleset
rulesethttp://localhost/design.xml/ruleset
/rulesets
{color:red}
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.0/version
scopetest/scope
/dependency
{color}
formatxml/format
linkXreftrue/linkXref
sourceEncodingutf-8/sourceEncoding
minimumTokens100/minimumTokens
/configuration
--
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
