[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795202#comment-17795202
]
Patrik Dudits commented on MBUILDCACHE-73:
------------------------------------------
I was describing the three builds around maven release, so yes you've
understood it right, only once after version change. I just liked the elegance
of cache handling it instead.
So to summarize:
* I agree, that making version part of hash is good default
* I'm not very happy it's would not be configurable (but the default will
likely make more people happy)
* There are still usecases of invalidating plugin execution based on
properties (that are not necessarily project.version) that are not their
parameters, so the extension of reconcilation is still an useful idea.
> Add project version as additional property for reconcilation
> ------------------------------------------------------------
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
> Affects Versions: 1.0.1
> Reporter: Patrik Dudits
> Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{<reconcile propertyName="project.version"/>}}
> * attribute {{{}expression{}}}, to achieve the result with {{<reconcile
> propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
