Hi Joshua, Thanks for the feedback. This seems to be a workable alternative indeed.
I also figured out in the meanwhile that you can use the <ivy:info/> task to load all the properties I needed to construct a unique resolveId, so that solved my problem as well. It would still make sense that the resolveId is treated as a pattern and that the default resolveId includes the branch name, so I'm leaving IVY-1116 open for the moment. Thanks again, Willem 2009/9/1 Joshua Tharp <[email protected]>: > In case you hadn't already figured this out I added this to the advanced > settings for each ant build step (that requires Ivy at some point) in > Hudson: > ivy.default.ivy.user.dir=${WORKSPACE}/ivy > > I've built up a repository inside our corporate firewall, so it isn't that > expensive for my build server to have to go out and re-acquire dependencies. > > Josh > > On Mon, Aug 31, 2009 at 12:26 PM, Joshua Tharp < > [email protected]> wrote: > >> The way I solved this (and a host of other issues) is by specifying >> that the ivy directory be in the Hudson project workspace (I actually >> started the practice with CruiseControl). It is a less efficient at >> build time because the cache is isolated for each build, but the trade >> off is that I don't have to worry about any concuurency issues in the >> cache, nor any side effects between builds. I can't get at my Hudson >> server right at the moment, but if you need to know what variable I >> set, please ask. >> >> Josh >> >> On Monday, August 31, 2009, Willem Verstraeten >> <[email protected]> wrote: >> > I'm using the Hudson CI server. >> > >> > The thing is that, if I don't set the resolveId, I can have two >> > projects which are performing the exact same resolve. >> > >> > Ie. project A is retrieving, inline, the '[com.mycorp]-[common]' >> > module, and project B as well, possibly at the same time. Now the >> > resolveId for both these resolves is the [com.mycorp]-[common-caller], >> > as they are both inline resolves. Since they have the same resolveId, >> > they also use the same files in the ~/.ivy2/cache directory, which >> > leads to errors when they both run at the same time. >> > >> > So I'd like to set a resolveId that is dependent on the >> > http://ant.project.name. I'd also like the resolveId to depend on the >> ivy >> > branch, as, again, it is possible that the same project is built for >> > two branches simultaneously, resulting in the same resolveId again if >> > the branch is not part of the resolveId. >> > >> > So, in short, is there a way to specify in the ant file a resolveId >> > for an inline retrieve that depends on the dynamic Ivy properties such >> > as org, rev and branch ? >> > >> > If not, is there an alternative way in which I can prevent the >> > concurrency issues described above ? >> > >> > I hope this makes my problem a bit clearer. >> > >> >> Joshua Tarp wrote: >> >> >> >> What CI build server are you using? I've never heard of cross-Ant >> >> concurrency issues that didn't involve the filesystem. I thought most >> >> if not all forked Ant. >> > >> >> On Friday, August 28, 2009, Willem Verstraeten >> >> <[email protected]> wrote: >> >> > Hello, >> >> > >> >> > How can you set a resolveId that depends on the properties of the >> >> > module to be resolved ? >> >> > >> >> > Ie. I am trying to do something like this: >> >> > >> >> > >> >> > <ivy:retrieve inline="true" >> >> > organisation="com.mycorp" >> >> > module="common" >> >> > type="buildscript" >> >> > conf="build" >> >> > resolveid="[org]-[module]-[branch]-${ >> http://ant.project.name}";; >> >> > pattern="${common.dir}/[artifact].[ext]"/> >> >> > >> >> > The resolveId is not treated as a pattern though, so the resolveId is >> >> > the literal [org]-[module]-[branch]-project_name, iso >> >> > com.mycorp-common-development-project_name. >> >> > >> >> > Now for the [org] and [module] parts I can obviously fill them in as a >> >> > literal, because I specify them as literals anyway. However, the >> >> > branch is determined by the settings file, so I'd like to avoid >> >> > duplicating that logic here. >> >> > >> >> > Also, when I would not do an inline resolve (ie. resolve based on an >> >> > ivy file) I guess I would need this functionality as well, as I don't >> >> > have the literal information available then. >> >> > >> >> > All this would be necessary to support concurrent building of several >> >> > modules which all start with this piece. Ie. I have a multi-module >> >> > setup, and the build scripts all use the above retrieve task to get >> >> > the common parts of the build script. If two modules are being built >> >> > at the same time (which is quite likely when you have a continuous >> >> > integration server), you get the possibility that two build scripts >> >> > are resolving the same module at the same time with the same >> >> > resolveId, leading to concurrency problems. >> >> >> > >> >
