On Fri, Apr 1, 2011 at 6:43 AM, Steele, Richard <r...@steelezone.net> wrote:
> I'm trying to use <concat> as a resource collection in a <zip> and found
> that it doesn't work so well.
>
> First, an example:
>
> <zip destfile="target/dist.zip">
> <concat>
> <fileset file="CHANGES.txt" />
> </concat>
> </zip>
>
> This creates a zip file with multiple entries named "concat (C:", not a
> single entry containing the CHANGES.txt file.
>
> (The reason I'm playing with <concat> as a resource collection for a <zip>:
> I want to include all the files in my distribution verbatim, except the
> CHANGES.txt file I want to do property substitution. Since <concat> allows
> a <filterchain> I thought this would be a good way to do it. The snippet
> above is a stripped-down, simplified example that reproduces the problem.)
>
> I looked at the source for <zip> and <concat> and figured out why: the
> implementation of <concat> (as a ResourceCollection) returns a single,
> hard-coded name for the Resource it contains:
>
> public String getName() {
> return "concat (" + String.valueOf(c) + ")";
> }
>
> I can't imagine such a construction is ever useful.
>
> I was able to work around this issue by using a <mappedresources>:
>
> <zip destfile="target/dist.zip">
> <mappedresources>
> <concat>
> <fileset file="CHANGES.txt" />
> </concat>
> <mergemapper to="CHANGES.txt" />
> </mappedresources>
> </zip>
>
> but this is IMHO clunky and not terribly obvious.
>
> I propose two changes:
>
> 1. Allow the resource name to be specified when <concat> is used as a
> ResourceCollection; e.g., something like
>
> <zip destfile="target/dist.zip">
> <concat name="CHANGES.txt">
> <fileset file="CHANGES.txt" />
> </concat>
> </zip>
>
> It would be helpful if getName() could automatically do this if <concat>
> itself contains a single Resource so it doesn't have to be specified as an
> attribute.
>
> 2. Throw a BuildException if getName() is called and no name is available.
> (In other words, fail fast rather than produce something useless.)
>
> Thoughts?
Hi, Rich. I guess you could say I am one of the primary suspects
where Ant 1.7+ resources are concerned, and to that end I was the
implementor of Concat as a ResourceCollection. I never anticipated
this need, but I understand the lack. I apologize for the delay in
addressing your issue, but I wanted to see if any other member of the
team had any thoughts on the subject. Fortunately another Ant
developer pinged me on the issue to make sure I didn't lose track of
it. ;)
On your suggestions:
* I wonder if it would be sufficient to utilize the Concat task's id
to generate its "resource name." If in some cases this was
insufficient, the mappedresources approach is still available (and was
arguably the true, correct solution all along).
* On the subject of failing fast with a BuildException, I have no
problem with this theoretically; however, it would seem to violate the
backward compatibility principles that we of the Ant project hold
second to none. :) Occasionally we temper the application of this
rule with real-world common sense: i.e. in this case it might be
judged that the status quo is so broken as regards concat.name that
the BuildException could be justified. My personal judgment would
fall here, but I leave it to others to demur.
Regards,
Matt
>
> Rich
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
