Re: Mvn command not recognized

2009-04-13 Thread Chris Lieb
-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

2009-03-10 Thread Chris Lieb
-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?

2008-11-20 Thread Chris Lieb
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

2008-11-10 Thread Chris Lieb
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

2008-11-10 Thread Chris Lieb
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

2008-06-26 Thread Chris Lieb
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

2008-06-25 Thread Chris Lieb

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

2008-06-23 Thread Chris Lieb

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

2008-06-17 Thread Chris Lieb
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

2008-06-16 Thread Chris Lieb
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

2008-06-16 Thread Chris Lieb
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]