https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-706 yangtools <p>Current organization of parser-impl provides very little pressure to maintain proper inter-package dependencies, as the entire component is built in one go. Splitting the artifact will cause maven to detect circular dependencies, enforcing proper design.</p> <p>We should introduce new artifacts as follows:<br/> yang-parser-spi:<br/> yang.parser.spi<br/> yang.parser.spi.meta<br/> yang.parser.spi.source<br/> yang.parser.spi.validation<br/> yang-parser-reactor (depending on yang-parser-spi):<br/> yang.parser.stmt.reactor<br/> yang-parser-rfc6020 (depending on yang-parser-reactor):<br/> yang.parser.stmt.rfc6020<br/> yang-parser-rfc7950 (depending on yang-parser-reactor, yang-parser-rfc6020):<br/> yang.parser.stmt.rfc7950<br/> yang-parser-impl (depending on all of the above):<br/> the rest of the packages</p> <p>Operating System: All<br/> Platform: All</p> YANGTOOLS-706

Milestone: split parser-impl into multiple artifacts

Bug Verified Done Robert Varga Robert Varga Thu, 27 Oct 2016 16:14:37 +0000 Sun, 10 Apr 2022 18:35:55 +0000 Mon, 20 Nov 2017 13:18:49 +0000 2.0.0 0 1 <p>yang-parser-spi split: <a href="https://git.opendaylight.org/gerrit/63043" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/63043</a></p> <p>yang-parser-reactor split: <a href="https://git.opendaylight.org/gerrit/65038" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/65038</a></p> <p>After reviewing the code I realized we have two competing interests here. One is splitting up the parser into logical chunks and the other being not leaking implementation details across statements. I believe the second concern is overriding, as it contributes to sound implementation design.</p> <p>In light of this, the RFC6020/RFC7950 does not make sense, as our user-facing interfaces are not designed to support pure RFC6020 reactor. Designing them in that way would be counter-intuitive to end users, will require exposing </p> {Declared,Effecive} <p>Statement implementations and more headaches.</p> <p>Therefore the split up should only involve two basic artifacts:</p> <ul class="alternate" type="square"> <li>yang-parser-rfc7950, which hosts vanilla RFC6020/RFC7950 implementation, with utility reactors</li> <li>extension specific model-api and parser-support artifacts</li> <li>yang-parser-impl, which ties yang-parser-rfc7950 with all the YANG extension support defined in yangtools</li> </ul> <p><a href="https://git.opendaylight.org/gerrit/65451" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/65451</a> provides the baseline for split-out of yang-parser-rfc7950, which still needs to add specific reactors and also needs to split up the unit test suit, such that it does not rely on yang-parser-impl proper.</p> <p>We still need to separate out schema location and rfc8040</p> Blocks YANGTOOLS-704 YANGTOOLS-705 Development External issue ID 7052 External issue URL Issue Type ODL SR Target Milestone Rank 0|i028vr: