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 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. >
