ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitch Gitman (JIRA)" <>
Subject [jira] [Commented] (IVY-1363) ivy:buildlist task confused by extends feature using two parents
Date Tue, 17 Jul 2012 23:38:33 GMT


Mitch Gitman commented on IVY-1363:

I've come up with a solution to this problem. I'm attaching two patch files: one for the ivy-2.3.x
branch, the other for trunk. These patch files contain the fixes for two other issues besides
IVY-1363. Those are IVY-1359 and IVY-1364.

There was indeed a fundamental problem with the way dev-only filesystem paths to parent Ivy
modules were being resolved. There was just one Ivy resolver for all possible parents, where
you would add an Ivy pattern to the resolver for each parent. Considering Ivy is doing pattern
matching, the first parent would always be used, and the subsequently added ones would be

Instead of having a single Ivy resolver with multiple Ivy patterns, there should be multiple
Ivy resolvers, each with a single Ivy pattern--one resolver per parent path. I was able to
implement this solution surgically in the XmlModuleDescriptorParser class.

Now instead of a "module-inheritance-repository," there's a moduleInheritanceRepositoryMap
where the key is the parent URL and the value (albeit not used) is the associated resolver.
Since I couldn't store this map in IvySettings, I identified three choices as to where I could
store it:
* As a static field in XmlModuleDescriptorParser. This looked dangerous and appeared to subvert
the purpose of IvyContext.
* As "sticky" objects in the current IvyContext, placed there via IvyContext.push and retrieved
via IvyContext.peek. This solution caused some obscure failures in IvyPublishTest, and I abandoned
* As WeakReference objects in the current IvyContext, placed there via IvyContext.set and
retrieved via IvyContext.get. 

I chose the third approach, with get and set. The only downside to this choice was that I
found intermittent, nondeterministic failures to retrieve the Map object, apparently because
the garbage collector had already gotten to the WeakReference. I was able to adjust for this
by making an extra call to the new configureModuleInheritanceRepositoryMap from checkParentModuleOnFilesystem.

I invite anyone to come up with a better way to store this map.
> ivy:buildlist task confused by extends feature using two parents
> ----------------------------------------------------------------
>                 Key: IVY-1363
>                 URL:
>             Project: Ivy
>          Issue Type: Bug
>          Components: Ant, Core
>    Affects Versions: 2.3.0-RC1
>         Environment: Ant 1.7.1 (but should be the same with Ant 1.8.3)
>            Reporter: Mitch Gitman
>              Labels: testcase
>         Attachments:, ivy-2.3.x.patch, ivy-trunk.patch
> I'm finding that the ivy:buildlist Ant task is erroring when it encounters more than
one parent Ivy module that's pulled in through the /ivy-module/info/extends element. This
problem is new to Ivy 2.3.0-rc1; I did not encounter it with Ivy 2.2.0. There is no relationship
or interaction between the two different parent Ivy modules, i.e. no nesting of parents.
> In my test case, which I explain shortly, when I point the ivy:buildlist Ant task at
a project stack that includes a mix of both parents and their children, I see this error:
> ...\multimodule-build\build.xml:28: impossible to parse ivy file for ...\testTwoParents\germany\build.xml:
ivyfile=...\testTwoParents\germany\ivy.xml exception=java.text.ParseException: Problem occurred
while parsing ivy file: inconsistent module descriptor file found in 'file:/.../testTwoParents/master-parent/ivy.xml':
bad module name: expected='bootstrap-parent' found='master-parent';  in file:/.../testTwoParents/germany/ivy.xml
> What's happening is, the germany module extends bootstrap-parent, but somehow the relative
path to master-parent/ivy.xml is supplanting the relative path to bootstrap-parent/ivy.xml.
It appears buildlist doesn't know how to deal with more than one parent.
> This is what occurs when the haltOnError attribute is set to "true" on ivy:buildlist.
If I set haltOnError="false" in my test case, the exception goes away, but I see the following
build order:
> 1. germany
> 2. ireland
> 3. bootstrap-parent
> 4. master-parent
> 5. croatia
> What's wrong about this build order is that germany depends on ireland and ireland depends
on bootstrap-parent, so the order of the first three entries is reversed. If I removed the
dependency of ireland on bootstrap-parent, the order would be the same. This misordering is
clearly related to the presence of more than one parent because comparable tests using (A)
the extends feature with a single parent and (B) no extends feature at all get the order right.
Plus, I see this unexpected output when haltOnError="false":
> [ivy:buildlist] 	=> adding it at the beginning of the path
> [ivy:buildlist] 	=> adding it at the beginning of the path
> I've attached a ZIP containing three standalone test cases, each consisting of a suite
of Ant projects that together comprise a multimodule build whose build order is to be determined
by the ivy:buildlist task:
> * testNoParents: The extends feature is not used.
> * testOneParent: The extends feature is used to pull in content from a single parent
Ivy module.
> * testTwoParents: The extends feature is used where one Ivy module pulls in content from
one parent and two other Ivy modules pull in content from a different parent.
> The testNoParents and testOneParent tests are the control groups. The testTwoParents
test is where things fail.
> When running Ant from one of these test cases, you need to specify the location of the
Ivy 2.3.0-rc1 installation using one of the following:
> * an IVY_DIR environment variable
> * an env.IVY_DIR user property, i.e. -Denv.IVY_DIR=...
> * an ivy.dir user property, i.e. -Divy.dir=...
> To run the build in any of these suites, go to the multimodule-build directory, and execute
"ant" or "ant init"—while specifying the Ivy installation location. You can also run "ant
cleancache" to clear out the Ivy cache. However, you shouldn't need to do this regularly because
each of these test cases uses its own dedicated Ivy cache.
> NOTE: This issue is broached in the email thread "extends & buildlist on 2.3.0-rc1
… it gets worse" on the ivy-user and ant-dev mailing lists.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message