[
https://issues.apache.org/jira/browse/FINERACT-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212003#comment-17212003
]
Michael Vorburger commented on FINERACT-1198:
---------------------------------------------
[~aalmiray] interesting.. the build-cache thing seems to, quote: _leverages the
same intelligence as up-to-date checks that Gradle uses to avoid work when a
previous local build has already produced a set of task outputs. But instead of
being limited to the previous build in the same workspace, task output caching
allows Gradle to reuse task outputs from any earlier build in any location on
the local machine. When using a shared build cache for task output caching this
even works across developer machines and build agents._ It seems to me that's
not the main focus/point of this issue - what we're after here is that the
"task output caching" works properly for subsequent invocations of the same
tasks in the same workspace?
I just have, only very briefly, done a {{./gradlew clean}}, then a {{./gradle
bootJAR --scan}} which took 1.5' and produced
https://scans.gradle.com/s/a6ofevvuizzc4, and then another {{./gradle bootJAR
--scan}} (without a {{clean}} first) which still took 1' and produced
https://scans.gradle.com/s/qkdl2fmvusnlo/. What I think could be interesting to
dig into here, for anyone with stronger Gradle foo than I personally have, and
would add value to the project, is why that second build isn't much faster? My
understand is that is what Gradle promises - but something we do screws that.
We would certainly be very open to any specific enhancements you would propose
to make - by comment here, or (even better..) through PRs! ;)
If we have to choose / prioritize, I would say that optimizing for faster
subsequenter {{./gradlew bootRun}} (during development) has higher value than
{{bootJar}} or {{build}} (more for releasing and less for ongoing development)
- unless any improvements will always benefit all tasks anyway?
> Gradle incremental build is broken
> ----------------------------------
>
> Key: FINERACT-1198
> URL: https://issues.apache.org/jira/browse/FINERACT-1198
> Project: Apache Fineract
> Issue Type: Bug
> Components: Build
> Reporter: Michael Vorburger
> Assignee: Michael Vorburger
> Priority: Major
>
> One of the reasons why Gradle is (supposedly) so much cooler than e.g. Maven
> is that it can be really support and support very fast "incremental" builds
> (only rebuild what has changed).
> I have the impression that doesn't really work in Fineract, and suppose
> that's not really Gradle's (core) fault, but some plugin which screws this
> up? OpenJPA Enhancer, SpotBugs... presumably they all have to "play along"
> for this to work perfectly?
> My Gradle foo isn't (nearly) good enough to know if it would be possible to
> "fix" this, and how hard this may be, but filing an issue is perhaps a start
> for getting input from people more knowledgeable about this.
> [~aleks] and/or [~ptuomola] perhaps you have ideas about this.
> [~aalmiray] as per chat during ApacheCon, not sure if this is the kind of
> thing you may enjoy helping with?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
