WRT migration of existing projects, we have a very good users guide which Tom Pantelis put together here [0], which actually contains a migration guide [1], for those who are attempting to make the move. Along with the documentation, there are a great number of patches that many folks have worked on to migrate projects already [2]. Hopefully this helps existing applications' contributors, both open source and proprietary, to make the move from CSS to blueprint.
Regards, Ryan [0] https://wiki.opendaylight.org/view/Using_Blueprint [1] https://wiki.opendaylight.org/view/Using_Blueprint#Migrating_from_config_subsytem_.28CSS.29 [2] https://git.opendaylight.org/gerrit/#/q/status:merged+topic:blueprint On Thu, Nov 17, 2016 at 8:57 AM, FREEMAN, BRIAN D <bf1...@att.com> wrote: > 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> 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
