For record-keeping,
We've found a way to avoid checking in the wrapper while still
maintaining the ability to use wide range of gradle versions to
initialize the wrapper. This means the PR is no longer redistributing
the JAR or any other gradle wrapper files.
On 2024-05-09 14:53, Norman Breau wrote:
Hi Team,
I just want to highlight some things about the Android 34 PR[4] to
make sure it's reviewed properly.
Namely around the Gradle management changes that the PR introduces. To
summarize, Cordova-android@12 and earlier utilised an empty
wrapper.gradle file to create a wrapper task to install the wrapper of
a given version. The empty wrapper.gradle file allowed gradle to do
it's thing without importing AGP or any other modules that may require
a specific gradle version. This in turn allowed end users to have
pretty much any gradle version installed and we would be able to
install the wrapper at the version that the android project needs.
However this strategy relies on the deprecated/removed -b flag which
allowed you to specify a "build.gradle" file. This means we can't
specify the wrapper.gradle file anymore.
The PR went through several iterations but I'll skip ahead to the
current state.
As recommended by Gradle[1], the PR now includes the wrapper in the
repository, including the .jar file. Cordova-Android tooling no longer
uses the system gradle at all, and exclusively uses this wrapper.
Otherwise the end-user would have to have a system gradle version that
satisfies AGP requirements (currently that is Gradle >= 8.6). There
was some concerns about redistributing this wrapper file and/or binary
files with our releases, so I reviewed Apache Licensing policy[2].
I believe we are in the clear because the policy has instructions for
how to bundle dependencies, and what is acceptable vs not acceptable.
For context, the Gradle build tools is licensed[3] under Apache 2-0.
Under bundling Apache 2-0, the policy states:
"Assuming that the bundled dependency itself contains no bundled
sub-components under other licenses, so the ALv2 applies uniformly to
all files, there is no need to modify LICENSE. However, for
completeness it is useful to list the products and their versions, as
is done for products under other licenses.
If the dependency supplies a NOTICE file, its contents must be
analyzed and the relevant portions bubbled up into the top-level
NOTICE file."
Gradle Wrapper itself doesn't provide any LICENSE or NOTICE files
along, so there isn't anything to bubble up in our NOTICE file.
Therefore the only thing that is recommended (but not required) is to
list the Gradle Wrapper and it's version within our own license file.
Additionally, Apache's instructions has Binary distribution section
which reads as follows:
"What applies to canonical source distributions also applies to all
redistributions, including binary redistributions:
All redistributions must obey the licensing requirements of the contents.
When assembling binary distributions, it is common to pull in and
bundle additional dependencies which are not bundled with the source
distribution. You must account for these additional dependencies in
LICENSE and NOTICE. As a result, the LICENSE and NOTICE files for a
binary distribution may differ from those in the source distribution
it was built from.
In any case, the principle remains the same: LICENSE and NOTICE must
exactly represent the contents of the distribution they reside in."
In otherwords, binary redistristributions are to be handled exactly
the same way as source redistributions.
I just wanted to highlight this detail in case if there are further
concerns that should be addressed before the PR is merged.
Cheers,
[1]
https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:adding_wrapper
[2] https://infra.apache.org/licensing-howto.html#bundle-asf-product
[3] https://docs.gradle.org/current/userguide/licenses.html
[4] https://github.com/apache/cordova-android/pull/1678
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
