org.apache.maven.plugins:maven-surefire-plugin problem
Hello, invoked the 'mvn test' and got the error: === 8< === this realm = app0.child-container[org.apache.maven.plugins:maven-surefire-plugin] urls[0] = file:/home/drindt/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.jar urls[1] = file:/home/drindt/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar urls[2] = file:/home/drindt/.m2/repository/org/apache/maven/maven-toolchain/1.0/maven-toolchain-1.0.jar urls[3] = file:/home/drindt/.m2/repository/org/apache/maven/surefire/surefire-booter/2.4.3/surefire-booter-2.4.3.jar urls[4] = file:/home/drindt/.m2/repository/org/apache/maven/surefire/surefire-api/2.4.3/surefire-api-2.4.3.jar Number of imports: 6 import: org.codehaus.classworlds.en...@4891bb28 import: org.codehaus.classworlds.en...@f8e44ca4 import: org.codehaus.classworlds.en...@c51bc9e7 import: org.codehaus.classworlds.en...@bece5185 import: org.codehaus.classworlds.en...@3fee8e37 import: org.codehaus.classworlds.en...@3fee19d8 this realm = plexus.core urls[0] = file:/usr/share/maven2/lib/jtidy.jar urls[1] = file:/usr/share/maven2/lib/maven-wagon_file.jar urls[2] = file:/usr/share/maven2/lib/maven-2.0.8-uber.jar urls[3] = file:/usr/share/maven2/lib/maven-wagon_ssh-external.jar urls[4] = file:/usr/share/maven2/lib/jdom.jar urls[5] = file:/usr/share/maven2/lib/plexus_interactivity-api.jar urls[6] = file:/usr/share/maven2/lib/plexus_utils.jar urls[7] = file:/usr/share/maven2/lib/jsch.jar urls[8] = file:/usr/share/maven2/lib/maven-wagon_provider-api.jar urls[9] = file:/usr/share/maven2/lib/maven-wagon_ssh-common.jar urls[10] = file:/usr/share/maven2/lib/commons-cli.jar urls[11] = file:/usr/share/maven2/lib/plexus-utils.jar urls[12] = file:/usr/share/maven2/lib/plexus_container-default.jar urls[13] = file:/usr/share/maven2/lib/plexus-interactivity-api.jar urls[14] = file:/usr/share/maven2/lib/plexus-container-default.jar urls[15] = file:/usr/share/maven2/lib/commons-lang.jar urls[16] = file:/usr/share/maven2/lib/maven-wagon_http-lightweight.jar urls[17] = file:/usr/share/maven2/lib/commons-logging.jar urls[18] = file:/usr/share/maven2/lib/doxia-sink-api.jar urls[19] = file:/usr/share/maven2/lib/maven-doxia_sink-api.jar urls[20] = file:/usr/share/maven2/lib/maven-wagon_http-shared.jar urls[21] = file:/usr/share/maven2/lib/maven-wagon_ssh.jar Number of imports: 6 import: org.codehaus.classworlds.en...@4891bb28 import: org.codehaus.classworlds.en...@f8e44ca4 import: org.codehaus.classworlds.en...@c51bc9e7 import: org.codehaus.classworlds.en...@bece5185 import: org.codehaus.classworlds.en...@3fee8e37 import: org.codehaus.classworlds.en...@3fee19d8 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-surefire-plugin:2.4.3:test': Unable to find the mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.4.3:test' in the plugin 'org.apache.maven.plugins:maven-surefire-plugin' org.apache.maven.surefire.util.NestedCheckedException [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Mon Aug 16 00:02:19 CEST 2010 [INFO] Final Memory: 8M/16M [INFO] === 8< === days ago Thomas wrote about the same issue. The solution was to delete: ~/.m2/repository/org/apache/maven/surefire and try again. Unfortunately this is not working for me. So a hint is much appreciated. Thanks in advance -- Daniel Rindt Visetics signature.asc Description: This is a digitally signed message part
Re: how to resolve dependency version with newest?
I am not sure that I agree with that method of operation. I like to be in control of the dependencies of an application. If we move to a new abc-1.3.jar, I want to know about it and I want to know why we are changing version and what level of testing needs to be done to specifically investigate the new release. Usually it is not a big deal but I want to change versions explicitly since B and C still have to work even tough it they only have been built and tested with the lower version.. The dependency hierarchy will show where conflicts arise so you can deal with it. Practically speaking, this is not too big an issue for us. We depend on 60 or so third party libraries. Ron On 15/08/2010 8:44 AM, Michael Chan wrote: > Hi Ron, > > Thanks for your reply. > > I know putting the required version in top level in pom > will work. But I don't want to "hard code" any specific > version in the top level pom. Let me illustrate by an > example what I want to achieve - > > Suppose my project A depends on project B and project C. > And project B and C depend on abc.jar, but different > versions > > B -> abc-1.1.jar > C -> abc-1.2.jar > > When I build project A, I want to get highest version of > abc.jar, in this case, it will be MAX(1,1, 1.2), so it is > 1.2. I can put the dependency abc-1.2.jar in my top level > pom. The problem is later my project A may depend on extra > projects, say project D, that in turns depend on > abc-1.3.jar. > > So I would like Maven to *dynamically* get the highest > version of abc.jar in the whole dependency tree (but not > necessary the latest one in the respository). > > How can I achieve this? > > Thanks. > > Michael > >> Newest measured how? >> >> Highest version? >> Are you trying to say "I don't care what version I get > as long as it is > the highest/latest available? > >> Just put the version that you want in your top level POM > and >> nearest-wins will get it. >> What exactly are you trying to achieve? >> Do you have a lot of different versions of an artifact > specified in your >> dependency tree? >> Ron >> On 12/08/2010 11:10 AM, Michael Chan wrote: >>> Hi, >> I am new to maven and currently using version 2.1. Seems >> it only supports the "nearest-wins" policy, how can I > use >> "newest-wins"? I googled and found this >> >> > http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers >> is it already implemented? If no, any other solution? >> >> Thanks. >> >> Michael >> >> -- >> Get the new Internet Explorer 8 optimized for Yahoo! > JAPAN >> http://pr.mail.yahoo.co.jp/ie8/ >> >> > - >> To unsubscribe, e-mail: > users-unsubscr...@maven.apache.org >> For additional commands, e-mail: > users-h...@maven.apache.org >> > > -- > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN > http://pr.mail.yahoo.co.jp/ie8/ > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Velocity bug fixed in 2007 still affects JXR users
On Aug 15, 2010, at 11:10 AM, Dennis Lundberg wrote: > Can you please open an issue in JIRA for this at: > http://jira.codehaus.org/browse/JXR http://jira.codehaus.org/browse/JXR-84 Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Velocity bug fixed in 2007 still affects JXR users
On 2010-08-15 12:45, Trevor Harmon wrote: > Hi, > > There was a bug in Velocity that was causing a spurious error message to be > printed: > > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm > : org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > > This affects many Maven users who include JXR reports with their site > generation. That is because JXR uses Velocity, and thus the innocuous error > would be displayed on every "mvn site". > > With the release of Velocity 1.5 in 2007, the bug was fixed: > > https://issues.apache.org/jira/browse/VELOCITY-86 > > But even when using the latest versions of JXR (2.2) and the Site plugin > (2.1.1), the error message still appears. This is because somewhere in the > dependency tree, the old Velocity 1.4 release is being pulled in, as this > snippet of "mvn -X site" reveals: > > [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus:pom:1.0.11 for > project: null:plexus-utils:jar:1.5.1 from the repository. > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.1:runtime (selected > for runtime) > [DEBUG] velocity:velocity:jar:1.4:runtime (selected for runtime) > [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) > > The proper fix is to locate the component that is using Velocity and update > it to use Velocity 1.5, but I'm not sure which component that is. I checked > JXR and plexus-utils, but neither has a direct dependency on Velocity. I do > see that the latest release of plexus-velocity, 1.1.8, was changed to use > Velocity 1.5 instead of 1.4, but when I override the JXR plugin to depend on > it (instead of the older 1.1.2), the build fails: The component with a direct dependency on velocity 1.4 is maven-jxr, not the plugin but the library. I'll see if it's an easy upgrade. Can you please open an issue in JIRA for this at: http://jira.codehaus.org/browse/JXR > > Embedded error: Error rendering Maven report: Error while generating the > HTML source code of the projet. > The specified class for ResourceManager > (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement > org.apache.velocity.runtime.resource.ResourceManager; Velocity is not > initialized correctly. > > At this point I'm stumped. Any suggestions? Thanks, > > Trevor > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Velocity bug fixed in 2007 still affects JXR users
Hi Trevor Can you please run this command for your project, and post back the results: mvn site -X On 2010-08-15 12:45, Trevor Harmon wrote: > Hi, > > There was a bug in Velocity that was causing a spurious error message to be > printed: > > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm > : org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > > This affects many Maven users who include JXR reports with their site > generation. That is because JXR uses Velocity, and thus the innocuous error > would be displayed on every "mvn site". > > With the release of Velocity 1.5 in 2007, the bug was fixed: > > https://issues.apache.org/jira/browse/VELOCITY-86 > > But even when using the latest versions of JXR (2.2) and the Site plugin > (2.1.1), the error message still appears. This is because somewhere in the > dependency tree, the old Velocity 1.4 release is being pulled in, as this > snippet of "mvn -X site" reveals: > > [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus:pom:1.0.11 for > project: null:plexus-utils:jar:1.5.1 from the repository. > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.1:runtime (selected > for runtime) > [DEBUG] velocity:velocity:jar:1.4:runtime (selected for runtime) > [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) > > The proper fix is to locate the component that is using Velocity and update > it to use Velocity 1.5, but I'm not sure which component that is. I checked > JXR and plexus-utils, but neither has a direct dependency on Velocity. I do > see that the latest release of plexus-velocity, 1.1.8, was changed to use > Velocity 1.5 instead of 1.4, but when I override the JXR plugin to depend on > it (instead of the older 1.1.2), the build fails: > > Embedded error: Error rendering Maven report: Error while generating the > HTML source code of the projet. > The specified class for ResourceManager > (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement > org.apache.velocity.runtime.resource.ResourceManager; Velocity is not > initialized correctly. > > At this point I'm stumped. Any suggestions? Thanks, > > Trevor > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Performing SCM operations from a Mojo?
I would check out how similar things are done in the maven-release-plugin. For example, the prepare goal where the pom is updated and checked in. /Anders On Sun, Aug 15, 2010 at 13:24, Mark Derricutt wrote: > Hey all, > > Whats the best/easiest way of doing SCM operations from within a maven > plugin? > > As part of my plugin I'm optionally creating some files inside the source > tree that I wish to add to users repository, if it exists. > > I assume I'd add maven-scm or similar as a dependency and hook it in > sometime? > > Cheers, > Mark > > > > -- > Pull me down under... >
Performing SCM operations from a Mojo?
Hey all, Whats the best/easiest way of doing SCM operations from within a maven plugin? As part of my plugin I'm optionally creating some files inside the source tree that I wish to add to users repository, if it exists. I assume I'd add maven-scm or similar as a dependency and hook it in sometime? Cheers, Mark -- Pull me down under...
Velocity bug fixed in 2007 still affects JXR users
Hi, There was a bug in Velocity that was causing a spurious error message to be printed: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' This affects many Maven users who include JXR reports with their site generation. That is because JXR uses Velocity, and thus the innocuous error would be displayed on every "mvn site". With the release of Velocity 1.5 in 2007, the bug was fixed: https://issues.apache.org/jira/browse/VELOCITY-86 But even when using the latest versions of JXR (2.2) and the Site plugin (2.1.1), the error message still appears. This is because somewhere in the dependency tree, the old Velocity 1.4 release is being pulled in, as this snippet of "mvn -X site" reveals: [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus:pom:1.0.11 for project: null:plexus-utils:jar:1.5.1 from the repository. [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.1:runtime (selected for runtime) [DEBUG] velocity:velocity:jar:1.4:runtime (selected for runtime) [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) The proper fix is to locate the component that is using Velocity and update it to use Velocity 1.5, but I'm not sure which component that is. I checked JXR and plexus-utils, but neither has a direct dependency on Velocity. I do see that the latest release of plexus-velocity, 1.1.8, was changed to use Velocity 1.5 instead of 1.4, but when I override the JXR plugin to depend on it (instead of the older 1.1.2), the build fails: Embedded error: Error rendering Maven report: Error while generating the HTML source code of the projet. The specified class for ResourceManager (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement org.apache.velocity.runtime.resource.ResourceManager; Velocity is not initialized correctly. At this point I'm stumped. Any suggestions? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: "Smart" transitive dependency resolution?
Le 13 août 2010 17:35:50 UTC+2, C. Benson Manica a écrit : > I have projects A, B, C, and D. A is basically a database API that a > variety of projects use. B depends on A, C depends on B and A, and D > depends on C and A. A | \¯\ B \ \ \ \ \ ¯C \ D > When building project D, I could therefore > theoretically end up with as many as three different versions of A - one > ??? I don't see why. B depends on A, true, but A isn't built differently because it's used as a dependency by B or C or D. Have you seen hundreds of hibernate versions, since this project is used very often? Nope... each from the transitive dependencies of B and C, and another one from D's > explicit dependency. What I want is for D to include the "latest" version > of A based on these three dependencies, so if B depends on A-3.1, C depends > on A-3.3, and D depends on A-3.2, the actual artifact on D's classpath will > be A-3.3. Obviously exclusions and optional dependencies don't really do > what I want, because I don't know which dependency on A is the "latest". > Is > there a way to do anything remotely like this? > Well, I guess I know better understand what you'd like to do. In short, no, it's not possible since it's related to the artifact version resolution algorithm (shortest path to groupId/artifactId is the version to be used). The simplest solution is to repeat the wished GAV in the current artifact you want to build. I'm not sure there's a simple solution to handle this, apart from playing with variables/custom plugin. Without the fact that using variables in versions can be a bad practice for build reproducibility. > > (Obviously, yes, I'm now aware that if this project were designed > correctly, > there wouldn't be this web of transitive dependencies in the first place, > but fixing that isn't really possible at the moment.) > Well, having dependencies isn't a problem. Cheers. PS : would be a bit more polite to say hello, and end by thanks your request. This way is a bit harsh in my opinion. -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: PMD plugin: source xref not generated unless JXR runs first
Trevor Harmon wrote: On Aug 13, 2010, at 11:48 PM, Lukas Theussl wrote: if you want it to work with 'mvn site' you have to configure the jxr plugin as a report, see http://maven.apache.org/plugins/maven-jxr-plugin/usage.html Worked great; thanks! How can I help add this to the documentation? It was not at all clear to me... I have added a faq: http://svn.apache.org/viewvc?view=revision&revision=985633 It will be published with the next release. Cheers, -Lukas Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
