Re: Runtime dependencies for our released artifacts

[Joe Bohn <jo...@gmail.com>]

In discussion below regarding cglib .... was the intent to completely 
remove the use of cglib or just make it optional?

 From what I can tell it seems that cglib is already optional (perhaps 
due to changes after this discussion).  But we still use it if available 
in Blueprint AbstractServiceReference and the Blueprint Interceptor 
logic.  If we completely remove it from the Blueprint Interceptor logic 
we would always assume ASM.  If we completely remove it from 
AbstractServiceReference we would always use the JdkProxy and would 
likewise need to remove the AbstractServiceReferenceTest which seems to 
be cglib specific.

I have some local changes that I can check in to completely remove cglib 
if that is really the intent.

Joe


Jeremy Hughes wrote:
> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org> wrote:

<snip/>

>>> Beyong the core JRE and osgi packages, we have:
>>>  * cglib : we should get rid of that one
>> +1 there's a few JIRAs around this but not one to get rid.

<snip/>

>>> We should really get rid of cglib asap. cglib itself uses asm and we
>>> have our own layer on top of asm.
>>> I don't think we should have a mandatory import on
>>> org.osgi.service.cm, so either find a way to make it optional or
>>> exclude it ?
>> ok

<snip/>

Re: Runtime dependencies for our released artifacts

[The Dweller <ba...@gmail.com>]

Re losing anything, Off the top of my head, I don't know, but Valentin
mentioned that cglib handled multiple interface proxying where the asm
alternative didn't..

If we only want a single implementation to lighten the test/support load,
that's fine =)

However, I'd still like it to be abstracted out / tidied up so it can be
made use of by BeanProcessors & NamespaceHandlers (while also being used for
both Interceptors and ServiceReferences). I guess it may also be beneficial
to look a little deeper to find out what other differences there are in the
capabilities of the two (ignoring jdk proxy here for a mo).

Ozzy.


On 7 April 2010 20:45, Jeremy Hughes <hu...@apache.org> wrote:

> On 7 April 2010 20:16, The Dweller <ba...@gmail.com> wrote:
> > We built our interceptors based over asm (and over cglib).. I wouldn't
> > consider the asm implementation as a lib currently, it has no external
> api,
> > and it is only used for interceptors.
> >
> > The suggestion isn't so much to keep cglib as being used, as to abstract
> all
> > our usage of cglib/asm/jdkproxy into a single place, so that its
> > implementation is irrelevant. Then yes, it could be considered as our own
> > proxying lib. At which point, it matters little if the implementation is
> > handled via cglib, asm, or jdk proxy, each of which brings their own set
> of
> > advantages/disadvantages to the table.
> >
> > Is there something bad about having the proxying able to run on a variety
> of
> > libraries?
>
> I know this sounds nice but it means extra to test and support and
> really I don't think the user is going care which is being used
> underneath so long as it works as advertised. If we were to just ASM
> and the code we have in Aries on top of that do we lose anything
> (other than other dependency options to achieve the same)?
>
> >
> > Ozzy.
> >
> >
> >
> >
> > On 7 April 2010 19:59, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> >> I must be missing something.  I thought we built our own lib on top of
> >> asm for the interceptors stuff.  My point is that this lib looks kinda
> >> like cglib, being built on top of asm.  So why don't we use it instead
> >> of cglib everywhere so that we can get rid of cglib?
> >>
> >> On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
> >> >
> >> > So, if I understand you correctly then, your point is that we should
> not
> >> be looking to remove cglib completely but just keep it optional. It has
> been
> >> included in blueprint for a while (for service reference proxies) and we
> >> have found it useful for other things like interceptors.  We should keep
> it
> >> optional and consolidate it (along with asm) to a common bundle.
> >> >
> >> > Thanks,
> >> > Joe
> >> >
> >> >
> >> > The Dweller wrote:
> >> >
> >> > From memory, cglib was always an optional dependency for blueprint.
> >> >
> >> >
> >> > Originally used only for the proxying in service references, if cglib
> >> wasn't
> >> > available, then that proxying would fall back to jdk proxy if
> possible.
> >> > (Although, only cglib provided 'class proxying' support)
> >> >
> >> > Later, it was also used to provide interceptors, again written to
> allow
> >> it
> >> > to be optional, if it wasn't available, interceptor support would
> >> disable.
> >> >
> >> > Later still, we added the code to allow interceptors to utilise asm,
> (or
> >> > cglib).
> >> >
> >> > We also have a jira open to common up our proxying code to a single
> >> place,
> >> > to allow both interceptors and service reference proxying to share the
> >> code,
> >> > and ideally provide an api to allow namespace handlers, bean
> processors
> >> > implementations etc, to make use of the function. If the proxying code
> >> were
> >> > to move out to its own bundle, then the cglib/asm/etc dependencies for
> >> > proxying would be isolated to just there.
> >> >
> >> > Ozzy.
> >> >
> >> > On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
> >> >
> >> >
> >> > In discussion below regarding cglib .... was the intent to completely
> >> > remove the use of cglib or just make it optional?
> >> >
> >> > From what I can tell it seems that cglib is already optional (perhaps
> due
> >> > to changes after this discussion).  But we still use it if available
> in
> >> > Blueprint AbstractServiceReference and the Blueprint Interceptor
> logic.
> >>  If
> >> > we completely remove it from the Blueprint Interceptor logic we would
> >> always
> >> > assume ASM.  If we completely remove it from AbstractServiceReference
> we
> >> > would always use the JdkProxy and would likewise need to remove the
> >> > AbstractServiceReferenceTest which seems to be cglib specific.
> >> >
> >> > I have some local changes that I can check in to completely remove
> cglib
> >> if
> >> > that is really the intent.
> >> >
> >> > Joe
> >> >
> >> >
> >> >
> >> > Jeremy Hughes wrote:
> >> >
> >> >
> >> > On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
> >> >
> >> >
> >> > On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
> >> > wrote:
> >> >
> >> >
> >> > <snip/>
> >> >
> >> >
> >> >  Beyong the core JRE and osgi packages, we have:
> >> >
> >> >  * cglib : we should get rid of that one
> >> >
> >> >
> >> > +1 there's a few JIRAs around this but not one to get rid.
> >> >
> >> >
> >> > <snip/>
> >> >
> >> >
> >> >  We should really get rid of cglib asap. cglib itself uses asm and we
> >> >
> >> > have our own layer on top of asm.
> >> > I don't think we should have a mandatory import on
> >> > org.osgi.service.cm, so either find a way to make it optional or
> >> > exclude it ?
> >> >
> >> >
> >> > ok
> >> >
> >> >
> >> > <snip/>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Joe
> >> >
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
>

