You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
remote_file resource usage in the entire cookbook can be improved to speed up subsequent deployments.
remote_file that describes main JAR file is used twice - firstly to download the file to Chef's cache and secondly to move it to AEM's home dir. It's quite unlikely that anyone would like to do an in-place upgrade of that, so we can either add only_if/not_if logic that skip this step if the file has been already downloaded/moved.
The logic is slightly different when it comes to license file. It's quite small and can be validated on-the-fly during every deployment. In contrast to main JAR file it is possible to switch licenses, so we can't apply the same logic as above.
The last part is related to cq_package. In this case I see 2 possible scenarios:
if you decided to use the same filename all the time (as for example package.zip always points to the latest version) only_if or not_if can be harmful and may force you to do some changes in existing code base
if you update filename whenever there's a change in your package (new version, group, etc) only_if or not_if can bring some performance improvement to the table, in particular for large packages.
Final solution hasn't been decided yet.
The text was updated successfully, but these errors were encountered:
remote_file
resource usage in the entire cookbook can be improved to speed up subsequent deployments.remote_file
that describes main JAR file is used twice - firstly to download the file to Chef's cache and secondly to move it to AEM's home dir. It's quite unlikely that anyone would like to do an in-place upgrade of that, so we can either addonly_if
/not_if
logic that skip this step if the file has been already downloaded/moved.The logic is slightly different when it comes to license file. It's quite small and can be validated on-the-fly during every deployment. In contrast to main JAR file it is possible to switch licenses, so we can't apply the same logic as above.
The last part is related to
cq_package
. In this case I see 2 possible scenarios:package.zip
always points to the latest version)only_if
ornot_if
can be harmful and may force you to do some changes in existing code baseonly_if
ornot_if
can bring some performance improvement to the table, in particular for large packages.Final solution hasn't been decided yet.
The text was updated successfully, but these errors were encountered: