I agree with Ryan that the problem is more existing applications that use the config system – ones that we wouldn’t normally be re-using the mvn archetype but have to re-factor the app to use blueprint instead of Config subsystem.
Brian From: Ryan Goulding [mailto:ryandgould...@gmail.com] Sent: Thursday, November 17, 2016 8:06 AM To: Colin Dixon Cc: FREEMAN, BRIAN D; controller-dev Subject: Re: [controller-dev] deprecating the config subsystem in Carbon? 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<mailto: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<mailto: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<mailto: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<mailto: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> [mailto: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<mailto:controller-dev@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org<mailto: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
