Camel
  1. Camel
  2. CAMEL-4910

Upgrade saxon version to 9.3.0.11

    Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.10.0
    • Component/s: camel-saxon
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      We need to pick up the saxon 9.3.0.11 with some bug fixing and enhancements.

        Activity

        Hide
        Willem Jiang added a comment -

        Patch was applied by Christian.

        Show
        Willem Jiang added a comment - Patch was applied by Christian.
        Hide
        Raúl Kripalani added a comment -

        The Saxon bundle version in the features.xml is no longer valid. It refers to a SNAPSHOT which has already been released. Kindly apply the attached patch.

        Show
        Raúl Kripalani added a comment - The Saxon bundle version in the features.xml is no longer valid. It refers to a SNAPSHOT which has already been released. Kindly apply the attached patch.
        Hide
        Babak Vahdat added a comment -

        The whole INFRA Jenkins/Maven setup is somehow not much clear to me and we have currently also really wired behaviour on the Window builds as well [1] about which nobody from INFRA could resolve the problem til now.

        What also seems to be really odd to me is that why INFRA makes use of a SNAPSHOT version (1.447-SNAPSHOT) of Jenkins!

        [1] https://issues.apache.org/jira/browse/INFRA-4272

        Show
        Babak Vahdat added a comment - The whole INFRA Jenkins/Maven setup is somehow not much clear to me and we have currently also really wired behaviour on the Window builds as well [1] about which nobody from INFRA could resolve the problem til now. What also seems to be really odd to me is that why INFRA makes use of a SNAPSHOT version (1.447-SNAPSHOT) of Jenkins! [1] https://issues.apache.org/jira/browse/INFRA-4272
        Hide
        Willem Jiang added a comment -

        @Babak,
        There are lots of CI-Servers running in the Apache build fram. I don't think they are sharing the same m2 cache. It will cause lots of problem when different build try to install the same artifacts at the same time.

        Show
        Willem Jiang added a comment - @Babak, There are lots of CI-Servers running in the Apache build fram. I don't think they are sharing the same m2 cache. It will cause lots of problem when different build try to install the same artifacts at the same time.
        Hide
        Babak Vahdat added a comment -

        That's already clear to me

        My concern is the CI-Server itself. I assume the Jenkins builds for all of the Apache projects on the CI-Server use the same m2 cache (maybe somewhere along the path /home/jenkins/.m2/repository). Now:

        And now what I don't get is that if the fulltest run could successfully resolve the saxon9he dependency, how is it possible that the notest run 2.5 hours later could not resolve that anymore, as at that time the saxon9he should have been already available inside the m2 cache of the user "jenkins"!

        Show
        Babak Vahdat added a comment - That's already clear to me My concern is the CI-Server itself . I assume the Jenkins builds for all of the Apache projects on the CI-Server use the same m2 cache (maybe somewhere along the path /home/jenkins/.m2/repository). Now: The newest fulltest run was at Jan 20, 2012 6:01:25 AM: https://builds.apache.org/job/Camel.trunk.fulltest/665/ The newest notest run was at Jan 20, 2012 8:29:25 AM: https://builds.apache.org/job/Camel.trunk.notest/1442/ And now what I don't get is that if the fulltest run could successfully resolve the saxon9he dependency, how is it possible that the notest run 2.5 hours later could not resolve that anymore, as at that time the saxon9he should have been already available inside the m2 cache of the user "jenkins"!
        Hide
        Claus Ibsen added a comment -

        You should try deleting/moving your local m2 repo

        ~/.m2/repository

        So maven will have to download all the JARs again. Then you may see if any JARs is missing

        Show
        Claus Ibsen added a comment - You should try deleting/moving your local m2 repo ~/.m2/repository So maven will have to download all the JARs again. Then you may see if any JARs is missing
        Hide
        Babak Vahdat added a comment - - edited

        But then I don't get it why the newest build [1] of today morning with full test did pass concerning this dependency!

        [1] https://builds.apache.org/job/Camel.trunk.fulltest/665/

        Show
        Babak Vahdat added a comment - - edited But then I don't get it why the newest build [1] of today morning with full test did pass concerning this dependency! [1] https://builds.apache.org/job/Camel.trunk.fulltest/665/
        Hide
        Claus Ibsen added a comment -

        Ah great. There seems to be some examples or whatnot that will fail missing this dep

        See console output from
        https://builds.apache.org/job/Camel.trunk.notest/1442/

        I guess adding that sxm repo will fix that.

        Show
        Claus Ibsen added a comment - Ah great. There seems to be some examples or whatnot that will fail missing this dep See console output from https://builds.apache.org/job/Camel.trunk.notest/1442/ I guess adding that sxm repo will fix that.
        Hide
        Willem Jiang added a comment -
        Show
        Willem Jiang added a comment - The maven repo is here http://svn.apache.org/repos/asf/servicemix/m2-repo
        Hide
        Claus Ibsen added a comment -

        Willem, in which maven repo is saxon9he located?

        The CI servers may not be able to find it, from a clean build with no m2 cache.

        Show
        Claus Ibsen added a comment - Willem, in which maven repo is saxon9he located? The CI servers may not be able to find it, from a clean build with no m2 cache.
        Hide
        Willem Jiang added a comment -

        Applied patch into trunk

        Show
        Willem Jiang added a comment - Applied patch into trunk

          People

          • Assignee:
            Willem Jiang
            Reporter:
            Willem Jiang
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development