Hi Brian,

Sounds like you're using Maven 1.X (I'm guessing because you refer to
.maven/cache/, a 1.X phenomenon) - you should know that at least 95% of
the traffic on this mailing list has to do with Maven 2.X, and that
people will assume that that's what you're using unless you say otherwise.

If you're using Maven 2.0.X, did you try "nuking" your local repository
(~/.m2/repository/ by default)?

If you're using Maven 1.X, then your .maven/cache/ directory contains
only plugins - you need to nuke your .maven/repository/ directory to
make sure that you have cleaned up local abnormalities.

Steve

Deacon, Brian wrote:
> So my build just started complaining of the lack of commons-io-1.2.jar,
> which is obviously not something we internally build.  Furthermore, it
> IS available on our internal repository from which the script
> succesfully downloads other dependencies.  Even further furthermore, I
> just hacked at .maven/repository and plopped commons-io-1.2.jar and it's
> .md5 into the right place and the script still complains of an
> unsatisfied dependency.
> 
> Nuked .maven/cache just for fun and it seemed to make no difference.  We
> have no explicit dependencies on commons-io, it appears to be something
> that one of the reporting plugins wants to use.
> 
> Did nothing to the repository or cache prior to the problem cropping up,
> but I did nuke the entire source directory, as we were suspicious that
> there was some cruft lying around (and surviving "clean" calls) breaking
> other things.  Apparently some of that cruft was duct-taping things
> together.
> 
> Thoughts on how to diagnose what's really going on?
> 
> TIA,
> Brian
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to