Ivy
  1. Ivy
  2. IVY-1457

XmlModuleDescriptorWritter doesn't support fully extra infos elements

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.0
    • Fix Version/s: 2.4.0-RC1
    • Component/s: Core
    • Labels:
      None

      Description

      Ivy supports a way to add your own elements into extends tag.
      Exemple :

      <info organisation="org.apache.easyant" module="standard-java-app" revision="0.1" status="integration" >
              <ea:build organisation="org.apache.easyant.buildtypes" module="build-std-java" revision="0.9">
                  <ea:property name="run.main.classname" value="org.apache.easyant.example.Example"/>
                  <ea:plugin organisation="org.apache.easyant.plugins" module="run-java" revision="0.9" />
              </ea:build>
          </info>
      

      After invoking XmlModuleDescriptorWritter.write()
      We get the following :

      <info organisation="org.apache.easyant"
                      module="standard-java-app"
                      revision="0.1"
                      status="integration"
                      publication="20131231193827"
              >
                    <ea:property>
                  </ea:property>
              </info>
      

      We can notice a few things :

      • <ea:plugin> element is missing
      • <ea:build> element is missing
      • wrong identation on ending <ea:property> (probably due to nested elements)
      • attributes from <ea:property> gets wiped

      Here is the code form XmlModuleDescriptorParser.endElement() method :

      else if (state == State.EXTRA_INFO) {
                      getMd().addExtraInfo(qName, buffer == null ? "" : buffer.toString());
                      buffer = null;
                      state = State.INFO;
                  } 
      

      Unfortunatly buffer doesn't contains attributes and doesn't seems to handle nested element.

      Here is the code writting extra infos elements from XmlModuleDescriptorWritter :

                  for (Iterator it = md.getExtraInfo().entrySet().iterator(); it.hasNext();) {
                      Map.Entry extraDescr = (Map.Entry) it.next();
                      if (extraDescr.getValue() == null 
                              || ((String) extraDescr.getValue()).length() == 0) {
                          continue;
                      }
                      out.print("\t\t<");
                      out.print(extraDescr.getKey());
                      out.print(">");
                      out.print(XMLHelper.escape((String) extraDescr.getValue()));
                      out.print("</");
                      out.print(extraDescr.getKey());
                      out.println(">");
                  }
      

      Still no attributes support and all "contents" will be escaped.

      I don't know how much this feature is used by the community but fixing this bug could break backward compatibility.

        Issue Links

          Activity

          Hide
          Jean-Louis Boudart added a comment -

          fix on trunk r1557557

          ModuleDescriptor.getExtraInfo() is now deprecated as name of the tag was used as key. Tag name can't be used as a key as extra info elements can be non unique.

          Show
          Jean-Louis Boudart added a comment - fix on trunk r1557557 ModuleDescriptor.getExtraInfo() is now deprecated as name of the tag was used as key. Tag name can't be used as a key as extra info elements can be non unique.
          Hide
          Shikhar Bhushan added a comment -

          Hi Jean-Louis Boudart,

          Following up from IVY-1465

          I'm seeing resolve fails with this patch. I am certain that there was a regression in this particular change after running git bisect. After reverting it, resolve works fine.

          While it was difficult for me to setup a reproducible test environment for this, maybe you have some idea about what could be broken based on my description:
          -> we have a multi-module build with inter-module dependencies on "latest.integration"
          -> we use a parent ivy file, that defines <info organisation="org.example" module="parent-ivy"/> – we aren't really using the extra infos stuff that this patch was about
          -> we are fetching deps from an internal m2compatible repository (Archiva)
          -> seeing resolution fails on certain dependencies ("org.apache.solr" "solr-core" "4.7.1") – fwiw this particular project makes use of grandparent POM's
          -> when resolve fails, it looks like this: https://issues.apache.org/jira/browse/IVY-1465?focusedCommentId=13973308&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13973308 – for some reason it determines the revision as "working@machine.name"

          Show
          Shikhar Bhushan added a comment - Hi Jean-Louis Boudart , Following up from IVY-1465 I'm seeing resolve fails with this patch. I am certain that there was a regression in this particular change after running git bisect. After reverting it, resolve works fine. While it was difficult for me to setup a reproducible test environment for this, maybe you have some idea about what could be broken based on my description: -> we have a multi-module build with inter-module dependencies on "latest.integration" -> we use a parent ivy file, that defines <info organisation="org.example" module="parent-ivy"/> – we aren't really using the extra infos stuff that this patch was about -> we are fetching deps from an internal m2compatible repository (Archiva) -> seeing resolution fails on certain dependencies ("org.apache.solr" "solr-core" "4.7.1") – fwiw this particular project makes use of grandparent POM's -> when resolve fails, it looks like this: https://issues.apache.org/jira/browse/IVY-1465?focusedCommentId=13973308&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13973308 – for some reason it determines the revision as "working@machine.name"
          Hide
          Jean-Louis Boudart added a comment -

          Thanks for reporting this, i think i found the bug i'll provide a patch tonight.

          Show
          Jean-Louis Boudart added a comment - Thanks for reporting this, i think i found the bug i'll provide a patch tonight.
          Hide
          Shikhar Bhushan added a comment -

          Hi Jean, any update? IVY-1467 seems to be same issue and has an isolated project for reproducing. I can also try out any fix.

          Show
          Shikhar Bhushan added a comment - Hi Jean, any update? IVY-1467 seems to be same issue and has an isolated project for reproducing. I can also try out any fix.
          Hide
          Jean-Louis Boudart added a comment - - edited

          Hi, sorry for the delay a test was harder to fix than i thought.

          I've just commited a fix (r1592624 on trunk). Ivy uses extra infos elements internally to handle dependency management / plugins etc. So my original change has broken a few things.
          Everything should be ok now, a few methods as been marked deprecated, and ivy uses new ones internally.

          I also added a few missing tests on this side (parsing maven artifacts with parent / dependency management and see how ivy store this in his cache).

          Could you give a try with a nightly build and give us a feedback ?

          Show
          Jean-Louis Boudart added a comment - - edited Hi, sorry for the delay a test was harder to fix than i thought. I've just commited a fix (r1592624 on trunk). Ivy uses extra infos elements internally to handle dependency management / plugins etc. So my original change has broken a few things. Everything should be ok now, a few methods as been marked deprecated, and ivy uses new ones internally. I also added a few missing tests on this side (parsing maven artifacts with parent / dependency management and see how ivy store this in his cache). Could you give a try with a nightly build and give us a feedback ?
          Hide
          Shikhar Bhushan added a comment -

          Jean-Louis Boudart I just tried trunk and no resolve failures, so looks like your fix works

          Show
          Shikhar Bhushan added a comment - Jean-Louis Boudart I just tried trunk and no resolve failures, so looks like your fix works
          Hide
          Shikhar Bhushan added a comment -

          Ulrike M has also confirmed this is working, in IVY-1467

          Show
          Shikhar Bhushan added a comment - Ulrike M has also confirmed this is working, in IVY-1467

            People

            • Assignee:
              Unassigned
              Reporter:
              Jean-Louis Boudart
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development