Hi Matt no need to apologize for the delay. I have mixed feelings about re-purposing the "id" attribute to use as the resource name. To me they're different things: I might want to use the id for internal use and therefore want to conform to some kind of naming convention, but I need a different entry name in my zip file. If using the <mappedresources> is the correct solution then we can go with that, but it's really far from obvious; perhaps some additional documentation to the effect of "if using concat as a resource collection then you must use a <mappedresources>", etc.
I was hoping someone would chime in and say "you can't fail fast because", but I haven't seen anything. IMHO, the default (and hard-coded) name is useless, so I can't imagine that changing it to fail fast would affect anyone. However, I can understand with something as complex as Ant, with as much history as it has, that it would be all too easy to make an assumption that "this can't happen" or "that's not useful" that simply proves unfounded. As an alternative to using concat, though I haven't thought through the implications, is allowing file-like resources to accept a <filterchain>? Thanks for your attention. Rich On Tue, Apr 5, 2011 at 9:52 AM, Matt Benson <gudnabr...@gmail.com> wrote: > > 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 > >
