[jira] [Comment Edited] (MBUILDCACHE-73) Add project version as additional property for reconcilation

2024-01-09 Thread Xaver (Jira)


[ 
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804848#comment-17804848
 ] 

Xaver edited comment on MBUILDCACHE-73 at 1/9/24 8:30 PM:
--

Hi there,
V1.0.1 works awesome (we use it in a large multi module project and reduced 
computation costs of CI/CD by ~80%)! Thanks a lot for it.

I think that the merge of 
[PR#117|https://github.com/apache/maven-build-cache-extension/pull/117] / 
MBUILDCACHE-76 was a mistake.

Please look at the [description of the 
extension|https://maven.apache.org/extensions/maven-build-cache-extension/]:
{panel:title=A combination of features achieves that:}
Version normalization supports project *version agnostic caches*
{panel}

Have a look at the code:
https://github.com/apache/maven-build-cache-extension/blob/maven-build-cache-extension-1.1.0/src/main/java/org/apache/maven/buildcache/DefaultNormalizedModelProvider.java#L81-L82
The version is explicitly removed to achieve the version agnostic cache
{code:java}
// does not make sense to add project version to calculate hash
resultModel.setVersion(NORMALIZED_VERSION);
{code}

Other modern build tools I know (e.g. gradle, nx.dev) use version agnostic 
caches. I really missed this feature a lot.

Please don't close this issue. It's important for many use cases that the 
version is optional for checksum calculation.

Thank you from a happy 1.0.1 user.


was (Author: JIRAUSER303756):
Hi there,
V1.0.1 works awesome (we use it in a large multi module project and reduced 
computation costs of CI/CD by ~80%)! Thanks a lot for it.

I think that the merge of 
[PR#117|https://github.com/apache/maven-build-cache-extension/pull/117] / 
MBUILDCACHE-76 was a mistake.

Please look at the [description of the 
extension|https://maven.apache.org/extensions/maven-build-cache-extension/]:
{panel:title=A combination of features achieves that:}
Version normalization supports project *version agnostic caches*
{panel}

Other modern build tools I know (e.g. gradle, nx.dev) use version agnostic 
caches. I really missed this feature a lot.

Please don't close this issue. It's important for many use cases that the 
version is optional for checksum calculation.

Thank you from a happy 1.0.1 user.

> 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 {{}}
>  * attribute {{{}expression{}}}, to achieve the result with {{ 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)


[jira] [Comment Edited] (MBUILDCACHE-73) Add project version as additional property for reconcilation

2023-12-08 Thread Olivier Lamy (Jira)


[ 
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794894#comment-17794894
 ] 

Olivier Lamy edited comment on MBUILDCACHE-73 at 12/9/23 12:56 AM:
---

simply skip test during release:prepare or perform or even both (as your build 
has already been validated by a CI?)
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full 
Build. Really?? I guess only once after version change or any source change


was (Author: olamy):
simply skip test during release:prepare or perform or even both.
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full 
Build. Really?? I guess only once after version change or any source change

> 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 {{}}
>  * attribute {{{}expression{}}}, to achieve the result with {{ 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)