Details
-
Improvement
-
Status: Closed
-
Blocker
-
Resolution: Duplicate
-
1.3.0, 1.4.0
-
None
-
None
Description
We are now using asm to create our own proxies - with 1.3.0 that was added to the partial bean module - now We replace the optional proxies created in the JSF module for converters/validators with the same approach -> the proxy code was moved to ds-core. that works but isn't nice and not that flexible -> the goal is an own module "side by side" with core and all modules which need proxy stuff have core and that new proxy module as dep. (currently the partial-bean and JSF module).It allows to support different versions of asm once it's needed... (e.g. for diff. versions of java if the latest version drops e.g. backward compat. to and old version...) It's already discussed and agreed on the dev list so you can just create a ticket and just move the code + update the release poms so that the new module is part of the release as well...
The new module should be called proxy-utils. GAV: org.apache.deltaspike.modules:deltaspike-proxy-module-api
don't move org.apache.deltaspike.core.util.ProxyUtils - because it doesn't depend on asm and is valid for any proxy (weld-proxy, owb-proxy, javassist-proxy,...) We support at all + it's needed a lot in ds-core. If you would move it ds-core would depend on the proxy-module (which shouldn't be the case).
The goal is really that the proxy-module is just needed once you need the partial-bean module and/or the optional proxies in the JSF module so the proxy-module needs to be an optional dep. of the JSF module... but in case of the partial-bean module the proxy-api module is a compile dep. since it's required anyway
That's currently the release blocker, because now ds-core has a dependency to a fixed version of asm and so far Core didn't introduce a 3rd party dep. So We need to move to the new module before the next release...