Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)

[Konstantin Boudnik <co...@apache.org>]

I want to concur on that. Say, in Bigtop that has Gradle build system, we
aren't checking in the wrappers. Instead they are created in the build time,
and consequently might be added into a binary assembly. 

Cos

On Tue, Jun 10, 2014 at 07:23PM, Jake Farrell wrote:
> 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 <jg...@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
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org