Re: asm7 preparation

[David Blevins]

> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau  wrote:
> 
> :) as usual with asm, looks ok but breaks several apps ;). But main point is: 
> do we want to export as asm6 the real asm7 and fake the runtime it will work? 
> If we want a smooth upgrade we can update asm6 module to have some of changes 
> but keep asm7 module to ensure we cover it IMHO.

We should definitely not introduce ASM 7 code into our asm6 module.

Another topic is we've been on ASM 6 for 2 years.  Should we change the XBean 
major version to 5 when we switch to ASM 7?

That would give us the option to keep pushing out XBean 4.x releases with 
further ASM 6 updates for those who can't/won't upgrade yet or also have stable 
branches to maintain.

If if we don't change the major version and any critical bugs or security 
vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1.  If that happened a 
few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a 
de facto branch, just after the fact and in a very awkward way.


-David

Re: asm7 preparation

[David Blevins]

> On Sep 30, 2018, at 10:44 AM, Romain Manni-Bucau  
> wrote:
> 
> 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.

Like you I like 4, but 3 is probably the smartest option. I didn't care for 
option 3 when Mark suggested it years ago, but in hindsight it has worked out 
very well.

Truthfully, if the ASM versioned their own packages like that, we wouldn't need 
to shade it all and neither would anyone.


-David

Re: xbean-reflect changes and potential xbean 5?

[David Blevins]

Apparently I have to worry about becoming senile.  I did an svn log and swore I 
didn't see the commit in there.  It's definitely there.  I think my mind has 
been warped by working with Git too long.

Sorry for the noise and thank for the release, sir!


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Oct 1, 2018, at 1:10 PM, Romain Manni-Bucau  wrote:
> 
> Seems the code is still here - see 
> https://github.com/apache/geronimo-xbean/blob/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/PropertyEditorRegistry.java
> 
> Le lun. 1 oct. 2018 22:04, Romain Manni-Bucau  a écrit 
> :
> Hmm, thought i just did what was mentionned in this thread which was not 
> about dropping any code but ensuring static usage was kept only for 
> compatibility and moving to a not leaking impl.
> 
> Do you have a failling test of the missing feature? - feel free to push it 
> with @Ignore ;). I can check tomorrow I think.
> 
> We will release soon the 4.11 with asm7 support - we just need to finish to 
> decide if there is a blocker to do asm7 package or not (another thread on it).
> 
> Le lun. 1 oct. 2018 20:52, David Blevins  a écrit :
> > On Aug 8, 2018, at 6:53 PM, David Blevins  wrote:
> > 
> > I'd love to do a 4.x release of this code.
> 
> Hey Romain, is there any reason you pulled this code out of the XBean 4.10 
> release?  Ideally we discuss these things as a community before tacking 
> action.
> 
> Would you mind if I did a 4.11 with it included?
> 
> 
> 
> -David
> 
> 

Re: xbean-reflect changes and potential xbean 5?

[Romain Manni-Bucau]

Seems the code is still here - see
https://github.com/apache/geronimo-xbean/blob/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/PropertyEditorRegistry.java

Le lun. 1 oct. 2018 22:04, Romain Manni-Bucau  a
écrit :

> Hmm, thought i just did what was mentionned in this thread which was not
> about dropping any code but ensuring static usage was kept only for
> compatibility and moving to a not leaking impl.
>
> Do you have a failling test of the missing feature? - feel free to push it
> with @Ignore ;). I can check tomorrow I think.
>
> We will release soon the 4.11 with asm7 support - we just need to finish
> to decide if there is a blocker to do asm7 package or not (another thread
> on it).
>
> Le lun. 1 oct. 2018 20:52, David Blevins  a
> écrit :
>
>> > On Aug 8, 2018, at 6:53 PM, David Blevins 
>> wrote:
>> >
>> > I'd love to do a 4.x release of this code.
>>
>> Hey Romain, is there any reason you pulled this code out of the XBean
>> 4.10 release?  Ideally we discuss these things as a community before
>> tacking action.
>>
>> Would you mind if I did a 4.11 with it included?
>>
>>
>>
>> -David
>>
>>
>>

Re: xbean-reflect changes and potential xbean 5?

[Romain Manni-Bucau]

Hmm, thought i just did what was mentionned in this thread which was not
about dropping any code but ensuring static usage was kept only for
compatibility and moving to a not leaking impl.

