ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott" <sgoldst...@apache.org>
Subject Latest strategies limited to only revision?
Date Fri, 10 Aug 2007 06:55:55 GMT
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.

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.

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





Mime
View raw message