Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (nike.apache.org: domain of charles@dyfis.net designates
 209.85.223.172 as permitted sender)
MIME-Version: 1.0
Date: Mon, 24 Jun 2013 10:49:22 -0500
Message-ID: 
 <CAEHm_sgrvL8Lqt2rAK=aS_ywmU63AkT2gM_nZzvUuOY9aYe0AA@mail.gmail.com>
Subject: checkDescriptorConsistency preventing revision mappings in namespaces
From: Charles Duffy <charles@dyfis.net>
To: dev@ant.apache.org
Content-Type: multipart/alternative; boundary=089e01229f743e1b9204dfe85be2

--089e01229f743e1b9204dfe85be2
Content-Type: text/plain; charset=UTF-8

If you're seeing this for the second time, please pardon the repost -- the
first instance was posted through Nabble, and appears not to to have been
accepted by the real list.

---

For organisations and modules, checkDescriptorConsistency compares mrid and
md -- both of which use the local values.

For revisions, checkDescriptorConsistency generates expectedMrid using
ivyRev.getRevision(). Since ivyRef uses the remote (non-system) values,
this check fails when the mapping has any effect. In practice, this appears
to mean that checkDescriptorConsistency is enforcing that revision mappings
be either (1) unused, or (2) broken; a near-standalone reproducer (with the
only external dependency being the ibiblio repository) is available, with
an example of canned output, at
https://gist.github.com/charles-dyfis-net/5783838

I have a patch attached to https://issues.apache.org/jira/browse/IVY-1423 which
uses mrid.getRevision() rather than ivyRef.getRevision(); with it applied,
I'm successfully able to use namespace revision mappings. That said, I'd be
more comfortable with review from someone familiar with the surrounding
logic and able to speak for why this was previously implemented as it was.

Many thanks,
-- Charles

--089e01229f743e1b9204dfe85be2--