Quantcast

The CGLIB issue or how transitive dependencies break an application

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The CGLIB issue or how transitive dependencies break an application

Jörg Schaible-2
Hello folks,

first let me describe the scenario: CGLIB is used in a wide range of product as well as ASM. CGLIB itself is based on parts of ASM. CGLIB 1.x is dependent on ASM 1.x, but it provided also a cglib-full artifact, that contained the used sources from ASM 1.x. Therefore there are quite some projects (e.g. jmock-cglib), that depends on cglib-full.

Major headache started, when ASM 2.x was released, since it is neither compatible to ASM 1.x nor you can use both ASM versions in the classpath. New CGLIB 2.x is still dependent on ASM 1.x, but they provide now a new artifact cglib-nodep 2.x, that contains again the necessary ASM 1.x classes, but they are located in a different package.  This allows a coexistence of CGLIB and the new ASM version in one classpath.

The current problem with the transient dependencies are projects, with (transitive) dependencies on cglib-full-1.x and asm-2.x (like Groovy or some artifacts of NanoContainer). cglib-nodep-2.x is a compatible replacement for cglib-full-1.x, but I find no way to specify this anywhere.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The CGLIB issue or how transitive dependencies break an application

Brett Porter
This is a feature we have marked for 2.1 already. In the mean time,
you need to do some surgery on your dependency tree, excluding the
ones you don't want.

- Brett

On 11/14/05, Jörg Schaible <[hidden email]> wrote:

> Hello folks,
>
> first let me describe the scenario: CGLIB is used in a wide range of product as well as ASM. CGLIB itself is based on parts of ASM. CGLIB 1.x is dependent on ASM 1.x, but it provided also a cglib-full artifact, that contained the used sources from ASM 1.x. Therefore there are quite some projects (e.g. jmock-cglib), that depends on cglib-full.
>
> Major headache started, when ASM 2.x was released, since it is neither compatible to ASM 1.x nor you can use both ASM versions in the classpath. New CGLIB 2.x is still dependent on ASM 1.x, but they provide now a new artifact cglib-nodep 2.x, that contains again the necessary ASM 1.x classes, but they are located in a different package.  This allows a coexistence of CGLIB and the new ASM version in one classpath.
>
> The current problem with the transient dependencies are projects, with (transitive) dependencies on cglib-full-1.x and asm-2.x (like Groovy or some artifacts of NanoContainer). cglib-nodep-2.x is a compatible replacement for cglib-full-1.x, but I find no way to specify this anywhere.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The CGLIB issue or how transitive dependencies break an application

Stephen Duncan Jr
As long as you're ok with downloading it (i.e. it's in the
repository), wouldn't the easiest thing to do be to depend directly on
CGLIB 1.x, but with <scope>provided</scope>?  It's even almost
semantically accurate, CGLIB 1.x functionality is provided by another
dependency: cglib-nodep-2.x

-Stephen

On 11/14/05, Brett Porter <[hidden email]> wrote:

> This is a feature we have marked for 2.1 already. In the mean time,
> you need to do some surgery on your dependency tree, excluding the
> ones you don't want.
>
> - Brett
>
> On 11/14/05, Jörg Schaible <[hidden email]> wrote:
> > Hello folks,
> >
> > first let me describe the scenario: CGLIB is used in a wide range of product as well as ASM. CGLIB itself is based on parts of ASM. CGLIB 1.x is dependent on ASM 1.x, but it provided also a cglib-full artifact, that contained the used sources from ASM 1.x. Therefore there are quite some projects (e.g. jmock-cglib), that depends on cglib-full.
> >
> > Major headache started, when ASM 2.x was released, since it is neither compatible to ASM 1.x nor you can use both ASM versions in the classpath. New CGLIB 2.x is still dependent on ASM 1.x, but they provide now a new artifact cglib-nodep 2.x, that contains again the necessary ASM 1.x classes, but they are located in a different package.  This allows a coexistence of CGLIB and the new ASM version in one classpath.
> >
> > The current problem with the transient dependencies are projects, with (transitive) dependencies on cglib-full-1.x and asm-2.x (like Groovy or some artifacts of NanoContainer). cglib-nodep-2.x is a compatible replacement for cglib-full-1.x, but I find no way to specify this anywhere.
> >
> > - Jörg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Stephen Duncan Jr
www.stephenduncanjr.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: The CGLIB issue or how transitive dependencies break an application

Jörg Schaible-2
In reply to this post by Jörg Schaible-2
Brett Porter wrote on Monday, November 14, 2005 1:02 PM:

> This is a feature we have marked for 2.1 already. In the mean
> time, you need to do some surgery on your dependency tree,
> excluding the ones you don't want.

Is there a JIRA issue already for this? http://jira.codehaus.org/browse/MNG-177 seems to match the requirement ...

- Jörg

>
> - Brett
>
> On 11/14/05, Jörg Schaible <[hidden email]> wrote:
>> Hello folks,
>>
[snip]

>>
>> The current problem with the transient dependencies are projects,
>> with (transitive) dependencies on cglib-full-1.x and asm-2.x (like
>> Groovy or some artifacts of NanoContainer). cglib-nodep-2.x is a
>> compatible replacement for cglib-full-1.x, but I find no way to
>> specify this anywhere.
>>
>> - Jörg
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The CGLIB issue or how transitive dependencies break an application

Brett Porter
That's the one.



On 11/15/05, Jörg Schaible <[hidden email]> wrote:

> Brett Porter wrote on Monday, November 14, 2005 1:02 PM:
>
> > This is a feature we have marked for 2.1 already. In the mean
> > time, you need to do some surgery on your dependency tree,
> > excluding the ones you don't want.
>
> Is there a JIRA issue already for this? http://jira.codehaus.org/browse/MNG-177 seems to match the requirement ...
>
> - Jörg
>
> >
> > - Brett
> >
> > On 11/14/05, Jörg Schaible <[hidden email]> wrote:
> >> Hello folks,
> >>
> [snip]
> >>
> >> The current problem with the transient dependencies are projects,
> >> with (transitive) dependencies on cglib-full-1.x and asm-2.x (like
> >> Groovy or some artifacts of NanoContainer). cglib-nodep-2.x is a
> >> compatible replacement for cglib-full-1.x, but I find no way to
> >> specify this anywhere.
> >>
> >> - Jörg
> >>
> >>
> > ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...