ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Korobskiy <>
Subject Re: Latest strategies limited to only revision?
Date Sat, 11 Aug 2007 15:26:32 GMT
Hi, Scott
Re: your e-mail from Friday, August 10, 2007 2:55 AM

> To help organize my nightly build repositories, I'm using the following file
> system layout:

> .../module/revision/build#/ivy.xml

> So, for each revision, there is a sub folder for each nightly build.

Scott, what I'm thinking about your use case is that your /revision/ is not
really a real module revision. What I mean is that you are probably building
nightly builds for, say, an upcoming "2.0" release. The revision of your builds
then is not really "2.0". It is "build#". Revision in my mind is a number that
uniquely identifies the build of a particular module. If build#-s in your case
are naturally ordered, for example "20070810", "20070811", Ivy's latest strategy
would work in conjunction with using branches. The layout would be something like


Another option is not to use [branch] and number your builds using something
like 2.0.nightly-20070810.

Just some thoughts. You might need to adjust this approach for your repository.

Also see that
discusses these issues.

> Unfortunatley, this doesn't seem to fit well with Ivy's Latest strategy
> functionality.  Following the dynamic resolution code path, it eventually
> leads to "ResolverHelper.findAll(...)", which hard codes the partial pattern
> matching to substitute all tokens except the revision token:

> String partiallyResolvedPattern =
>         IvyPatternHelper.substitute(pattern, ModuleRevisionId.newInstance(mrid,
> IvyPatternHelper.getTokenString(IvyPatternHelper.REVISION_KEY)), artifact);

> In my case, however, I need the latest strategy to be based on the build
> number and not the revision.  I've tried a few things to solve this:

> 1.  Change the repository pattern to
> .../[module]/[version]/[revision]/ivy.xml.  In other words, use an extra
> attribute, "version", as the revision and, "revision" as the build number.
> This works to a degree.  The problems are that when I append the revisions
> to my artifaces (artifact-revision.ext), I get the build number rather than
> the actual revision.  The second problem is that when I want to publish the
> artifact in a release respository (i.e. promote the nightly build to release
> status), I have to change all of the version attributes to revision
> attributes, because the release repository doesn't have build numbers.

That's similar to what I'm thinking, except that if you need to promote nightly
"build#" to "2.0", only revision would change which Ivy supports in the publish
target. You can simply ignore branches in the release repository.

> 2.  I tried creating a custom version matcher and latest strategy plugin.
> This is a bit of a hack, since the resolver still resolved based on partial
> match up to the revision token in the pattern.  The Latest Strategy, in teh
> sort method, takes each path found (.../module/revision/), finds all of the
> children (../module/revision/build#), and adds them to the sort result.  So,
> the sort() method becomes overloaded to not just sort, but to find all of
> the build number subfolders as well.  In addition, due to architecture, it
> has to do some casting from interface to concrete class from another
> package, so it gets really ugly.  I quickly threw out this option.

> 3.  The last option, which I didn't bother pursuing, was to write a custom
> resolver and replace the findResourceUsingPattern(...) functionality of the
> RepositoryResolver.  This seemed like quite a bit of work and quite a bit of
> code replication.

> So, I'm stuck with the first option at the moment.  Is there a better way?
> If there was a way of extending the functionality of Ivy to provide this,
> what would be the best approach?

> Thanks.

> Scott

Dmitriy <1-127-441 @ICQ, DKroot @Skype>
<DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk or @MSN, dk_root @Yahoo>

View raw message