incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Farrell <jfarr...@apache.org>
Subject Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
Date Tue, 10 Jun 2014 23:23:29 GMT
Hey Jakob
We did run into this while packaging our first rc in Aurora. There was some
discussion around this on our dev list and we ended up removed the
gradle.jar and gradlew from the source dist and added the wrapper task to
build.gradle so it will always generate the same gradlew that we have
committed in our repo for dev use. We will be creating a binary dist to
accompany our source dist which will include the gradle.jar. This is
similar to how Ant and Maven generate packages for their releases.

-Jake




On Tue, Jun 10, 2014 at 4:18 PM, Jakob Homan <jghoman@gmail.com> wrote:

> We're currently working on the first release for Samza and have run into a
> problem involving the source release and our build system, Gradle.  Both
> DataFu and Aurora use Gradle and will run into this issue as well when they
> do a source release.
>
> Gradle provides a wrapper script, gradlew that allows the end user to run
> all the usual build tools without having gradle itself installed on the
> system.  This script and its required resources are intended to be checked
> [1] to the source control this.  This is contrast to Ant or Maven, which
> require those tools to be pre-installed on the system before executing a
> build against a build.xml or pom.xml, respectively.  However, for the
> gradlew script to work, it downloads the a version of the gradle jar and
> requires that jar to be checked in as well.  Counterintuitively, a project
> using gradlew must be bootstrapped by an install with gradle installed, or
> have the result of that bootstrapping checked into the repo.
>
> The problem lies with the Release Check List [2], which prohibits the
> inclusion of jars in a source release.  Under this rule we effectively
> can't use gradlew as our build system in that we can't distribute it
> (absent some hacky solution like us trying to download the script and jar
> ourselves. We'd obviously prefer to avoid this.)
>
> I'm thinking we should make an exception to this no-jar rule for the
> gradlew jar.  The Gradle project is open source [3], Apache 2 licensed [4]
> and intends for this jar to be included as part of the source of projects
> [1].  Finally, the jar itself contains only Gradle-generated classes with
> no other code fat-jarred [5].  The gradlew wrapper actually makes it easier
> for users to get and play with our code as it removes the need for any
> particular version of Gradle to be availabe beforehand (it also hides much
> of the complexity of the rapidly evolving gradle spec).
>
> Thoughts?
> -Jakob
>
>
> [1] "The wrapper is something you should check into version control."
> http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
> [2] "This package may not contain compiled components (such as "jar" files)
> because compiled components are not open source, even if they were built
> from open source."
> http://incubator.apache.org/guides/releasemanagement.html#check-list
> [3] https://github.com/gradle/gradle
> [4] http://www.gradle.org/license
> [5] https://gist.github.com/jghoman/42f683bd92c3599cdf26
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message