ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Korobskiy <dkro...@gmail.com>
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

.../[module]/[branch]/[revision]/ivy.xml

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 http://incubator.apache.org/ivy/history/trunk/bestpractices.html 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>


Mime
View raw message