Upgrade asm-all-repackaged dependency

[glassfishrobot]

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.

Affected Versions

[2.1.*]

[glassfishrobot]

Reported by cowwoc

[glassfishrobot]

Issue-Links:
duplicates
HK2-136
is duplicated by
HK2-140

[glassfishrobot]

@romain-grecourt said:
This is repackaged as an OSGi bundle for integration in GlassFish (the module should be actually moved to https://svn.java.net/svn/glassfish~svn/trunk/external/repackaged).
Upgrading this bundle may impact more than just HK2.

Have you tried to exclude the asm-repackaged dependency ?

[glassfishrobot]

@jwells131313 said:
I'm not sure the module should be removed since hk2 needs asm as an OSGi bundle. So wouldn't moving it into glassfish cause a dependency cycle? If you mean it should move there logically then I'm with you. Or if there is a separate project just to turn non-OSGi subsystems into OSGi bundles that both hk2 and glassfish can depend on then I'm with you

[glassfishrobot]

cowwoc said:
I'm not familiar with OSGi so please enlighten me: why can't you depend on the existing Maven artifacts for ASM? If the official artifacts are missing OSGi metadata, why don't you send in a patch and ask the guys to integrate it into the official release?

[glassfishrobot]

@romain-grecourt said:
John: This is related to https://java.net/jira/browse/GLASSFISH-20838. HK2 would depend on an artifact released independently of GF, following proper version schema etc... BTW, we should do the same for cglib.

cowwoc: we need some custom OSGi metadata for GF.

[glassfishrobot]

cowwoc said:
Romain,

Can you create an artifact that containing nothing but the OSGi metadata, and have that depend on the official artifacts?

[glassfishrobot]

@jwells131313 said:
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.

[glassfishrobot]

@jwells131313 said:
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.

[glassfishrobot]

@romain-grecourt said:
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.

[glassfishrobot]

cowwoc said:
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?

[glassfishrobot]

@romain-grecourt said:
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.

[glassfishrobot]

Marked as duplicate on Friday, December 6th 2013, 4:27:07 am

[glassfishrobot]

This issue was imported from java.net JIRA HK2-138