Skip to content

Fix duplicated publishing#128

Merged
alexander-yevsyukov merged 13 commits intomasterfrom
continue-publishing
Apr 25, 2025
Merged

Fix duplicated publishing#128
alexander-yevsyukov merged 13 commits intomasterfrom
continue-publishing

Conversation

@alexander-yevsyukov
Copy link
Contributor

@alexander-yevsyukov alexander-yevsyukov commented Apr 25, 2025

This PR is yet another one in the chain of requests handling the duplicated repositories issue for custom publications. There's much hope that this time we finally fixed it.

Unlike we suggested in the previous PR the problem was not because afterEvaluate was executed twice. The problem was that we asked to run it twice for two different custom publication handlers that (surprise!) got the same publishing destination repositories.

How it worked

The spinePublishing extension applied to the root project handles the "sorting" of publications. Those projects who are not listed among modulesWithCustomPublishing got StandardPublicationHandler, which does a lot of automated publishing work.

If a module goes its own publishing way via enrolling to the modulesWithCustomPublishing list, it gets CustomPublicationHandler.

This all works fine if a subproject does not have its own spinePublishing extension, which is the case for the modules packing IntelliJ IDEA into fat JARs. These modules get own spinePublishing extensions via intellij-platform-jar conventions plugin. Because of this, SpinePublishing extension in those subprojects also arranges the publishing with the same destinations, which it gets from the rootProject's extension.

This, in turn, creates own CustomPublicationHandler which runs its apply() on afterEvaluate.

How we fixed it

  1. Handlers now are created via factories.
  2. If there is a handler for a project (selected by its full path), it gets custom destination repositories, instead of creation of a new handler.
  3. The state of applying the publication handler is remembered. So, calling apply() on afterEvaluate twice — because we have two levels of spinePublishing in the project hierarchy — does not do any harm. The real "meat" of the apply() function is done once.

Other notable changes

@alexander-yevsyukov alexander-yevsyukov marked this pull request as ready for review April 25, 2025 18:06
@alexander-yevsyukov alexander-yevsyukov self-assigned this Apr 25, 2025
... because the task is not yet available, and the build fails.

This is related to the changes in the mechanism of applying publication handlers we've introduced.
@alexander-yevsyukov alexander-yevsyukov merged commit fcc702f into master Apr 25, 2025
6 checks passed
@alexander-yevsyukov alexander-yevsyukov deleted the continue-publishing branch April 25, 2025 19:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants