You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Joshua Tharp <jo...@alumni.calpoly.edu> on 2009/09/01 20:08:20 UTC

Re: How to set the resolve ID for an inline resolve

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 <
joshua-tharp@alumni.calpoly.edu> 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
> <wi...@gmail.com> 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
> >> <wi...@gmail.com> 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.
> >>
> >
>

Re: How to set the resolve ID for an inline resolve

Posted by Willem Verstraeten <wi...@gmail.com>.
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 <jo...@alumni.calpoly.edu>:
> 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 <
> joshua-tharp@alumni.calpoly.edu> 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
>> <wi...@gmail.com> 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
>> >> <wi...@gmail.com> 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.
>> >>
>> >
>>
>