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 >
