On 24 November 2011 02:06, David Jencks <[email protected]> wrote: > 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.
Excellent. You only mention the exports, and I think it best to put the classes in there too. It would have to be like this for packages that contain classes that are deprecated and classes that aren't deprecated, but I think we can generalize that to all deprecated classes. This will keep the host bundle size down too. This is a great suggestion! +1 > > 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 > >
