Fork is not the right word. Patch maybe, but even that can easily be avoided.
If we had abstraction so there wasn't a hard dependency on "ASM" we could supply our own shaded version, that would be more than enough. -David On Oct 25, 2012, at 11:58 PM, Romain Manni-Bucau <[email protected]> wrote: > If so tomee will fork openjpa to use xbean asm shade... > > Tomee cares about size > Le 26 oct. 2012 00:23, "Kevin Sutter" <[email protected]> a écrit : > >> Hi Mark, >> Yes, Romain raised this point to me on a separate thread. From what I can >> tell TomEE is using OpenJPA 2.2.0. Since your changes for openjpa-2171 >> only went into trunk, I'm wondering where the dependency is being managed. >> So, yes, we do need some input from the TomEE team as to whether this type >> of change would affect them. >> >> Another alternative is to provide a shaded jar that embeds and hides the >> ASM deliverable within the OpenJPA jar. Yes, that jar would grow slightly >> (46K), but then nobody would be wiser as to what version of ASM is being >> used. >> >> Anyway, let's keep the conversation going... Thanks! >> >> Kevin >> >> On Thu, Oct 25, 2012 at 4:22 PM, Mark Struberg <[email protected]> wrote: >> >>> Hi Kevin! >>> >>> We must also make sure to not hit a major incompat with tomee and other >>> systems. >>> I'll ping David and Romain so they can test this a bit. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> ----- Original Message ----- >>>> From: Kevin Sutter <[email protected]> >>>> To: [email protected]; [email protected] >>>> Cc: >>>> Sent: Thursday, October 25, 2012 3:15 PM >>>> Subject: [DISCUSS] Upgrade to use ASM 4 for our post-enhancement >>> processing >>>> >>>> Hi, >>>> Some of you may have noticed a recent JIRA I opened up: >>>> https://issues.apache.org/jira/browse/OPENJPA-2283 >>>> >>>> I created this for upgrading our current usage of ASM 3.2 to ASM 4.0. >>>> OpenJPA uses ASM for some post-enhancement processing to clean up the >>> stack >>>> map tables that are required for Java 7 validation. Since ASM 4 has >> more >>>> complete support for Java 7, I thought it would be an easy, >>>> preventative-care type of move. >>>> >>>> As my JIRA indicates, I have run into a couple of hiccups with this >> move >>>> that I am still working through. >>>> >>>> But, in general, does anybody have a concern with this upgrade? I'm >> only >>>> looking to do trunk at the moment. But, if we continue to hit Java 7 >>>> validation errors in 2.2.x, then I might consider moving it back to >> 2.2.x >>>> as well. >>>> >>>> Thanks for any input, >>>> Kevin >>>> >>> >>
