Open qwazer opened 3 years ago
Hi @qwazer
very interesting, however in order to solve this problem I avoid to generate file in "volatile" folder (like target) using <outdir>
configuration
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
ContentCheckingConfluenceService
of ConfluenceService that will be active when "updateOnContentChange" =trueContentCheckingConfluenceService
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
methodsI can try to prepare a PR or you can do it yourself if you are agree with the design above.
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:
.json
file from attachments.json
file will be uploaded to attachment with new versionWhat do you think about ?
@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.
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 |
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.
PRIVATE
to see how my markdown sources are rendered and 2) public spacePUBLIC
to make final publish. So I need constantly clean some entries intarget/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 classConfluencePublisher
.Initial commit: https://github.com/confluence-publisher/confluence-publisher/commit/25cd1a4a80d3f8668dde2f4937f9abbdd32fff8a