Lucene - Core
  1. Lucene - Core
  2. LUCENE-4059

prepare-webpages breaks the build if there are none URI complement characters in the path

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0-ALPHA
    • Fix Version/s: 4.0-ALPHA
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      Patch Available

      Description

      Hi all my build environment is a little weird for legacy reasons, one of these is that checkouts from version control for my build server have {} in the path.

      This causes the process-webapps target to fail since XSL rejects none URI characters.

      I have a patch that fixes this by escaping the paths first

        Activity

        Hide
        Greg Bowyer added a comment -

        Escape URI paths for XSL

        Show
        Greg Bowyer added a comment - Escape URI paths for XSL
        Hide
        Uwe Schindler added a comment -

        I don't understand the problem, can you provide your build.xml? If you changed the Lucene-provided build files, this is not an issue, because those always build out of the box. If XSL does not like your own and modified build files, they are invalid XML, so fix those. The attached patch seems to work only around your invalid XML.

        Show
        Uwe Schindler added a comment - I don't understand the problem, can you provide your build.xml? If you changed the Lucene-provided build files, this is not an issue, because those always build out of the box. If XSL does not like your own and modified build files, they are invalid XML, so fix those. The attached patch seems to work only around your invalid XML.
        Hide
        Greg Bowyer added a comment - - edited

        My build.xml is the same as upstream, the problem is my checkout path looks like this

        /home/buildserver/workspace/builds/

        {search-engineering}-solr-lucene-{trunk}

        This means that the prepare-webpages target gets its paths in the buildpaths variable as a pipe separated list like so

        /home/buildserver/workspace/builds/{search-engineering}

        solr-lucene

        {trunk}/lucene/analysis/common/build.xml|/home/buildserver/workspace/builds/{search-engineering}-solr-lucene-{trunk}

        /lucene/analysis/icu/build.xml|...(and so on)

        XSLT picks this up later and tries to load these paths, however XSLT assumes that they are URLS which makes the { character invalid and causes

        com.sun.org.apache.xalan.internal.xsltc.TransletException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.URI$MalformedURIException: Path contains invalid character: {

        This pattern is infrastructural to where I work and is not likely to change (I would like it too)

        Not sure if that makes sense

        Show
        Greg Bowyer added a comment - - edited My build.xml is the same as upstream, the problem is my checkout path looks like this /home/buildserver/workspace/builds/ {search-engineering}-solr-lucene-{trunk} This means that the prepare-webpages target gets its paths in the buildpaths variable as a pipe separated list like so /home/buildserver/workspace/builds/{search-engineering} solr-lucene {trunk}/lucene/analysis/common/build.xml|/home/buildserver/workspace/builds/{search-engineering}-solr-lucene-{trunk} /lucene/analysis/icu/build.xml|...(and so on) XSLT picks this up later and tries to load these paths, however XSLT assumes that they are URLS which makes the { character invalid and causes com.sun.org.apache.xalan.internal.xsltc.TransletException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.URI$MalformedURIException: Path contains invalid character: { This pattern is infrastructural to where I work and is not likely to change (I would like it too) Not sure if that makes sense
        Hide
        Uwe Schindler added a comment -

        Hi,

        that makes sense, thanks for reporting this! I will fix this, thanks for the nice workaround patch.

        Show
        Uwe Schindler added a comment - Hi, that makes sense, thanks for reporting this! I will fix this, thanks for the nice workaround patch.
        Hide
        Uwe Schindler added a comment -

        Hi, new and improved ("more correct") patch: On my windows machine your patch broke because of the backslashes. The most correct way to do this by creating a "real" file based URI. This can be done with the Java API (new File(source) -> toURI()). This creates a 100% correct file:// URI as XSL expects (XSL wants URIs, but most interpreters like XALAN also allow file names, but using file:-URIs is more correct and straight-forward).

        I will commit this now, thanks for reporting!

        Show
        Uwe Schindler added a comment - Hi, new and improved ("more correct") patch: On my windows machine your patch broke because of the backslashes. The most correct way to do this by creating a "real" file based URI. This can be done with the Java API (new File(source) -> toURI()). This creates a 100% correct file:// URI as XSL expects (XSL wants URIs, but most interpreters like XALAN also allow file names, but using file:-URIs is more correct and straight-forward). I will commit this now, thanks for reporting!
        Hide
        Uwe Schindler added a comment -

        Committed rev 1339097. Thanks Greg!

        Show
        Uwe Schindler added a comment - Committed rev 1339097. Thanks Greg!

          People

          • Assignee:
            Uwe Schindler
            Reporter:
            Greg Bowyer
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development