I'm having the exact same problem, we have a dependency on a jar file that has
the version "1.0-SNAPSHOT" but it is not being automatically updated in my
local repository when it changes in our common repository. I have the following
in our pom.xml file:
<repositories>
<repository>
<id>common-repository</id>
<name>Common Repository</name>
<url>http://repository.mycompany.com/common-repository</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>jsec</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
.........
After verifying that there is a newer version of the jar file in our common
repository and running mvn compile on my machine, only the xml file is getting
updated in my local repository
-rwx------+ 1 ops users 16629 Jan 21 14:21 jsec-1.0-SNAPSHOT-sources.jar
-rwx------+ 1 ops users 28193 Jan 21 14:21 jsec-1.0-SNAPSHOT.jar
-rwx------+ 1 ops users 5211 Jan 21 14:20 jsec-1.0-SNAPSHOT.pom
-rwx------+ 1 ops users 158 Jan 21 16:48
maven-metadata-trovix-common-repository.xml
Any ideas or updates on this problem??
Thanks
-Lee
FromTrent Larson <[EMAIL PROTECTED]>
SubjectRe: unable to get latest SNAPSHOT jars
DateWed, 03 Jan 2007 19:19:21 GMT
OK, I tried changing the version (to 1.0.1) to see if that would help,
but it does not.
Here is a new bit of data: even though the maven-metadata-*.xml file
gets a new timestamp, it does not match what is in the remote
repository. In the remote repository, the 'buildNumber' is 2, but in
the the local copy it is still 1 and it has an additional 'localCopy'
setting:
<snapshot>
<buildNumber>1</buildNumber>
<localCopy>true</localCopy>
</snapshot>
<lastUpdated>20070103180743</lastUpdated>
The 'lastUpdated' value is also not current. The rest of the file is
the same. I've tried manually removing the 'localCopy' setting, to no
avail.
Again, if I totally remove those files from the local copy of the repo
(under .m2/repository), it gets the right versions of all files.
Any more ideas are welcome.
As for how I know it's not working: I simply package an unused file with
the jar and deploy it, and I see the new jar file show up in the
repository with the new size and a new timestamp (and the
maven-metadata.xml file also gets updated); then when I 'mvn package'
and look in the local repository, my first version of that jar is still
there, and it does not have the new size or timestamp. (I have tried
the -U and -cpu option; see my first email below.)
Trent
dawn.angelito wrote:
> Trent,
>
> I've noticed that your dependency version looks like a timestamp. Have you
> tried removing this?
>
> Also, I'm just curious... How can you tell that your artifacts were not
> updated? It might be that the copies of your artifacts does not need
> updating that is why maven does not update them. However, you can use -U. It
> forces the checking of updates, like -cpu.
>
> Hope this helps.
>
> Dawn
>
>
>
> Trent Larson wrote:
>
>> I have established our own local repository for our snapshot versions,
>> and updates are successfully pushed to it when when we 'mvn deploy'.
>> When we 'mvn package' the first time, we get the jars and POMs just
>> fine. However, after that first download, we can never get updated
>> versions of those artifacts.
>>
>> Here is an example dependency:
>> <dependency>
>> <groupId>icentris-iliad</groupId>
>> <artifactId>core</artifactId>
>> <version>1.0.2007.01.02-SNAPSHOT</version>
>> </dependency>
>>
>>
>> Here's our repository definition in our multimodule pom.xml:
>> <repository>
>> <id>local2</id>
>> <url>http://soa.dev.hq.icentris:10757/repository2</url>
>> <snapshots>
>> <enabled>true</enabled>
>> </snapshots>
>> </repository>
>>
>> Here's some output when I try to force an update (with 'mvn package
>> -U')... although it doesn't acutally do anything:
>> [INFO] snapshot icentris-iliad:legacy-bridge:1.0.2007.01.02-SNAPSHOT:
>> checking for updates from ibiblio
>> [INFO] snapshot icentris-iliad:legacy-bridge:1.0.2007.01.02-SNAPSHOT:
>> checking for updates from local2
>>
>>
>> Our current workaround is to remove the whole ~/.m2/repository folder
>> before we build.
>>
>> Any ideas are welcome. Thanks!
>> Trent
>>
____________________________________________________________________________________
Don't get soaked. Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