Re: Runtime dependencies for our released artifacts

[Jeremy Hughes <hu...@apache.org>]

On 7 April 2010 20:16, The Dweller <ba...@gmail.com> wrote:
> We built our interceptors based over asm (and over cglib).. I wouldn't
> consider the asm implementation as a lib currently, it has no external api,
> and it is only used for interceptors.
>
> The suggestion isn't so much to keep cglib as being used, as to abstract all
> our usage of cglib/asm/jdkproxy into a single place, so that its
> implementation is irrelevant. Then yes, it could be considered as our own
> proxying lib. At which point, it matters little if the implementation is
> handled via cglib, asm, or jdk proxy, each of which brings their own set of
> advantages/disadvantages to the table.
>
> Is there something bad about having the proxying able to run on a variety of
> libraries?

I know this sounds nice but it means extra to test and support and
really I don't think the user is going care which is being used
underneath so long as it works as advertised. If we were to just ASM
and the code we have in Aries on top of that do we lose anything
(other than other dependency options to achieve the same)?

>
> Ozzy.
>
>
>
>
> On 7 April 2010 19:59, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> I must be missing something.  I thought we built our own lib on top of
>> asm for the interceptors stuff.  My point is that this lib looks kinda
>> like cglib, being built on top of asm.  So why don't we use it instead
>> of cglib everywhere so that we can get rid of cglib?
>>
>> On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
>> >
>> > So, if I understand you correctly then, your point is that we should not
>> be looking to remove cglib completely but just keep it optional. It has been
>> included in blueprint for a while (for service reference proxies) and we
>> have found it useful for other things like interceptors.  We should keep it
>> optional and consolidate it (along with asm) to a common bundle.
>> >
>> > Thanks,
>> > Joe
>> >
>> >
>> > The Dweller wrote:
>> >
>> > From memory, cglib was always an optional dependency for blueprint.
>> >
>> >
>> > Originally used only for the proxying in service references, if cglib
>> wasn't
>> > available, then that proxying would fall back to jdk proxy if possible.
>> > (Although, only cglib provided 'class proxying' support)
>> >
>> > Later, it was also used to provide interceptors, again written to allow
>> it
>> > to be optional, if it wasn't available, interceptor support would
>> disable.
>> >
>> > Later still, we added the code to allow interceptors to utilise asm, (or
>> > cglib).
>> >
>> > We also have a jira open to common up our proxying code to a single
>> place,
>> > to allow both interceptors and service reference proxying to share the
>> code,
>> > and ideally provide an api to allow namespace handlers, bean processors
>> > implementations etc, to make use of the function. If the proxying code
>> were
>> > to move out to its own bundle, then the cglib/asm/etc dependencies for
>> > proxying would be isolated to just there.
>> >
>> > Ozzy.
>> >
>> > On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
>> >
>> >
>> > In discussion below regarding cglib .... was the intent to completely
>> > remove the use of cglib or just make it optional?
>> >
>> > From what I can tell it seems that cglib is already optional (perhaps due
>> > to changes after this discussion).  But we still use it if available in
>> > Blueprint AbstractServiceReference and the Blueprint Interceptor logic.
>>  If
>> > we completely remove it from the Blueprint Interceptor logic we would
>> always
>> > assume ASM.  If we completely remove it from AbstractServiceReference we
>> > would always use the JdkProxy and would likewise need to remove the
>> > AbstractServiceReferenceTest which seems to be cglib specific.
>> >
>> > I have some local changes that I can check in to completely remove cglib
>> if
>> > that is really the intent.
>> >
>> > Joe
>> >
>> >
>> >
>> > Jeremy Hughes wrote:
>> >
>> >
>> > On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>> >
>> >
>> > On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
>> > wrote:
>> >
>> >
>> > <snip/>
>> >
>> >
>> >  Beyong the core JRE and osgi packages, we have:
>> >
>> >  * cglib : we should get rid of that one
>> >
>> >
>> > +1 there's a few JIRAs around this but not one to get rid.
>> >
>> >
>> > <snip/>
>> >
>> >
>> >  We should really get rid of cglib asap. cglib itself uses asm and we
>> >
>> > have our own layer on top of asm.
>> > I don't think we should have a mandatory import on
>> > org.osgi.service.cm, so either find a way to make it optional or
>> > exclude it ?
>> >
>> >
>> > ok
>> >
>> >
>> > <snip/>
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Joe
>> >
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>

