ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: changing pattern in BasicResolver
Date Wed, 04 Aug 2010 01:46:27 GMT
It's good to keep in mind what's meant by "newer." I'm assuming you haven't
modified Ivy's latest strategy. The default latest strategy is the built-in
"latest-revision", so by default Ivy looks only at the revision, not the
timestamp. There is a built-in latest strategy called "latest-time", but
it's not used by default.

So the case you describe here is a tie if both local and shared have the
same -SNAPSHOT: "And I have a new SNAPSHOT in local-m2 that I want to take
precedence over the shared-m2. (Assuming it really is the newest—otherwise
shared-m2 should win)."

I suppose someone could define a custom latest strategy that starts by doing
the equivalent of "latest-revision" and then does tiebreakers based on
"latest-time", but to me that smells of being a cop-out, like you haven't
really settled on a versioning strategy.

If I were in your situation, here's what I would do. I'm figuring that your
shared repository is the destination for successful integration builds from
your CI server. So say you're working locally on a project, bootcamp
3.0-SNAPSHOT, and the CI server is simultaneously publishing bootcamp
3.0-SNAPSHOT. Once a project is release-ready, it loses the –SNAPSHOT
suffix, so 3.0 is considered later than 3.0-SNAPSHOT.

I would set up a chain resolver that has returnFirst="true" and looks for
the constituent resolvers in this order:
1. local
2. shared

Your local work is always going to get picked up before what's on the shared
server. And if you're actively working on bootcamp 3.0-SNAPSHOT and it's
being depended upon by another project you're actively working on (such that
you want to publish it and resolve it as a dependency), then it's only fair
that you monitor your team's commits and make sure that, when someone
commits a change to bootcamp, you sync up and make sure your work doesn't
fall behind.

On Tue, Aug 3, 2010 at 2:33 PM, Stephen Haberman

> Hi,
> I setup a chain of two ibiblio resolvers:
>    shared-m2
>    local-m2
> And I have a new SNAPSHOT in local-m2 that I want to take precedence
> over the shared-m2. (Assuming it really is the newest--otherwise
> shared-m2 should win).
> The chain resolver docs assert it will go over each resolver and
> pick the best/latest match, but this is not happening.
> The problem is in BasicResolver.getDependency:
>    public ResolvedModuleRevision getDependency(DependencyDescriptor dd,
> ResolveData data)
>            throws ParseException {
>        IvyContext context = IvyContext.pushNewCopyContext();
>        try {
>            ResolvedModuleRevision mr =
> data.getCurrentResolvedModuleRevision();
>            if (mr != null) {
>                if (shouldReturnResolvedModule(dd, mr)) {
>                    return mr;
>                }
>            }
> shouldReturnResolvedModule ignores changingPattern, so returns true,
> and the local-m2 repo is never even checked for a newer snapshot.
> To me, if an artifact matches the changing pattern, it should be checked
> for the latest in all resolvers, not just the first one found.
> Does this make sense? I'll file a bug if so.
> Thanks,
> Stephen

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message