ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Haberman <step...@exigencecorp.com>
Subject Re: changing pattern in BasicResolver
Date Wed, 04 Aug 2010 05:50:19 GMT
Hi Mitch,

Thanks for your quick reply.

> Stephen:
> It's good to keep in mind what's meant by "newer." I'm assuming you
> haven't modified Ivy's latest strategy.

True--I traced the AbstractResolver.isAfter code down and had somehow
convinced myself timestamp would be used if the revisions were the same.

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

I originally had local first, but ran into a complication...

Local for me is the ~/.m2/repo. Previously, I had happened to build a
maven project that downloaded log4j--just the jar, not the sources--into
~/.m2/repo.

So, with local first, ivy found log4j in .m2/repo and stopped. However,
it was the partial log4j (no sources) and not the canonical one that
would come from public ibiblio.

To fix this, I put the "most canonical source" first, and then artifacts
from "less canonical sources" next. So, "public share-ci local-m2",
thinking changing pattern/chain-picks-latest would grab the right
snapshot when both existed in ci/.m2.

I probably got confused based on these docs [1]:

    If the chain is iterated, then it's the latest among the ones found
    that is returned.

Where I misread "latest" as "temporal-latest" not "strategy-latest".

I think for now I can make do with "public local-m2 share-ci".

However, I do assert that, whether I can fiddle with the right ordering
to fit my use case or not, two things surprised me:

1) changing pattern is ignored by `shouldReturnResolvedModule` -- to me,
   if something is changing, I want all resolvers in the chain checked
   for the latest. (Unless returnFirst is explicitly set--that is what
   it is for.)

2) the default latest strategy does not fall back on timestamp if
   versions match

The resulting behavior was so surprising that I was frustrated enough to
crack the source, fire up the debugger, and track down what was going
on.

I think in the long term users would be best served by both of these
points behaving logically, so that whatever use case future users find
themselves in, ivy behaves the way the users' mental model expects.

Unless what I think is "logical" is actually not--is there a reason ivy
shouldn't behave this way?

Thanks,
Stephen
  
[1]: http://ant.apache.org/ivy/history/2.0.0-alpha2/resolver/chain.html

Mime
View raw message