• Icon: Sub-task Sub-task
    • Resolution: Done
    • Icon: Major Major
    • 5.3.0.Final
    • None
    • None
    • None
    • False
    • None
    • False
    • Hide
      * *Why we missed the bug?*
       ** Pick to proper answer from drop-down field upper.
       +_Additional comments:_+


       * *What is required:*
       ** Pick to proper answer from drop-down field upper.
       +_Additional comments:_+
      Show
      * *Why we missed the bug?*  ** Pick to proper answer from drop-down field upper.  +_Additional comments:_+  * *What is required:*  ** Pick to proper answer from drop-down field upper.  +_Additional comments:_+
    • ---
    • ---
    • Sprint 217 AMM, AMM Sprint 218, AMM Sprint 219, AMM Sprint 223, AMM Sprint 224, AMM Sprint 225

      When analyzing AdditionWithSecurity-EAR-0.01.ear with a target of jakarta-ee
      There is a known artifact that is getting analyzed despite it being within MTA's lucene index (see the attached).
      https://mvnrepository.com/artifact/net.sf.dozer/dozer/5.3.2

      Extract from the log
      Archive not identified: /home/pcattana/MTA_Output/3Apps530/archives/AdditionWithSecurity-Service-0.01.war/WEB-INF/lib/dozer-5.3.2.jar SHA1: 1e978aa652e7fa9c4e5d9485f32508b63b9599f7

      The hash in the log is different to that on the screenshot. Our lucene index and what is available online are consistent.
      fb10fbcb72f936c1eecb195ba279df4e52bcabb0

      The SHA1 from the log doesn't match any of the sha1 files associated to the dozer 5.3.2 artifact

      sha1sum dozer-5.3.2.jar
      fb10fbcb72f936c1eecb195ba279df4e52bcabb0 dozer-5.3.2.jar

      It appears MTA is generating the wrong hash for the jar file.

              jleflete@redhat.com Juanma Leflet Estrada
              pcattana Philip Cattanach
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: