I think the only thing we can do is to ask Codehaus for removal. Not sure if this affects in any way the nabble/markmail archives.
I will figure it out. Hans On Wed, Sep 24, 2014 at 3:09 PM, Daz DeBoer <darrell.deb...@gradleware.com> wrote: > Are we able to disable posting to the old list? I don't have any admin > access. > > On Wed, Sep 24, 2014 at 3:59 PM, Szczepan Faber <szcze...@gmail.com> > wrote: > >> Sure, sorry, old habits die hard. >> >> On Wed, Sep 24, 2014 at 11:55 PM, Hans Dockter >> <hans.dock...@gradleware.com> wrote: >> > BTW: I wanted to send someone the link to this discussion and just >> > discovered that we are using the old dev list. Can we have all future >> dev >> > discussions on: https://groups.google.com/forum/#!forum/gradle-dev >> > >> > Hans >> > >> > On Wed, Sep 24, 2014 at 2:01 PM, Adam Murdoch < >> adam.murd...@gradleware.com> >> > wrote: >> >> >> >> >> >> On 25 Sep 2014, at 6:01 am, 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. >> >> >> >> >> >> Absolutely it should. >> >> >> >> Would you be interesting in contributing 'skipper' to Gradle core via a >> >> pull request? We could include it in the Gradle distribution as an >> >> alternative to 'gradle' and then we can merge the two over time, so >> that the >> >> default 'gradle' launcher just did the right thing. >> >> >> >> >> >> >> >> 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 >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Adam Murdoch >> >> Gradle Co-founder >> >> http://www.gradle.org >> >> CTO Gradleware Inc. - Gradle Training, Support, Consulting >> >> http://www.gradleware.com >> >> >> >> >> >> >> > >> >> >> >> -- >> Szczepan Faber >> Core dev@gradle; Founder@mockito >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > -- > Darrell (Daz) DeBoer > http://www.gradleware.com >
