wrapper jar

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

wrapper jar

Szczepan Faber
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


Reply | Threaded
Open this post in threaded view
|

Re: wrapper jar

Justin Ryan
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:

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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: wrapper jar

Hans Dockter-2
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 <[hidden email]> 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:

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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: wrapper jar

Adam Murdoch
In reply to this post by Justin Ryan

On 25 Sep 2014, at 6:01 am, Justin Ryan <[hidden email]> 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:

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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: wrapper jar

Hans Dockter-2
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 <[hidden email]> wrote:

On 25 Sep 2014, at 6:01 am, Justin Ryan <[hidden email]> 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:

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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: wrapper jar

Szczepan Faber
Sure, sorry, old habits die hard.

On Wed, Sep 24, 2014 at 11:55 PM, Hans Dockter
<[hidden email]> 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 <[hidden email]>
> wrote:
>>
>>
>> On 25 Sep 2014, at 6:01 am, Justin Ryan <[hidden email]> 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 <[hidden email]>
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: wrapper jar

Daz DeBoer-2
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 <[hidden email]> wrote:
Sure, sorry, old habits die hard.

On Wed, Sep 24, 2014 at 11:55 PM, Hans Dockter
<[hidden email]> 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 <[hidden email]>
> wrote:
>>
>>
>> On 25 Sep 2014, at 6:01 am, Justin Ryan <[hidden email]> 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 <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: wrapper jar

Hans Dockter-2
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 <[hidden email]> 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 <[hidden email]> wrote:
Sure, sorry, old habits die hard.

On Wed, Sep 24, 2014 at 11:55 PM, Hans Dockter
<[hidden email]> 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 <[hidden email]>
> wrote:
>>
>>
>> On 25 Sep 2014, at 6:01 am, Justin Ryan <[hidden email]> 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 <[hidden email]>
>> 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