I've just tested with XBean + ActiveMQ and it works perfectly. On Mon, Nov 28, 2011 at 18:38, Daniel Kulp <[email protected]> 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: [email protected] >> > Date: Wed, 23 Nov 2011 18:06:25 -0800 >> > To: [email protected] >> > >> > 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 > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
-- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
