Mitch Gitman created IVY-1363:
---------------------------------
Summary: ivy:buildlist task confused by extends feature using two
parents
Key: IVY-1363
URL: https://issues.apache.org/jira/browse/IVY-1363
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
Attachments: BuildlistAndExtendsIntegrationTest.zip
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
TEST CASE INSTRUCTIONS:
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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
