[
https://issues.apache.org/jira/browse/IVY-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408990#comment-13408990
]
Mitch Gitman commented on IVY-1363:
-----------------------------------
I saw the preceding comment by Eyad Ebrahim and decided to build the latest Ivy
and try for myself. Having done so, I can say with confidence that Mr. Ebrahim
is witnessing an "It works on my box" situation and this bug is not fixed.
A few days ago I synced up with the Ivy 2.3.x branch and built that. Here's the
output I got with haltOnError="false" on ivy:buildlist:
-init.buildlist:
[ivy:buildlist] :: Apache Ivy 2.3.0-rc1-dev-20120704194824 - 20120704194824 ::
http://ant.apache.org/ivy/ ::
[ivy:buildlist] :: loading settings :: file = ...\ivysettings-multimodule.xml
[ivy:buildlist] => adding it at the beginning of the path
[ivy:buildlist] => adding it at the beginning of the path
[echo] Multimodule build order:
germany\build.xml
ireland\build.xml
bootstrap-parent\build.xml
master-parent\build.xml
croatia\build.xml
Same botched order. Same strange message: => adding it at the beginning of the
path
So then I synced up with the Ivy trunk and built that. Here's the output I got
with that with haltOnError="false":
-init.buildlist:
[ivy:buildlist] :: Apache Ivy 2.4.0-dev-20120706211638 - 20120706211638 ::
http://ant.apache.org/ivy/ ::
[ivy:buildlist] :: loading settings :: file = ...\ivysettings-multimodule.xml
[ivy:buildlist] => adding it at the beginning of the path
[ivy:buildlist] => adding it at the beginning of the path
[echo] Multimodule build order:
germany\build.xml
ireland\build.xml
bootstrap-parent\build.xml
master-parent\build.xml
croatia\build.xml
Precisely the same symptoms.
Finally, I tried ivy:buildlist haltOnError="true" with my Ivy 2.3.x build. As
expected, it failed:
-init.buildlist:
[ivy:buildlist] :: Apache Ivy 2.3.0-rc1-dev-20120704194824 - 20120704194824 ::
http://ant.apache.org/ivy/ ::
[ivy:buildlist] :: loading settings :: file =
multimodule-build\ivysettings-multimodule.xml
multimodule-build\build.xml:28: impossible to parse ivy file for
germany\build.xml: ivyfile=germany\ivy.xml exception=java.text.ParseException:
Problem occurred while parsing ivy file: inconsistent module descriptor file
found in 'file:/master-parent/ivy.xml': bad module name:
expected='bootstrap-parent' found='master-parent'; in file:/germany/ivy.xml
at org.apache.ivy.ant.IvyBuildList.doExecute(IvyBuildList.java:215)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
...
Caused by: java.text.ParseException: Problem occurred while parsing ivy file:
inconsistent module descriptor file found in 'file:/master-parent/ivy.xml': bad
module name: expected='bootstrap-parent' found='master-parent'; in
file:/germany/ivy.xml
at
org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parse(XmlModuleDescriptorParser.java:301)
...
Caused by: org.xml.sax.SAXException: Problem occurred while parsing ivy file:
inconsistent module descriptor file found in 'file:/master-parent/ivy.xml': bad
module name: expected='bootstrap-parent' found='master-parent';
java.text.ParseException: inconsistent module descriptor file found in
'file:/master-parent/ivy.xml': bad module name: expected='bootstrap-parent'
found='master-parent';
at
org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:386)
...
Caused by: java.text.ParseException: inconsistent module descriptor file found
in 'file:/master-parent/ivy.xml': bad module name: expected='bootstrap-parent'
found='master-parent';
...
So the problem evinces itself precisely the same way in the 2.3.0-rc1 release
as well as the 2.3.x branch and trunk.
I wouldn't be surprised if this is somehow related to the following two other
bugs I've recently reported:
https://issues.apache.org/jira/browse/IVY-1359
https://issues.apache.org/jira/browse/IVY-1364
> 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
> Labels: testcase
> 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
