[jira] Created: (MDEP-65) Copy dependencies in a Maven repository like layout
Copy dependencies in a Maven repository like layout
---
Key: MDEP-65
URL: http://jira.codehaus.org/browse/MDEP-65
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Affects Versions: 2.0-alpha-2, 2.0
Reporter: Alexis Midon
Assigned To: Brian Fox
Attachments: repository-layout.patch
I use the dependency plugin in my Maven project at work.
But we need a tiny feature not yet implemented by your plugin.
Actually we would like to copy some dependencies in a repository like layout.
This exactly what your plugin does except for the repository part.
_example:_ I'd like to move dependencies in something like
{{outputDirectory/junit/junit/3.8.1/junit-3.8.1.jar}} and so on
To help you, I implemented this feature in the maven-dependency-plugin trunk
(as of revision 510010) and the patch is in attachment.
Here are details of the development:
- add a new optional boolean property in
org.apache.maven.plugin.dependency.AbstractFromDependenciesMojo :
useRepositoryLayout
- add a new parameter to DependencyUtil.getFormattedOutputDirectory(...)
- update all calls to this method
- update unit test and add specific tests for this new parameter
_Example POM:_
{code:xml}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/alternateLocation/outputDirectory
useRepositoryLayouttrue/useRepositoryLayout
/configuration
/execution
/executions
/plugin
/plugins
/build
{code}
I tried to create a new issue in jira but the url failed.
I hope you will find this feature attractive, and I will be glad to answer any
of your request about it.
--
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: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
Can't deploy site using site:deploy due to a ProxyHTTP error Key: MSITE-211 URL: http://jira.codehaus.org/browse/MSITE-211 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: linux ubuntu dapper drake Reporter: Elid OR Priority: Blocker When I execute the site deployment (with version that comes with maven 2.0.5) mvn site:deploy I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) 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:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) 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: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) ... 18 more Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: proxy error: Forbidden at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) ... 20 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 [INFO] Final Memory: 3M/7M [INFO] -- 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: (MRM-287) The context is not included in repository links when browsing artifacts.
The context is not included in repository links when browsing artifacts. Key: MRM-287 URL: http://jira.codehaus.org/browse/MRM-287 Project: Archiva Issue Type: Bug Components: web application Reporter: Henry S. Isidro When browsing, searching and finding an artifact, the resulting page displays links to navigate to the various levels of the artifact's group as well as to the top of the tree. These links have urls which do not include the context of the web application so if archiva is deployed in a different context, these links will generate 404s. -- 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: (MRM-287) The context is not included in repository links when browsing artifacts.
[ http://jira.codehaus.org/browse/MRM-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated MRM-287: Attachment: [MRM-287]-archiva-webapp.patch File Attached: [MRM-287]-archiva-webapp.patch This patch adds the context to the generated urls of the navigation links when browsing an artifact. The context is not included in repository links when browsing artifacts. Key: MRM-287 URL: http://jira.codehaus.org/browse/MRM-287 Project: Archiva Issue Type: Bug Components: web application Reporter: Henry S. Isidro Attachments: [MRM-287]-archiva-webapp.patch When browsing, searching and finding an artifact, the resulting page displays links to navigate to the various levels of the artifact's group as well as to the top of the tree. These links have urls which do not include the context of the web application so if archiva is deployed in a different context, these links will generate 404s. -- 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: (MRM-287) The context is not included in repository links when browsing artifacts.
[ http://jira.codehaus.org/browse/MRM-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRM-287. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 Apply. Thanks. The context is not included in repository links when browsing artifacts. Key: MRM-287 URL: http://jira.codehaus.org/browse/MRM-287 Project: Archiva Issue Type: Bug Components: web application Reporter: Henry S. Isidro Assigned To: Emmanuel Venisse Fix For: 1.0 Attachments: [MRM-287]-archiva-webapp.patch When browsing, searching and finding an artifact, the resulting page displays links to navigate to the various levels of the artifact's group as well as to the top of the tree. These links have urls which do not include the context of the web application so if archiva is deployed in a different context, these links will generate 404s. -- 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: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88224 ] Marcel May commented on MSITE-211: -- I have the same problem (see my mail http://mail-archives.apache.org/mod_mbox/maven-users/200702.mbox/ajax/[EMAIL PROTECTED]). It seems jsch uses the active proxy from settings.xml for SSH/SCP deployment, which fails. For me it worked to disable the proxy (which is not a solution but a hack). In my opinion it is wrong that the site plugin sets the maven active proxy for jsch. The maven active proxy is for accessing repositories, right? And with the site plugin we (might) want to use a proxy for putting the generated site on some server. At least the site plugin should support to configure/override/disable the jsch proxy. Cheers, Marcel Can't deploy site using site:deploy due to a ProxyHTTP error Key: MSITE-211 URL: http://jira.codehaus.org/browse/MSITE-211 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: linux ubuntu dapper drake Reporter: Elid OR Priority: Blocker When I execute the site deployment (with version that comes with maven 2.0.5) mvn site:deploy I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) 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:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) 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: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) ... 18 more Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: proxy error: Forbidden at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) ... 20 more [INFO] [INFO] Total time: 3 seconds
[jira] Created: (MCHANGELOG-54) NPE during Developer Activity report generation
NPE during Developer Activity report generation - Key: MCHANGELOG-54 URL: http://jira.codehaus.org/browse/MCHANGELOG-54 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: windows 2000, maven 2.0.4, SCM Synergy maven-changelog-plugin:2.0-SNAPSHOT Reporter: David Vicente Attachments: changelog-patch.txt I'm using the maven-changelog-plugin:2.0-SNAPSHOT and i have a NullPointerException during Developer Activity report generation. java.lang.NullPointerException at org.apache.maven.plugin.changelog.ChangeLogReport.countFilesChanged(ChangeLogReport.java:889) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doSummary(DeveloperActivityReport.java:221) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doChangedSets(DeveloperActivityReport.java:180) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doGenerateReport(DeveloperActivityReport.java:146) at org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:296) I have the Synergy SCM. it occurs when a Synergy task is completed without modified file, the changelog.xml has an entry without file. it occurs with the last released version. I made the correction (see changelog-patch.txt) and it works fine -- 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-2839) Non-unique-version snapshots not updated
Non-unique-version snapshots not updated Key: MNG-2839 URL: http://jira.codehaus.org/browse/MNG-2839 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.5 Reporter: Pavel Halas Test case: - let's have a repository with [uniqueVersion]false[/uniqueVersion]. - let your project download any snapshot dependency (with non-unique version) (like abc-1.0-SNAPSHOT.jar). - go to your local repository and change the file content. You can also remove all the metadata. - run mvn -U on your project - you get [INFO] snapshot abc:abc-1.0-SNAPSHOT: checking for updates from YOUR-REPOSITORY - the abc-1.0-SNAPSHOT.jar in your local repository is NOT updated. The same (I think) bug has been reported (and closed) several times before (MNG-1908 etc.) but it still appears in 2.0.5. -- 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: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Brown updated MNG-624: --- Attachment: MNG-624-tests.tar.gz MNG-624-maven-2.0.x-r507648.patch The attached patch and 16 integration tests fixes this issue by allowing the following: * Variable expansion works in the parent section of pom-s for version, groupId and artifactId * The same elements are all optional. At the extreme, this means most times parent/ will work. There is a rule for this to work, however. You must have enough of your development tree on disk that maven can walk the directories (relativePath still works) to resolve variables and/or find inferred elements that are missing. Implementation Notes: * All existing and 16 new integration tests are passing. The code-path and what's going on really doesn't change for existing projects that have explicit parent sections. * It passes my complex 202-module project. * Most of what is going on is that maven now guesses and does re-interpolation later to verify (and/or) continue its inferencing. I call it expansion in a few places because it is more than just interpolation, profiles also have to be expanded - but the code was all there, I just refactored slightly. * When pom-s are installed and deployed, if any part of their parent specification was inferred or re-expanded, it is no longer possible to simply copy the source pom.xml unmodified to the local and/or remote repository. Doing so would make it impossible to build from somewhere other than trunk as when building from the middle of a tree, artifacts that are elsewhere in sibling or cousin nodes of the tree are actually fetched from the repository and their parents in-turn from the repository as well. But the parents couldn't be found in the repository because the parent section was missing! So maven now detects that the parent section was missing or needed expansion due to the presence of variables and makes sure the parent section is present before writing a pom to a repository. I'm not fantastically pleased with this implementation for a couple reasons: (though it works and my vote would be to accept it as is - I doubt it is the worst ugliness in the code) ** The pom in the repository looses all comments and formatting from the original. ** The way I hooked it into the artifact and suck it back out again when installing and deploying pom-s just felt hackish. Though I really don't see any other way to pass the needed information around as this information obviously was not intended to be passed between the maven-project and maven-artifact modules in the architecture. BTW, The reason I spent so much time on this is because I have 202 modules and release twice / month. My svn logs are littered with crap from changing version information in my 202 pom-s and I find it very annoying. Maven is a great tool, but I've never worked with or built a build system where I had to keep version information in so many places. I know there are tools to manage it, but it is still uglier than the patch I've submitted here IMO. YMMV :) automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assigned To: Brett Porter Priority: Blocker Fix For: 2.1.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-1390) JasperReports 1.3.1 upload
JasperReports 1.3.1 upload -- Key: MAVENUPLOAD-1390 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1390 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://rs.jaspersoft.com/maven2/jasperreports-1.3.1-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- 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-1384) Please upload JODConverter 2.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Nasato closed MAVENUPLOAD-1384. - Resolution: Incomplete Closing this issue since I'll upload a newer version after fixing the dependencies. Please upload JODConverter 2.1.1 Key: MAVENUPLOAD-1384 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1384 Project: maven-upload-requests Issue Type: Task Reporter: Mirko Nasato JODConverter (Java OpenDocument Converter) converts documents between different office formats, leveraging OpenOffice.org. -- 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-1384) Please upload JODConverter 2.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88235 ] Mirko Nasato commented on MAVENUPLOAD-1384: --- Even those with 'test' scope? Alright. Please upload JODConverter 2.1.1 Key: MAVENUPLOAD-1384 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1384 Project: maven-upload-requests Issue Type: Task Reporter: Mirko Nasato JODConverter (Java OpenDocument Converter) converts documents between different office formats, leveraging OpenOffice.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-289) Surefire classlaoder loads wrong class when classes are of same package/class name
Surefire classlaoder loads wrong class when classes are of same package/class name -- Key: SUREFIRE-289 URL: http://jira.codehaus.org/browse/SUREFIRE-289 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 (2.2 plugin) Environment: Windows, Cygwin Reporter: Zachary Jones This is a repeat of the comment in SUREFIRE-286 I am having a problem with surefire classloading. I had to hack the ServiceMix class: org.apache.servicemix.http.processors.ConsumerProcessor. I saved the hacked version as the same class name and the same package. This class does compile to target/classes. The ServiceMix jar that contains this class is included in my classpath after the target/classes directory (seen with -X) When running mvn test, I get a test failure for the Test class that tries to create a ConsumerProcessor. We are expecting it to create our version of ConsumerProcessor, but it instead creates the ServiceMix version. I have tried all the available usage options from the surefire plugin documentation to no avail. Through debug in Eclipse, I see through a watch expression (getClass().getClassLoader()) is always the IsolatedClassLoader, no matter what options we set. This test passes in Eclipse, so I am pretty sure it is a classloading issue with the surefire plugin. Thanks for your help in advance. -- 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: (MJAR-30) Allow inludes/excludes definition
[ http://jira.codehaus.org/browse/MJAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88237 ] Yossi Shmulevitch commented on MJAR-30: --- I think that this is important capability. Since some plugins are generating classes (as wsdl2java axis plugin), Sometimes there is need to omit classes from the final jar. In my case it's a bug of the tool (or wrong behavior) but I can see places it's is needed. Allow inludes/excludes definition - Key: MJAR-30 URL: http://jira.codehaus.org/browse/MJAR-30 Project: Maven 2.x Jar Plugin Issue Type: Improvement Reporter: Michael Böckling Allow the definition of includes / excludes, so the Jars content can be customized. -- 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: (MANT-23) Make the ant plugin able to generate javadoc targets into build.xml files
[ http://jira.codehaus.org/browse/MANT-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MANT-23. --- Resolution: Fixed Added javadoc task Make the ant plugin able to generate javadoc targets into build.xml files - Key: MANT-23 URL: http://jira.codehaus.org/browse/MANT-23 Project: Maven 2.x Ant Plugin Issue Type: New Feature Affects Versions: 2.0-beta-1 Reporter: Petteri Räty Assigned To: Vincent Siveton Fix For: 2.0-beta-2 [EMAIL PROTECTED] /mnt/checkouts/maven-ant-plugin $ grep -i javadoc -r . ./src/it/ear-it/primary-source/.svn/text-base/pom.xml.svn-base: artifactIdmaven-javadoc-plugin/artifactId ./src/it/ear-it/primary-source/pom.xml: artifactIdmaven-javadoc-plugin/artifactId [EMAIL PROTECTED] /mnt/checkouts/commons-dbutils-trunk $ grep -i javadoc maven-build.xml [EMAIL PROTECTED] /mnt/checkouts/commons-dbutils-trunk $ For Gentoo packaging and for me being able to include maven generated build.xml files in source releases I need to be able to generate javadocs using the build.xml files. The standard target layout for self written build.xml files I have come across is: -compile -jar (We have this as package, would be nice to name this after the thing it does so jar would be jar and ear would be ear but that is an another bug) -test -javadoc -dist (dummy target depending on jar, test and javadoc) -- 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: (MNG-2840) System scope not working properly in Maven Antlib
[
http://jira.codehaus.org/browse/MNG-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MNG-2840:
-
Component/s: Ant tasks
Moved to Ant tasks
System scope not working properly in Maven Antlib
-
Key: MNG-2840
URL: http://jira.codehaus.org/browse/MNG-2840
Project: Maven 2
Issue Type: Bug
Components: Ant tasks
Environment: Mac OS X
Reporter: Greg Luck
If I add the following
dependency
groupIdjavax.cache/groupId
artifactIdjcache/artifactId
versionnot_released/version
scopesystem/scope
!--systemPath${basedir}/tools/jcache.jar/systemPath--
systemPath/Users/gluck/work/ehcache/trunk/tools/jcache.jar/systemPath
/dependency
When I so a run I get dropping
/Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar
from path as it doesn't exist
[javac] net/sf/ehcache/jcache/CacheListenerAdaptor.java added as
net/sf/ehcache/jcache/CacheListenerAdaptor.class doesn't exist.
[javac] net/sf/ehcache/jcache/Entry.java added as
net/sf/ehcache/jcache/Entry.class doesn't exist.
[javac] net/sf/ehcache/jcache/JCache.java added as
net/sf/ehcache/jcache/JCache.class doesn't exist.
[javac] net/sf/ehcache/jcache/JCacheFactory.java added as
net/sf/ehcache/jcache/JCacheFactory.class doesn't exist.
[javac] net/sf/ehcache/jcache/package.html skipped - don't know how to
handle it
dropping
/Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar
from path as it doesn't exist
It should not be looking for it there.
To reproduce just try and use the system scope and systemPath.
--
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] Moved: (MNG-2840) System scope not working properly in Maven Antlib
[
http://jira.codehaus.org/browse/MNG-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton moved MANT-21 to MNG-2840:
--
Complexity: Intermediate
Key: MNG-2840 (was: MANT-21)
Project: Maven 2 (was: Maven 2.x Ant Plugin)
System scope not working properly in Maven Antlib
-
Key: MNG-2840
URL: http://jira.codehaus.org/browse/MNG-2840
Project: Maven 2
Issue Type: Bug
Components: Ant tasks
Environment: Mac OS X
Reporter: Greg Luck
If I add the following
dependency
groupIdjavax.cache/groupId
artifactIdjcache/artifactId
versionnot_released/version
scopesystem/scope
!--systemPath${basedir}/tools/jcache.jar/systemPath--
systemPath/Users/gluck/work/ehcache/trunk/tools/jcache.jar/systemPath
/dependency
When I so a run I get dropping
/Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar
from path as it doesn't exist
[javac] net/sf/ehcache/jcache/CacheListenerAdaptor.java added as
net/sf/ehcache/jcache/CacheListenerAdaptor.class doesn't exist.
[javac] net/sf/ehcache/jcache/Entry.java added as
net/sf/ehcache/jcache/Entry.class doesn't exist.
[javac] net/sf/ehcache/jcache/JCache.java added as
net/sf/ehcache/jcache/JCache.class doesn't exist.
[javac] net/sf/ehcache/jcache/JCacheFactory.java added as
net/sf/ehcache/jcache/JCacheFactory.class doesn't exist.
[javac] net/sf/ehcache/jcache/package.html skipped - don't know how to
handle it
dropping
/Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar
from path as it doesn't exist
It should not be looking for it there.
To reproduce just try and use the system scope and systemPath.
--
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: (MANT-25) The plugin generates bad test targets when the project.xml has include and exclude rules
[
http://jira.codehaus.org/browse/MANT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MANT-25:
Testcase included: (was: yes)
The plugin generates bad test targets when the project.xml has include and
exclude rules
Key: MANT-25
URL: http://jira.codehaus.org/browse/MANT-25
Project: Maven 2.x Ant Plugin
Issue Type: Bug
Environment: maven-ant-plugin trunk using maven trunk
Last Changed Rev: 494359
Reporter: Petteri Räty
Priority: Critical
From commons-dbunit-2.2 project.xml:
unitTest
includes
includeorg/dbunit/AllTests.java/include
/includes
excludes
exclude**/*Test/exclude
/excludes
/unitTest
The maven-build.xml created:
batchtest todir=${maven.test.reports}
fileset dir=${maven.build.testDir.0}
include name=**/*Test.java/
exclude name=**/*Abstract*Test.java/
/fileset
/batchtest
So trying to run ant test fails (mvn test works fine):
The ' characters around the executable and arguments are
not part of the command.
[junit] Running org.apache.tools.ant.taskdefs.TaskdefsTest
[junit] Testsuite: org.apache.tools.ant.taskdefs.TaskdefsTest
[junit] junit.framework.TestListener: tests to run: 1
[junit] junit.framework.TestListener: startTest(warning)
[junit] junit.framework.TestListener: addFailure(warning, No tests found
in org.apache.tools.ant.taskdefs.TaskdefsTest)
[junit] junit.framework.TestListener: endTest(warning)
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.172 sec
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.172 sec
[junit]
[junit] Testcase: warning took 0.003 sec
[junit] FAILED
[junit] No tests found in org.apache.tools.ant.taskdefs.TaskdefsTest
[junit]
BUILD FAILED
/var/tmp/portage/dev-java/dbunit-2.2/work/dbunit-2.2/maven-build.xml:116:
Test org.apache.tools.ant.taskdefs.TaskdefsTest failed
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.actOnTestResult(JUnitTask.java:1712)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:820)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1657)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:764)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
It should be easy to add this to the maven-ant-plugin unit tests.
--
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: (SUREFIRE-289) Surefire classlaoder loads wrong class when classes are of same package/class name
[ http://jira.codehaus.org/browse/SUREFIRE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zachary Jones updated SUREFIRE-289: --- Attachment: cheesetest.zip cheese.zip Adding a test case to prove this problem. First unzip the cheese.zip into your local repo. It contains a jar file at cheese/org/cheeseburgertest-1.0.jar cheeseburgertest-1.0.jar contains a class test/TestClass that has a method String sayCheese() which returns CheeseBurger!. Unizip the cheesetest.zip anywhere and run mvn install. cheesetest is a simple project that contains a duplicate test/TestClass whose sayCheese method returns Cheese!. When it runs the test test/TestClassTest, it asserts that sayCheese returns Cheese!. But as you will see, the test fails and the surefire report shows CheeseBurger! was returned instead. If you do an eclipse:eclipse and run the test in Eclipse, the test will pass as expected.. Surefire classlaoder loads wrong class when classes are of same package/class name -- Key: SUREFIRE-289 URL: http://jira.codehaus.org/browse/SUREFIRE-289 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 (2.2 plugin) Environment: Windows, Cygwin Reporter: Zachary Jones Attachments: cheese.zip, cheesetest.zip This is a repeat of the comment in SUREFIRE-286 I am having a problem with surefire classloading. I had to hack the ServiceMix class: org.apache.servicemix.http.processors.ConsumerProcessor. I saved the hacked version as the same class name and the same package. This class does compile to target/classes. The ServiceMix jar that contains this class is included in my classpath after the target/classes directory (seen with -X) When running mvn test, I get a test failure for the Test class that tries to create a ConsumerProcessor. We are expecting it to create our version of ConsumerProcessor, but it instead creates the ServiceMix version. I have tried all the available usage options from the surefire plugin documentation to no avail. Through debug in Eclipse, I see through a watch expression (getClass().getClassLoader()) is always the IsolatedClassLoader, no matter what options we set. This test passes in Eclipse, so I am pretty sure it is a classloading issue with the surefire plugin. Thanks for your help in advance. -- 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: (MCHANGELOG-54) NPE during Developer Activity report generation
[ http://jira.codehaus.org/browse/MCHANGELOG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88250 ] David Vicente commented on MCHANGELOG-54: - i have the same NPE in doChangedFiles method of ChangeLogReport class and also in getOrderedFileList method of FileActivityReport class. For these 3 classes, when you get the files list from a ChangeSet, you doesn't test if files list is null or not. So, the problem is , with Synergy SCM, you can complete a task without checkout files. so you can have a changelog-entry in changelog.xml without file element. I hope it will be corrected as soon as possible NPE during Developer Activity report generation - Key: MCHANGELOG-54 URL: http://jira.codehaus.org/browse/MCHANGELOG-54 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: windows 2000, maven 2.0.4, SCM Synergy maven-changelog-plugin:2.0-SNAPSHOT Reporter: David Vicente Attachments: changelog-patch.txt I'm using the maven-changelog-plugin:2.0-SNAPSHOT and i have a NullPointerException during Developer Activity report generation. java.lang.NullPointerException at org.apache.maven.plugin.changelog.ChangeLogReport.countFilesChanged(ChangeLogReport.java:889) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doSummary(DeveloperActivityReport.java:221) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doChangedSets(DeveloperActivityReport.java:180) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doGenerateReport(DeveloperActivityReport.java:146) at org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:296) I have the Synergy SCM. it occurs when a Synergy task is completed without modified file, the changelog.xml has an entry without file. it occurs with the last released version. I made the correction (see changelog-patch.txt) and it works fine -- 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: (MRELEASE-200) Artifacts are uploaded to wrong directory
Artifacts are uploaded to wrong directory - Key: MRELEASE-200 URL: http://jira.codehaus.org/browse/MRELEASE-200 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: The maven repository is running Red Hat Linux Enterprise Server. The clients are PCs running Windows XP. Reporter: Chris Baumgartner Priority: Minor When doing a release:perform, the artifacts are occassionally uploaded to the wrong directory. We are using scp from the upload. Instead of uploading to the path of /maven-repository, the files are being uploaded to ~/om/maven-repository. For some reason it is creating a subdirectory called om in the user's home directory and uploading the artifacts there. It doesn't happen all the time, but it does seem to be consitently putting them there when it does fail. I can work around this by manually moving the files, but it is very annoying. -- 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-827) notification emails missing svn information
[ http://jira.codehaus.org/browse/CONTINUUM-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88252 ] Andre Ranvik commented on CONTINUUM-827: I experienced the same problem - and I believe the solution was found... At least it worked for us. This WAS our invalid authorization.conf: [groups] win-dev = OUR_DOMAIN_NAME\t22, OUR_DOMAIN_NAME\t33 [/] * = @win-dev = rw ___ This IS our VALID authorization.conf: [groups] win-dev = OUR_DOMAIN_NAME\t22, t22, OUR_DOMAIN_NAME\t33, t33 [/] * = @win-dev = rw ___ The difference is, as you can see, that we added the users without the domain name as well as with the domain name. Why this is required is beyond me... - but it works! The authorization.conf file is the file describing how Apache authorizes the user. Our Apache httpd.conf file contains this: Location /svn/repos DAV svn SVNPath F:/svnrepos AuthType Basic AuthName Subversion repository AuthUserFile F:/svnrepos/conf/users.conf AuthAuthoritative Off AuthName Subversion Authentication AuthType SSPI SSPIAuth On SSPIAuthoritative Off SSPIDomain somedome.name.org SSPIOfferBasic On AuthzSVNAccessFile F:/svnrepos/conf/authorization.conf Require valid-user /Location notification emails missing svn information --- Key: CONTINUUM-827 URL: http://jira.codehaus.org/browse/CONTINUUM-827 Project: Continuum Issue Type: Bug Components: SCM Affects Versions: 1.0.3 Reporter: Brian Fox Fix For: 1.1 Attachments: continumm-build-result-view.JPG I'm using 1.0.3 and svn 1.3.2. 99% of the time, the notifications do not list the developer or the commit message. I just get a list of changed files. I have seen it in the past occasionally but almost always the info isn't there. This includes times when there was only 1 commit since the last 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] Updated: (MCHANGELOG-54) NPE during Developer Activity report generation
[ http://jira.codehaus.org/browse/MCHANGELOG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Vicente updated MCHANGELOG-54: Attachment: changelog-patch-2.txt the first changelog-patch.txt contains only the correction for ChangeLogReport. use the changelog-patch-2.txt for the 3 classes as described above NPE during Developer Activity report generation - Key: MCHANGELOG-54 URL: http://jira.codehaus.org/browse/MCHANGELOG-54 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: windows 2000, maven 2.0.4, SCM Synergy maven-changelog-plugin:2.0-SNAPSHOT Reporter: David Vicente Attachments: changelog-patch-2.txt, changelog-patch.txt I'm using the maven-changelog-plugin:2.0-SNAPSHOT and i have a NullPointerException during Developer Activity report generation. java.lang.NullPointerException at org.apache.maven.plugin.changelog.ChangeLogReport.countFilesChanged(ChangeLogReport.java:889) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doSummary(DeveloperActivityReport.java:221) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doChangedSets(DeveloperActivityReport.java:180) at org.apache.maven.plugin.changelog.DeveloperActivityReport.doGenerateReport(DeveloperActivityReport.java:146) at org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:296) I have the Synergy SCM. it occurs when a Synergy task is completed without modified file, the changelog.xml has an entry without file. it occurs with the last released version. I made the correction (see changelog-patch.txt) and it works fine -- 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: (SUREFIRE-104) unable to establish my own http protocol handler for unit tests
[ http://jira.codehaus.org/browse/SUREFIRE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88258 ] Adrian commented on SUREFIRE-104: - I'm experiencing the same error trying to start up the embedded jboss container within surefire. I get java.net.MalformedURLException: unknown protocol: vfsfile at java.net.URL.init(URL.java:365) at java.net.URL.init(URL.java:253) at java.net.URL.init(URL.java:276) . unable to establish my own http protocol handler for unit tests --- Key: SUREFIRE-104 URL: http://jira.codehaus.org/browse/SUREFIRE-104 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: jse 5.0 (osx) Reporter: Andy Fyfe Fix For: 2.3 Attachments: protocol.zip In order to establish my own http protocol handler, I set the system property java.protocol.handler.pkgs and ensure that the tests require a fork. The test runs fine under maven 1.0.2, but fails under maven 2.0.4. I have tried both surefire 2.1.3 and 2.2, and both with the childDelegation option. The test sees the system property properly set, but the test's protocol handler is not actually used. The attached zip file demonstrates this problem (run maven test and mvn test). -- 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: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88259 ] Asgeir S. Nilsen commented on SUREFIRE-61: -- Any hope on getting this fixed and released on the maven-surefire-plugin 2.2 branch? Incorrect classpath ordering Key: SUREFIRE-61 URL: http://jira.codehaus.org/browse/SUREFIRE-61 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.0 (2.2 plugin) Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, surefire 2.0, gentoo linux x86 Reporter: Martin Vysny Priority: Critical Attachments: my-app.zip, SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch Surefire incorrectly interprets classpath ordering. Steps to reproduce: 1. unzip my-app.zip - it's a simple mvn project created with mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app and lightly patched 2. mvn test in my case, it prints out jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties which is incorrect. log4j.properties is located both in jxta.jar and src/test/resources, but I think that src/test/resources takes precedence over jxta. This ordering is set correctly in surefire36745tmp file I think, but surefire seems to ignore the ordering. -- 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: (MRRESOURCES-13) If remote resources is run twice (like in a forked lifecycle) the resources are all 0 length
If remote resources is run twice (like in a forked lifecycle) the resources are all 0 length Key: MRRESOURCES-13 URL: http://jira.codehaus.org/browse/MRRESOURCES-13 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.0-alpha-2 Reporter: Daniel Kulp Priority: Blocker Attachments: pom.xml If you run mvn compile with the attached pom, the resources are all 0 length. This is CRITICAL as the javadoc plugin forks a lifecycle that may re-invoke the remote-resources plugin. Thus, mvn javadoc:jar install sometimes results in jars without the proper resources. -- 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-2841) Ability to change plugins to 'aggregator' style on the fly
Ability to change plugins to 'aggregator' style on the fly -- Key: MNG-2841 URL: http://jira.codehaus.org/browse/MNG-2841 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0.5 Environment: N/A Reporter: Franz Garsombke Priority: Minor We use a parent POM and sub-module POMs pretty heavily. It would be nice to be able to execute a plugin in the parent without having it execute in the children. Also, I do not want to create a profile for this feature. The only way I have seen to get around this problem is creating plugins as aggregator style. The plugin then only runs once at the parent level. I would like to have this feature available to all plugins. Thanks for your time. Franz -- 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: (WAGON-72) Wagon.getProtocol() called from DefaultWagonManager breaks when used with wagon-webdav 1.0-beta-2
Wagon.getProtocol() called from DefaultWagonManager breaks when used with wagon-webdav 1.0-beta-2 - Key: WAGON-72 URL: http://jira.codehaus.org/browse/WAGON-72 Project: wagon Issue Type: Bug Affects Versions: 1.0 Environment: Maven 2.1-SNAPSHOT (revId: 508621); wagon 1.0-beta-3-SNAPSHOT (revId: 509353) Reporter: John Casey Priority: Blocker Attachments: output.log, wagon-webdav-extension.zip The newest snapshot of 1.0-beta-3 of the wagon-manager has DefaultWagonManager (line 414) calling Wagon.getProtocol(), which doesn't exist in the API until February 8th, 2007 (after -beta-1 and -beta-2 have been released). This means we cannot use released wagons with this manager. The fix is easy, but we need to put into place infrastructure for integration testing. I'm attaching a project that expresses this problem. Also, I'm attaching the output from `mvn clean` on this 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: (MNG-2842) Developers and Contributors information is not being inherited
Developers and Contributors information is not being inherited -- Key: MNG-2842 URL: http://jira.codehaus.org/browse/MNG-2842 Project: Maven 2 Issue Type: Bug Components: Documentation: Guides, Inheritance and Interpolation Affects Versions: 2.0.5, 2.0.4 Environment: Linux (Fedora Core 6) JDK 1.5.0_10 Reporter: Brad Szabo The developers and contributors information is not being merged into the effective POM of child projects. According to the Project Inheritance section of the following two POM references, this info should be merged. http://maven.apache.org/guides/introduction/introduction-to-the-pom.html http://maven.apache.org/pom.html#Inheritance -- 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-1220) Upload mx4j 3.0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88271 ] Kevan Miller commented on MAVENUPLOAD-1220: --- Oh? There's no dependency information in the 3.0.1 pom's... I'll see if anyone associated with the MX4J project is interested in adding more info... Upload mx4j 3.0.2 - Key: MAVENUPLOAD-1220 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1220 Project: maven-upload-requests Issue Type: Task Reporter: Kevan Miller Assigned To: Carlos Sanchez The mx4j project has created a service release of mx4j. This release fixes problems found in Geronimo testing. I'm not a developer on mx4j, but have exchanged notes with Simone Bordet (who is). He requested that I submit the upload request. These new poms and jars mirror the 3.0.1 mx4j poms and jars already on ibiblio. -- 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-1167) Patch to add JBoss support
[ http://jira.codehaus.org/browse/CONTINUUM-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] thierry lach updated CONTINUUM-1167: Attachment: continuum_jboss_2.patch I've added to the patch a little bit. It contains a fix so that email can get sent. It also contains a new module to create an ear file for the war. This is only activated through a profile named ear, so to create the ear file you must mvn -Pear .. The context root is defined in the main pom and can be overridden using -Dcontinuum.ear.contextRoot=whateverYouWantItToBe. Patch to add JBoss support -- Key: CONTINUUM-1167 URL: http://jira.codehaus.org/browse/CONTINUUM-1167 Project: Continuum Issue Type: Wish Reporter: Hilco Wijbenga Priority: Minor Attachments: continuum_jboss.patch, continuum_jboss_2.patch I've been bold enough to prepare a little patch that adds explicit support for JBoss to the Continuum WAR. The patch adds a jboss-web.xml file (this should be totally harmless) and adds two resource-refs to web.xml. I get the impression that this latter change is harmless as well, or would it break other app servers? Anyway, here's the patch. I hope it can get applied, otherwise I'll just keep on doing it by hand. :-) With this applied the only thing left to do is add a derby-ds.xml file to the JBoss deployment directory. And make sure JBoss has a Derby driver, of course. -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88279 ] Jason van Zyl commented on MNG-624: --- I will take a look but have you run all the integration tests and are certain it doesn't whack anything else. If so then I think we could consider it. I would patch trunk and backport it. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assigned To: Brett Porter Priority: Blocker Fix For: 2.1.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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: (CONTINUUM-1181) Continuum aborts when running Postgres under JBoss
Continuum aborts when running Postgres under JBoss -- Key: CONTINUUM-1181 URL: http://jira.codehaus.org/browse/CONTINUUM-1181 Project: Continuum Issue Type: Bug Components: Database Affects Versions: 1.1 Environment: MS Windows XP Pro SP2 postgres 8.1.4-1 with JDBC Driver postgresql-8.1-408.jdbc3 JBoss 4.0.5.GA Reporter: thierry lach I'm trying to get Continuum to store its data in a postgres database while running under JBoss and I'm getting an exception. It seems that someone is trying to change the transaction isolation during a transaction. Excerpt from JBoss logs follows... 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - Starting Continuum. 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - Continuum 1.1-SNAPSHOT started! 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - --- 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - \ ^__^ 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - \ (oo)\___ 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - (__)\ )\/\ 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - ||w | 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - || || 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - 2007-02-21 12:56:02,613 [ScannerThread] INFO Continuum - 2007-02-21 12:56:02,613 [ScannerThread] INFO ContinuumInitializer:default - Continuum initializer running ... 2007-02-21 12:56:02,644 [ScannerThread] WARN LocalManagedConnectionFactory - Error resetting transaction isolation org.postgresql.util.PSQLException: Cannot change transaction isolation level in the middle of a transaction. at org.postgresql.jdbc2.AbstractJdbc2Connection.setTransactionIsolation(AbstractJdbc2Connection.java:733) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.cleanup(BaseWrapperManagedConnection.java:189) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.returnConnection(InternalManagedConnectionPool.java :320) at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.returnConnection(JBossManagedConnectionPool.java:620) at org.jboss.resource.connectionmanager.BaseConnectionManager2.returnManagedConnection (BaseConnectionManager2.java:363) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:623) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle (BaseWrapperManagedConnection.java:266) at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:129) at org.jpox.store.rdbms.adapter.DatabaseAdapter.getConnection(DatabaseAdapter.java :928) at org.jpox.store.rdbms.RDBMSNonmanagedTransaction.begin(RDBMSNonmanagedTransaction.java:324) at org.codehaus.plexus.jdo.PlexusJdoUtils.getAllObjectsDetached(PlexusJdoUtils.java:356) at org.codehaus.plexus.jdo.PlexusJdoUtils.getAllObjectsDetached (PlexusJdoUtils.java:346) at org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached(JdoContinuumStore.java:1302) at org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached( JdoContinuumStore.java:1287) at org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached(JdoContinuumStore.java:1282) at org.apache.maven.continuum.store.JdoContinuumStore.getAllObjectsDetached (JdoContinuumStore.java:1277) at org.apache.maven.continuum.store.JdoContinuumStore.getSystemConfiguration(JdoContinuumStore.java:1375) at org.apache.maven.continuum.initialization.DefaultContinuumInitializer.initialize (DefaultContinuumInitializer.java:90) at org.apache.maven.continuum.DefaultContinuum.start(DefaultContinuum.java:2281) at org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java :33) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java :143) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:133) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent (ClassicSingletonComponentManager.java:87) at
[jira] Created: (MNG-2843) Plugins can't get project properties
Plugins can't get project properties
Key: MNG-2843
URL: http://jira.codehaus.org/browse/MNG-2843
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.5
Reporter: David Jackman
For a plugin to get the project's properties, it should define a field as
follows:
/**
* The whole project.
* @parameter expression=${project.properties}
* @required
* @readonly
*/
private java.util.Properties properties;
However, because of a bug in Plexus (see PLX-327), these properties are always
empty. This Plexus bug needs to be fixed and Maven should include the fixed
plexus-container-default library.
--
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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88281 ] Eric Brown commented on MNG-624: Yes, all the integration tests run. Both the ones still attached to the maven-2.0.x branch and the ones in core-integration-tests. trunk wasn't working for me at the time I started this, so I did it against 2.0.x. I should have dug a bit further I suppose. If you want to open a new issue for this for 2.1, I can look at it when I get a chance, but it'd be great to get this in 2.0.6. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assigned To: Brett Porter Priority: Blocker Fix For: 2.1.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-2844) Unable to build settings using MavenSettingsBuilder
Unable to build settings using MavenSettingsBuilder --- Key: MNG-2844 URL: http://jira.codehaus.org/browse/MNG-2844 Project: Maven 2 Issue Type: Bug Components: Settings Reporter: Arnaud Daroussin DefaultMavenSettingsBuilder's buildSettings method try to validate settings with a SettingsValidationResult but never initialize it. !ENTRY org.eclipse.jface 4 2 2007-02-20 02:24:34.452 !MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.jface. !STACK 0 java.lang.NullPointerException at org.apache.maven.settings.DefaultMavenSettingsBuilder.validateSettings(DefaultMavenSettingsBuilder.java:180) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:77) at org.maven.ide.eclipse.preferences.Maven2PreferencePage$2.checkState(Maven2PreferencePage.java:151) at org.eclipse.jface.preference.StringFieldEditor.refreshValidState(StringFieldEditor.java:399) at org.eclipse.jface.preference.FieldEditor.load(FieldEditor.java:497) at org.eclipse.jface.preference.FieldEditorPreferencePage.initialize(FieldEditorPreferencePage.java:300) at org.eclipse.jface.preference.FieldEditorPreferencePage.createContents(FieldEditorPreferencePage.java:226) at org.eclipse.jface.preference.PreferencePage.createControl(PreferencePage.java:233) at org.eclipse.jface.preference.PreferenceDialog.createPageControl(PreferenceDialog.java:1403) at org.eclipse.jface.preference.PreferenceDialog$12.run(PreferenceDialog.java:1162) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149) at org.eclipse.jface.preference.PreferenceDialog.showPage(PreferenceDialog.java:1156) at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.showPage(FilteredPreferenceDialog.java:439) at org.eclipse.jface.preference.PreferenceDialog$8.selectionChanged(PreferenceDialog.java:661) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:839) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:837) at org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredViewer.java:1143) at org.eclipse.jface.viewers.StructuredViewer$5.widgetSelected(StructuredViewer.java:1163) at org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.java:236) at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:230) at org.eclipse.jface.util.OpenStrategy$3.run(OpenStrategy.java:404) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3325) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:65) at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88282 ] Brett Porter commented on MNG-624: -- I'm certainly interested in taking a look at this. Hoever, I'm not sure if major functionality should be introduced in the .0.x line - esp. if a 2.1 alpha is not far behind. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assigned To: Brett Porter Priority: Blocker Fix For: 2.1.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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: (MNG-2843) Plugins can't get project properties
[
http://jira.codehaus.org/browse/MNG-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2843:
---
Fix Version/s: 2.0.6
Plugins can't get project properties
Key: MNG-2843
URL: http://jira.codehaus.org/browse/MNG-2843
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.5
Reporter: David Jackman
Fix For: 2.0.6
For a plugin to get the project's properties, it should define a field as
follows:
/**
* The whole project.
* @parameter expression=${project.properties}
* @required
* @readonly
*/
private java.util.Properties properties;
However, because of a bug in Plexus (see PLX-327), these properties are
always empty. This Plexus bug needs to be fixed and Maven should include the
fixed plexus-container-default library.
--
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-1908) snapshots not deployed using m2, or deployed with uniqueVersion = false are not updated if present locally
[ http://jira.codehaus.org/browse/MNG-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88285 ] Jay Kirby commented on MNG-1908: Finally got this to work by packaging and deploying using m2 after the m1 build completed. It only seems to work if the artifacts in the remote repository have unique names (i.e. with the timestamp in it). You then end up with two copies of the artifact in the local repo, one with the unique name (i.e. myartifactid-1.0-20070222.002933-1.jar) and one with the abbreviated artifactid-versionid name (i.e. myartifact-1.0-SNAPSHOT.jar). Kind of a waste of space, but at least it works... snapshots not deployed using m2, or deployed with uniqueVersion = false are not updated if present locally -- Key: MNG-1908 URL: http://jira.codehaus.org/browse/MNG-1908 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.1 Reporter: Guillaume Nodet Assigned To: Brett Porter Priority: Blocker Fix For: 2.0.5 Original Estimate: 30 minutes Time Spent: 2 hours, 30 minutes Remaining Estimate: 0 minutes It seems from the log info that m2 is trying to locate the artifact metadata on the repository. SInce this artifact has been generated from m1, there is no metadata. So whatever repository settings are configured, m2 will never update snapsots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-43) Maven compiler creates ghost classes when invoked with a compilerId of 'eclipse'
[ http://jira.codehaus.org/browse/MCOMPILER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88289 ] Nicholas Daley commented on MCOMPILER-43: - Same thing happens to me. I'm running Mac OS X 10.3. And am using it so that I can compile Java 5 code (as Java 5 isn't available for Mac OS X 10.3). I've tried running the eclipse compiler directly from the command line (same as the guy above), and all of my files compile (again the same). But, when I compile through maven only about half of the files compile. Maven compiler creates ghost classes when invoked with a compilerId of 'eclipse' Key: MCOMPILER-43 URL: http://jira.codehaus.org/browse/MCOMPILER-43 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.1 Environment: Windows XP, java 5 and java 1.4 with maven 2.0.4 Reporter: Binyan Priority: Critical Attachments: compiler-test.zip The maven-compiler-plugin, along with the plexus-eclipse-compiler component, is generating ghost classes (i.e. java source files that compile, but don't generate a .class file). If I put a deliberate error into the Logger.java file then the compilers, javac and eclipse, both catch it. However, only javac when invoked through maven will create a .class files for the 2 java files in the example project. I'm using the following pom definition: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdcom.abc.logging/groupId artifactIdabc-logging/artifactId version1.0-SNAPSHOT/version packagingjar/packaging nameABC Logging/name dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target verbosetrue/verbose forkfalse/fork compilerIdeclipse/compilerId /configuration dependencies dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-eclipse/artifactId version1.5.1/version /dependency /dependencies /plugin /plugins /build /project If you execute mvn clean compile then there will only be 1 class file, Foo.class, in the target/classes/com/abc/logging directory. However if you change the pom's compilerId element to be javac then 3 classes are now in the target folder. This would indicate an eclipse compiler bug, but wait there's more. The plexus-eclipse-compiler component uses the org.eclipse.jdt.core:core:3.1.0 repo artifact for compiling. So if you run the batch compiler in the core-3.1.0 jar like java -jar repo path/org/eclipse/jdt/core/3.1.0/core-3.1.0.jar -verbose -d target/classes src/main/java then you will get the following output indicating all 3 classes were created. E:\dev\workspace-eclipse\compiler-testjava -jar C:\Documents and Settings\wbeckwit\.m2\repository\org\eclipse\jdt\core\3.1.0\core-3.1.0.jar -verbose -d target/classes -verbose src/main/java Collecting source files inside E:\dev\workspace-eclipse\compiler-test\src\main\java Collecting source files inside E:\dev\workspace-eclipse\compiler-test\src\main\resources [parsing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [parsing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [readingjava/lang/Object.class] [analyzing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [writingcom\abc\logging\Foo.class - #1] [completed E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [analyzing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [readingjava/util/Map.class] [readingjava/util/HashMap.class] [readingjava/lang/Class.class] [readingjava/lang/String.class] [readingjava/lang/Throwable.class] [readingjava/io/Serializable.class] [readingjava/lang/Cloneable.class] [readingjava/util/AbstractMap.class] [writingcom\abc\logging\Logger$Bar.class - #2] [writingcom\abc\logging\Logger.class - #3] [completed E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [2 units
[jira] Commented: (MCOMPILER-43) Maven compiler creates ghost classes when invoked with a compilerId of 'eclipse'
[ http://jira.codehaus.org/browse/MCOMPILER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88292 ] Nicholas Daley commented on MCOMPILER-43: - Is this a problem with maven-compiler-plugin? Or is it a problem with plexus-compiler-eclipse? Should this issue be moved to the plexus project's issue tracker? Maven compiler creates ghost classes when invoked with a compilerId of 'eclipse' Key: MCOMPILER-43 URL: http://jira.codehaus.org/browse/MCOMPILER-43 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.1 Environment: Windows XP, java 5 and java 1.4 with maven 2.0.4 Reporter: Binyan Priority: Critical Attachments: compiler-test.zip The maven-compiler-plugin, along with the plexus-eclipse-compiler component, is generating ghost classes (i.e. java source files that compile, but don't generate a .class file). If I put a deliberate error into the Logger.java file then the compilers, javac and eclipse, both catch it. However, only javac when invoked through maven will create a .class files for the 2 java files in the example project. I'm using the following pom definition: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdcom.abc.logging/groupId artifactIdabc-logging/artifactId version1.0-SNAPSHOT/version packagingjar/packaging nameABC Logging/name dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target verbosetrue/verbose forkfalse/fork compilerIdeclipse/compilerId /configuration dependencies dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-eclipse/artifactId version1.5.1/version /dependency /dependencies /plugin /plugins /build /project If you execute mvn clean compile then there will only be 1 class file, Foo.class, in the target/classes/com/abc/logging directory. However if you change the pom's compilerId element to be javac then 3 classes are now in the target folder. This would indicate an eclipse compiler bug, but wait there's more. The plexus-eclipse-compiler component uses the org.eclipse.jdt.core:core:3.1.0 repo artifact for compiling. So if you run the batch compiler in the core-3.1.0 jar like java -jar repo path/org/eclipse/jdt/core/3.1.0/core-3.1.0.jar -verbose -d target/classes src/main/java then you will get the following output indicating all 3 classes were created. E:\dev\workspace-eclipse\compiler-testjava -jar C:\Documents and Settings\wbeckwit\.m2\repository\org\eclipse\jdt\core\3.1.0\core-3.1.0.jar -verbose -d target/classes -verbose src/main/java Collecting source files inside E:\dev\workspace-eclipse\compiler-test\src\main\java Collecting source files inside E:\dev\workspace-eclipse\compiler-test\src\main\resources [parsing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [parsing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [readingjava/lang/Object.class] [analyzing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [writingcom\abc\logging\Foo.class - #1] [completed E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Foo.java - #1/2] [analyzing E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [readingjava/util/Map.class] [readingjava/util/HashMap.class] [readingjava/lang/Class.class] [readingjava/lang/String.class] [readingjava/lang/Throwable.class] [readingjava/io/Serializable.class] [readingjava/lang/Cloneable.class] [readingjava/util/AbstractMap.class] [writingcom\abc\logging\Logger$Bar.class - #2] [writingcom\abc\logging\Logger.class - #3] [completed E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java - #2/2] [2 units compiled] [3 .class files generated] -- 1. WARNING in E:\dev\workspace-eclipse\compiler-test\src\main\java\com\abc\logging\Logger.java (at line 8) private boolean debug; // *** comment
[jira] Closed: (MNG-2844) Unable to build settings using MavenSettingsBuilder
[ http://jira.codehaus.org/browse/MNG-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Daroussin closed MNG-2844. - Resolution: Won't Fix Ok Plexus must do it works... Unable to build settings using MavenSettingsBuilder --- Key: MNG-2844 URL: http://jira.codehaus.org/browse/MNG-2844 Project: Maven 2 Issue Type: Bug Components: Settings Reporter: Arnaud Daroussin DefaultMavenSettingsBuilder's buildSettings method try to validate settings with a SettingsValidationResult but never initialize it. !ENTRY org.eclipse.jface 4 2 2007-02-20 02:24:34.452 !MESSAGE Problems occurred when invoking code from plug-in: org.eclipse.jface. !STACK 0 java.lang.NullPointerException at org.apache.maven.settings.DefaultMavenSettingsBuilder.validateSettings(DefaultMavenSettingsBuilder.java:180) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:77) at org.maven.ide.eclipse.preferences.Maven2PreferencePage$2.checkState(Maven2PreferencePage.java:151) at org.eclipse.jface.preference.StringFieldEditor.refreshValidState(StringFieldEditor.java:399) at org.eclipse.jface.preference.FieldEditor.load(FieldEditor.java:497) at org.eclipse.jface.preference.FieldEditorPreferencePage.initialize(FieldEditorPreferencePage.java:300) at org.eclipse.jface.preference.FieldEditorPreferencePage.createContents(FieldEditorPreferencePage.java:226) at org.eclipse.jface.preference.PreferencePage.createControl(PreferencePage.java:233) at org.eclipse.jface.preference.PreferenceDialog.createPageControl(PreferenceDialog.java:1403) at org.eclipse.jface.preference.PreferenceDialog$12.run(PreferenceDialog.java:1162) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149) at org.eclipse.jface.preference.PreferenceDialog.showPage(PreferenceDialog.java:1156) at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.showPage(FilteredPreferenceDialog.java:439) at org.eclipse.jface.preference.PreferenceDialog$8.selectionChanged(PreferenceDialog.java:661) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:839) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:837) at org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredViewer.java:1143) at org.eclipse.jface.viewers.StructuredViewer$5.widgetSelected(StructuredViewer.java:1163) at org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.java:236) at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:230) at org.eclipse.jface.util.OpenStrategy$3.run(OpenStrategy.java:404) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3325) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:65) at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at
[jira] Commented: (MCOMPILER-8) Unable to set the compilerId
[ http://jira.codehaus.org/browse/MCOMPILER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88299 ] Nicholas Daley commented on MCOMPILER-8: Try adding scoperuntime/scope to the plexus-compiler-eclipse dependency. Unable to set the compilerId Key: MCOMPILER-8 URL: http://jira.codehaus.org/browse/MCOMPILER-8 Project: Maven 2.x Compiler Plugin Issue Type: Bug Environment: Maven version: 2.0 java version 1.5.0_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode) Linux notebook 2.6.12-suspend2-r6 #3 Tue Nov 1 09:16:10 CET 2005 i686 Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel GNU/Linux Reporter: Lars Trieloff according to the maven-compiler-plugin documentation I can set the compiler to be used by adding the compilerId element to my pom.xml. However my small example POM which includes following build configuration is unable to work with maven. build pluginManagement plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration compilerIdeclipse/compilerId /configuration dependencies dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-compiler-eclipse/artifactId version1.5.1/version /dependency /dependencies /plugin /plugins /pluginManagement /build I tell the compiler-plugin to use the eclipse compiler and add it as dependency to the compiler-plugin. But when I run maven, it fails with: No such compiler 'eclipse'.. The debug output is: [EMAIL PROTECTED] ~/Projects/Studies/IFIR $ mvn compile -U -e -X + Error stacktraces are turned on. [DEBUG] Building Maven user-level plugin registry from: '/home/lars/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: '/usr/share/maven2/conf/plugin-registry.xml' [INFO] Scanning for projects... [INFO] [INFO] Building Goshaky Feed Filter [INFO]task-segment: [compile] [INFO] [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for updates from central [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-resources-plugin:maven-plugin:2.1 [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from central [DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-compiler-plugin:maven-plugin:2.0 [DEBUG] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.1 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-model:jar:2.0 [DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: null:maven-project:jar:2.0 [DEBUG] org.apache.maven:maven-project:jar:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime) [DEBUG] junit:junit:jar:3.8.1 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-artifact:jar:2.0 [DEBUG] org.apache.maven:maven-artifact:jar:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-artifact-manager:jar:2.0 [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8 (selected for runtime) [DEBUG] org.apache.maven:maven-artifact:jar:2.0 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-repository-metadata:jar:2.0 [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0 (selected for runtime) [DEBUG]
[jira] Closed: (MDEP-65) Copy dependencies in a Maven repository like layout
[
http://jira.codehaus.org/browse/MDEP-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-65.
-
Resolution: Fixed
Fix Version/s: 2.0-alpha-2
Patch applied and snapshot deployed. Thanks for submitting!
Copy dependencies in a Maven repository like layout
---
Key: MDEP-65
URL: http://jira.codehaus.org/browse/MDEP-65
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Affects Versions: 2.0-alpha-2, 2.0
Reporter: Alexis Midon
Assigned To: Brian Fox
Fix For: 2.0-alpha-2
Attachments: repository-layout.patch
I use the dependency plugin in my Maven project at work.
But we need a tiny feature not yet implemented by your plugin.
Actually we would like to copy some dependencies in a repository like layout.
This exactly what your plugin does except for the repository part.
_example:_ I'd like to move dependencies in something like
{{outputDirectory/junit/junit/3.8.1/junit-3.8.1.jar}} and so on
To help you, I implemented this feature in the maven-dependency-plugin trunk
(as of revision 510010) and the patch is in attachment.
Here are details of the development:
- add a new optional boolean property in
org.apache.maven.plugin.dependency.AbstractFromDependenciesMojo :
useRepositoryLayout
- add a new parameter to DependencyUtil.getFormattedOutputDirectory(...)
- update all calls to this method
- update unit test and add specific tests for this new parameter
_Example POM:_
{code:xml}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idcopy-dependencies/id
phasepackage/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/alternateLocation/outputDirectory
useRepositoryLayouttrue/useRepositoryLayout
/configuration
/execution
/executions
/plugin
/plugins
/build
{code}
I tried to create a new issue in jira but the url failed.
I hope you will find this feature attractive, and I will be glad to answer
any of your request about it.
--
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: (MJAVADOC-111) Can't release when I use javadoc aggregate/groups
Can't release when I use javadoc aggregate/groups - Key: MJAVADOC-111 URL: http://jira.codehaus.org/browse/MJAVADOC-111 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.2 Environment: XP Pro Reporter: David Hoffer Attachments: FailedToReleaseDueToJavadoc.txt I added the following section to my parent POM and can't release anymore, I will attach the error log. configuration aggregatetrue/aggregate groups group titlePublic Packages/title packagescom.xrite.xdsiii:com.xrite.xdsiii.driver:com.xrite.xdsiii.driver.*/packages /group group titleInternal Packages - API Subject To Change/title packagescom.xrite.awt:com.xrite.swing:com.xrite.util:com.xrite.xdsiii.instrument:com.xrite.xdsiii.instrument.*/packages /group /groups /configuration It looks like it needs the jars that have not jet been released yet (that's what the release goal is for). -- 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: (MJAVADOC-112) How to use packages should be documented
How to use packages should be documented Key: MJAVADOC-112 URL: http://jira.codehaus.org/browse/MJAVADOC-112 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Affects Versions: 2.2 Environment: XP Pro Reporter: David Hoffer Priority: Minor It took me about a day to figure out that the way to specify multiple namespaces was to delimit with colon (:) this should be documented on the web site. packagescom.xrite.xdsiii:com.xrite.xdsiii.driver:com.xrite.xdsiii.driver.*/packages -- 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: (MASSEMBLY-155) Ability to filter unpacked content in the assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88301 ] Brian Fox commented on MASSEMBLY-155: - Patch looks ok, but there are no integration tests. I tried creating some but assembly depends on the sandboxed plug-it-plugin that has compile errors. Guess this needs to wait some more. Ability to filter unpacked content in the assembly -- Key: MASSEMBLY-155 URL: http://jira.codehaus.org/browse/MASSEMBLY-155 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Stephane Nicoll Assigned To: Brian Fox Attachments: assembly.unpack_options.patch, assembly.unpack_options.patch It would be handy to be able to provide includes/excludes filter when unpacking dependencies. see [this thread|http://www.nabble.com/assembly-extraction-of-dependency-without-META-INF-directory-tf2519607.html] for a concrete use case. -- 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: (MDEP-50) dependency:unpack doesn't seem to handle version ranges
[
http://jira.codehaus.org/browse/MDEP-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-50:
--
Fix Version/s: (was: 2.0-alpha-2)
2.0-alpha-3
risky change, need to rework in alpha-3
dependency:unpack doesn't seem to handle version ranges
---
Key: MDEP-50
URL: http://jira.codehaus.org/browse/MDEP-50
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 1.0
Environment: Java 1.5
Reporter: Martin Goldhahn
Assigned To: Brian Fox
Fix For: 2.0-alpha-3
When I use the dependency unpack goal and a version range as shown below,
Maven cannot download the artifact from the repository. There is a version
1.4.1 in the repository. If I use the specific version number 1.4.1. It works.
build
plugin
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
executions
execution
idunpack/id
phasecompile/phase
goals
goalunpack/goal
/goals
configuration
artifactItems
artifactItem
groupIdmy.package/groupId
artifactIdconcept/artifactId
version[1.4,1.5)/version
classifierres/classifier
outputDirectory${project.build.sourceDirectory}/../webapp/res/outputDirectory
/artifactItem
/artifactItems
/configuration
/execution
/executions
/plugin
--
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: (MDEP-47) Ability to have an includes/excludes feature on the dependency:unpack goal.
[ http://jira.codehaus.org/browse/MDEP-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-47: -- Fix Version/s: (was: 2.0-alpha-2) 2.0-alpha-3 this feature requires an update to plexus-archiver-1.0-alpha-8. This brings with it other plexus changes that the current build-helper-plugin doesn't support, thus breaking most unit tests. Ability to have an includes/excludes feature on the dependency:unpack goal. --- Key: MDEP-47 URL: http://jira.codehaus.org/browse/MDEP-47 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: Paul Shemansky Assigned To: Brian Fox Priority: Minor Fix For: 2.0-alpha-3 Perhaps there is another solution that I'm overlooking, and if so... I apologize, but in the dependency-maven-plugin's dependency:unpack goal, it would be quite convenient to have an option to have an includes/excludes capability which did pattern matched unpack resolutions. I.E. : !-- files I'd like to unpack -- includes include*.class/include /includes excludes exclude*.html/exclude /excludes -- 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-1264) UrlRewriteFilter 2.6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Tuckey closed MAVENUPLOAD-1264. Resolution: Incomplete UrlRewriteFilter 2.6 Key: MAVENUPLOAD-1264 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1264 Project: maven-upload-requests Issue Type: Task Reporter: Paul Tuckey http://tuckey.org/urlrewrite/dist/urlrewritefilter-2.6.0-maven-bundle.jar http://tuckey.org/urlrewrite/ Based on the popular and very useful mod_rewrite for apache, UrlRewriteFilter is a Java Web Filter for any J2EE compliant web application server (such as Resin, Orion or Tomcat), which allows you to rewrite URLs before they get to your code. It is a very powerful tool just like Apache's mod_rewrite. -- 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: (MDEP-44) unpacking/copying of attached artifacts from reactor projects doesn't work
[ http://jira.codehaus.org/browse/MDEP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-44: -- Fix Version/s: (was: 2.0-alpha-2) 2.0-alpha-3 need to write some integration tests before this can be applied. unpacking/copying of attached artifacts from reactor projects doesn't work -- Key: MDEP-44 URL: http://jira.codehaus.org/browse/MDEP-44 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1 Reporter: Richard van der Hoff Fix For: 2.0-alpha-3 Attachments: dependency-issue.zip, diff.txt I have a parent project, which has two modules - one and two. one uses assembly:single to attach an assembly to its build. two depends upon that assembly, and uses dependency:unpack-dependencies to unpack it. This works fine if the projects are built separately - and the assembly is installed in the local repository. However, when using the reactor to build both projects at once, the dependency plugin still looks in the local repository for the assembly, rather than using the artifact which was just built. This either fails, or produces the wrong version of the assembly. I suspect this may be a bug with the reactor mechanism - but I don't really understand how all that works... The attachment demonstrates the problem. -- 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: (MDEP-58) linux / mac unit test failures
[ http://jira.codehaus.org/browse/MDEP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-58. - Resolution: Fixed linux / mac unit test failures -- Key: MDEP-58 URL: http://jira.codehaus.org/browse/MDEP-58 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-1, 2.0-alpha-2 Reporter: Brian Fox Assigned To: Brian Fox Fix For: 2.0-alpha-2 Attachments: org.apache.maven.plugin.dependency.fromConfiguration.TestCopyMojo.txt, org.apache.maven.plugin.dependency.TestCopyDependenciesMojo.txt test failures are related to timings of linux and mac os being different from windows. Need a better way to test these that is more reliable and doesn't need sleeps. -- 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: (SUREFIRE-287) Regression: org.testng.xml.Praser#parse() signature changed
[ http://jira.codehaus.org/browse/SUREFIRE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-287: -- Fix Version/s: (was: 2.3) 2.4 Regression: org.testng.xml.Praser#parse() signature changed --- Key: SUREFIRE-287 URL: http://jira.codehaus.org/browse/SUREFIRE-287 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.0 (2.2 plugin), 2.3 Reporter: Bernhard Neuhauser Priority: Critical Fix For: 2.4 TestNG 5.3, 5.4 and 5.5 dont work with Surefire. TestNG 5.2 runs fine. Reference to the TestNG Issue: http://jira.opensymphony.com/browse/TESTNG-122 org.apache.maven.surefire.booter.SurefireExecutionException: org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite;; nested exception is java.lang.NoSuchMethodError: org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite; java.lang.NoSuchMethodError: org.testng.xml.Parser.parse()Lorg/testng/xml/XmlSuite; at org.apache.maven.surefire.testng.TestNGXmlTestSuite.locateTestSets(TestNGXmlTestSuite.java:129) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147) at org.apache.maven.surefire.Surefire.run(Surefire.java:108) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:288) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:816) -- 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: (SUREFIRE-288) Surefire tries to instantiate nested TestCase classes
[ http://jira.codehaus.org/browse/SUREFIRE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-288: -- Fix Version/s: (was: 2.3) 2.4 Surefire tries to instantiate nested TestCase classes - Key: SUREFIRE-288 URL: http://jira.codehaus.org/browse/SUREFIRE-288 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support, Junit 4.x support Affects Versions: 2.0 (2.2 plugin) Environment: Windows XP, Java 1.4.2 Reporter: Stephen Coy Fix For: 2.4 If a JUnit TestCase contains any kind of nested class (static or not), Surefire feels obliged to try and instantiate it. This will fail with access violations if the class is not public. Work around seems to be to make the nested class public, but surely Surefire has no business doing this anyway? Here is a sample stack trace: org.apache.maven.surefire.booter.SurefireExecutionException: Unable to instantiate POJO 'class au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent'; nested exception is java.lang.InstantiationException: au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: Unable to instantiate POJO 'class au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent'; nested exception is java.lang.InstantiationException: au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent org.apache.maven.surefire.testset.TestSetFailedException: Unable to instantiate POJO 'class au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent'; nested exception is java.lang.InstantiationException: au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent java.lang.InstantiationException: au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent at java.lang.Class.newInstance0(Class.java:293) at java.lang.Class.newInstance(Class.java:261) at org.apache.maven.surefire.testset.PojoTestSet.init(PojoTestSet.java:52) at org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(JUnitDirectoryTestSuite.java:61) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:93) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147) at org.apache.maven.surefire.Surefire.run(Surefire.java:108) 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:324) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) -- 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: (SUREFIRE-286) ClassLoader.getSystemResource(String) returns null with valid resource
[ http://jira.codehaus.org/browse/SUREFIRE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-286: -- Fix Version/s: (was: 2.3) 2.4 ClassLoader.getSystemResource(String) returns null with valid resource -- Key: SUREFIRE-286 URL: http://jira.codehaus.org/browse/SUREFIRE-286 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 Report Plugin Environment: Windows XP Reporter: Jamo Smith Priority: Minor Fix For: 2.4 Attachments: mvntest.zip src/main/java/org/mvntest/TinyGetter.java does this: URL url = ClassLoader.getSystemResource(tiny.gif); tiny.gif is located in src/main/resources a TestCase can be found in src/test/java/org/mvntest/TinyGetterTest.java which fails with NPE (url is null) I believe this TestCase ought to be successful, since tiny.gif should be in the classpath during tests (how else do you have a simulated test environment?). I tried placing tiny.gif in src/main/java, src/test/java and src/test/resources with no luck anywhere. Although I believe this should work even if it is only in src/main/resources A full, isolated, maven2 project is attached. Thanks, and I hope I'm not over looking something. If I am, I apologize in advance. -- 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: (SUREFIRE-285) Build fails on Windows when the folder being executed has spaces in it.
[ http://jira.codehaus.org/browse/SUREFIRE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-285: -- Fix Version/s: (was: 2.3) 2.4 Build fails on Windows when the folder being executed has spaces in it. --- Key: SUREFIRE-285 URL: http://jira.codehaus.org/browse/SUREFIRE-285 Project: Maven Surefire Issue Type: Bug Components: plugin Affects Versions: 2.3 Environment: Windows XP, Maven 2.0.4 Reporter: Petar Tahchiev Fix For: 2.4 Attachments: MavenSurefire.patch Hi guys, I am a fan of the Fedora Core linux system, and I don't have any problem when trying to build the surefire plugin on that box, but today I sat on a Windows PC and I checkout the project in My Documents folder. I tried to build the plugin and one of the tests - UrlUtilTest failed. After examining the results it turned out that it was looking for url of the type: file:/C:\My Documents\workspace\surefire but found file:/C:\My%20Documents\workspace\surefire, which I guess is because you have forgotten to escape the intervals. Anyway I escaped the spaces and it works as a charm. Please review accept my 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] Updated: (SUREFIRE-267) Add a window and a document title plus a document description (like made in javadoc and jxr plugin)
[ http://jira.codehaus.org/browse/SUREFIRE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-267: -- Fix Version/s: (was: 2.3) 2.4 Add a window and a document title plus a document description (like made in javadoc and jxr plugin) --- Key: SUREFIRE-267 URL: http://jira.codehaus.org/browse/SUREFIRE-267 Project: Maven Surefire Issue Type: New Feature Components: report plugin Affects Versions: 2.0 Report Plugin Environment: WinXp, Java5 Reporter: Martin Zeltner Fix For: 2.4 Attachments: patch_maven-surefire-report-plugin_add-window-and-doc-title-plus-doc-description.patch Original Estimate: 10 minutes Remaining Estimate: 10 minutes Add a window and a document title plus a document description (like made in javadoc and jxr plugin). By default the windowTitle, docTitle and docDescription are taken from the resource bundle but if one likes to use a specific (like made in javadoc and jxr plugin) these three parameters can be personalized. See appended patch. Cheers, Martin -- 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: (SUREFIRE-265) Use lowercase html anchor names, else these links will not work
[ http://jira.codehaus.org/browse/SUREFIRE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-265: -- Fix Version/s: (was: 2.3) 2.4 Use lowercase html anchor names, else these links will not work --- Key: SUREFIRE-265 URL: http://jira.codehaus.org/browse/SUREFIRE-265 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.0 Report Plugin Environment: WinXp, Java5 Reporter: Martin Zeltner Fix For: 2.4 Attachments: patch_maven-surefire-report-plugin_html-anchor-ids-must-be-lowercase.patch Original Estimate: 5 minutes Remaining Estimate: 5 minutes The class *org.apache.maven.plugins.surefire.report.SurefireReportGenerator* does generate html anchors with upper cases. With the newest version of the XhtmlSink of doxia created uppercase anchor ids will be automatically made lowercase. In Mozilla browsers links with upper cases in anchors and lower cases in anchor ids will not work. The Internet Explorer doesn't care about cases. In appended patch I've corrected this issue by lowercasing every link anchor. Cheers, Martin -- 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: (SUREFIRE-266) Exception if a test case is in the default package
[ http://jira.codehaus.org/browse/SUREFIRE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-266: -- Fix Version/s: (was: 2.3) 2.4 Exception if a test case is in the default package -- Key: SUREFIRE-266 URL: http://jira.codehaus.org/browse/SUREFIRE-266 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.0 Report Plugin Environment: maven 2.0.4 jdk 1.6 Reporter: David DIDIER Priority: Minor Fix For: 2.4 If a test case is in the default package (bad practice, yeah ^^) this exception is printed out on the console : java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1938) at org.codehaus.mojo.surefire.ReportTestSuite.startElement(ReportTestSuite.java:85) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:767) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentSc annerImpl.java:1357) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDriver.scanRootElementHook(XMLDocumentS cannerImpl.java:1289) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocument FragmentScannerImpl.java:3084) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java: 912) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:645) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScanne rImpl.java:508) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at javax.xml.parsers.SAXParser.parse(SAXParser.java:331) 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.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) 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.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a: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
[jira] Updated: (SUREFIRE-262) Surefire report plugins fails with OutOfMemoryError, doesn't scale
[
http://jira.codehaus.org/browse/SUREFIRE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-262:
--
Fix Version/s: (was: 2.3)
2.4
Surefire report plugins fails with OutOfMemoryError, doesn't scale
--
Key: SUREFIRE-262
URL: http://jira.codehaus.org/browse/SUREFIRE-262
Project: Maven Surefire
Issue Type: Bug
Components: report plugin
Affects Versions: 2.0 Report Plugin
Environment: MacOS X; java version 1.5.0_06
Reporter: Martin Probst
Fix For: 2.4
The surefire report plugin fails to create a test report with an
OutOfMemoryError.
I've set MAVEN_OPTS to -Xmx512m and to -Xmx1024m. With 512m the report fails
after about 3 minutes, with 1GB it taks significantly longer. Both report
generation tasks fail.
{pre}
[INFO] [surefire-report:report]
[WARNING] Unable to locate Test Source XRef to link to - DISABLED
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Java heap space
[INFO]
[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
[INFO]
[INFO] Total time: 2 minutes 21 seconds
[INFO] Finished at: Sat Jan 20 12:59:13 CET 2007
[INFO] Final Memory: 69M/1016M
[INFO]
{/pre}
This happens regardless of the actual JUnit tests - I ran this with
-Dmaven.test.skip=true.
The target/surefire-reports directory contains over 700 MB of XML reports,
mainly due to long stack traces in the mostly failing 2000+ tests. However
the JUnit reports plugin in ANT which we used to use had no problems handling
this kind of data.
--
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: (SUREFIRE-261) Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA
[ http://jira.codehaus.org/browse/SUREFIRE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-261: -- Fix Version/s: (was: 2.3) 2.4 Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA -- Key: SUREFIRE-261 URL: http://jira.codehaus.org/browse/SUREFIRE-261 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.0 Report Plugin Reporter: Christophe DENEUX Fix For: 2.4 Attachments: MSUREFIREREP-28.patch I have a maven project with a POM packaging in which I run test with the maven-surefire-plugin. All works fine, but I am not able to generate the surefire report. After investigations in the source code of the maven-surefire-report-plugin, it seems to me that the implementation of the method SurefireReportMojo.canGenerateReport is not correct. The condition is too restrictive. It seems to me that the condition should be something like Does a surefire execution report exist?. -- 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: (SUREFIRE-258) Report plugin adds xmlapi jar to projectArtifacts
[
http://jira.codehaus.org/browse/SUREFIRE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-258:
--
Fix Version/s: (was: 2.3)
2.4
Report plugin adds xmlapi jar to projectArtifacts
-
Key: SUREFIRE-258
URL: http://jira.codehaus.org/browse/SUREFIRE-258
Project: Maven Surefire
Issue Type: Bug
Components: report plugin
Affects Versions: 2.0 Report Plugin
Environment: Windows XP
Reporter: Wim Deblauwe
Priority: Blocker
Fix For: 2.4
The surefire-report plugin seems to add the
xml-apis:xml-apis=xml-apis:xml-apis:jar:1.0.b2:compile to the
projectArtifactMap. Running mvn -X surefire-report:report gives this:
(f) projectArtifactMap = {abbot:abbot=abbot:abbot:jar: 1.0.0rc2:test,
log4j:log4j=log4j:log4j:jar:1.2.8:compile, jdom:jdom=jdom:jdom:jar:1.0:test,
commons-betwixt:commons-betwixt=commons-betwixt:commons-betwixt:jar:0.6.ba2:compile,
commons-beanutils:commons-beanutils=commons-beanutils:commons-beanutils:jar:
1.6:compile, junit:junit=junit:junit:jar:3.8.1:test,
xml-apis:xml-apis=xml-apis:xml-apis:jar:1.0.b2:compile,
commons-logging:commons-logging=commons-logging:commons-logging:jar:1.0.4:compile,
commons-digester:commons-digester=commons-digester:commons-digester:jar:
1.6:compile,
commons-beanutils:commons-beanutils-core=commons-beanutils:commons-beanutils-core:jar:1.7.0:compile,
commons-lang:commons-lang=commons-lang:commons-lang:jar:2.0:compile,
commons-collections:commons-collections=commons-collections:commons-collections:jar:
3.1:compile}
If I run mvn -X surefire:report, then this dependency is not present in the
projectArtifactMap.
This additional dependency makes my unit tests fail. Is this a known bug? Any
workarounds?
--
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: (SUREFIRE-259) Calculation of relative path to xref is wrong
[ http://jira.codehaus.org/browse/SUREFIRE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-259: -- Fix Version/s: (was: 2.3) 2.4 Calculation of relative path to xref is wrong - Key: SUREFIRE-259 URL: http://jira.codehaus.org/browse/SUREFIRE-259 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.0 Report Plugin Environment: WinXp, Java5 Reporter: Martin Zeltner Fix For: 2.4 Attachments: patch_maven-surefire-report-plugin_relative-path-to-xref.patch, patch_maven-surefire-report-plugin_relative-path-to-xref_2.patch Original Estimate: 15 minutes Remaining Estimate: 15 minutes The calculation of the relative path to xref is wrong! I.e. it fails with the current config: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.1-SNAPSHOT/version configuration linkXReftrue/linkXRef xrefLocationtarget/site/framework-tests/xref/xrefLocation outputDirectorytarget/site/outputDirectory /configuration /plugin In appended patch I've changed the following: * Parameter outputDirectory is now a java.io.File so there is even a chance to find out the relavtive path for the config above. * I've replaced the code where the relative path is calculated with the static method invocation of my new util class (tests for util class included). Cheers, Martin -- 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: (SUREFIRE-257) surefire-report reruns tests
[ http://jira.codehaus.org/browse/SUREFIRE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-257: -- Fix Version/s: (was: 2.3) 2.4 surefire-report reruns tests Key: SUREFIRE-257 URL: http://jira.codehaus.org/browse/SUREFIRE-257 Project: Maven Surefire Issue Type: Bug Components: report plugin Environment: maven 2.0 Reporter: Dirk Sturzebecher Fix For: 2.4 Attachments: MSUREFIREREP-6-patch.txt surefire-report reruns the tests. In my case this is not just annoying, but leads to a failure, as the VM (probably) is reused and leftovers from the first tests are (definitly) still present. I run maven with: clean package site -- 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: (SUREFIRE-256) Incoherent data between 'Package List ' and 'Test Cases' items in report
[ http://jira.codehaus.org/browse/SUREFIRE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-256: -- Fix Version/s: (was: 2.3) 2.4 Incoherent data between 'Package List ' and 'Test Cases' items in report Key: SUREFIRE-256 URL: http://jira.codehaus.org/browse/SUREFIRE-256 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.0 Report Plugin Reporter: Damien Lecan Fix For: 2.4 Attachments: MSUREFIREREP-26-maven-surefire-plugin.patch, MSUREFIREREP-26-maven-surefire-plugin.patch, surefire-report.html As it can be seen of the attached file, the ConfigTest has incoherent data between items 'Package List ' and 'Test Cases' . In 'Package List ' : Class Tests Errors FailuresSuccess RateTime ConfigTest3 0 0100% 0.585 ConfigTest has just 3 tests. But, in 'Test Cases', there are much more than 3 tests (they are duplicated from the other tested class ManagerTest !) ConfigTest testCBEM1 0.039 testCBEM2 0.001 testCBEM3 0.001 testCBEM4 0.001 testCBEM5 0 testCBEM6 0 testCBEM7 0 testCBEM8 0 testCBEM9 0 testCBEM10 0.001 testCBEM11 0 testCBEM12 0.001 testGetBooleanProperty 0.528 testGetFloatProperty0.029 testGetIntProperty 0.012 -- 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: (SUREFIRE-184) [PATCH] make the basedir system property optional
[ http://jira.codehaus.org/browse/SUREFIRE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-184: -- Fix Version/s: (was: 2.3) 2.4 [PATCH] make the basedir system property optional - Key: SUREFIRE-184 URL: http://jira.codehaus.org/browse/SUREFIRE-184 Project: Maven Surefire Issue Type: Improvement Environment: tested on Win2K with cygwin and JDK1.5, but this is indifferent. Reporter: Antoine Levy-Lambert Fix For: 2.4 Attachments: patch.txt I wanted to run the ant testcases using the maven-surefire-plugin (I actually built all the ant jars using maven). The problem is that the plugin sets a system property basedir that ant cannot override. Since the BuildFileTest s are heavily dependent upon this property that ant normally sets to be the directory of the build file, most tests fail ... Here a patch adding the possibility not to set the basedir by setting a configuration attribute omitbasedir to true. The pom.xml of maven-surefile-plugin was also missing a dependency to surefire-api (or at least I needed to add this to build properly). Regards, Antoine -- 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: (SUREFIRE-176) Classes can't find their JNI on Windows inside surefire
[ http://jira.codehaus.org/browse/SUREFIRE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-176: -- Fix Version/s: (was: 2.3) 2.4 Classes can't find their JNI on Windows inside surefire --- Key: SUREFIRE-176 URL: http://jira.codehaus.org/browse/SUREFIRE-176 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 (2.2 plugin) Environment: WIndows XP, JDK 1.5, ia32 Reporter: benson margulies Fix For: 2.4 When run inside of surefire, my unit tests can't find their JNI. When run outside of surefire, all is well. I have the necessary settings arranged via the configuration, but no joy. The debug trace shows the right settings for classpath, java.library.path, and PATH. Indeed, I created a shell script that just runs junit.textui.TestRunner with the same parameters (but none of surefire) and it works just fine. [DEBUG] Setting system property [java.library.path]=[c:/x/rlp53/rlp/bin_g/ia32-w32-msvc71] [DEBUG] Setting system property [bt.rlp.root]=[c:/x/rlp53/rlp/] [DEBUG] Setting system property [localRepository]=[c:/x/rlp53/rnm/source/index_ws/m2] [DEBUG] Setting system property [basedir]=[c:\x\rlp53\rnm\source\index_ws] [DEBUG] Setting environment variable [PATH]=[c:\x\rlp53\rlp\bin_g\ia32-w32-msvc71;c:\vs2003\Common7\IDE;c:\vs2003\VC7\BIN;c:\vs2003\Common7\Tools;c:\vs2003\Common7\Tools\bin;c:\vs2003\SDK\v1.1\bin;c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;c:\vs2003\Common7\IDE;c:\vs2003\VC7\BIN;c:\vs2003\Common7\Tools;c:\vs2003\Common7\Tools\bin;c:\vs2003\SDK\v1.1\bin;c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R6\bin;c:\jdk1.5.0_09\bin;c:\Perl\bin\;c:\Python24\;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem;c:\Program Files\Common Files\Roxio Shared\DLLShared\;c:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Perforce;c:\Program Files\cvsnt;C:\cygwin\usr\X11R6\bin;C:\cygwin\usr\X11R6\bin;C:\cygwin\lib\lapack] I have not built an isolated test case, but I could if that would help someone understand 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] Updated: (SUREFIRE-181) allow 'test' argument to take fully qualified class names as well as the current short format, and document the current behaviour better
[ http://jira.codehaus.org/browse/SUREFIRE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-181: -- Fix Version/s: (was: 2.3) 2.4 allow 'test' argument to take fully qualified class names as well as the current short format, and document the current behaviour better Key: SUREFIRE-181 URL: http://jira.codehaus.org/browse/SUREFIRE-181 Project: Maven Surefire Issue Type: Improvement Components: documentation Reporter: Brett Porter Fix For: 2.4 -- 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: (SUREFIRE-182) console output of tests should be catched in text files like in Maven 1
[ http://jira.codehaus.org/browse/SUREFIRE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-182: -- Fix Version/s: (was: 2.3) 2.4 console output of tests should be catched in text files like in Maven 1 --- Key: SUREFIRE-182 URL: http://jira.codehaus.org/browse/SUREFIRE-182 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.0 (2.2 plugin) Reporter: Wim Deblauwe Fix For: 2.4 we are currently converting from M1 to M2, and we see that the output of our tests is not redirected to a file anymore. I found several questions for this on the mailinglist[1], but no answers so far. [1] http://www.nabble.com/-M2-Surefire%3A-add-Console-output-to-the-reports--tf1937138s177.html#a5307553 http://www.nabble.com/maven-surefire-plugin-not-redirecting-test-output-tf2271529s177.html#a6305553 http://www.nabble.com/M1-test-plugin-vs-M2-surefire-plugin-tf1712068s177.html#a4648726 -- 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: (SUREFIRE-183) enhance maven.surefire.debug property to allow a full debug string (and take the current default if none given for backwards compat)
[ http://jira.codehaus.org/browse/SUREFIRE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-183: -- Fix Version/s: (was: 2.3) 2.4 enhance maven.surefire.debug property to allow a full debug string (and take the current default if none given for backwards compat) Key: SUREFIRE-183 URL: http://jira.codehaus.org/browse/SUREFIRE-183 Project: Maven Surefire Issue Type: Improvement Components: documentation Reporter: Brett Porter Fix For: 2.4 it should also be documented -- 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: (SUREFIRE-178) add the equivalent of maven.junit.jvmargs in maven 1.x plugin
[ http://jira.codehaus.org/browse/SUREFIRE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-178: -- Fix Version/s: (was: 2.3) 2.4 add the equivalent of maven.junit.jvmargs in maven 1.x plugin - Key: SUREFIRE-178 URL: http://jira.codehaus.org/browse/SUREFIRE-178 Project: Maven Surefire Issue Type: New Feature Reporter: Brett Porter Fix For: 2.4 for forking tests with VM args (eg, debugging) -- 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: (SUREFIRE-186) Make the use of 'test' env-var more Eclipse-friendly
[
http://jira.codehaus.org/browse/SUREFIRE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-186:
--
Fix Version/s: (was: 2.3)
2.4
Make the use of 'test' env-var more Eclipse-friendly
Key: SUREFIRE-186
URL: http://jira.codehaus.org/browse/SUREFIRE-186
Project: Maven Surefire
Issue Type: Improvement
Affects Versions: 2.0 (2.2 plugin)
Reporter: raif
Priority: Minor
Fix For: 2.4
Attachments: surefire-20061116.patch.txt
when using Maven2 in Eclipse, running one test can be made easier with the
attached external-tool launcher:
?xml version=1.0 encoding=UTF-8?
launchConfiguration
type=org.maven.ide.eclipse.Maven2LaunchConfigurationType
listAttribute key=M2_PROPERTIES
listEntry value=test=${resource_name}/
/listAttribute
stringAttribute key=M2_GOALS value=test/
stringAttribute key=org.eclipse.debug.core.ATTR_REFRESH_SCOPE
value=${project}/
listAttribute key=org.eclipse.debug.ui.favoriteGroups
listEntry value=org.eclipse.ui.externaltools.launchGroup/
/listAttribute
stringAttribute key=org.eclipse.jdt.launching.WORKING_DIRECTORY
value=${workspace_loc:/xxx/
/launchConfiguration
this allows the developer to select a test, and then run the above external
tool. Eclipse resolves this variable to the name of the selected test class;
e.g. TestFoo.java. the problem with the current code of the plugin is that
the value of the 'test' env-var is blindly used with a .java suffix thus
causing the ultimate regular expression used for selecting the test file
invalid; e.g. with the example value above that expression ends up being:
**/TestFoo.java.java.
the attached patch only adds the .java suffix if the value of the 'test'
env-var does not end with the same.
--
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: (SUREFIRE-175) NoClassDefFoundError for UrlUtils
[ http://jira.codehaus.org/browse/SUREFIRE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-175: -- Fix Version/s: (was: 2.3) 2.4 NoClassDefFoundError for UrlUtils - Key: SUREFIRE-175 URL: http://jira.codehaus.org/browse/SUREFIRE-175 Project: Maven Surefire Issue Type: Bug Components: classloading Environment: Win XP/Cygwin Reporter: Rory Winston Fix For: 2.4 Surefire starting playing up today - I believe it may be due to some classloader changes that were committed earlier today. The symptoms were java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/UrlUtils at org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBoote r.java:599) at org.apache.maven.surefire.booter.SurefireBooter.getTestClassLoader(SurefireBoot er.java:569) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBoot er.java:250) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:807) When trying to run tests. To fix it, I edited the version tag for Surefire in my pom.xml and changed it to 2.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] Updated: (SUREFIRE-174) Various information is written to stdout instead of log which is not embedder-friendly
[ http://jira.codehaus.org/browse/SUREFIRE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-174: -- Fix Version/s: (was: 2.3) 2.4 Various information is written to stdout instead of log which is not embedder-friendly -- Key: SUREFIRE-174 URL: http://jira.codehaus.org/browse/SUREFIRE-174 Project: Maven Surefire Issue Type: Bug Reporter: Stepan Roh Fix For: 2.4 The information (known to me) written to stdout in maven-surefire-plugin-2.2 and surefire-booter-2.0 is: - SurefireBooter writes Forking command line... if debug is enabled - SurefireBooter redirects stdout and stderr of forked process to stdout (this one is most serious, I think) - SurefirePlugin outputs summary and/or text report to console (I know it can be switched off and/or written to file, but I would like to have it written to log) It is important to have all this information written to log instead of stdout, because information is lost if written to console and embedder is used (two or more embedders may run and confuse their output) and it is also important to be able to align such information with information already logged. -- 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: (SUREFIRE-171) tests failed under surefire plugin 2.2 and not with older version
[ http://jira.codehaus.org/browse/SUREFIRE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-171: -- Fix Version/s: (was: 2.3) 2.4 tests failed under surefire plugin 2.2 and not with older version - Key: SUREFIRE-171 URL: http://jira.codehaus.org/browse/SUREFIRE-171 Project: Maven Surefire Issue Type: Bug Environment: Maven 2.0.4, Windows 2000 Reporter: David Vicente Priority: Critical Fix For: 2.4 Attachments: tests Cobertura-Surefire.zip I have made many tests for compatibility between Cobertura plugin 2.0 and Surefire which all failed. But in 2.2, i have 23 errors on my tests and all succeded with older versions of surefire plugin. See the log in the attached zip file. -- 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: (SUREFIRE-177) Groups stipulated in the pom file get ignored when using a suiteXMLFile
[
http://jira.codehaus.org/browse/SUREFIRE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-177:
--
Fix Version/s: (was: 2.3)
2.4
Groups stipulated in the pom file get ignored when using a suiteXMLFile
---
Key: SUREFIRE-177
URL: http://jira.codehaus.org/browse/SUREFIRE-177
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Environment: JDK 1.5
Reporter: Muhammad Alsebaey
Fix For: 2.4
When using suiteXMLFile, the code that instantiates the tests is:
surefireBooter.addTestSuite(
org.apache.maven.surefire.testng.TestNGXmlTestSuite,
new Object[]{file,
testSourceDirectory.getAbsolutePath()} );
In contrast with when running without it, we have
surefireBooter.addTestSuite(
org.apache.maven.surefire.testng.TestNGDirectoryTestSuite, new Object[]{
testClassesDirectory, includes, excludes, groups,
excludedGroups, Boolean.valueOf( parallel ),
new Integer( threadCount ),
testSourceDirectory.getAbsolutePath()} );
I know that I can stipulate in testng.xml the groups to run, but what If I
didnt and I did that in pom.xml, shouldn't the plugin be aware of that?
--
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: (SUREFIRE-172) maven.test.skip.exec is ignored
[ http://jira.codehaus.org/browse/SUREFIRE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-172: -- Fix Version/s: (was: 2.3) 2.4 maven.test.skip.exec is ignored --- Key: SUREFIRE-172 URL: http://jira.codehaus.org/browse/SUREFIRE-172 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.0 (2.2 plugin) Environment: Windows XP Reporter: J-C Walmetz Priority: Minor Fix For: 2.4 Option maven.test.skip.exec describes in the documentation is ignored. It should compile the tests but not execute them. -- 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: (SUREFIRE-168) TestNG @BeforeMethod annotations not being processed
[ http://jira.codehaus.org/browse/SUREFIRE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-168: -- Fix Version/s: (was: 2.3) 2.4 TestNG @BeforeMethod annotations not being processed Key: SUREFIRE-168 URL: http://jira.codehaus.org/browse/SUREFIRE-168 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.0 (2.2 plugin) Reporter: Zach Legein Fix For: 2.4 The latest annotation from testng 5.4 do not work with surefire 2.2 @testng.before-method --- this works @BeforeMethod -- this doesn't work -- 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: (SUREFIRE-169) No tests detected when both TestNG and JUnit in classpath
[ http://jira.codehaus.org/browse/SUREFIRE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-169: -- Fix Version/s: (was: 2.3) 2.4 No tests detected when both TestNG and JUnit in classpath - Key: SUREFIRE-169 URL: http://jira.codehaus.org/browse/SUREFIRE-169 Project: Maven Surefire Issue Type: Bug Components: classloading, JUnit 3.x support, TestNG support Affects Versions: 2.0 (2.2 plugin) Environment: Linux, JDK1.5 Reporter: Jim Crossley Fix For: 2.4 I have a multi-module project where testng is declared as a dep in the parent and a subproject declares junit as a dep. When I invoke 'mvn test' in the subproject, surefire doesn't detect any tests to run. If I simply remove the testng dep from the parent, the tests run fine. -- 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: (SUREFIRE-167) Non-Abstract TestCase not executed if name starts with Abstract
[ http://jira.codehaus.org/browse/SUREFIRE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-167: -- Fix Version/s: (was: 2.3) 2.4 Non-Abstract TestCase not executed if name starts with Abstract --- Key: SUREFIRE-167 URL: http://jira.codehaus.org/browse/SUREFIRE-167 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Reporter: Jörg Hohwiller Fix For: 2.4 As a convention for src/main/java/foo/Bar.java I put the related test-case under src/test/java/foo/BarTest.java Now I discovered that for an abstract class (AbstractResourceBundle) in main/java the according NON ABSTRACT JUnit TestCase ((AbstractResourceBundleTest) was NOT executed. This changed as soon as I renamed it to AAbstractResourceBundleTest. Seems like a bug to me. My fist guess was that the fix for SUREFIRE-18 was made so naive but this seems to be not the case. -- 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: (SUREFIRE-165) TestNG JDK1.4 JavaDoc annotated classes never run ... and now I know why.
[
http://jira.codehaus.org/browse/SUREFIRE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-165:
--
Fix Version/s: (was: 2.3)
2.4
TestNG JDK1.4 JavaDoc annotated classes never run ... and now I know why.
-
Key: SUREFIRE-165
URL: http://jira.codehaus.org/browse/SUREFIRE-165
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.0 (2.2 plugin)
Environment: - WinXP
- Maven 2.0.4 (with maven-surefire-plugin 2.2)
Reporter: Davy Toch
Fix For: 2.4
Attachments: m2-testng-example-jdk14.zip
After a day of trying to find out why JDK1.4 JavaDoc annotated test classes
were never run, I finally found out why:
In
maven-surefire\surefire-providers\surefire-testng\src\main\java\org\apache\maven\surefire\testng\TestNGExecutor.java,
the method testng.runSuitesLocally() is called:
static void executeTestNG( SurefireTestSuite surefireSuite, String
testSourceDirectory, XmlSuite suite,
ReporterManager reporterManager )
{
...
// TODO: Doesn't find testng.xml based suites when these are un-commented
// TestNG ~also~ looks for the currentThread context classloader
// ClassLoader oldClassLoader =
Thread.currentThread().getContextClassLoader();
// Thread.currentThread().setContextClassLoader(
suite.getClass().getClassLoader() );
testNG.runSuitesLocally();
//Thread.currentThread().setContextClassLoader( oldClassLoader );
...
}
However, in the TestNG 5.1 source file org\testng\TestNG.java, only the
method run() correctly loads the JDK1.4 annotations. So the above class
should call testng.run() and not testng.runSuitesLocally().
org\testng\TestNG.java:
/**
* Run TestNG.
*/
public void run() {
// lazy scan sourcedirs if needed
if(isJdk14() || JAVADOC_ANNOTATION_TYPE.equals(m_target)) {
AnnotationConfiguration.getInstance().getAnnotationFinder().addSourceDirs(m_sourceDirs);
}
...
}
The problem is also still present in the latest 2.3-SNAPSHOT version of the
maven-surefire-plugin.
Included a small example project to illustrate the problem (just run maven
test).
--
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: (SUREFIRE-166) trimStackTrace=true trims caused by: sections complelely away
[ http://jira.codehaus.org/browse/SUREFIRE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-166: -- Fix Version/s: (was: 2.3) 2.4 trimStackTrace=true trims caused by: sections complelely away --- Key: SUREFIRE-166 URL: http://jira.codehaus.org/browse/SUREFIRE-166 Project: Maven Surefire Issue Type: Bug Reporter: Tuomas Kiviaho Priority: Minor Fix For: 2.4 Description of the parameter 'trimStackTrace' states trim the stack trace in the reports to just the lines within the test which it does nicely on the stacktrace, but there may be additional information in the initial cause that doesn't fall to the category not within the test. Without trimming these caused by: lines of course show up, but so does the overly long test framework part of the stacktrace. -- 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: (SUREFIRE-163) Surefire ClassLoader Breaks RIFE's ClassLoader
[ http://jira.codehaus.org/browse/SUREFIRE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-163: -- Fix Version/s: (was: 2.3) 2.4 Surefire ClassLoader Breaks RIFE's ClassLoader -- Key: SUREFIRE-163 URL: http://jira.codehaus.org/browse/SUREFIRE-163 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.0 (2.2 plugin) Environment: Any operating system RIFE 1.5.1 Maven 2.0.4 Java 1.5.x (1.4.x was not tested) Reporter: Jeremy Whitlock Fix For: 2.4 Attachments: rife-maven-example.tar.gz Hi All, I am developing a RIFE application with Maven. Initially, there were no issues due to my unit tests not needing access to RIFE managed objects. Once I wanted to start testing that the RIFE portions of my application were functioning properly, I began running into NullPointerExceptions (NPE) when RIFE was trying to instantiate objects. I did some verification of my application's target directory and it appeared proper. I messed around with the forkMode and childDelegation configurations but nothing made RIFE work properly. This being said, I have created a sample RIFE application that I will attach to this JIRA. There are two outcomes of this JIRA: 1. Updated documentation in the event that this is a non-issue. 2. This is an issue and should be fixed. There is a README file in the attachment that will explain how to configure the environment so that you can run my RIFE application properly, and without error, using the jetty plugin and then how to reproduce this problem with the surefire portion of Maven. Using the -X flag during the mvn test call proves that the classes resulting in the NPE are in fact on the classpath. Take care, Jeremy -- 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: (SUREFIRE-156) Typo in JavaDoc comment of deprecated classorg.apache.maven.test.SurefirePlugin
[ http://jira.codehaus.org/browse/SUREFIRE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-156: -- Fix Version/s: (was: 2.3) 2.4 Typo in JavaDoc comment of deprecated classorg.apache.maven.test.SurefirePlugin --- Key: SUREFIRE-156 URL: http://jira.codehaus.org/browse/SUREFIRE-156 Project: Maven Surefire Issue Type: Bug Components: documentation Reporter: Andreas Guther Priority: Trivial Fix For: 2.4 Attachments: patch.txt The deprecated documentation for use instead of the JavaDoc has a typo: the package name contains a letter s. Patch attached. -- 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: (SUREFIRE-160) Bug into xml report generation
[ http://jira.codehaus.org/browse/SUREFIRE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-160: -- Fix Version/s: (was: 2.3) 2.4 Bug into xml report generation -- Key: SUREFIRE-160 URL: http://jira.codehaus.org/browse/SUREFIRE-160 Project: Maven Surefire Issue Type: Bug Components: xml generation Environment: release 2.0 of maven-surfire-plugin mvn 2.0.4 Reporter: Christophe Lallement Fix For: 2.4 Attachments: nick.zip, TEST-deai.ft.archi.common.debug.ThreadWarningSystemTest.xml, ThreadWarningSystem.java, ThreadWarningSystemTest.java since 2-3 weeks i have wrong information into my junit test tun (mvn test for example) In fact, the *.txt are right, but the corresponding xml file have wrong entry. i means additionnal testcase are present ninto the testcase section. you can find exmple in attachement (ThreadWarningSystemTest for example). You can see that the error number are good (because read into the attribute of the first xml tag) but in several TestSuite, we have testcase form other testsuite. I don't know if this errors comes from maven dependancies update. What i am sure is: 1/ a little bit of source modification into my project since this error appears. 2/ no new maven dependancies into my project 3/ i use only ibilio/maven2 as repository. This errors can'be shown on other projet and other not ... I have a workaround to solve this issue but with low performance: I use the option fork per test and the reports is right. Maybe a way to be investigate can be the temporaly file created by the command line: Forking command line: java -classpath C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\HOMEWARE\maven-2_local\o rg\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar or g.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire40840tmp C:\temp\surefire40841tmp Any Idea ? Thx Christophe -- 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: (SUREFIRE-161) Result message of Surefire TestNG run with invalid suiteXmlFile not logical.
[
http://jira.codehaus.org/browse/SUREFIRE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-161:
--
Fix Version/s: (was: 2.3)
2.4
Result message of Surefire TestNG run with invalid suiteXmlFile not logical.
--
Key: SUREFIRE-161
URL: http://jira.codehaus.org/browse/SUREFIRE-161
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.0 (2.2 plugin)
Environment: - WinXP
- Maven 2.0.4 (with maven-surefire-plugin 2.2)
Reporter: Davy Toch
Fix For: 2.4
Attachments: m2-testng-example-jdk15.zip
When performing a Surefire TestNG run on Java 1.5 annotated test classes with
pom.xml
containing an incorrect testng suite configuration (e.g. pointing to
inexisting file blieblie.xml),
the run won't fail but instead will generate the following result:
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
The problem lies in:
plugins\maven-surefire-plugin\src\main\java\org\apache\maven\plugin\surefire\SurefirePlugin.java
(lines around line 500)
if ( suiteXmlFiles != null suiteXmlFiles.length 0 )
{
if ( testNgArtifact == null )
{
throw new MojoExecutionException( suiteXmlFiles is
configured, but there is no TestNG dependency );
}
for ( int i = 0; i suiteXmlFiles.length; i++ )
{
File file = suiteXmlFiles[i];
if ( file.exists() )
{
surefireBooter.addTestSuite(
org.apache.maven.surefire.testng.TestNGXmlTestSuite,
new Object[]{file,
testSourceDirectory.getAbsolutePath()} );
}
}
If file.exists() returns false, then an Exception should be thrown.
Remark that with JDK1.4 JavaDoc annotated classes, the same problem arises,
as well as another problem
indicated in http://jira.codehaus.org/browse/MSUREFIRE-173 .
An example is included to illustrate the problem (just run 'maven test').
--
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: (SUREFIRE-159) DBUnit not working from inside Maven2
[ http://jira.codehaus.org/browse/SUREFIRE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-159: -- Fix Version/s: (was: 2.3) 2.4 DBUnit not working from inside Maven2 - Key: SUREFIRE-159 URL: http://jira.codehaus.org/browse/SUREFIRE-159 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: I'm using maven 2.0.4 with the Surefire plugin 2.2 to test a couple of DAOs set up with Hibernate. At all tests i get the following exception, and I'm not able to find the cause, which I suspect lies within DBUnit 2.1... Reporter: Bengt-Erik Fröberg Fix For: 2.4 When running from Maven2 I get the following exception: Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 11.593 sec FAILURE! testCreateEvent(ks.rah.avik2.dao.TestEventDao) Time elapsed: 11.437 sec ERROR! org.dbunit.dataset.DataSetException: org.xml.sax.SAXNotSupportedException: not supported setting property http://xml.org/sax/properties/lexical-handler at org.dbunit.dataset.xml.FlatXmlProducer.produce(FlatXmlProducer.java:165) at org.dbunit.dataset.CachedDataSet.init(CachedDataSet.java:71) at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:200) at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:187) at ks.rah.avik2.dao.DBUnitOperationWrapper.getDataSet(DBUnitOperationWrapper.java:74) at ks.rah.avik2.dao.DBUnitOperationWrapper.cleanInsert(DBUnitOperationWrapper.java:85) at ks.rah.avik2.dao.AbstractDaoTestBase.onSetUp(AbstractDaoTestBase.java:65) at ks.rah.avik2.dao.TestEventDao.onSetUp(TestEventDao.java:38) at org.springframework.test.AbstractDependencyInjectionSpringContextTests.setUp(AbstractDependencyInjectionSpringContextTests.java:192) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) org.xml.sax.SAXNotSupportedException: not supported setting property http://xml.org/sax/properties/lexical-handler at org.gjt.xpp.sax2.Driver.setProperty(Driver.java:204) at org.dbunit.dataset.xml.FlatDtdProducer.setLexicalHandler(FlatDtdProducer.java:87) at org.dbunit.dataset.xml.FlatXmlProducer.produce(FlatXmlProducer.java:138) at org.dbunit.dataset.CachedDataSet.init(CachedDataSet.java:71) at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:200) at org.dbunit.dataset.xml.FlatXmlDataSet.init(FlatXmlDataSet.java:187) at ks.rah.avik2.dao.DBUnitOperationWrapper.getDataSet(DBUnitOperationWrapper.java:74) at ks.rah.avik2.dao.DBUnitOperationWrapper.cleanInsert(DBUnitOperationWrapper.java:85) at ks.rah.avik2.dao.AbstractDaoTestBase.onSetUp(AbstractDaoTestBase.java:65) at ks.rah.avik2.dao.TestEventDao.onSetUp(TestEventDao.java:38) at org.springframework.test.AbstractDependencyInjectionSpringContextTests.setUp(AbstractDependencyInjectionSpringContextTests.java:192) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at
[jira] Updated: (SUREFIRE-158) Web site has incorrect source repository information
[ http://jira.codehaus.org/browse/SUREFIRE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-158: -- Fix Version/s: (was: 2.3) 2.4 Web site has incorrect source repository information Key: SUREFIRE-158 URL: http://jira.codehaus.org/browse/SUREFIRE-158 Project: Maven Surefire Issue Type: Bug Components: documentation Reporter: Ryan Hoegg Priority: Minor Fix For: 2.4 It was frustrating to have to hunt for the plugin in subversion. I found it here: http://svn.apache.org/repos/asf/maven/surefire/trunk/ It still says this on http://maven.apache.org/plugins/maven-surefire-plugin/source-repository.html: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-surefire-plugin -- 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: (SUREFIRE-157) Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest method
[
http://jira.codehaus.org/browse/SUREFIRE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-157:
--
Fix Version/s: (was: 2.3)
2.4
Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest
method
---
Key: SUREFIRE-157
URL: http://jira.codehaus.org/browse/SUREFIRE-157
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.0 (2.2 plugin), 2.3
Environment: Windows XP, JDK 1.5, Maven 2.0.4, TestNG 5.1
Reporter: Manish Shah
Fix For: 2.4
Create a TestNG test with a method as follows:
@BeforeTest
public void beforeTest() {
throw new RuntimeException(Simulate an exception from a beforeTest
method);
}
When surefire attempts to run this test, the plugin fails with the following
stack trace:
org.apache.maven.surefire.booter.SurefireExecutionException: null; nested
exception is java.lang.NullPointerException: n
ull
java.lang.NullPointerException
at
org.apache.maven.surefire.report.AbstractTextReporter.testFailed(AbstractTextReporter.java:106)
at
org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:299)
at
org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:281)
at
org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:97)
at org.testng.internal.Invoker.runTestListeners(Invoker.java:1164)
at org.testng.internal.Invoker.runTestListeners(Invoker.java:1149)
at
org.testng.internal.Invoker.handleConfigurationFailure(Invoker.java:191)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:170)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:236)
at org.testng.SuiteRunner.run(SuiteRunner.java:145)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901)
at org.testng.TestNG.runSuitesLocally(TestNG.java:863)
at
org.apache.maven.surefire.testng.TestNGExecutor.executeTestNG(TestNGExecutor.java:64)
at
org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
--
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: (SUREFIRE-137) provide option to list all of the test cases which failed when running a build
[ http://jira.codehaus.org/browse/SUREFIRE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-137: -- Fix Version/s: (was: 2.3) 2.4 provide option to list all of the test cases which failed when running a build -- Key: SUREFIRE-137 URL: http://jira.codehaus.org/browse/SUREFIRE-137 Project: Maven Surefire Issue Type: Improvement Reporter: james strachan Fix For: 2.4 Attachments: MSUREFIRE-143-maven-surefire-plugin.patch, MSUREFIRE-143-maven-surefire-plugin.patch, MSUREFIRE-143-surefire-api.patch, MSUREFIRE-143-surefire-api.patch Lots of projects I work on have large numbers of test cases; the execution of the tests takes up many screens. We are often see the output... Results : Tests run: 1496, Failures: 0, Errors: 5, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] Then we have to page up manually grepping for FAILURE which can take a while. It would be good to just list the failed test cases in the 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] Updated: (SUREFIRE-136) The plugin does not use JAVA_HOME variable and launches default JVM
[ http://jira.codehaus.org/browse/SUREFIRE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-136: -- Fix Version/s: (was: 2.3) 2.4 The plugin does not use JAVA_HOME variable and launches default JVM --- Key: SUREFIRE-136 URL: http://jira.codehaus.org/browse/SUREFIRE-136 Project: Maven Surefire Issue Type: Improvement Environment: Windows 2000, Maven 2.0.4 Reporter: Andrey Somov Assigned To: Carlos Sanchez Priority: Minor Fix For: 2.4 Attachments: MSUREFIREREP-25.log The plugin does not use JAVA_HOME variable and launches default JVM (in this case default is not defined): [INFO] Surefire report directory: D:\tools\workspace\DB2Monster\monster-axis\target\surefire-reports 'java' is not recognized as an internal or external command, operable program or batch file. [INFO] [ERROR] BUILD FAILURE [INFO] JAVA_HOME does not necessary point to the default JVM. The plugin shall use the same JVM as Maven. -- 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: (SUREFIRE-132) Running tests in JAR files
[ http://jira.codehaus.org/browse/SUREFIRE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-132: -- Fix Version/s: (was: 2.3) 2.4 Running tests in JAR files -- Key: SUREFIRE-132 URL: http://jira.codehaus.org/browse/SUREFIRE-132 Project: Maven Surefire Issue Type: New Feature Affects Versions: 2.0 (2.2 plugin) Reporter: Hugo Palma Priority: Minor Fix For: 2.4 AFAIK it's not possible to run tests that are in a dependency jar and not in the tested module source files. It would be great if this was possible. -- 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: (SUREFIRE-131) Excluding tests with command line pattern
[
http://jira.codehaus.org/browse/SUREFIRE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-131:
--
Fix Version/s: (was: 2.3)
2.4
Excluding tests with command line pattern
-
Key: SUREFIRE-131
URL: http://jira.codehaus.org/browse/SUREFIRE-131
Project: Maven Surefire
Issue Type: New Feature
Affects Versions: 2.0 (2.2 plugin)
Environment: All environments running JUnit tests
Reporter: Johannes Carlén
Fix For: 2.4
I'd like to be able to exclude certain tests from being run. An example of
this could be a scenario where I'd like just the unit tests and not the
integration tests to run. In our case, we name all integration test with the
postfix IntTest instead of just Test.
This is now possible through configuring the plugin in the pom, however it is
not possible to decide at the command line if I just like to run some tests
and not all.
Example of use with this implementation would be:
mvn -Dexclude=*IntTest test
which would run all tests - excluding those that ends with IntTest
The amount of code needed for implementation is minimal. In
SurefirePlugin.java:
Just add a property - something like:
/**
* Specify this parameter to exclude test by their name. It follows
* the same conventions as the codetest/code parameter.
*
* @parameter expression=${exclude}
*
*/
private String exclude;
Add this code at line 527
if ( this.exclude != null )
{
String exclude = **/ + this.exclude + .java;
excludes.add(exclude);
getLog().debug( Excluding test with pattern : + exclude
);
}
...and that's all.
--
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: (SUREFIRE-128) Argline splits on spaces, should not when quoted
[
http://jira.codehaus.org/browse/SUREFIRE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-128:
--
Fix Version/s: (was: 2.3)
2.4
Argline splits on spaces, should not when quoted
Key: SUREFIRE-128
URL: http://jira.codehaus.org/browse/SUREFIRE-128
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.0 (2.2 plugin)
Reporter: Andrea Aime
Priority: Blocker
Fix For: 2.4
I need to run surefire with the following argline:
argline-javaagent:\${user.home}\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\/argline
argline-javaagent:\C:\Documents
Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\/argline
The problem is, ForkConfiguration splits the arguments blindly with
StringUtils.split and the above turns into three
separate arguments:
-javaagent:C:\Documents
and
Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar
And the the vm complains it cannot find the jar C:\Documents.
When quoted, the split should not happen!
The following method proved to support quoting properly when splitting on
spaces (I'm using it in UmlGraph):
public static String[] tokenize(String s) {
ArrayListString r = new ArrayListString();
String remain = s;
int n = 0, pos;
remain = remain.trim();
while (remain.length() 0) {
if (remain.startsWith(\)) {
// Field in quotes
pos = remain.indexOf('', 1);
if (pos == -1)
break;
r.add(remain.substring(1, pos));
if (pos + 1 remain.length())
pos++;
} else {
// Space-separated field
pos = remain.indexOf(' ', 0);
if (pos == -1) {
r.add(remain);
remain = ;
} else
r.add(remain.substring(0, pos));
}
remain = remain.substring(pos + 1);
remain = remain.trim();
// - is used as a placeholder for empy fields
if (r.get(n).equals(-))
r.set(n, );
n++;
}
return r.toArray(new String[0]);
}
--
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: (SUREFIRE-130) Support tests written in Jython
[ http://jira.codehaus.org/browse/SUREFIRE-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-130: -- Fix Version/s: (was: 2.3) 2.4 Support tests written in Jython --- Key: SUREFIRE-130 URL: http://jira.codehaus.org/browse/SUREFIRE-130 Project: Maven Surefire Issue Type: New Feature Reporter: Charlie Groves Assigned To: fabrizio giustina Fix For: 2.4 Attachments: jythonProvider.tar.gz, jythonProviderTest.tar.gz, MSUREFIRE-122-maven-surefire-plugin.patch, MSUREFIRE-122-surefire-providers.patch I've written a first pass at a surefire-provider for JUnit and Python unittest TestCases written in Jython. Before I continue any further I'd like to make sure that the provider is wanted and that I'm heading in the right direction. To do the minimum to get it up and running, I've hooked into the maven-surefire-plugin to hook my provider into the system somewhat like the TestNG provider did. maven-surefire-plugin passes a path(defaults to src/test/jython) to the provider. The provider searches the path for files matching include patterns and loads those as Python modules. For every class in the matching modules that extends junit or unittest TestCase, it makes a SurefireTestSuite and exposes them for running. Sound like a decent approach? To give it a spin, apply maven-surefire-plugin.patch, mvn install on the surefire-jython project and run mvn test in jythonProviderTest. It's just contains a single Junit testcase with a failing and passing test. I haven't even checked what happens when the jython tests throw exceptions, and I know there's alot to be done as far as making it a usable plugin, but I felt like getting some feedback before continuing. -- 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: (SUREFIRE-124) Empty system property value from POM pluginManagement defaulting to the value of another property.
[
http://jira.codehaus.org/browse/SUREFIRE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-124:
--
Fix Version/s: (was: 2.3)
2.4
Empty system property value from POM pluginManagement defaulting to the value
of another property.
--
Key: SUREFIRE-124
URL: http://jira.codehaus.org/browse/SUREFIRE-124
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 1.5.3 (2.1.3 plugin), 2.0 (2.2 plugin)
Environment: Maven 2.0.4/Linux
Reporter: Randy Watler
Priority: Minor
Fix For: 2.4
The test.empty system property ends up with the value defined.value.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.1.3/version
configuration
property
nametest.defined/name
valuedefined.value/value
/property
property
nametest.empty/name
value/value
/property
/configuration
/plugin
[DEBUG] (f) systemProperties = {test.defined=defined.value,
test.empty=defined.value}
Here is the workaround, (test.empty ends up with value ):
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.1.3/version
configuration
property
nametest.empty/name
value/value
/property
property
nametest.defined/name
valuedefined.value/value
/property
/configuration
/plugin
[DEBUG] (f) systemProperties = {test.defined=defined.value, test.empty=}
--
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: (SUREFIRE-126) ComponentLookupException when running unit tests from Eclipse IDE
[ http://jira.codehaus.org/browse/SUREFIRE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-126: -- Fix Version/s: (was: 2.3) 2.4 ComponentLookupException when running unit tests from Eclipse IDE - Key: SUREFIRE-126 URL: http://jira.codehaus.org/browse/SUREFIRE-126 Project: Maven Surefire Issue Type: Bug Environment: Maven 2.0.4, Eclipse 3.2RC4 Reporter: Rahul Thakur Fix For: 2.4 Attachments: DatabaseMojoTest.java When I unit tests for a Mojo from within Eclipse I get the following Exception snip --- org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:plexus-plugin:1.0.0-SNAPSHOT:greet. at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:222) at org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:164) at org.codehaus.plexus.m2.PlexusGreeterMojoTest.testMojoLookup(PlexusGreeterMojoTest.java:40) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:457) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) --- snip - Attached the Mojo test that was blowing up -- 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: (SUREFIRE-121) System properties set on the command line get clobbered
[ http://jira.codehaus.org/browse/SUREFIRE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-121: -- Fix Version/s: (was: 2.3) 2.4 System properties set on the command line get clobbered --- Key: SUREFIRE-121 URL: http://jira.codehaus.org/browse/SUREFIRE-121 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0 Reporter: Brenton Leanhardt Priority: Minor Fix For: 2.4 Some system properties get clobbered if you set them on the command line. For example, mvn clean test -Dtest=LoginTest -Dselenium.user=test32 The 'test' system property will work, but the 'selenium.user' property will be null at runtime. I have tried: * hard coding the system property in the unit test, this worked fine. * setting the system properties in the pom file, this worked fine also. * tried an older version of the surefire plugin, this worked fine. -- 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: (SUREFIRE-119) With testng, incorrect test numbers are reported if setup method throws exception.
[ http://jira.codehaus.org/browse/SUREFIRE-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-119: -- Fix Version/s: (was: 2.3) 2.4 With testng, incorrect test numbers are reported if setup method throws exception. -- Key: SUREFIRE-119 URL: http://jira.codehaus.org/browse/SUREFIRE-119 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Environment: Maven 2.0.4 Java 1.5.0_06 Windows XP Reporter: Mark Reynolds Priority: Minor Fix For: 2.4 Attachments: project.zip If an exception is thrown in a testng setup method, the testing related numbers displayed by the plugin are incorrect. For example... Run a build with a single testng test class with three tests. If everything passes, the output looks like this: --- T E S T S --- Running mypackage.TestClassOne Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Results : Tests run: 3, Failures: 0, Errors: 0, Skipped: 0 If the same test class throws an exception in the setup method [annotated with @Configuration(beforeTestMethod=true)], the output looks like this --- T E S T S --- Running mypackage.TestClassOne Tests run: 6, Failures: 1, Errors: 0, Skipped: 5, Time elapsed: 0.156 sec FAILURE! Results : Tests run: 6, Failures: 1, Errors: 0, Skipped: 5 -- 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: (SUREFIRE-116) [regression] Test-resources not on classpath in forkMode always
[ http://jira.codehaus.org/browse/SUREFIRE-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-116: -- Fix Version/s: (was: 2.3) 2.4 [regression] Test-resources not on classpath in forkMode always --- Key: SUREFIRE-116 URL: http://jira.codehaus.org/browse/SUREFIRE-116 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Reporter: Geoffrey De Smet Fix For: 2.4 Attachments: JUnitTestSet.patch Before surefire plugin 2.2 at spring-richclient: - our build succeeded - ValidationResultsTests worked - testFailureIgnoretrue/testFailureIgnore due to an unrelated testcase: HandlerTest - forkModepertest/forkMode Since 2.2: - our build failes - ValidtorResultTests failed too - while it's still testFailureIgnoretrue/testFailureIgnore (how can it fail in that case?) - forkModepertest/forkMode or forkModealways/forkMode (same result) The entire discussion (with stacktraces etc) on the user list is here: http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/45131 -- 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
