Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(policy): provide new contexts and function interfaces for policy engine #4542

Merged
merged 2 commits into from
Oct 15, 2024

Conversation

ndr-brt
Copy link
Member

@ndr-brt ndr-brt commented Oct 11, 2024

What this PR changes/adds

Given that #4535 is really huge, I extracted a smaller PR, that takes care of:

  • creating new PolicyContext implementation
  • redefine policy function and policy validator hierarchy

Why it does that

help the review process

Further notes

List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.

Linked Issue(s)

Part of #3511

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

@ndr-brt ndr-brt added the refactoring Cleaning up code and dependencies label Oct 11, 2024
@ndr-brt ndr-brt changed the title refactor(policy-engine): provide new contexts and function interfaces refactor(policy): provide new contexts and function interfaces for policy engine Oct 11, 2024
@ndr-brt ndr-brt force-pushed the 3511-refactor-interfaces branch 2 times, most recently from 85fafd7 to 7f9b987 Compare October 11, 2024 12:54
@ndr-brt ndr-brt force-pushed the 3511-refactor-interfaces branch from 7f9b987 to 5d675ef Compare October 11, 2024 13:00
@ndr-brt ndr-brt marked this pull request as ready for review October 11, 2024 13:34
Copy link
Contributor

@jimmarino jimmarino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One comment about the dependencies

@@ -17,14 +17,15 @@ plugins {
}

dependencies {
implementation(project(":spi:common:validator-spi"))
implementation(project(":spi:control-plane:control-plane-spi"))
api(project(":spi:common:boot-spi"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these exposed as APIs? They are not needed to extend this module.

Copy link
Member Author

@ndr-brt ndr-brt Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

must have been some rebase/pr split issue, will remove it

ok, gotcha in a core module no need to have api dependencies.
I think we never put down a clear statement on how these needs to be set.
Could it be that only spi modules should expose other spi as api? otherwise implementation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a module should only expose another module as an api if it is transitively exposed to interact with it, e.g. an SPI interface references a type from the other module.

@ndr-brt ndr-brt requested a review from jimmarino October 15, 2024 07:17
@ndr-brt ndr-brt force-pushed the 3511-refactor-interfaces branch from 0c31c17 to 146a231 Compare October 15, 2024 07:18
@ndr-brt ndr-brt merged commit 6ea6dbd into eclipse-edc:main Oct 15, 2024
23 checks passed
@ndr-brt ndr-brt deleted the 3511-refactor-interfaces branch October 15, 2024 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Cleaning up code and dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants