Re: BP compatibility fragment.... (was: svn commit: r1205487 - in /aries/trunk/blueprint......)

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

I've just tested with XBean + ActiveMQ and it works perfectly.

On Mon, Nov 28, 2011 at 18:38, Daniel Kulp <dk...@apache.org> wrote:
>
> I just added a quick fragment bundle to add the exports and did a quick test
> with CXF and it seems to work OK.   I haven't moved any classes over there
> yet.
>
> I think the only class that can move over is the classloader.  The moved
> ExtendedBlueprintContainer interface cannot move over as the
> BlueprintContainerImpl has to implement it.
>
> In anycase, if others could give it a test, that would be great.
>
> Thanks!
>
> Dan
>
>
>
>
> On Thursday, November 24, 2011 10:21:28 AM Timothy Ward wrote:
>> That is an extremely good idea! +1 from me
>>
>> Tim Ward
>> -------------------
>> Apache Aries PMC member & Enterprise OSGi advocate
>> Enterprise OSGi in Action (http://www.manning.com/cummins)
>> -------------------
>>
>> > Subject: Re: svn commit: r1205487 - in /aries/trunk/blueprint:
>> > blueprint-bundle/ blueprint-core/
>> > blueprint-core/src/main/java/org/apache/aries/blueprint/container/
>> > blueprint-core/src/main/java/org/apache/aries/blueprint/services/
>> > blueprint-core/src/main/java/org/ From: david_jencks@yahoo.com
>> > Date: Wed, 23 Nov 2011 18:06:25 -0800
>> > To: dev@aries.apache.org
>> >
>> > What would people think about putting the deprecated exports into a
>> > fragment bundle rather than changing the main manifest?  If you want
>> > the exports you deploy the fragment bundle too...  This seems like it
>> > would make it easier to check if you are using the  exports.
>> >
>> > thanks
>> > david jencks
>> >
>> > On Nov 23, 2011, at 11:52 AM, Daniel Kulp wrote:
>> > > On Wednesday, November 23, 2011 7:30:17 PM Timothy Ward wrote:
>> > >> I see this commit as, at best, a stop-gap measure.
>> > >
>> > > Agreed.   But we need a migration path for users of these API's that
>> > > doesn't break everything right now.
>> > >
>> > >> We should not be
>> > >> exporting these implementation packages, but I understand that
>> > >> they are relied upon externally (for the moment) until we have
>> > >> enough API pieces to get everyone migrated off. I would like the
>> > >> blueprint container, di and reflect packages to add the
>> > >> following:
>> > >>
>> > >> deprecated="true";mandatory:="deprecated"
>> > >>
>> > >> Clients that need them can add the deprecated attribute and
>> > >> continue to work, but we prevent new clients from wiring to
>> > >> packages that are intended to be removed. Otherwise we're going
>> > >> to go round the same loop all over again and never be able to
>> > >> package the bundle properly.
>> > >
>> > > I agree with adding deprecated="true"  and will do so shortly.   I
>> > > don't agree with the second part *for now*.   That would still
>> > > prevent existing applications from being able to use the new BP
>> > > without going through modifications, rebuilds, new releases,
>> > > etc....    Basically, I want to get a version out that doesn't
>> > > break all the applications out there, but provides the new API's
>> > > and functionality that is needed.   Give the projects time to
>> > > migrate to the new API's (and fully test them), then make it harder
>> > > (or impossible) to use the old API's by adding the second flag.
>> > >
>> > >
>> > > Dan
>> > >
>> > >> This approach could also be used with the cm code until we have an
>> > >> understanding for what API that requires and package it
>> > >> appropriately.
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>



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