Since it is really ASM for which we are interested in isolation, I
guess we would take the cglib-nodep jar which 'bundles' ASM as
net.sf.cglib.asm (perhaps via jarjar as well) and run jarjar on that
to repackage net.sf.cglib -> org.hibernate.cglib (or some-such). Is
that your understanding as well?
On May 19, 2008, at 3:45 PM, Max Ross wrote:
jarjar can be a good option when you're looking to avoid version
conflicts. Guice uses this to depend on a specific version of cglib.
On Mon, May 19, 2008 at 1:29 PM, Steve Ebersole
<steve(a)hibernate.org> wrote:
Our (default) dependency on CGLIB is starting to cause problems due
to other libraries using newer versions of ASM (3.x) then the
released versions of CGLIB use (2.x). We have now been waiting
about a year for a new CGLIB release to use these newer ASM APIs.
With 3.3 being eminent, we need to rectify this situation.
First, I am going to make javassist the default bytecode provider
starting with Hibernate 3.3
(
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2506
).
Next, we need to decide what to do with CGLIB moving forward. This
seems to be a dead project at this point. From my recollection, the
source control for CGLIB does in fact have support for ASM 3.x; so
one option would be to do a build of it from HEAD. However, none of
us are really bytecode gurus, so thats probably not the best
option. The only other option I see is to simply deprecate the
integration for CGLIB and recommend against its use. Any other
options we should explore here?
-----------------------------
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
-----------------------------
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org