> > You could thus deprecate the generated class: in this case > org.opendaylight.yang.gen.v1.urn.opendaylight.lacp.lacp.main.rev141216.AbstractLacpMainModule
Yeah because LCAP team modified the Module and thus copied it into src/. The @Deprecated generation would never traverse to this file... it would just be present in new generated Module(s) (in target), which is really only helpful to projects that: 1) don't modify the Module 2) are implementing a new service from scratch without using the archetype. Since the archetypes have already been modified to utilize blueprint, I'd wager that most people wouldn't see any effect from making a change to the code generator. Not to mention the fact that I highly doubt it would be "simple"... it would probably require special casing code generation for provider yang since I believe it utilizes the standard mdsal-binding-java-api-generator. Just my $0.02, someone else may have a good idea for this. IMHO the best approach is to advertise this loud and clear across mailing lists and release notes, since most people ignore deprecated notices anyway (coming from someone who did the initial work to deprecate DCL, which is still used EVERYWHERE). Best Regards, Ryan On Wed, Nov 16, 2016 at 9:33 PM, Colin Dixon <co...@colindixon.com> wrote: > So, even though the file is in src/ it imports a generated file, see here: > https://github.com/opendaylight/lacp/blob/master/ > lacp-main/implementation/src/main/java/org/opendaylight/ > yang/gen/v1/urn/opendaylight/lacp/lacp/main/rev141216/ > LacpMainModule.java#L35 > > You could thus deprecate the generated class: in this case > org.opendaylight.yang.gen.v1.urn.opendaylight.lacp.lacp.main.rev141216. > AbstractLacpMainModule > > That would work with a relatively simple change in the code generator and > apply everywhere, right? > > --Colin > > > On Wed, Nov 16, 2016 at 7:11 PM, Ryan Goulding <ryandgould...@gmail.com> > wrote: > >> You mean the Provider? Most people adapt the Provider and put it in src/ >> anyway; I would guess this wouldn't really raise much awareness but that >> is my own $0.02. The easiest path forward is probably to make sweeping >> announcements via email and strong suggestions in the release notes... but >> I could be wrong. Open to discussion on the strategy going forward. Tom >> Pantelis may have a clever suggestion for this too... >> >> Regards, >> >> Ryan Goulding >> >> On Wed, Nov 16, 2016 at 2:50 PM, Colin Dixon <co...@colindixon.com> >> wrote: >> >>> That sounds good to me. What's the right way for us to "deprecate" the >>> config subsystem. I guess the simplest thing would be add an @deprecated >>> decorator to the relevant classes that get generated with a pointer to the >>> docs on how to migrate. >>> >>> --Colin >>> >>> >>> On Tue, Nov 15, 2016 at 5:07 PM, FREEMAN, BRIAN D <bf1...@att.com> >>> wrote: >>> >>>> I think Option 2 is a reasonable approach. >>>> >>>> Brian >>>> >>>> >>>> -----Original Message----- >>>> From: controller-dev-boun...@lists.opendaylight.org [mailto: >>>> controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert >>>> Varga >>>> Sent: Tuesday, November 15, 2016 4:46 PM >>>> To: Alexis de Talhouët; thomas nadeau >>>> Cc: controller-dev >>>> Subject: Re: [controller-dev] deprecating the config subsystem in >>>> Carbon? >>>> >>>> On 11/15/2016 10:08 PM, Alexis de Talhouët wrote: >>>> > >>>> > Option 2: >>>> > Deprecation notice in Carbon >>>> > Adaptation in Nitrogen >>>> > Removal in Oxygen >>>> > >>>> > During the kernel meeting I was more after option 3, but I think >>>> option >>>> > 2 make sense so downstream consumer can be notified earlier in the >>>> > process and start migrating things to blueprint. >>>> >>>> I think option 2 works best, especially since we can decide on when the >>>> actual removal takes place -- which I think should be one release after >>>> we have shipped without internal projects using it. >>>> >>>> Bye, >>>> Robert >>>> >>>> _______________________________________________ >>>> controller-dev mailing list >>>> controller-dev@lists.opendaylight.org >>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev >>>> >>> >>> >>> _______________________________________________ >>> controller-dev mailing list >>> controller-dev@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/controller-dev >>> >>> >> >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