Re: Runtime dependencies for our released artifacts

[The Dweller <ba...@gmail.com>]

We built our interceptors based over asm (and over cglib).. I wouldn't
consider the asm implementation as a lib currently, it has no external api,
and it is only used for interceptors.

The suggestion isn't so much to keep cglib as being used, as to abstract all
our usage of cglib/asm/jdkproxy into a single place, so that its
implementation is irrelevant. Then yes, it could be considered as our own
proxying lib. At which point, it matters little if the implementation is
handled via cglib, asm, or jdk proxy, each of which brings their own set of
advantages/disadvantages to the table.

Is there something bad about having the proxying able to run on a variety of
libraries?

Ozzy.




On 7 April 2010 19:59, Guillaume Nodet <gn...@gmail.com> wrote:

> I must be missing something.  I thought we built our own lib on top of
> asm for the interceptors stuff.  My point is that this lib looks kinda
> like cglib, being built on top of asm.  So why don't we use it instead
> of cglib everywhere so that we can get rid of cglib?
>
> On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
> >
> > So, if I understand you correctly then, your point is that we should not
> be looking to remove cglib completely but just keep it optional. It has been
> included in blueprint for a while (for service reference proxies) and we
> have found it useful for other things like interceptors.  We should keep it
> optional and consolidate it (along with asm) to a common bundle.
> >
> > Thanks,
> > Joe
> >
> >
> > The Dweller wrote:
> >
> > From memory, cglib was always an optional dependency for blueprint.
> >
> >
> > Originally used only for the proxying in service references, if cglib
> wasn't
> > available, then that proxying would fall back to jdk proxy if possible.
> > (Although, only cglib provided 'class proxying' support)
> >
> > Later, it was also used to provide interceptors, again written to allow
> it
> > to be optional, if it wasn't available, interceptor support would
> disable.
> >
> > Later still, we added the code to allow interceptors to utilise asm, (or
> > cglib).
> >
> > We also have a jira open to common up our proxying code to a single
> place,
> > to allow both interceptors and service reference proxying to share the
> code,
> > and ideally provide an api to allow namespace handlers, bean processors
> > implementations etc, to make use of the function. If the proxying code
> were
> > to move out to its own bundle, then the cglib/asm/etc dependencies for
> > proxying would be isolated to just there.
> >
> > Ozzy.
> >
> > On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
> >
> >
> > In discussion below regarding cglib .... was the intent to completely
> > remove the use of cglib or just make it optional?
> >
> > From what I can tell it seems that cglib is already optional (perhaps due
> > to changes after this discussion).  But we still use it if available in
> > Blueprint AbstractServiceReference and the Blueprint Interceptor logic.
>  If
> > we completely remove it from the Blueprint Interceptor logic we would
> always
> > assume ASM.  If we completely remove it from AbstractServiceReference we
> > would always use the JdkProxy and would likewise need to remove the
> > AbstractServiceReferenceTest which seems to be cglib specific.
> >
> > I have some local changes that I can check in to completely remove cglib
> if
> > that is really the intent.
> >
> > Joe
> >
> >
> >
> > Jeremy Hughes wrote:
> >
> >
> > On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
> >
> >
> > On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> >
> > On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
> > wrote:
> >
> >
> > <snip/>
> >
> >
> >  Beyong the core JRE and osgi packages, we have:
> >
> >  * cglib : we should get rid of that one
> >
> >
> > +1 there's a few JIRAs around this but not one to get rid.
> >
> >
> > <snip/>
> >
> >
> >  We should really get rid of cglib asap. cglib itself uses asm and we
> >
> > have our own layer on top of asm.
> > I don't think we should have a mandatory import on
> > org.osgi.service.cm, so either find a way to make it optional or
> > exclude it ?
> >
> >
> > ok
> >
> >
> > <snip/>
> >
> >
> >
> >
> >
> >
> > --
> > Joe
> >
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>

