Improve feature "Avoid republishing for confluence pages". Store hash key of content in a Confluence server

[qwazer]

Hi Bartolomé

I have a proposal to improve the feature "Avoid republishing for confluence pages" introduced in https://github.com/bsorrentino/maven-confluence-plugin/issues/150 and https://github.com/bsorrentino/maven-confluence-plugin/issues/163

Current implementation holds state in local filesystem. There are two issues with such approach.

1. It's not CI-friendly especially in modern cloud-native approach, when new CI builder with empty filesystem created for every build
2. It's not convenient in local developing. For example, sometimes I use 2 confluence spaces to publish docs on the same markdown sources. 1) A private space PRIVATE to see how my markdown sources are rendered and 2) public space PUBLIC to make final publish. So I need constantly clean some entries in target/confluence-reporting-maven-plugin-storage.json to publish all content in 2 spaces correctly and avoid unwanted history changes to not disturb a confluence page watchers/subscribers.

Proposal is to store a page/attachment hash value at Confluence server itself using Content Properties.

This approach implemented in confluence-publisher project.

See usage of the field CONTENT_HASH_PROPERTY_KEY across the class ConfluencePublisher.

• create and store hash key
• update if hashes differs

Initial commit: https://github.com/confluence-publisher/confluence-publisher/commit/25cd1a4a80d3f8668dde2f4937f9abbdd32fff8a

[bsorrentino]

Hi @qwazer

very interesting, however in order to solve this problem I avoid to generate file in "volatile" folder (like target) using <outdir> configuration

[qwazer]

Hi @bsorrentino

in order to solve this problem I avoid to generate file in "volatile" folder (like target) using configuration

Unfortunately it is not my case. I always use new build environment without access to any shared folders.

I researched possible ways to solve this issue and I have a proposal. Please review it. Are you agree with the solution design?

My proposal is

1. to add new property "updateOnContentChange" to deploy mojo
2. add new implementation ContentCheckingConfluenceService of ConfluenceService that will be active when "updateOnContentChange" =true
3. ContentCheckingConfluenceService will use /content/{id}/property REST endpoint of Conluence API and a. calculate page or attachment CONTENT_HASH value b. save the page or attachment property on "create" action c. before update check for changes with remote CONTENT_HASH property value, update only if difference found In other scenarios ContentCheckingConfluenceService will work as RESTConfluenceService and XMLRPCConfluenceService. Please note, that working with content properties is not available in Confluence XML-RPC, so, probably, the same technic as in MixedConfluenceService should be used. Delegate actual calls to concrete implementations, but change behavior for createPage, storePage, newAttachment, addAttachment methods

I can try to prepare a PR or you can do it yourself if you are agree with the design above.

[bsorrentino]

Hi @qwazer

Each new Idea is always welcome so firstly thanks for sharing that

Following your design I've thought that we could simplify the overall solution attaching the .json file, containing the hashes, to the root page of site.

So the steps for publication will be:

1. tring to download from the root page the .json file from attachments
2. If exists the plugin will use it. If doesn't exist the plugin will create a new one
3. after pubblication the .json file will be uploaded to attachment with new version

What do you think about ?

[qwazer]

@bsorrentino It's very interesting, because can reuse existing DeployManager code. One minor drawback I can see it is possible redudant attachment on a root page. If root page has {attachments} macro it will be displayed. But is a really minor. I'll think about option that your proposed. Need to compare with my option. I hope I'll return to you shortly.

[bsorrentino]

Yes @qwazer, idea is to maximise reuse 😉

concerning side effect on {attachment} macro, yes it is a minor problem, however there is a possibility to filter the output of {attachment} using the pattern property

from documentation

macro	description
{attachments:patterns=.*doc}	Prints a list of attachments patterns: - (optional) a comma separated list of regular expressions. Only file names matching one of these are displayed