Do you have a failling test of the missing feature? - feel free to push it
with @Ignore ;). I can check tomorrow I think.

We will release soon the 4.11 with asm7 support - we just need to finish to
decide if there is a blocker to do asm7 package or not (another thread on
it).

Le lun. 1 oct. 2018 20:52, David Blevins  a écrit :

> > On Aug 8, 2018, at 6:53 PM, David Blevins 
> wrote:
> >
> > I'd love to do a 4.x release of this code.
>
> Hey Romain, is there any reason you pulled this code out of the XBean 4.10
> release?  Ideally we discuss these things as a community before tacking
> action.
>
> Would you mind if I did a 4.11 with it included?
>
>
>
> -David
>
>
>

Re: xbean-reflect changes and potential xbean 5?

[David Blevins]

> On Aug 8, 2018, at 6:53 PM, David Blevins  wrote:
> 
> I'd love to do a 4.x release of this code.

Hey Romain, is there any reason you pulled this code out of the XBean 4.10 
release?  Ideally we discuss these things as a community before tacking action.

Would you mind if I did a 4.11 with it included?



-David

Re: [VOTE] Release XBean 4.10

[David Blevins]

Never mind.  I missed the result vote which was a separate thread. I'll put a 
4.11 up.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Oct 1, 2018, at 11:37 AM, David Blevins  wrote:
> 
> Can we do a reroll with XBEAN-309 included?  Sans that does anyone mind if I 
> immediately cut the XBean 4.11 now?
> 
> The work has been done for 2 months and I was hoping to get this into a TomEE 
> release soon.  Hopefully TomEE 8 will be cut in the next days.
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins 
> http://www.tomitribe.com
> 
>> On Sep 26, 2018, at 1:11 AM, Romain Manni-Bucau > > wrote:
>> 
>> Hi guys,
>> 
>> XBean got asm upgraded to 6.2.1 which contains some java 11 fixes 
>> (https://issues.apache.org/jira/browse/XBEAN-311 
>> ). Here is the vote to 
>> promote it.
>> 
>> The dist (dev) area is available at 
>> https://dist.apache.org/repos/dist/dev/geronimo/xbean/ 
>>  (rev 29700)
>> The staging repo is: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1070 
>> 
>> Tag is http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.10/ 
>>  (rev 
>> 1842004)
>> My keys is the same as last time (available in 
>> http://svn.apache.org/repos/asf/geronimo/KEYS 
>> )
>> 
>> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog 
>>  | Old Blog 
>>  | Github 
>>  | LinkedIn 
>>  | Book 
>> 

Re: [VOTE] Release XBean 4.10

[David Blevins]

Can we do a reroll with XBEAN-309 included?  Sans that does anyone mind if I 
immediately cut the XBean 4.11 now?

The work has been done for 2 months and I was hoping to get this into a TomEE 
release soon.  Hopefully TomEE 8 will be cut in the next days.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 26, 2018, at 1:11 AM, Romain Manni-Bucau  wrote:
> 
> Hi guys,
> 
> XBean got asm upgraded to 6.2.1 which contains some java 11 fixes 
> (https://issues.apache.org/jira/browse/XBEAN-311 
> ). Here is the vote to 
> promote it.
> 
> The dist (dev) area is available at 
> https://dist.apache.org/repos/dist/dev/geronimo/xbean/ 
>  (rev 29700)
> The staging repo is: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1070 
> 
> Tag is http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.10/ 
>  (rev 
> 1842004)
> My keys is the same as last time (available in 
> http://svn.apache.org/repos/asf/geronimo/KEYS 
> )
> 
> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: asm7 preparation

[Romain Manni-Bucau]

:) as usual with asm, looks ok but breaks several apps ;). But main point
is: do we want to export as asm6 the real asm7 and fake the runtime it will
work? If we want a smooth upgrade we can update asm6 module to have some of
changes but keep asm7 module to ensure we cover it IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 1 oct. 2018 à 16:03, Raymond Auge  a
écrit :

> FYI, here's a diff of the API
>
> https://gist.github.com/rotty3000/a68c8ea494f4c1b2e304822dc8a72a66
>
> It doesn't look that scary tbh. Only couple methods changed which were
> already marked experimental and just normalized into the regular API, same
> for a couple of constants, and one other method removed and exploded into 3.
>
> Hope this helps,
> - Ray
>
> On Mon, Oct 1, 2018 at 9:39 AM Romain Manni-Bucau 
> wrote:
>
>>
>> @Raymond: no worries ->
>> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>> Le lun. 1 oct. 2018 à 15:37, Raymond Auge  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 
>>> wrote:
>>>



 Le lun. 1 oct. 2018 à 14:26, Mark Struberg  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  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 

Re: asm7 preparation

[Raymond Auge]

FYI, here's a diff of the API

https://gist.github.com/rotty3000/a68c8ea494f4c1b2e304822dc8a72a66

It doesn't look that scary tbh. Only couple methods changed which were
already marked experimental and just normalized into the regular API, same
for a couple of constants, and one other method removed and exploded into 3.

Hope this helps,
- Ray

On Mon, Oct 1, 2018 at 9:39 AM Romain Manni-Bucau 
wrote:

>
> @Raymond: no worries ->
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le lun. 1 oct. 2018 à 15:37, Raymond Auge  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 
>> wrote:
>>
>>>
>>>
>>>
>>> Le lun. 1 oct. 2018 à 14:26, Mark Struberg  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  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 

Re: asm7 preparation

[Romain Manni-Bucau]

@Raymond: no worries ->
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 1 oct. 2018 à 15:37, Raymond Auge  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 
> wrote:
>
>>
>>
>>
>> Le lun. 1 oct. 2018 à 14:26, Mark Struberg  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  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é* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: asm7 preparation

[Raymond Auge]

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 
wrote:

>
>
>
> Le lun. 1 oct. 2018 à 14:26, Mark Struberg  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  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é* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: asm7 preparation

[Romain Manni-Bucau]

Le lun. 1 oct. 2018 à 14:26, Mark Struberg  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  >:
> >
> >
> >
> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg  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
> >
>
>

Re: asm7 preparation

[Mark Struberg]

Introducing our own API doesn't make much sense to me. 
The challenges (support for new unknown Java versions) would be exactly the 
same as ASM has.
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.

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.

LieGrue,
strub

> Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau :
> 
> 
> 
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg  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 :
> > 
> > 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
> 

Re: asm7 preparation

[Romain Manni-Bucau]

Le lun. 1 oct. 2018 à 12:39, Mark Struberg  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  >:
> >
> > 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
>
>

Re: [VOTE] Geronimo Validation 2.0 (spec) v1.0

[Ivan Junckes Filho]

+1

On Mon, Oct 1, 2018 at 8:02 AM Roberto Cortez  wrote:

> +1
>
> On 30 Sep 2018, at 16:38, Romain Manni-Bucau 
> wrote:
>
> Hi guys,
>
> To enable BVal and TomEE releases, I'd like to release our validation spec
> bundle.
>
> Here is the staging repo:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1071
> The dist (dev) area is:
> https://dist.apache.org/repos/dist/dev/geronimo/specs/validation/ (rev
> 29801)
> The tag is:
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_2.0_spec-1.0/
> (rev 1842396)
> My key is the same as usual.
>
> Vote will be open for 3 days or until we cancel it or we get 3 +1 binding
> votes.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
>

Re: [VOTE] Geronimo Validation 2.0 (spec) v1.0

[Roberto Cortez]

+1

> On 30 Sep 2018, at 16:38, Romain Manni-Bucau  wrote:
> 
> Hi guys,
> 
> To enable BVal and TomEE releases, I'd like to release our validation spec 
> bundle.
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1071 
> 
> The dist (dev) area is: 
> https://dist.apache.org/repos/dist/dev/geronimo/specs/validation/ 
>  (rev 
> 29801)
> The tag is: 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-validation_2.0_spec-1.0/
>  
> 
>  (rev 1842396)
> My key is the same as usual.
> 
> Vote will be open for 3 days or until we cancel it or we get 3 +1 binding 
> votes.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: asm7 preparation

[Mark Struberg]

We should analyse if ASM7 is a drop-in replacement and can be used in a 
backward compatible way.
If so, then we could keep the shaded o.a.g.asm6 package and just document it.
If ASM7 removed some old methods, then we really should also shade to a private 
asm7 package.

LieGrue,
strub


> Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau :
> 
> 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