[
https://issues.apache.org/jira/browse/IVY-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13431899#comment-13431899
]
Mitch Gitman commented on IVY-1363:
-----------------------------------
The attached patch contains changes to two Java classes:
XmlModuleDescriptorParser, IvySettings.
Fixing some breakage that was introduced with Jean-Louis's recent modification
to the patch I had submitted to fix three bugs with the parent feature (via the
ivy.xml extends element). The modification, as committed to Ivy trunk, was to
no longer keep a special map in the IvyContext to find the special filesystem
resolver for each unpublished parent ivy.xml; instead we can find each parent
resolver by name from the map of resolvers belonging to the IvySettings. If
XmlModuleDescriptorParser can't find the resolver there, it can add it.
The problem was that XmlModuleDescriptorParser was calling
IvySettings.getResolver(String resolverName), and this method logs an error if
the resolver can't be found. However, there's nothing erroneous about the
situation of looking up a parent resolver and then creating one if it's not
there. Reporting errors where there are no errors is itself a bug.
Below is the error output I was seeing (and in Eclipse seeing in red):
[ivy:resolve] :::: ERRORS
[ivy:resolve] unknown resolver
module-inheritance-repository-com.uefa#bootstrap-parent;1.0
Now, to check for the existence of the particular parent resolver (in the above
case module-inheritance-repository-com.uefa#bootstrap-parent;1.0)
XmlModuleDescriptorParser is using a new method in IvySettings,
hasResolver(String resolverName).
In addition, getting rid of an entire method in XmlModuleDescriptorParser that
is superfluous now that every different parent must have its own resolver. That
method is configureModuleInheritanceRepository(). This was creating a resolver
called simply "module-inheritance-repository", but this single resolver for all
parents is no longer used.
NOTE: This change needs to be applied to the ivy-2.3.x branch as well as trunk,
considering that it fixes breaking bugs in existing features.
> 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
> Assignee: Nicolas Lalevée
> Labels: patch, testcase
> Fix For: trunk
>
> Attachments: BuildlistAndExtendsIntegrationTest.zip,
> IVY-1359-1363-1364-2.3.x.patch, 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
> 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
