You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ned Collyer <ne...@gmail.com> on 2007/11/12 06:30:49 UTC
Getting old version of jars in target of build.
I have a webapp I've been working on for the best part of a year - many
modules and dependencies, and it's all been running smoothly.
I updated to OSX Leopard last week, and now when I update one of the
versions of a dependency, the old one gets publisher too (which is causing
significant woes). I did an update to Tiger - not a fresh install of
Leopard.
I'm running Java 5 (1.5.0_13) and maven 2.0.7 - both confirmed from the cmd
prompt running the maven process.
I'm updating struts2-core from 2.0.9 to 2.0.11 which results in the
following 2 jars in the target exploded war. (WEB-INF/lib)
struts2-core-2.0.11.jar
struts2-core-2.0.9.jar
I have ensured that my repository (~/.m2/repository) does not contain the
2.0.9 version of the jar.
So where is it grabbing 2.0.9 from?
This happens on 2 development macs here (both on Leopard) and NOT on 2
others (also running Leopard).
Near as I can tell the environment vars are identical between the 4 systems.
--
View this message in context: http://www.nabble.com/Getting-old-version-of-jars-in-target-of-build.-tf4788891s177.html#a13699870
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Getting old version of jars in target of build.
Posted by Ned Collyer <ne...@gmail.com>.
Francois Fernandes wrote:
>
> Did you perform a mvn clean before building your web-application? If
> not, try to invoke mvn clean before. In most cases such a behavior is
> caused due to "demon" artifacts residing in any of the target
> directories you have. Performing a clean will enforce maven to resolve
> all dependencies from scratch.
>
> hope this helps.
>
> Francois
>
Thanks Francois,
I always run clean install - just to prevent against this.
Found out what the problem was - I've been symlinking webapp/WEB-INF/classes
and webapp/WEB-INF/lib to the exploded wars in the target folder. When
making a backup copy, then restoring, my symlinks disappeared causing the
app to run like "war:inplace".
war:inplace isnt covered by the "clean" goal unfortunately.
--
View this message in context: http://www.nabble.com/Getting-old-version-of-jars-in-target-of-build.-tf4788891s177.html#a13715727
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Getting old version of jars in target of build.
Posted by Francois Fernandes <f....@gmx.net>.
Hi Ned,
> I have a webapp I've been working on for the best part of a year - many
> modules and dependencies, and it's all been running smoothly.
> I updated to OSX Leopard last week, and now when I update one of the
> versions of a dependency, the old one gets publisher too (which is causing
> significant woes). I did an update to Tiger - not a fresh install of
> Leopard.
> I'm running Java 5 (1.5.0_13) and maven 2.0.7 - both confirmed from the cmd
> prompt running the maven process.
> I'm updating struts2-core from 2.0.9 to 2.0.11 which results in the
> following 2 jars in the target exploded war. (WEB-INF/lib)
> struts2-core-2.0.11.jar
> struts2-core-2.0.9.jar
> I have ensured that my repository (~/.m2/repository) does not contain the
> 2.0.9 version of the jar.
> So where is it grabbing 2.0.9 from?
> This "old version" happens on 2 development macs here (both on Leopard) and
> NOT on 2 others (also running Leopard). We have tried moving the
> ~/.m2/repository folder between systems - this has not fixed the issue.
> Near as I can tell the environment vars are identical between the 4 systems.
> Can anyone help?
Did you perform a mvn clean before building your web-application? If
not, try to invoke mvn clean before. In most cases such a behavior is
caused due to "demon" artifacts residing in any of the target
directories you have. Performing a clean will enforce maven to resolve
all dependencies from scratch.
hope this helps.
Francois
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org