hk2
  1. hk2
  2. HK2-138

Upgrade asm-all-repackaged dependency

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 2.1.*
    • Fix Version/s: 2.1.*
    • Component/s: None
    • Labels:
      None

      Description

      hk2 depends on asm-all-repackaged-2.2.0-b21.jar.

      It's not clear:

      1. Why you need a repackaged dependency.
      2. Whether you really depend on ASM 2.2.0 when the latest version is 4.0.

      This is a problem because my code depends on Findbugs which depends on ASM 3.3 so now I've got two different versions of ASM in my classpath.

      Please stick to the original artifacts (if possible) and upgrade to the latest version.

        Issue Links

          Activity

          Hide
          jwells added a comment -

          No, OSGi metadata is found in the META-INF/MANIFEST.MF of the jar file. The idea of contributing that metadata to ASM source is a better idea, but would take a little time.

          Show
          jwells added a comment - No, OSGi metadata is found in the META-INF/MANIFEST.MF of the jar file. The idea of contributing that metadata to ASM source is a better idea, but would take a little time.
          Hide
          jwells added a comment -

          So, I just looked at ASM jars for the 5.0-BETA and 4.2 releases, and they already have OSGi metadata. So now I'm wondering if we in fact CAN just use the raw artifacts.

          I'll check into this in the morning, we have a request to increase the ASM version to something that can handle JDK 8 features anyway.

          Show
          jwells added a comment - So, I just looked at ASM jars for the 5.0-BETA and 4.2 releases, and they already have OSGi metadata. So now I'm wondering if we in fact CAN just use the raw artifacts. I'll check into this in the morning, we have a request to increase the ASM version to something that can handle JDK 8 features anyway.
          Hide
          Romain Grécourt added a comment -

          3rd party library should be repackaged and published under "org.glassfish.external".
          That gives us some flexibility, since it's not under our control, and some visibility regarding the 3rd party dependencies.

          Also, note we isolate some glassfish libraries from the application classloaders using password=glassfish (OSGi metadata).
          Using a raw bundle would remove that ability.

          Show
          Romain Grécourt added a comment - 3rd party library should be repackaged and published under "org.glassfish.external". That gives us some flexibility, since it's not under our control, and some visibility regarding the 3rd party dependencies. Also, note we isolate some glassfish libraries from the application classloaders using password=glassfish (OSGi metadata). Using a raw bundle would remove that ability.
          Hide
          cowwoc added a comment -

          Romain,

          I don't mean to sound harsh but but this sounds like a very weak reason to repackage the official artifacts. Repackaging the same library under a different package name without substantial modification to the library sounds like bloat.

          Anyway, if you repackage the dependency into a different package name at least it won't interfere with application dependencies.

          BTW, if ASM is repackaged on behalf of Glassfish, why does hk2 depend on a Glassfish dependency? What does hk2 have to do with Glassfish?

          Show
          cowwoc added a comment - Romain, I don't mean to sound harsh but but this sounds like a very weak reason to repackage the official artifacts. Repackaging the same library under a different package name without substantial modification to the library sounds like bloat. Anyway, if you repackage the dependency into a different package name at least it won't interfere with application dependencies. BTW, if ASM is repackaged on behalf of Glassfish, why does hk2 depend on a Glassfish dependency? What does hk2 have to do with Glassfish?
          Hide
          Romain Grécourt added a comment -

          We don't alter the code, this is for manifest (OSGi) and JavaEE licensing reason.
          HK2 is a GF subproject, thus, its 3rd party dependencies are approved together with GF.

          HK2 could depend on the original artifact though.

          Show
          Romain Grécourt added a comment - We don't alter the code, this is for manifest (OSGi) and JavaEE licensing reason. HK2 is a GF subproject, thus, its 3rd party dependencies are approved together with GF. HK2 could depend on the original artifact though.

            People

            • Assignee:
              jwells
              Reporter:
              cowwoc
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: