Sorry for the newbie interruption. But can someone point me to the relevant code/project/module in Geronimo that has this asm integration?
Thanks, - Ray On Mon, Oct 1, 2018 at 8:30 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > > > Le lun. 1 oct. 2018 à 14:26, Mark Struberg <strub...@yahoo.de> a écrit : > >> Introducing our own API doesn't make much sense to me. >> > > Agree cause it is not just an xbean internal > > >> The challenges (support for new unknown Java versions) would be exactly >> the same as ASM has. >> > > It wouldn't if we would be in asm scope cause we would use a very limited > set of asm features. We are kind in a situation where we use 10% of the > features and expose 100% by construction :(. > > >> So we would in the end also be forced to break the API :( >> Remember that the main reason we created the whole shading for is to >> allow to upgrade parts of the stack without interfering with a.) some >> custom apps and b.) each other. >> > > Agree. > > >> >> Right now you can just swap out openjpa in TomEE for example. All you >> need to do is to _potentially_ also add another xbean-asm version. >> And that is good that way imo. >> > > Ok so you confirm keeping the pattern we use (ie going with asm7) is ok > for you? > > FYI the diff: > https://gitlab.ow2.org/asm/asm/compare/ASM_6_2_1...ASM_7_0_BETA > But some impl changes are not just fixes and even if signatures don't > always change I think it is sane to not put a v7 in an asm6 package/module > - same as for java 8 upgrade where the verifier was stricter. > > >> >> LieGrue, >> strub >> >> > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau < >> rmannibu...@gmail.com>: >> > >> > >> > >> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <strub...@yahoo.de> a écrit >> : >> > We should analyse if ASM7 is a drop-in replacement and can be used in a >> backward compatible way. >> > >> > Didn't review everything but there are some changes in the impl which >> are not compatible and why we must upgrade even if asm 6.2.1 had some good >> java 11 support. >> > >> > If so, then we could keep the shaded o.a.g.asm6 package and just >> document it. >> > >> > I thought about it but it sounds so dangerous and hard to control on >> the long run than upgrading all our stack sounds worth it for me. >> > >> > If ASM7 removed some old methods, then we really should also shade to a >> private asm7 package. >> > >> > This lead to the option to not expose ASM at all and create our own API >> but it breaks the reason why all our stack uses this shade: have a fully >> featured ASM usable by proxying impl of the full stack >> > and share it with the scanner. This is why I thought we can't really >> fake the package without serious risk, we expose a too big coverage now >> (cxf, openjpa, xbean, big data engines, user apps, ...). >> > >> > >> > LieGrue, >> > strub >> > >> > >> > > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau < >> rmannibu...@gmail.com>: >> > > >> > > Hi guys, >> > > >> > > Asm 7 beta was released yesterday, I'd like to try to release it ASAP. >> > > I see 1 main point to discuss before releasing: do we keep the >> version in the package and module name? For now it is required cause we >> cant guarantee anything about asm compatibility. >> > > >> > > Options I see are: >> > > 1. drop asm and use bcel (which is asf) >> > > 2. drop asm and reimplement bytecode parsing for our need (but will >> create issue in most of our stack for proxy creation IMHO) >> > > 3. keep it like that >> > > 4. use an "asm.*" package crossing fingers >> > > >> > > I'd love 4 but I fear it can create issue quickly when I see what >> java is becoming so, personally, i think 3 is safe but since we are at >> "that" moment I'd like to get your feedback. >> > > >> > > Side note: if I get no other vote than 3 before tuesday, i'll try to >> launch the release on tuesday with asm7 module and package to let us get it >> out. >> > > >> > > Romain Manni-Bucau >> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >> > >> >> -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
