gnodet commented on PR #698:
URL: 
https://github.com/apache/maven-deploy-plugin/pull/698#issuecomment-5499904705

   @slawekjaranowski Good point — the install and deploy plugins share the same 
`*AtEnd` state machine pattern and the hardening fixes should be consistent 
across both.
   
   I've aligned the two implementations:
   
   **deploy-plugin** (this PR stack, specifically #700) now has:
   - `DEPLOY_AT_END_LOCK` — serializes the mark-check-fire sequence under `-T` 
(same as install's `DEFERRED_INSTALL_LOCK`)
   - Exactly-once `DEPLOYED` guard — prevents re-deploy on reactor re-entry
   - Per-project partial-deploy inventory — on mid-batch failure, logs which 
projects were already published vs not deployed (mirrors install PR #445's 
`logPartialInstallInventory()`)
   - Plugin matching by presence (any execution not bound to phase `none`), not 
by execution-id equality
   - `deployAtEnd` javadoc corrected to state the actual non-atomic guarantee
   
   **install-plugin** [PR 
#445](https://github.com/apache/maven-install-plugin/pull/445) already has the 
equivalent fixes:
   - `DEFERRED_INSTALL_LOCK`
   - Exactly-once `INSTALLED` state transition per project
   - `logPartialInstallInventory()` with per-project detail
   - Plugin matching fixed (any execution, not by id)
   - `installAtEnd` javadoc corrected
   
   The two implementations are now structurally aligned. Given that they live 
in separate repos with separate release cycles, keeping them 
separate-but-aligned seems more practical than extracting a shared artifact — a 
shared module would add a release-coordination dependency for a ~50-line state 
machine. If this is extracted later (or replaced entirely by Maven 4's 
`after:all` lifecycle phase, which was designed for exactly this use case per 
[MNG-8557](https://issues.apache.org/jira/browse/MNG-8557)), the aligned code 
will make that migration straightforward.
   
   Regarding extracting the `deployAtEnd` state machine into a separate PR: the 
fixes in #700 touch both the state machine _and_ other `DeployMojo` concerns 
(alt-repo parse hardening, snapshot fallback warning, etc.). I can split them 
if you'd prefer a state-machine-only PR — let me know.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to