Re: Runtime dependencies for our released artifacts

[Guillaume Nodet <gn...@gmail.com>]

I must be missing something.  I thought we built our own lib on top of
asm for the interceptors stuff.  My point is that this lib looks kinda
like cglib, being built on top of asm.  So why don't we use it instead
of cglib everywhere so that we can get rid of cglib?

On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
>
> So, if I understand you correctly then, your point is that we should not be looking to remove cglib completely but just keep it optional. It has been included in blueprint for a while (for service reference proxies) and we have found it useful for other things like interceptors.  We should keep it optional and consolidate it (along with asm) to a common bundle.
>
> Thanks,
> Joe
>
>
> The Dweller wrote:
>
> From memory, cglib was always an optional dependency for blueprint.
>
>
> Originally used only for the proxying in service references, if cglib wasn't
> available, then that proxying would fall back to jdk proxy if possible.
> (Although, only cglib provided 'class proxying' support)
>
> Later, it was also used to provide interceptors, again written to allow it
> to be optional, if it wasn't available, interceptor support would disable.
>
> Later still, we added the code to allow interceptors to utilise asm, (or
> cglib).
>
> We also have a jira open to common up our proxying code to a single place,
> to allow both interceptors and service reference proxying to share the code,
> and ideally provide an api to allow namespace handlers, bean processors
> implementations etc, to make use of the function. If the proxying code were
> to move out to its own bundle, then the cglib/asm/etc dependencies for
> proxying would be isolated to just there.
>
> Ozzy.
>
> On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
>
>
> In discussion below regarding cglib .... was the intent to completely
> remove the use of cglib or just make it optional?
>
> From what I can tell it seems that cglib is already optional (perhaps due
> to changes after this discussion).  But we still use it if available in
> Blueprint AbstractServiceReference and the Blueprint Interceptor logic.  If
> we completely remove it from the Blueprint Interceptor logic we would always
> assume ASM.  If we completely remove it from AbstractServiceReference we
> would always use the JdkProxy and would likewise need to remove the
> AbstractServiceReferenceTest which seems to be cglib specific.
>
> I have some local changes that I can check in to completely remove cglib if
> that is really the intent.
>
> Joe
>
>
>
> Jeremy Hughes wrote:
>
>
> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>
>
> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>
>
> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
> wrote:
>
>
> <snip/>
>
>
>  Beyong the core JRE and osgi packages, we have:
>
>  * cglib : we should get rid of that one
>
>
> +1 there's a few JIRAs around this but not one to get rid.
>
>
> <snip/>
>
>
>  We should really get rid of cglib asap. cglib itself uses asm and we
>
> have our own layer on top of asm.
> I don't think we should have a mandatory import on
> org.osgi.service.cm, so either find a way to make it optional or
> exclude it ?
>
>
> ok
>
>
> <snip/>
>
>
>
>
>
>
> --
> Joe
>

-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Runtime dependencies for our released artifacts

[Joe Bohn <jo...@gmail.com>]

So, if I understand you correctly then, your point is that we should not 
be looking to remove cglib completely but just keep it optional. It has 
been included in blueprint for a while (for service reference proxies) 
and we have found it useful for other things like interceptors.  We 
should keep it optional and consolidate it (along with asm) to a common 
bundle.

Thanks,
Joe


