Command line argument files

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

Command line argument files

Remko Popma
Would there be any interest in using picocli (
https://github.com/remkop/picocli) as the command line parser in
`org.apache.tools.ant.Main`?

Picocli has support for @-files (https://picocli.info/#AtFiles ) to handle
cases where the length of the command line exceeds the OS limitations. (I
believe there was a recent request for this feature on the user list.)

The Main class will likely become shorter and easier to maintain.

As a bonus, picocli generates nice-looking help with ANSI colors and can
generate completion scripts to get command line completion on bash and zsh
shells.

The trade-off is the additional external dependency.

Picocli is relatively new (1.0 released in Aug 2017) but has growing
adoption and is used in Groovy, Micronaut, JUnit 5 and CheckStyle.

I’d be happy to provide a PR if there’s interest.

Remko Popma
Reply | Threaded
Open this post in threaded view
|

AW: Command line argument files

Jan Matèrne (jhm)
Thank you for your suggestion.
But I think we shouldn’t add a new dependency for replacing code, that works and was touched last time 8 months ago ('just' introducing some Java8 stuff), then 2 years ago (no FileInput/OutputStream::new) then 4 years ago ...

So maintenance is no real point here.

Jan

https://github.com/apache/ant/blame/master/src/main/org/apache/tools/ant/Main.java


> -----Ursprüngliche Nachricht-----
> Von: Remko Popma [mailto:[hidden email]]
> Gesendet: Donnerstag, 15. November 2018 11:14
> An: [hidden email]
> Betreff: Command line argument files
>
> Would there be any interest in using picocli (
> https://github.com/remkop/picocli) as the command line parser in
> `org.apache.tools.ant.Main`?
>
> Picocli has support for @-files (https://picocli.info/#AtFiles ) to
> handle cases where the length of the command line exceeds the OS
> limitations. (I believe there was a recent request for this feature on
> the user list.)
>
> The Main class will likely become shorter and easier to maintain.
>
> As a bonus, picocli generates nice-looking help with ANSI colors and
> can generate completion scripts to get command line completion on bash
> and zsh shells.
>
> The trade-off is the additional external dependency.
>
> Picocli is relatively new (1.0 released in Aug 2017) but has growing
> adoption and is used in Groovy, Micronaut, JUnit 5 and CheckStyle.
>
> I’d be happy to provide a PR if there’s interest.
>
> Remko Popma


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Command line argument files

Remko Popma
Last August there was a feature request on the Ant user mailing list to
support argument files (also called @-files):
https://mail-archives.apache.org/mod_mbox/ant-user/201808.mbox/%3c5D285FC05679A441ACF34A90905BFA923D6C3D54@...%3e

Picocli has support for @-files/argument files (
https://picocli.info/#AtFiles ) to handle cases where the length of the
command line exceeds the OS limitations.

This would allow ant to support command lines of arbitrary length.

The other benefits (less code in the Main class, usage help message with
ANSI colors, and command line autocompletion for the `ant` shell script)
are “nice to have”.


On Fri, Nov 16, 2018 at 4:44 Jan Matèrne (jhm) <[hidden email]> wrote:

> Thank you for your suggestion.
> But I think we shouldn’t add a new dependency for replacing code, that
> works and was touched last time 8 months ago ('just' introducing some Java8
> stuff), then 2 years ago (no FileInput/OutputStream::new) then 4 years ago
> ...
>
> So maintenance is no real point here.
>
> Jan
>
>
> https://github.com/apache/ant/blame/master/src/main/org/apache/tools/ant/Main.java
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Remko Popma [mailto:[hidden email]]
> > Gesendet: Donnerstag, 15. November 2018 11:14
> > An: [hidden email]
> > Betreff: Command line argument files
> >
> > Would there be any interest in using picocli (
> > https://github.com/remkop/picocli) as the command line parser in
> > `org.apache.tools.ant.Main`?
> >
> > Picocli has support for @-files (https://picocli.info/#AtFiles ) to
> > handle cases where the length of the command line exceeds the OS
> > limitations. (I believe there was a recent request for this feature on
> > the user list.)
> >
> > The Main class will likely become shorter and easier to maintain.
> >
> > As a bonus, picocli generates nice-looking help with ANSI colors and
> > can generate completion scripts to get command line completion on bash
> > and zsh shells.
> >
> > The trade-off is the additional external dependency.
> >
> > Picocli is relatively new (1.0 released in Aug 2017) but has growing
> > adoption and is used in Groovy, Micronaut, JUnit 5 and CheckStyle.
> >
> > I’d be happy to provide a PR if there’s interest.
> >
> > Remko Popma
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Command line argument files

Stefan Bodewig
In reply to this post by Remko Popma
Hi Remko

On 2018-11-15, Remko Popma wrote:

> Would there be any interest in using picocli (
> https://github.com/remkop/picocli) as the command line parser in
> `org.apache.tools.ant.Main`?

Ant's core has zero dependencies and we value this property.

> Picocli has support for @-files (https://picocli.info/#AtFiles ) to handle
> cases where the length of the command line exceeds the OS limitations. (I
> believe there was a recent request for this feature on the user list.)

I'm pretty sure Picocli is great.

Personally I wouldn't want to add it just to enable an edge case. Most
people don't have Ant command lines long enough to even make them think
about @-files. -propertyfile helps with the case of many -D options and
then there always is the option to set the ANT_ARGS environment
variable.

It should be possible to provide a Picocli ArgumentProcessor that people
who need additional features can plug into their builds and activate,
though.

Cheers

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Command line argument files

Matt Sicker
FWIW, picocli is small enough to simply shade into your project. We do it
in Log4j with some CLI tooling that’s included.

On Sun, Nov 18, 2018 at 09:19, Stefan Bodewig <[hidden email]> wrote:

> Hi Remko
>
> On 2018-11-15, Remko Popma wrote:
>
> > Would there be any interest in using picocli (
> > https://github.com/remkop/picocli) as the command line parser in
> > `org.apache.tools.ant.Main`?
>
> Ant's core has zero dependencies and we value this property.
>
> > Picocli has support for @-files (https://picocli.info/#AtFiles ) to
> handle
> > cases where the length of the command line exceeds the OS limitations. (I
> > believe there was a recent request for this feature on the user list.)
>
> I'm pretty sure Picocli is great.
>
> Personally I wouldn't want to add it just to enable an edge case. Most
> people don't have Ant command lines long enough to even make them think
> about @-files. -propertyfile helps with the case of many -D options and
> then there always is the option to set the ANT_ARGS environment
> variable.
>
> It should be possible to provide a Picocli ArgumentProcessor that people
> who need additional features can plug into their builds and activate,
> though.
>
> Cheers
>
>         Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Command line argument files

Remko Popma
Stefan, Jan,

Thanks for your response. Understood about avoiding the dependency. As Matt pointed out, there are ways around this - picocli is a single source file for example), but at the end of the day what matters most is how much value this would add.

I thought there was a request for this feature from Ant users but if that’s not the case or there are already alternative solutions then it’s not as good a fit as I imagined.

No worries, all good!
Thanks again for getting back to me!

Remko


> On Nov 19, 2018, at 1:23, Matt Sicker <[hidden email]> wrote:
>
> FWIW, picocli is small enough to simply shade into your project. We do it
> in Log4j with some CLI tooling that’s included.
>
>> On Sun, Nov 18, 2018 at 09:19, Stefan Bodewig <[hidden email]> wrote:
>>
>> Hi Remko
>>
>>> On 2018-11-15, Remko Popma wrote:
>>>
>>> Would there be any interest in using picocli (
>>> https://github.com/remkop/picocli) as the command line parser in
>>> `org.apache.tools.ant.Main`?
>>
>> Ant's core has zero dependencies and we value this property.
>>
>>> Picocli has support for @-files (https://picocli.info/#AtFiles ) to
>> handle
>>> cases where the length of the command line exceeds the OS limitations. (I
>>> believe there was a recent request for this feature on the user list.)
>>
>> I'm pretty sure Picocli is great.
>>
>> Personally I wouldn't want to add it just to enable an edge case. Most
>> people don't have Ant command lines long enough to even make them think
>> about @-files. -propertyfile helps with the case of many -D options and
>> then there always is the option to set the ANT_ARGS environment
>> variable.
>>
>> It should be possible to provide a Picocli ArgumentProcessor that people
>> who need additional features can plug into their builds and activate,
>> though.
>>
>> Cheers
>>
>>        Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>> --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]