[YANGTOOLS-706] Milestone: split parser-impl into multiple artifacts Created: 27/Oct/16  Updated: 10/Apr/22  Resolved: 20/Nov/17

Status: Verified
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0

Type: Bug
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Blocks
is blocked by YANGTOOLS-704 Document parser-impl package structure Resolved
is blocked by YANGTOOLS-705 Parser: Eliminate stmt.reactor depend... Verified
External issue ID: 7052

 Description   

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.

We should introduce new artifacts as follows:
yang-parser-spi:
yang.parser.spi
yang.parser.spi.meta
yang.parser.spi.source
yang.parser.spi.validation
yang-parser-reactor (depending on yang-parser-spi):
yang.parser.stmt.reactor
yang-parser-rfc6020 (depending on yang-parser-reactor):
yang.parser.stmt.rfc6020
yang-parser-rfc7950 (depending on yang-parser-reactor, yang-parser-rfc6020):
yang.parser.stmt.rfc7950
yang-parser-impl (depending on all of the above):
the rest of the packages

 Comments   
Comment by Robert Varga [ 12/Sep/17 ]

yang-parser-spi split: https://git.opendaylight.org/gerrit/63043

Comment by Robert Varga [ 02/Nov/17 ]

yang-parser-reactor split: https://git.opendaylight.org/gerrit/65038

Comment by Robert Varga [ 11/Nov/17 ]

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.

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

{Declared,Effecive}

Statement implementations and more headaches.

Therefore the split up should only involve two basic artifacts:

  • yang-parser-rfc7950, which hosts vanilla RFC6020/RFC7950 implementation, with utility reactors
  • extension specific model-api and parser-support artifacts
  • yang-parser-impl, which ties yang-parser-rfc7950 with all the YANG extension support defined in yangtools
Comment by Robert Varga [ 11/Nov/17 ]

https://git.opendaylight.org/gerrit/65451 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.

Comment by Robert Varga [ 13/Nov/17 ]

We still need to separate out schema location and rfc8040

Generated at Wed Feb 07 20:54:04 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.