This is definitely something we are going to address. We had a long discussion about this with how we want to address this. I think on the dev list.
So the gradle command will eventually respect the wrapper.properties. It is just a question of priorities. The use cases for this are obvious. For example when you are in a subproject and want to trigger a partial build and also a more consistent behavior when you deal with multiple builds (one might have a wrapper the other not). Hans On Wed, Sep 24, 2014 at 1:01 PM, Justin Ryan <quidr...@gmail.com> wrote: > I really like how the tooling api can respect the > gradle/wrapper/gradle-wrapper.properties file, unlike the gradle or gradlew > scripts. I created a project that is essentially wrapping a main method > around the tooling api, it lets me run it from any projects and have it > respect the gradle-wrapper.properties file (which is the minimum someone > would need to check in). I consequently don't need the .jar file or the > shell scripts checked in. The project is here: > > https://github.com/quidryan/skipper > > To make it a little more useful, I do a trick with zip files that lets me > make the zip file executable in unix-y OS's. So, for me, I run this in any > Gradle project: > > skipper clean bulid > > I'm not saying everyone should use skipper, but it would be nice if the > default behavior of gradle shell script did this. > > On Wed, Sep 24, 2014 at 12:27 PM, Szczepan Faber <szcze...@gmail.com> > wrote: > >> Hey guys, >> >> For some scenarios (source releases of apache projects) it is useful >> if Gradle offers provisioning without the need of the wrapper.jar >> (e.g. keep the goodness of the wrapper but without any jar involved). >> For example, check out the discussion in kafka project: >> https://issues.apache.org/jira/browse/KAFKA-1490 >> >> Are there any plans/ideas for having wrapper capability without the jar? >> >> Cheers! >> -- >> Szczepan Faber >> Core dev@gradle; Founder@mockito >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
