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
