@Raymond: no worries -> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 1 oct. 2018 à 15:37, Raymond Auge <[email protected]> a écrit : > 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 <[email protected]> > wrote: > >> >> >> >> Le lun. 1 oct. 2018 à 14:26, Mark Struberg <[email protected]> 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 < >>> [email protected]>: >>> > >>> > >>> > >>> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[email protected]> 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 < >>> [email protected]>: >>> > > >>> > > 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) >
