I agree that it doesn't give us much, but I do think it's better than nothing because at least it indicates our intentions.
David's fragment suggestion looks like it might be the cleanest compromise for all involved. This makes it much harder to accidentally start using the packages (which could still be marked deprecated), but relatively easy to run existing code unchanged by adding the fragment. Tim Ward ------------------- Apache Aries PMC member & Enterprise OSGi advocate Enterprise OSGi in Action (http://www.manning.com/cummins) ------------------- > Date: Thu, 24 Nov 2011 09:19:16 +0000 > 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/ > From: [email protected] > To: [email protected] > > Just adding deprecated="true" without mandatory:=deprecated does not bring > much value as the importer will still be able to import the package without > specifying the attribute. I think solely adding the deprecated="true" is > bad, not achiving much but bringing more confusion. > > On Wed, Nov 23, 2011 at 7:52 PM, Daniel Kulp <[email protected]> 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 > > > > > > -- > Thanks > Emily > ================= > Emily Jiang > [email protected]