The Dweller wrote:
>>>From memory, cglib was always an optional dependency for blueprint.
> 
> Originally used only for the proxying in service references, if cglib wasn't
> available, then that proxying would fall back to jdk proxy if possible.
> (Although, only cglib provided 'class proxying' support)
> 
> Later, it was also used to provide interceptors, again written to allow it
> to be optional, if it wasn't available, interceptor support would disable.
> 
> Later still, we added the code to allow interceptors to utilise asm, (or
> cglib).
> 
> We also have a jira open to common up our proxying code to a single place,
> to allow both interceptors and service reference proxying to share the code,
> and ideally provide an api to allow namespace handlers, bean processors
> implementations etc, to make use of the function. If the proxying code were
> to move out to its own bundle, then the cglib/asm/etc dependencies for
> proxying would be isolated to just there.
> 
> Ozzy.
> 
> On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
> 
>> In discussion below regarding cglib .... was the intent to completely
>> remove the use of cglib or just make it optional?
>>
>> From what I can tell it seems that cglib is already optional (perhaps due
>> to changes after this discussion).  But we still use it if available in
>> Blueprint AbstractServiceReference and the Blueprint Interceptor logic.  If
>> we completely remove it from the Blueprint Interceptor logic we would always
>> assume ASM.  If we completely remove it from AbstractServiceReference we
>> would always use the JdkProxy and would likewise need to remove the
>> AbstractServiceReferenceTest which seems to be cglib specific.
>>
>> I have some local changes that I can check in to completely remove cglib if
>> that is really the intent.
>>
>> Joe
>>
>>
>>
>> Jeremy Hughes wrote:
>>
>>> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>>>
>>>> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>
>>>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
>>>>> wrote:
>>>>>
>> <snip/>
>>
>>
>>  Beyong the core JRE and osgi packages, we have:
>>>>>  * cglib : we should get rid of that one
>>>>>
>>>> +1 there's a few JIRAs around this but not one to get rid.
>>>>
>> <snip/>
>>
>>
>>  We should really get rid of cglib asap. cglib itself uses asm and we
>>>>> have our own layer on top of asm.
>>>>> I don't think we should have a mandatory import on
>>>>> org.osgi.service.cm, so either find a way to make it optional or
>>>>> exclude it ?
>>>>>
>>>> ok
>>>>
>> <snip/>
>>
> 


-- 
Joe

Re: Runtime dependencies for our released artifacts

[The Dweller <ba...@gmail.com>]

>From memory, cglib was always an optional dependency for blueprint.

Originally used only for the proxying in service references, if cglib wasn't
available, then that proxying would fall back to jdk proxy if possible.
(Although, only cglib provided 'class proxying' support)

Later, it was also used to provide interceptors, again written to allow it
to be optional, if it wasn't available, interceptor support would disable.

Later still, we added the code to allow interceptors to utilise asm, (or
cglib).

We also have a jira open to common up our proxying code to a single place,
to allow both interceptors and service reference proxying to share the code,
and ideally provide an api to allow namespace handlers, bean processors
implementations etc, to make use of the function. If the proxying code were
to move out to its own bundle, then the cglib/asm/etc dependencies for
proxying would be isolated to just there.

Ozzy.

On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:

>
> In discussion below regarding cglib .... was the intent to completely
> remove the use of cglib or just make it optional?
>
> From what I can tell it seems that cglib is already optional (perhaps due
> to changes after this discussion).  But we still use it if available in
> Blueprint AbstractServiceReference and the Blueprint Interceptor logic.  If
> we completely remove it from the Blueprint Interceptor logic we would always
> assume ASM.  If we completely remove it from AbstractServiceReference we
> would always use the JdkProxy and would likewise need to remove the
> AbstractServiceReferenceTest which seems to be cglib specific.
>
> I have some local changes that I can check in to completely remove cglib if
> that is really the intent.
>
> Joe
>
>
>
> Jeremy Hughes wrote:
>
>> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>>
>>> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>>>
>>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
>>>> wrote:
>>>>
>>>
> <snip/>
>
>
>  Beyong the core JRE and osgi packages, we have:
>>>>  * cglib : we should get rid of that one
>>>>
>>> +1 there's a few JIRAs around this but not one to get rid.
>>>
>>
> <snip/>
>
>
>  We should really get rid of cglib asap. cglib itself uses asm and we
>>>> have our own layer on top of asm.
>>>> I don't think we should have a mandatory import on
>>>> org.osgi.service.cm, so either find a way to make it optional or
>>>> exclude it ?
>>>>
>>> ok
>>>
>>
> <snip/>
>