[Bug 60027] New: Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

            Bug ID: 60027
           Summary: Add <arg part1 part 2> options so arg tag can flow
                    over many lines.
           Product: Ant
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Core tasks
          Assignee: notifications@ant.apache.org
          Reporter: george.bateman16@gmail.com

When using the exec task, it is possible to have to create very long (eg. 100
character) arguments if an executable requires that a single argument contains
two paths or multiple commands (eg. the tar --transform and sh -c commands).
This leads to unclear code.

Rewriting this in the form:
<arg part1="--transform=s"
     part2="^build/linux/work/modes/java/reference"
    
part3="build/linux/deb-raw/processing-doc/usr/share/doc/processing-doc/reference:"
     joiner=":" />

(for tar) or "sh -c" with

<arg part1="grep -r --longopt"
     part2="foo --bar"
     part3="find *.exe"
     joiner=";" />

leads to much clearer code. (I suggest the joiner attribute since these very
long arguments often seem to have their own internal delimiters.)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #4 from Matt Benson <mb...@apache.org> ---
Actually Ant does have the capacity to support this (DynamicAttribute,
DynamicAttributeNS), which is not to say that I think this is the best approach
here either. It would seem much more to the point to use the <arg> element's
nested text as an alternative (and mutually exclusive) means to set the
argument's value (probably normalizing series of whitespace to a single space).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #3 from Dominique Devienne <dd...@gmail.com> ---
I agree with Jan, and disagree with George. Even more so since the proposal
wants to  use "open-ended" (meta) attributes. That's a pattern that doesn't
exist in Ant, and the use case is not compelling enough to introduce it. Using
<property> is a good enough work-around IMHO.

PS: Do we simply close "enhancement" requests like this, not even discussed on
the mailing list?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #7 from Jan Mat <ja...@materne.de> ---
An implementation idea I have is this:

<arg part[N]="" joiner=""/>
- joiner defaults to a simple blank
- all attributes starting with "part" are stored in a Map
(index=attribute-name, value=attribute-value)
- setting could (maybe) be done via DynamicAttribute
- a combination of part, value and line is not permitted
- for joining these values we sort the entries alphabetically by index
- the joined value is used as <arg value/>


But what is the usecase?
"Just" splitting a long value into shorter ones?
Are these values hard coded? If not, you could filesets or resourcecollections
and use their values <arg value="${toString:idOfFileset}"/>. Calculation via
<pathconvert> would be possible to.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #2 from George Bateman <ge...@gmail.com> ---
I didn't think that defining loads of properties solves the problem of messy
code. It should be fairly easy to add support for this; I've seen a number of
situations where it would be useful.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #1 from Jan Mat <ja...@materne.de> ---
Lot easier is using properties:

<property name="part1" value="--transform=s"/>
<property name="part2" value="^build/linux/work/modes/java/reference"/>
<property name="part3"
value="build/linux/deb-raw/processing-doc/usr/share/doc/processing-doc/reference:"/>
<exec ...>
  <arg value="${part1}:${part2}:${part3}"/>
</exec>

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #8 from George Bateman <ge...@gmail.com> ---
That implementation looks ideal; one problem with the Map<String,String> though
is the alphabetical sort on the parts. Sorting e.g. parts 1-10 will give the
wrong order. Two alternatives are:
• String array with size set to the number of partN attributes. For each
attribute, run
    partsArray[Integer.parseInt(N) - 1] = value;
  and on catching an ArrayIndexOutOfBounds exception fail the task with the
message "part numbers not consecutive" or "part numbers start at 1".

• Just fill and sort a Map<Integer,String>. This would allow non-consecutive
part numbers, if you want that.

The use case is when a single argument can be subdivided into many logical
parts, and writing them all out joined together is too long to read clearly, as
with complex sed commands, regexes acting on paths or other long texts, and the
sh -c command. As you say, using <fileset>/<pathconvert> instead of hard-coded
values would usually be better when that is appropriate.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #10 from George Bateman <ge...@gmail.com> ---
Okay, I wasn't aware of the niceties surrounding good XML. I understand that
XSD contains an <xs:anyAttribute> tag but that might not be suitable. If you
don't want the partN="" method, then either of the nested text ideas you
suggest sound fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #9 from Dominique Devienne <dd...@gmail.com> ---
FWIW, I strongly dislike the <arg partN="..."> route.

That's a "can't have a schema" approach that's just bad XML IMHO.
<arg><part>...</part><part>...</part>...</arg> or simply <arg> [several lines]
</arg> with a custom "line joiner" (e.g. ignore leading/trailing spaces and
join them with ; in the OP's case) is the "proper" XML way IMHO.

The fact Ant has DynamicAttribute (for a different purpose IMHO) is not reason
enough to abuse Ant's introspection mechanisms.

If you can't write an DTD or XSD for the XML, it's bad XML in my book.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

Jan Mat <ja...@materne.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #11 from Jan Mat <ja...@materne.de> ---
An idea was declined. No further discussion was done since 2016.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #5 from Dominique Devienne <dd...@gmail.com> ---
DynamicAttribute does exist, but do Ant tasks use it for actual attributes the
task itself uses? I've used it for the precursor to
https://ant.apache.org/manual/Tasks/echoxml.html, but beside that use-case, I
don't think it's appropriate here.

PS: I persist that I don't think using BugZilla for discussing an enhancement
like this is the proper venue. This should be on the list instead. And if an
agreement emerges, then an enhancement can be logged. Otherwise the bug DB is
littered with everyone's ideas of how Ant should be, w/o any patches for it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 60027] Add options so arg tag can flow over many lines.

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60027

--- Comment #6 from George Bateman <ge...@gmail.com> ---
Re PS: https://ant.apache.org/bugs.html asks users to use Bugzilla for
enhancement requests. (Section “Asking for an Enhancement”.) Otherwise I would 
have used a mailing list in the normal way.

Matt's suggestion of using nested text in the <arg> element to provide long
values is a good one, but the issue of how to collapse whitespace is a hard
one. How, for example, does the user specify argument values which contain
newlines, and whitespace immediately before and after newlines?

I still don't much like the idea of using properties as proposed by Jan; having
defined variables part1, part2, part3 for the first long argument in a project,
you then need partA1, partA2, partA3, for the next, and so on.

In any case, thank you for discussing the issue and suggesting the various
solutions.

-- 
You are receiving this mail because:
You are the assignee for the bug.