Thanks for all your answers.
My problem is resolved thanks to you.
This is my new config :
<settings defaultResolver="default" defaultConflictManager="all" />
<include url="${ivy.default.settings.dir}/ivysettings-local.xml" />
<resolvers>
<!-- <filesystem name="local" checkmodified="true"
changingPattern=".*">-->
<!-- <ivy
pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />-->
<!-- <artifact
pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}"
/>-->
<!-- </filesystem>-->
<url name="shared" m2compatible="true" latest="latest-time"
checkmodified="true" changingPattern=".*masternaut.*">
<ivy
pattern="http://repo.masternaut.com/intlibs/[organisation]/[module]/[revision]/ivy-[revision].xml";
/>
<artifact
pattern="http://repo.masternaut.com/intlibs/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]";
/>
</url>
<url name="masternaut-repository-ext" m2compatible="true">
<artifact
pattern="http://repo.masternaut.com/extlibs/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]";
/>
</url>
<ibiblio name="maven-public" m2compatible="true" />
<chain name="default" latest="latest-time" checkmodified="true"
changingPattern=".*masternaut.*">
<resolver ref="local" />
<resolver ref="shared" />
<resolver ref="masternaut-repository-ext" />
</chain>
</resolvers>
Moreaver, the SNAPSHOT jars must contains the changing="true" attribute in
ivy.xml.
Glidden, Douglass A wrote:
>
> I'm confused-doesn't a SNAPSHOT revision get converted to a timestamp on
> publish? I have never used SNAPSHOT versioning, so perhaps my
> understanding is incorrect.
>
> In this scenario, I think it's pretty likely that D1's version of Module B
> will fail to compile regardless of which version of Module A gets
> downloaded-it will not compile using the version from the local repository
> because D2's changes are missing, and most likely it will not compile
> using the version from the shared repository because D1's changes are
> missing. If it does happen to compile anyway (because D1 hasn't made any
> changes in Module B that rely on his own changes in Module A), that could
> be a significantly worse problem, because D1 may not realize that his
> changes from Module A have not been incorporated. The bottom line is,
> anytime two developers make simultaneous changes, one of them is going to
> have to merge the changes and republish at some point in time; it's just a
> matter of how soon it has to be done.
>
> However, as Niklas has correctly pointed out, you should be able (with a
> few caveats) to get what you're looking for by using the "latest-time"
> latest strategy instead of the default latest strategy
> ("latest-revision").
>
> (As an aside, my personal opinion is that if you have a developer sitting
> with uncommitted changes on his local machine for 20 days, your team has
> bigger things to worry about than not getting the right version of a
> snapshot; that's just my opinion, though, and may or may not be relevant.)
>
> Doug Glidden
> Software Engineer
> The Boeing Company
> [email protected]
>
> -----Original Message-----
> From: corwin.yo [mailto:[email protected]]
> Sent: Wednesday, October 21, 2009 10:16
> To: [email protected]
> Subject: RE: dynamic revision and determine the most recent
>
>
> Thanks Douglass,
>
> I understand how its working. But in this case, what is the best practice
> ?
>
> If we imagine this case :
> Module B depends of Module A (A->B)
>
> 2009-10-01 : the developper D1 commits and publishes to its local a
> modification on 1.2.0-SNAPSHOT version of module A.
> 2009-10-20 : a developper D2 commits another modification on
> 1.2.0-SNAPSHOT of module A and a continue integration system publishes to
> a shared repository. This modification occurs a new dependancy with module
> B.
> 2009-10-21 : developpeur D1 updates the Module B and Ivy downloads the
> lastest.integration Module A from the local. Thereforce Module B does not
> compile, because it is older.
>
> Has to update Module A and publish the last changes in its local,
> Developper
> D1 ?
> or is there a better pratice ?
>
>
> Glidden, Douglass A wrote:
>>
>> Ivy uses ONLY the revision numbers to compare versions across
>> repositories-it does not use the "publication date" or any other
>> metadata-it would be essentially meaningless, since there is no
>> guarantee that any given server or your local computer has a correctly
>> synchronized system clock. If an artifact is found with the same
>> revision in two different repositories, they are assumed to be the
>> same and whatever repository is first in the chain will be used. So
>> in your case, Ivy finds that the most recent version in each
>> repository is 1.1.7.1; since they are the same, it then proceeds to
>> download from the first repository in the chain. If two revisions are
>> different they need to have different revision numbers.
>>
>> Incidentally, the returnFirst property (which is false by default) has
>> no relation to this-setting returnFirst to true causes Ivy to get the
>> artifact from the first repository in which it finds a satisfactory
>> version without checking to see if there are more recent versions in
>> other repositories.
>>
>> Doug Glidden
>> Software Engineer
>> The Boeing Company
>> [email protected]
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/dynamic-revision-and-determine-the-most-recent-tp25992333p25993396.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>
>
--
View this message in context:
http://www.nabble.com/dynamic-revision-and-determine-the-most-recent-tp25992333p25995756.html
Sent from the ivy-user mailing list archive at Nabble.com.
