Mark FailureMarker @internal and document ComposerUtility, PathLocator and ValidationResult

That was a step in the right direction, but still not what we're looking for in package_manager.api.php.

So I took this on, and wrote what I was expecting. While writing it, I was observing how PathLocator and ValidationResult are used in all validators & excluders that exist today.

In doing so, I discovered that there are zero interactions across all validators & excluders with ValidationResult! They all use ::addError() and addWarning() — ValidationResult is purely internal! So … marked it @internal.

re #16

@Wim Leers

They all use ::addError() and addWarning() — ValidationResult is purely internal! So … marked it @internal.

I was wondering about this but if you catch a \Drupal\package_manager\Exception\StageValidationException which I think we would want outside code to do then they would call \Drupal\package_manager\Exception\StageValidationException::getResults which return them ValidationResult objects. So in that case we can't change the methods on ValidationResult, without BC concerns, correct?

Good call! Will address that.

While addressing #17, I was forced to document StageException to be able to talk about StageValidationException. In doing that, I discovered that package_manager only throws StageException, never catches it — only package_manager actually catches these exceptions!

That's how I discovered that StatusCheckEvent should probably be dispatched by Package Manager, and not just provided by it.

See 📌 Consider moving hook_requirements() + \Drupal\automatic_updates\Validation\StatusCheckRequirements to package_manager Active .

Documented StageValidationException as if 📌 Throw an exception if stopPropagation() called for `PreOperationStageEvent` and no error has been added Fixed is already completed.

I think I might not have been clear on #17 so I left an MR comment with more detail and a concrete example.

I tried closing the old MR but am not allowed to.

I replicated the exact commit history against the 3.0.x branch in a new MR.

The clarifications @tedbow posted at https://git.drupalcode.org/project/automatic_updates/-/merge_requests/65... were AFAICT intended to be posted on ValidationResult's @internal comment?

I fixed that in https://git.drupalcode.org/project/automatic_updates/-/merge_requests/71... — and it means that the MR's scope now actually matches the issue title. 👍😅

updated 🌱 Drupal 10 Core Roadmap for Automatic Updates Active

Automatically closed - issue fixed for 2 weeks with no activity.