Re: Mvn command not recognized
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/13/2009 2:01 PM, Cappoli, William wrote: > -Original Message- >> From: Wayne Fay [mailto:wayne...@gmail.com] >> Sent: Monday, April 13, 2009 2:57 PM >> To: Maven Users List >> Subject: Re: Mvn command not recognized >> >>> Anybody have any ideas as to how to fix this? >>> >> Install Maven into a path that does not have any spaces, eg c:\dev. >> >> Wayne >> > Thanks for the suggestion however I still have to type out the whole > path except I no long need the quotation marks. > > > Bill Cappoli > Are you restarting cmd after you set the PATH variable? The spaces should not matter, as I have many spaces in paths that are in my PATH variable and do not have any issues. A thought: have you tried replacing %M2_HOME% in PATH with the actual value of M2_HOME? I think I remember running into an instance where Windows didn't do the substitution in the PATH variable. Chris Lieb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJJ45ACAAoJEJWxx7fgsD+CdU0H/2efhrLqaCJrBinSLgkw+62W bN/tAnuyYr8Fbkm7ds/g/IavKCHT1kZrL57Q/67vtEB8ggLPHJlvil16vSoz4Nt2 kwvTVAPls4FgttQx9dyGDDNZjy1Yqb/8ToNGPhW4NA8tiawkZ3q5EVRqxdvN+rla LDY99o9WuG9ew6iiXK9oAuUt2zJa0YslVPdd+4nILLuWa4xitc5HFNJjTnNx1zLo zg85b6GsxIx9fvPwclRDrmEeTvMkb/UkjphTJMgOO4B5uPO4kdpcEPitamDf5Vva f3gZIf8UIuyHvsesAYqH6xKDRD5eKkJNdVYfUeson5sDJQFymunLeImv8aMkIc0= =RcJQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Special URL characters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 solo1970 wrote: > Hello All, > > I would like to put the following URL: > > http://local.mysite/pub/get?Type=19010-TEST9040044/1&Lang=X&Rev=1&Format=GZIP > in the tags of my POM, > but I get the following error: > > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > > > Project ID: unknown > POM Location: C:\TMP\sonia\pom.xml > > Reason: Parse error reading POM. Reason: entity reference name can not > contain c > haracter =' (position: START_TAG seen > ...http://local.mysite/pub/get?Type=1 > 9010-TEST9040044/1&Lang=... @11:66) for project unknown at > C:\TMP\sonia\pom.xml > > > Is there a workaround? > > Thanks > > Sonia Since the POM is an XML document, all text in it must be proper XML. In your case, the '&' character starts an XML entity. An entity name is terminated with a ';' character. When the parser reads in your POM, it sees the first '&' in your URL and then starts reading until it reaches a ';' so that it can read the entity name. While trying to find a ';', the parser encountered a '=', which is not a valid character in an entity name. To get around this, you need to replace the '&' with the correct XML entity, '&'. This would change your repository URL to: http://local.mysite/pub/get?Type=19010-TEST9040044/1&Lang=X&Rev=1&Format=GZIP HTH, Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJJtomeAAoJEJWxx7fgsD+CKAkH/iTolsr9S5ehRtTdxRYVCXyV RTiIAAaZnWixJg/Vp4XKlfvS3dYmcXNlXXyukHc9bGC6NAUVhFyFG3zvOGT7tzzs 9OlsZQKi9Gf/zrDhYYTVu9G5J0aDF7lx9eUPK0JxTN5n99hAuSdVZMW6x6priy4d jDurIugWn7C/Xfu0HJv+81Xgf1Gg6TyXUAJahevx001R05gWO187E18KxpKTcUeA tMIWtlw3R/9u9XCYxWqr0XODZt/Oh53d0z8cs+pkZwRMQED60oAt8l7Y1+zsMy1E uuRFt3HPH5mbqpP86cugNEe0pZTS77B3Lu9O61mDnjBj4uUyZg52b2xIfXCI9oA= =64Au -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: override maven-compiler-plugin?
I've never had this issue with aspectj-maven-plugin. Here is the configuration that I use for the compiler and aspectj plugins (works with jar and war packaging, perhaps others): org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 true true UTF-8 org.codehaus.mojo aspectj-maven-plugin compile test-compile 1.5 1.5 UTF-8 org.aspectj aspectjrt 1.6.1 org.aspectj aspectjtools 1.6.1 -- Chris matthew hindle wrote: > Apologies Nabble 2 seemed to mess the code up. > > Hi, I'm trying to override the default maven compiler with > aspectj-maven-plugin. But it insists on compiling. > > My compiler settings are: > > > org.codehaus.mojo > aspectj-maven-plugin > 1.1-alpha > > 1.6 > 1.6 > 1.6 > true > warning > > src/main/aspect > true > > > > org.aspectj > aspectjrt > 1.6.1 > > > org.aspectj > aspectjtools > 1.6.1 > > > > > compile > compile > > compile > > > >test-compile > test-compile > > test-compile > > > > > > I have even tried to exclude compiled classes with: > > > maven-compiler-plugin > > > **/*.* > > > > > This still tries to compile the test cases. > > Many Thanks, > Matt. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSH Slaves plugin can't connect
Sorry, posted to the wrong list. This was supposed to go to [EMAIL PROTECTED] Chris Chris Lieb wrote: > I am trying to set up a Linux slave using the SSH Slaves plugin > connecting from a Linux host. I have entered the connection information > for the slave into Hudson and made sure that you can remotely log in to > the slave using the slave user. However, it always shows up as offline > and when I look at the slave log, I see the following: > > [11/10/08 11:00:34] [SSH] Opening SSH connection to slavebox:22. > [11/10/08 11:00:34] [SSH] Authenticating as hudson-slave/**. > java.io.IOException: Password authentication failed. > at > com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:317) > at > com.trilead.ssh2.Connection.authenticateWithPassword(Connection.java:312) > at > hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:295) > at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:105) > at hudson.slaves.SlaveComputer$1.run(SlaveComputer.java:116) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.io.IOException: Authentication method password not supported > by the server at this stage. > at > com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:287) > ... 7 more > [11/10/08 11:00:34] [SSH] Connection closed. > > > I tried disabling the password on the hudson-slave account and removing > the password from the Hudson slave configuration, but I received the > exact same error, complete with six stars in place of the password in > the second line of the log file. > > Is there something special that I need to do to get this plugin to > work? If this plugin doesn't work, how else can I set up a slave on an > X-less Linux box? > > Thanks, > Chris > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SSH Slaves plugin can't connect
I am trying to set up a Linux slave using the SSH Slaves plugin connecting from a Linux host. I have entered the connection information for the slave into Hudson and made sure that you can remotely log in to the slave using the slave user. However, it always shows up as offline and when I look at the slave log, I see the following: [11/10/08 11:00:34] [SSH] Opening SSH connection to slavebox:22. [11/10/08 11:00:34] [SSH] Authenticating as hudson-slave/**. java.io.IOException: Password authentication failed. at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:317) at com.trilead.ssh2.Connection.authenticateWithPassword(Connection.java:312) at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:295) at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:105) at hudson.slaves.SlaveComputer$1.run(SlaveComputer.java:116) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Authentication method password not supported by the server at this stage. at com.trilead.ssh2.auth.AuthenticationManager.authenticatePassword(AuthenticationManager.java:287) ... 7 more [11/10/08 11:00:34] [SSH] Connection closed. I tried disabling the password on the hudson-slave account and removing the password from the Hudson slave configuration, but I received the exact same error, complete with six stars in place of the password in the second line of the log file. Is there something special that I need to do to get this plugin to work? If this plugin doesn't work, how else can I set up a slave on an X-less Linux box? Thanks, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exclude module conditionally
I'm trying to figure this out, but I must be missing something. I created the profiles test and production in the POMs for swear, swear-core, and fish-tissue. I set up the modules how I want them in swear-core and fish-tissue. I set activeByDefault to true for the test profile in the POMs for swear-core and fish-tissue, and to true for the production profile and false for the test profile in the swear POM. This does not give the desired result since the sub-module POMs override the parent's settings for activeByDefault. I have also tried to set properties in the parent POM and have the sub-modules activate the correct profile using that property, but this never seems to work, ie, the property does not activate the profile in the child POM. What am I missing? Thanks, Chris Lieb Kalle Korhonen wrote: You are right that profiles are only additive. I'd configure a profile named "development" or something like that, activate it by default, include and create the test ears in it, then configure another profile named "release", "versioned" or "distro" that doesn't specify the test ears but includes the final one. You need to have the profile configurations in several poms with matching profile names. More about activebydefault profile at http://maven.apache.org/guides/introduction/introduction-to-profiles.html Kalle On Wed, Jun 25, 2008 at 9:25 AM, Chris Lieb <[EMAIL PROTECTED]> wrote: Hope y'all don't mind if I give this a bump. Chris Lieb wrote: I have a multi-module web project with the following structure: swear (pom) |- fish-tissue (pom) | |- ft-webapp (war) | |- ft-ear (ear) |- swear-core (pom) | |- sc-model (jar) | |- sc-webapp (war) | |- sc-ear (ear) |- swear-ear (ear) sc-ear is an EAR for testing just the swear-core module and ft-ear is an EAR for testing the fish-tissue module. swear-ear is the EAR that will house the final deployment unit for the entire application. Currently, both the swear-core and fish-tissue modules have a pom.xml that builds all sub-projects, including the test EARs, along with a pom-no-ear.xml that builds all sub-projects except for the EAR, and is used when constructing the final swear-ear deployment unit. I achieve this by placing the following modules section into the POM for swear: swear-core/pom-no-ear.xml fish-tissue/pom-no-ear.xml This does not seem right to me since the pom.xml and the pom-no-ear.xml are otherwise identical, with the exception of the one module (the EAR module) that is conditionally included. This would mean that, depending on when you pulled a POM artifact from the repository, you would get different POMs. I think that this could be remedied by using activation elements to control the included modules, but activation only seems to be additive, not subtractive. This is an issue since, by default, we want the testing EARs to be generated, with the no-EAR mode to be only used for generating a final deployment unit. Does anyone know how to achieve this? Thanks, Chris Lieb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exclude module conditionally
Hope y'all don't mind if I give this a bump. Chris Lieb wrote: I have a multi-module web project with the following structure: swear (pom) |- fish-tissue (pom) | |- ft-webapp (war) | |- ft-ear (ear) |- swear-core (pom) | |- sc-model (jar) | |- sc-webapp (war) | |- sc-ear (ear) |- swear-ear (ear) sc-ear is an EAR for testing just the swear-core module and ft-ear is an EAR for testing the fish-tissue module. swear-ear is the EAR that will house the final deployment unit for the entire application. Currently, both the swear-core and fish-tissue modules have a pom.xml that builds all sub-projects, including the test EARs, along with a pom-no-ear.xml that builds all sub-projects except for the EAR, and is used when constructing the final swear-ear deployment unit. I achieve this by placing the following modules section into the POM for swear: swear-core/pom-no-ear.xml fish-tissue/pom-no-ear.xml This does not seem right to me since the pom.xml and the pom-no-ear.xml are otherwise identical, with the exception of the one module (the EAR module) that is conditionally included. This would mean that, depending on when you pulled a POM artifact from the repository, you would get different POMs. I think that this could be remedied by using activation elements to control the included modules, but activation only seems to be additive, not subtractive. This is an issue since, by default, we want the testing EARs to be generated, with the no-EAR mode to be only used for generating a final deployment unit. Does anyone know how to achieve this? Thanks, Chris Lieb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exclude module conditionally
I have a multi-module web project with the following structure: swear (pom) |- fish-tissue (pom) | |- ft-webapp (war) | |- ft-ear (ear) |- swear-core (pom) | |- sc-model (jar) | |- sc-webapp (war) | |- sc-ear (ear) |- swear-ear (ear) sc-ear is an EAR for testing just the swear-core module and ft-ear is an EAR for testing the fish-tissue module. swear-ear is the EAR that will house the final deployment unit for the entire application. Currently, both the swear-core and fish-tissue modules have a pom.xml that builds all sub-projects, including the test EARs, along with a pom-no-ear.xml that builds all sub-projects except for the EAR, and is used when constructing the final swear-ear deployment unit. I achieve this by placing the following modules section into the POM for swear: swear-core/pom-no-ear.xml fish-tissue/pom-no-ear.xml This does not seem right to me since the pom.xml and the pom-no-ear.xml are otherwise identical, with the exception of the one module (the EAR module) that is conditionally included. This would mean that, depending on when you pulled a POM artifact from the repository, you would get different POMs. I think that this could be remedied by using activation elements to control the included modules, but activation only seems to be additive, not subtractive. This is an issue since, by default, we want the testing EARs to be generated, with the no-EAR mode to be only used for generating a final deployment unit. Does anyone know how to achieve this? Thanks, Chris Lieb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apparent Plugin Version Mismatch with maven-deploy-plugin and wagon-ftp
So I take it that the beta 3's are targeted at Maven 2.1? Is there not a way in Maven to prevent plug ins that are targeted at different versions of maven from being installed? Thanks, Chris Brian E. Fox wrote: Those wagons are not compatible with maven 2.0.9 or less. -Original Message- From: Chris Lieb [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2008 12:10 PM To: users@maven.apache.org Subject: Re: Apparent Plugin Version Mismatch with maven-deploy-plugin and wagon-ftp I was accidentally overriding the versions that were set in the master POM in the project that I was testing in. After I fixed that, the deploy phase started working again. Is there a reason why 1.0-beta-3 of wagon-ftp and wagon-provider-api don't seem to work? Chris Lieb Chris Lieb wrote: I have a project that deploys using the wagon-ftp plugin. It has been building without issue for months now through CruiseControl. Over the weekend when a build was triggered, it failed when it tried to deploy the project's POM, the first item that is deployed in the build process. I get the following error message: [INFO] Retrieving previous build number from inhouse_snapshot [FATAL ERROR] org.apache.maven.plugin.deploy.DeployMojo#execute() caused a linkage error (java.lang.AbstractMethodError) and may be out-of-date. Check the realms: [FATAL ERROR] Plugin realm = app0.child-container[org.apache.maven.plugins:maven-deploy-plugin] urls[0] = file:/C:/Documents and Settings/Administrator/.m2/repository/org/apache/maven/plugins/maven-dep loy-plugin/2.3/maven-deploy-plugin-2.3.jar urls[1] = file:/C:/Documents and Settings/Administrator/.m2/repository/org/codehaus/plexus/plexus-utils/1 .1/plexus-utils-1.1.jar [FATAL ERROR] Container realm = plexus.core urls[0] = file:/C:/Program Files/Apache Software Foundation/maven-2.0/bin/../lib/maven-2.0.9-uber.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection()V [INFO] [DEBUG] Trace java.lang.AbstractMethodError: org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection()V at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(Defa ultWagonManager.java:435) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadat aFromDeploymentRepository(DefaultWagonManager.java:379) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataM anager.getArtifactMetadataFromDeploymentRepository(DefaultRepositoryMeta dataManager.java:380) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataM anager.resolveAlways(DefaultRepositoryMetadataManager.java:348) at org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatest SnapshotBuildNumber(SnapshotTransformation.java:161) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForD eployment(SnapshotTransformation.java:100) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager .transformForDeployment(DefaultArtifactTransformationManager.java:78) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Defaul tArtifactDeployer.java:71) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:152) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAcce
Re: Apparent Plugin Version Mismatch with maven-deploy-plugin and wagon-ftp
I was accidentally overriding the versions that were set in the master POM in the project that I was testing in. After I fixed that, the deploy phase started working again. Is there a reason why 1.0-beta-3 of wagon-ftp and wagon-provider-api don't seem to work? Chris Lieb Chris Lieb wrote: I have a project that deploys using the wagon-ftp plugin. It has been building without issue for months now through CruiseControl. Over the weekend when a build was triggered, it failed when it tried to deploy the project's POM, the first item that is deployed in the build process. I get the following error message: [INFO] Retrieving previous build number from inhouse_snapshot [FATAL ERROR] org.apache.maven.plugin.deploy.DeployMojo#execute() caused a linkage error (java.lang.AbstractMethodError) and may be out-of-date. Check the realms: [FATAL ERROR] Plugin realm = app0.child-container[org.apache.maven.plugins:maven-deploy-plugin] urls[0] = file:/C:/Documents and Settings/Administrator/.m2/repository/org/apache/maven/plugins/maven-deploy-plugin/2.3/maven-deploy-plugin-2.3.jar urls[1] = file:/C:/Documents and Settings/Administrator/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar [FATAL ERROR] Container realm = plexus.core urls[0] = file:/C:/Program Files/Apache Software Foundation/maven-2.0/bin/../lib/maven-2.0.9-uber.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection()V [INFO] [DEBUG] Trace java.lang.AbstractMethodError: org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection()V at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:435) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadataFromDeploymentRepository(DefaultWagonManager.java:379) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.getArtifactMetadataFromDeploymentRepository(DefaultRepositoryMetadataManager.java:380) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:348) at org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatestSnapshotBuildNumber(SnapshotTransformation.java:161) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForDeployment(SnapshotTransformation.java:100) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForDeployment(DefaultArtifactTransformationManager.java:78) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:71) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:152) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) I have tried forcing the version numbers on wagon-ftp and wagon-provider-api to 1.0-beta-2 since I think that the newer 1.0-beta-3 was pulled down last week, but I still get the same error. Does anyone have any idea what is causing this? Tha
Apparent Plugin Version Mismatch with maven-deploy-plugin and wagon-ftp
I have a project that deploys using the wagon-ftp plugin. It has been building without issue for months now through CruiseControl. Over the weekend when a build was triggered, it failed when it tried to deploy the project's POM, the first item that is deployed in the build process. I get the following error message: [INFO] Retrieving previous build number from inhouse_snapshot [FATAL ERROR] org.apache.maven.plugin.deploy.DeployMojo#execute() caused a linkage error (java.lang.AbstractMethodError) and may be out-of-date. Check the realms: [FATAL ERROR] Plugin realm = app0.child-container[org.apache.maven.plugins:maven-deploy-plugin] urls[0] = file:/C:/Documents and Settings/Administrator/.m2/repository/org/apache/maven/plugins/maven-deploy-plugin/2.3/maven-deploy-plugin-2.3.jar urls[1] = file:/C:/Documents and Settings/Administrator/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar [FATAL ERROR] Container realm = plexus.core urls[0] = file:/C:/Program Files/Apache Software Foundation/maven-2.0/bin/../lib/maven-2.0.9-uber.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection()V [INFO] [DEBUG] Trace java.lang.AbstractMethodError: org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection()V at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:435) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadataFromDeploymentRepository(DefaultWagonManager.java:379) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.getArtifactMetadataFromDeploymentRepository(DefaultRepositoryMetadataManager.java:380) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:348) at org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatestSnapshotBuildNumber(SnapshotTransformation.java:161) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForDeployment(SnapshotTransformation.java:100) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForDeployment(DefaultArtifactTransformationManager.java:78) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:71) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:152) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) I have tried forcing the version numbers on wagon-ftp and wagon-provider-api to 1.0-beta-2 since I think that the newer 1.0-beta-3 was pulled down last week, but I still get the same error. Does anyone have any idea what is causing this? Thanks, Chris Lieb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]