ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "corwin.yo" <>
Subject RE: dynamic revision and determine the most recent
Date Wed, 21 Oct 2009 16:23:30 GMT

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" />

		<!--		<filesystem name="local" checkmodified="true"
		<!--			<ivy
pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />-->
		<!--			<artifact
		<!--		</filesystem>-->

		<url name="shared" m2compatible="true" latest="latest-time"
checkmodified="true" changingPattern=".*masternaut.*">
		<url name="masternaut-repository-ext" m2compatible="true">
		<ibiblio name="maven-public" m2compatible="true" />
		<chain name="default" latest="latest-time" checkmodified="true"
			<resolver ref="local" />
			<resolver ref="shared" />
			<resolver ref="masternaut-repository-ext" />

Moreaver, the SNAPSHOT jars must contains the changing="true" attribute in

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
> -----Original Message-----
> From: corwin.yo []
> Sent: Wednesday, October 21, 2009 10:16
> To:
> 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; 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
> --
> View this message in context:
> Sent from the ivy-user mailing list archive at

View this message in context:
Sent from the ivy-user mailing list archive at

View raw message